Three Stegosaurus Moon

I’m learning a lot about game design as a result of my endeavors into the field. When I began to create this game I’m working on, it wasn’t at all about what the design would ultimately be, it was more just a practice with object-oriented programming using graphics and keyboard controls, just because they were two things that I thought I could easily use to make a playground for myself to create sprites and animate them, learning the ideas of OOP in the process. In that sense, this project has been a complete success. I know objects very well now, as a result of using a nested class structure for every game entity. I also have come to understand privilege and how it can be used effectively, as well as making the appropriate variables global and nonglobal. That’s all great, but what I’m realizing now is that in addition to all of that new coding knowledge, I’m also coming away with a better understanding of what makes an effective game design.

One of the most important steps for me in this regard has been the playtesting that my friends and family have done during various stages of the development. I spent quite a while building the engine from the ground up, which was where I got my OOP practice, and which was what I originally thought would be the main bulk of the work. When the engine was finished (or nearly finished), though, and I started having people playtest it and give me their feedback, I started noticing a lot of commonalities between how the players reacted to certain game aspects. For example, every time people would play one version of it, one of their comments afterward would be something like “I lost really quickly because I was concentrating on dodging the asteroids.” This was interesting, because the asteroids were in fact part of the background image and not part of the gameplay mechanic at all, yet since people saw them flying by in the same direction and at a similar speed as the enemy projectiles, they assumed that they had to dodge them. This brought up the intersting issue of visual design – namely, how can I make an interesting setting for this game without making it detract from or confuse the player’s experience.

In more general terms, how can I make it immediately obvious what a game element’s function is? A powerup that gives the player more health should indicate that by how it looks. Something that makes sense in the context of the story (they’re little medical kits in Half-Life 2, for example) or even a simple heart. Something that stands out and is obviously condusive to the player winning the game. Similarly, an enemy should look menacing to some degree, whether it’s the goombas in Mario that have little frowns and are conveniently at foot-stomping level, or the alien swarm guys in Gears of War who look like big angry gray tanks who clearly want to murder you. If there’s something you need to avoid, like enemies or projectiles, it should be really easy to see and to avoid. The lasers the enemies shoot in Metroid Prime are all brightly colored and very clearly come from an unpleasant source. Ikaruga is another great example of this, where the game mechanic is mostly based on the avoidance of enemy projectiles; in that game, they’re all very well-lit and colored, to make it exceedingly obvious where the player needs to be. That’s not to say that it’s easy to avoid the projectiles, but it does mean that there is a correlation that the player can pick up on between being close to a projectile and losing a life. There are no surprises. Backgrounds and settings shouldn’t distract, but should only serve their purpose as a stage-setter; in a well designed game, the player never has to wonder what any aspect of the game does: it’s all so obvious.

Another thing I’ve come across is the need for well-thought-out gradation of difficulty. This can be restated by saying the the played needs to feel at once challenged and successful at all times in order to keep enjoying the game. Noone wants to play a game where you die on the very first level every time; nor does anyone play games in which you make it to the end having hardly put forth any effort at all. The player’s mental state during play is important for the designer to take into consideration, as it’s ultimately the deciding factor that controls whether they go tell their friends that your game is ‘fun’. A player needs to be given rewards; there needs to be a sense that progress is being made. Levels up, points, weapon upgrades, and powerups all aim toward this end. I don’t think it’s important exactly which of these elements are used; rather, only that they are used to synthesize an overall experience of challenge and reward. A well-developed difficulty curve can compliment this; for example, you don’t want to introduce a new challenge or mode of playing in a situation in which it’s impossible to learn.

A great instance of this is the Zelda games, in which a lot of the excitement comes from collecting new items and weapons. A trick that’s commonly used in these games is to put the item in a room that’s impossible to leave without the use of the new item – to leave the slingshot room in Ocarina, the player uses the slingshot to shoot down a ladder that leads to the door. Clever. It’s a semitransparent method of easing the player into the correct control of the new game mechanic, without having it seem completely like a tutorial stage. It’s my opinion that this method is a better design principle to follow than actually including an almost nondiegetic tutorial stage – it keeps the player fully embedded in the game world.

These are just some thoughts that have occurred to me over the course of my work with designing a game. It’s a great learning experience to make a game from the ground up, both in programming and design. I’ll talk more about this at a later date. For now, go play your favorite video game.