Design Retrospective

One of the things I decided very early on in the project, was that this would be a game where a player could theoretically be so skillful that they would never take damage. I have played too many first person shooters with hit-scan enemy weapons to enjoy that shallow gameplay anymore. That design decision was absolutely the right one, and would almost guarantee that, barring me screwing up somewhere else, the game would have that pattern recognition and movement tactics that I was going for.

But the game was quite flawed back when it was just the circular turret going round and round. It was way too easy to simply hug the outside of the arena, and go around in circles opposite the sniper, and it would never hit you. This is a technique that is simply an exploit, and so the game needed to be fixed. The game was also so simple it would not hold anyone’s attention for very long at all. I’m a strong believer in simplicity in games, but this was ridiculous. With those two things in mind I started planning how to come up with multiple enemy types that would be fun to play against.

(First recorded playing of the game, this from about one month in. Already has healthpacks and hunters and burnspots added to it. Also has the players health draining constantly, forcing them to pick up the healthpacks, something that I somewhat regret removing from the final project):

CHARACTERS

The problem is that I didn’t give the same level of detail to fully understanding how the new enemies would force the player to play, as I did to trying to have cool enemies. For example: I wanted a sniper enemy that would charge up, and then do a blast of unavoidable damage to the player. I knew that I could theoretically make this fit with having all damage be avoidable, but it was quite difficult to fully realize. I came up with four different solutions.
1) Have the enemies flee when the player gets too close, and start their charging from level one.
2) Spread walls around the arena that block sniper fire, forcing the player to manoeuvre behind on of these walls at the right time.
3) Give the player a shield
4) Give the player a weapon that they can use to kill the snipers quickly.

And the problems with those solutions were:
1) This is incomplete, since the snipers would have to be given very long charging times, and have very few of them, in order for the player to realistically have a chance of getting within a radius close enough to interrupt them.
2) This was easily the best solution, and in fact, will be implemented in my next game. The problem is that it increases coding complexity enourmously. If we have walls, then we need everything to go around those walls, which means everything that moves now needs more complicated pathfinding. That sounds like kind of a fun and educational problem to work on, but collision resolution was always buggy for me, and this added a lot of potential collisions. Since the game was so obviously abstract, I could very well have just added the walls, and let everything move through them, except sniper fire. That’s not a bad solution, and is one I probably will test for my next game, but it was visually confusing as it was.
3) Again, if we give the player a shield it’s very unnatural that it will only block one thing. It makes the game less satisfying feel wise. I did all the work, and created a shield, only to find that it just wasn’t any fun to play with, since it made the user able to “get out of jail free” so to speak if they took a lot of damage from something. It also made the levels way harder to design.
4) I genuinely thought this was where the game was heading, and so I gave the player a sword that the could stab out with. Like solution 2, this is something that I will be putting in my next game, not necessarily a sword or melee weapon, but that I didn’t want to put in this game. The sword lead to bad gameplay, where the first few seconds would be scurrying around picking up things, trying to survive, but once the enemies had been destroyed there was nothing of interest left to do except go back and forth from the objects to the base, which is incredibly dull. Additionally, the snipes could still hit the player easily, since without walls there was a very low chance of the player being able to kill all the snipers before they hit the player at least once.

This pattern of thinking continued for all the other enemy types. I thought it would be cool to have bombs that wondered around the arena and exploded when the player got close, and that’s not too bad as an idea, but it took a lot of work to properly signal the bombs state to the player, and the bombs themselves were never exactly thrilling, just wandering around. I created burnspots on the ground, which were squares that appeared in semi-random locations and then burned the player after a brief warning, but again, they were too unfocused to be fun. Additionally, getting hit with a burnspot felt unlucky and a bit unfair, even though they didn’t burn immediately to give the player a chance.

It’s not as if all these enemies, the snipers, hunters, bombs, burnspots, and sprinkler (a turret that just spins around shooting forward), were necessarily bad ideas, they were just ideas that weren’t specific enough. For my next game I have realized how essential it is to design all the enemies in detail, before or with planning the rest of the game.

(At times all these enemies lead to the game being a broken mess. This was half programming problems and half design problems)

MODES

