My goals were far from achieved, but as with all worthy failures, I think I learned a ton more than I would have had I succeeded (and done the smart things. :P)
As a designer, I always have all sorts of off-the-wall ideas of crazy insane things that I've never seen and just wonder if they will work. While I think this creative curiosity is healthy for anyone who wants to be a game designer, it's dangerous for someone who wants to WORK as a game designer. Ideas are cheap, and worthless. That may sound harsh to many, but I guarantee to you that any game designer, working or otherwise, has hundreds of ideas just floating around. I guarantee that any professional game has an army of people behind it with a backlog longer than you can imagine. Ideas are great, but implementation is what separates the dreamers from the doers. With this in mind I made a decision fairly early on that I was going to make a platformer game.
The purpose of this was to force myself into an environment of focusing on implementation and prevent myself from getting too experimental I think it was a wise decision, but i think my handling of it crashed and burned. If you've ever done any looking at game maker, you've seen that there are hundreds of "engines" out there for all sorts of game types, and platformers is the most common. People have, essentially, mastered the systems underneath platforming games. This is a good thing, it allows for people interested in play, mechanics, and design to get involved without spending too much time digging around in things like coding collision or figuring out how to work with gravity.
It's also something that I, very stupidly, decided not to take advantage of. I'm not sure if I was thinking "oh, it'll be easy" or if I was just getting a kick out of the coding aspect, but I decided that I was going to code my own engine. I don't regret this, as I learned a ton about coding and how the Game Maker Language works. But, I definitely feel like it was a bad idea from the perspective of operating on a limited time frame and my desire to try and focus on the design aspects. I ended up spending more evenings trying to refine player collision versus spending my time trying to figure out how to make interesting situations/obstacles for the player to deal with. I basically spent the month as a coder with designer on the back burner.
I did learn some very valuable lessons as a designer though. First, and most obvious in retrospect, is to avoid duplicating work. Doubly so if it's something you don't fully understand or aren't highly experienced at. Had I taken one of those platformer engines and focused on just building the player epxerience within that engine, I think I would have come out with a much more desireable product in the end.
Anyways, on to more designery topics. Easing into complexity was a big thing I struggled with in this month's project. I think there's a certain appeal to the fantasy of "everything is normal and BOOM SHIT GOES NUTS!" but in practice that's a lot more difficult than it sounds. I started this project throwing in all sorts of obstacles and abilities right off the bat. Partly because I wanted to test them out, and partly because when most of use think of games, we think of them as completed pictures versus a lot of tiny pieces. It's important to make it clear to your player what they are supposed to be doing. When I dropped my player into a room with guns shooting, enemies jumping at them, and pitfalls of death, it became instantly clear that this was too much too fast.
After changing to a more smooth introduction, the game felt a lot better. Let's look at my first room. (I know, my collision blocks are an eyesore)
Starting the player in a position where you have one tiny block standing in your way, it's easy to come to the conclusion of "i should hop over that". And you just tought your player something valuable. Next I gave a jump two blocks high, "OK, I can jump that high. check".
The next jump worked out pretty well. You can make the jump from two different positions. I wanted a few buddies try this jump out and saw a lot of interesting responses. Most people tried the jump from Point A first. Where it got interesting is when people failed. Some tried to jump against the 3-high wall a few times, few decided to try from point B (which is easy), but most immediately rushed back to point A to try again. They become, almost instantly, fixated on this one minor goal, that they completely ignored that there was a much easier way right there. They failed at least 3 times before looking for point B. The ones who stuck it out would eventually get it though. I expected them to stop once they got it and pause for a second or say something, but none did. This makes me question the concept that we need to shower our players in rewards to get them to do anything.
I had a few ask me if it was possible to make it. I found this really interesting. Specifically when the people asked me if jump A was possible. I think being a video game, when presented with a jump like that, most people naturally assume that a game would not give them an impossible task. I noticed the people going for jump A were a bit more active gamers while the people who went for B were the more casual camp. I suppose games have trained group A that they should seek out the greater perceived challenge even with a lack of any form of reward? I'm not sure, but i found it interesting.
From there, the level forces you to back track to get the disc to open the blue door, then to do this again. What I liked here is that the A group, upon seeing it a second time, seemed to lose all determination to get the jump. They've done it once, so they knew it was possible, and that they could do it, but it wasn't until the second time through it that they realized there's an easier jump there, and they kind of had a "damnit, whatever" moment and went for jump B.
Anyways, I've talked too much about a single jump. :P
The second room I introduced hazards Originally I just had a "ramp" (I never got the character running up a ramp to work, which is already coded in tons of platformer engines... grrrr) where green balls of slime drop from the blue circle and roll downhill. Simple enough, just jump over the green things. But I found that some people didn't immediately realize that they were hazards I was a bit surprised here honestly, assumed knowledge would lead me to believe that stuff rolling at you would be bad. But it (apparently) wasn't readable. So I added a second "slime dropper" thing a bit earlier that just dropped slime from the ceiling. People immediately recognized this one, nobody got hit by the falling slime. This could be a question of graphic fidelity, if they were spikes would people have let the rolling slimes hit them?
With this set up, I was able to more clearly communicate the slimes as bad. Then giving the player a bit of a corner to jump out of stalled the player long enough for them to see slimes rolling down the ramp as well. After adding this nobody had any question as to what was going on.
BAH! This is no good, I fear that going through this thing room by room is going to make this blog post way too long. While I would like to talk about the next room introducing projectiles and teaching a player how to use duck, but I fear this is getting lengthy already, and that I need to wrap this up.
Conclusion
Overall, this is a huge failure as a game. But it was a huge learning opportunity for me as a designer. I've learned a lot of things that I will never repeat. And obtained some interesting perspective on level design and player behavior. I think that I may revisit this one after the year concludes, as I really enjoy the idea of a platformer and trying to make that interesting. I've got some concepts for an aesthetic and some further room puzzles and stuff that I'd love to try out. But when operating on such tight time tables, I fear I just went *WAY* out of scope here.
Anyways, on to more designery topics. Easing into complexity was a big thing I struggled with in this month's project. I think there's a certain appeal to the fantasy of "everything is normal and BOOM SHIT GOES NUTS!" but in practice that's a lot more difficult than it sounds. I started this project throwing in all sorts of obstacles and abilities right off the bat. Partly because I wanted to test them out, and partly because when most of use think of games, we think of them as completed pictures versus a lot of tiny pieces. It's important to make it clear to your player what they are supposed to be doing. When I dropped my player into a room with guns shooting, enemies jumping at them, and pitfalls of death, it became instantly clear that this was too much too fast.
After changing to a more smooth introduction, the game felt a lot better. Let's look at my first room. (I know, my collision blocks are an eyesore)
I had a few ask me if it was possible to make it. I found this really interesting. Specifically when the people asked me if jump A was possible. I think being a video game, when presented with a jump like that, most people naturally assume that a game would not give them an impossible task. I noticed the people going for jump A were a bit more active gamers while the people who went for B were the more casual camp. I suppose games have trained group A that they should seek out the greater perceived challenge even with a lack of any form of reward? I'm not sure, but i found it interesting.
From there, the level forces you to back track to get the disc to open the blue door, then to do this again. What I liked here is that the A group, upon seeing it a second time, seemed to lose all determination to get the jump. They've done it once, so they knew it was possible, and that they could do it, but it wasn't until the second time through it that they realized there's an easier jump there, and they kind of had a "damnit, whatever" moment and went for jump B.
Anyways, I've talked too much about a single jump. :P
The second room I introduced hazards Originally I just had a "ramp" (I never got the character running up a ramp to work, which is already coded in tons of platformer engines... grrrr) where green balls of slime drop from the blue circle and roll downhill. Simple enough, just jump over the green things. But I found that some people didn't immediately realize that they were hazards I was a bit surprised here honestly, assumed knowledge would lead me to believe that stuff rolling at you would be bad. But it (apparently) wasn't readable. So I added a second "slime dropper" thing a bit earlier that just dropped slime from the ceiling. People immediately recognized this one, nobody got hit by the falling slime. This could be a question of graphic fidelity, if they were spikes would people have let the rolling slimes hit them?
With this set up, I was able to more clearly communicate the slimes as bad. Then giving the player a bit of a corner to jump out of stalled the player long enough for them to see slimes rolling down the ramp as well. After adding this nobody had any question as to what was going on.
BAH! This is no good, I fear that going through this thing room by room is going to make this blog post way too long. While I would like to talk about the next room introducing projectiles and teaching a player how to use duck, but I fear this is getting lengthy already, and that I need to wrap this up.
Conclusion
Overall, this is a huge failure as a game. But it was a huge learning opportunity for me as a designer. I've learned a lot of things that I will never repeat. And obtained some interesting perspective on level design and player behavior. I think that I may revisit this one after the year concludes, as I really enjoy the idea of a platformer and trying to make that interesting. I've got some concepts for an aesthetic and some further room puzzles and stuff that I'd love to try out. But when operating on such tight time tables, I fear I just went *WAY* out of scope here.
Posts