I was planning on having the game be a series of “rooms”, where in each room you had to kill all the enemies. Basically all the means is that you had a time limit, and then needed to kill all the enemies, without dying of course, in that time limit. Once you did, then the next “room” or “level” would start and new enemies would spawn, etcetera. That’s not actually a terrible idea for a game, but it was never particularly fun. It suffers from the problem that the game starts off awesome with lots of things to dodge, but then gets less and less interesting as more enemies are killed off. This is quite a serious problem, and I’ve been trying to understand how to negate it, since it affects almost every first person shooter game I play. I’ve been thinking that keeping combat short, or having only certain enemies killable might do the trick. It’s a very important problem though.

Anyway, the point was that I decided to go non-combat. Helping this decision was that I had made a bunch of tutorials about a month before this decision. There was one for movement and one for attacking. I decided that tutorials by themselves are kind of boring so I created two mini-games that the player could play that were simple, but hopefully engaging. The first was for attacking, and the player had to rush to one of three randomly spawned objects and destroy it with his sword before the time ran out. It was fine for a tutorial game. The other, was essentially the seed for what the game would actually become. I called it capture the flag, although it’s only one sided.

What I realized while playing CTF, was that it was simply more fun than the game I was making. In addition to this, I had promised myself that the game would be done before 2015, and it was early December at this point, so this offered me a very good chance at making that goal. In fact, I consider it quite likely that, had I immediately removed all other enemies, I would have easily finished the game by Jan 1st, and possibly even Christmas. Instead, I tried to shove all the enemies from the, then main, game into the CTF game. The snipers were quickly disposed of, since it was quite obvious that they weren’t working out. The Sprinkler, which is the turret that just rotates around in the center shown in some previous videos, was added to the game only to be thrown out later when I realized that it felt like randomness when it hurt the player. The Hunters were also carried over into the CTF game, even though they had quite some work to be done to make them functional, as they weren’t really up to snuff in the main game. Eventually, like the Sprinkler, the Hunters I decided were just not all that much fun to play with, and they eventually got removed. This was a shame, as they were quite fun to play with on their own, but didn’t really add that much to the main game, and made the levels harder for me to design.

(Early version of the then named “capture the object game”. This when it was still a tutorial.)

LEVEL DESIGN

When the game started, there was no level, just one arena that had the same three hunters chasing the player, and that circular turret going round and round. As the game got more complex, I decided that it needed to have different scenarios, or levels. Differing numbers of enemies and different placements of the turrets for each room would spice things up. I had dreams of a campaign that I could create, and started creating text files that would be loaded in for each room. More on that in the programming post. When I abandoned the “kill all enemies” type game for the “Capture the Flag” type game that I ended up with, I realized that I needed to get serious about level, or scenario design.

Each game, or screen, or level, or scenario, whichever you would like to call it, in Monochrome consists of four things that can differ: The amount of turrets, the placement of the turrets, the amount of flags, or objects there are to pick up, and the time given to pick them up in. There is also a base, which never changes position.Those four things were all I had to play with.

Level design should provide opportunities for the game mechanics to shine strongly. Monochrome shines strongest, or is the most fun, when there are lots of gaps between bolts the the player can maneuver through. My original turret placements were too close together, which made it less bad to go around the turrets, and harder to go through them. Later, I figured that if I stuck turrets as close to the edge of the screen as possible, left and right, it would essentially make it impossible to not have any slick bolt maneuvering opportunities.

However, I still had a problem where players would quickly figure out that the most optimized way to play the game was to stay on the outside, which is terrible because the game is less fun that way. I’m a strong believer that the game should reward most the play which is the most fun. For Monochrome, that meant rewarding nimbly negotiating gaps between bolts, and punishing players for sticking to the outside and only ever coming in to pick up the objects. To that end, I gave the player rechargeable health, which minimized mistakes made earlier by making them go away. I also decreased the time available to pick up all the objects, which, when set properly, strongly minimizes the amount of time the player can spend taking inefficient paths, which is shorthand for staying to the outside.

(I made the time limit much higher and so the player can do this. Extremely boring.)

CONCLUSION

It’s both interesting and saddening that the game ended so similar to how it began. When the game first started there was just a sniper going counter clockwise around, which is sort of like a mounted turret, and some hunters that chased the player around. There was nothing to do but survive for 60 seconds, after which time the game immediately ended. It didn’t just end so much as entirely close the program, but still, that was the whole game. A huge number of things were added to the game, and an equal number of things were stripped out so as to have the game finished. In the end, all that remains are the turrets, even the hunters are gone.

This entry was posted in Game Design, Monochrome and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s