Game Undesign: Designing around limitations
We all have this super cool game we wanna make, like, for example, a sidescroller puzzle platformer with RPG elements and a massively complex loot system. However, making such game may not be a good idea because playability would suck.
This is going to be a rather short post (I am aware I always say that), because the subject itself is not big enough to require a big dissertation. Some people may already know this, but some others don’t so I hope this will at least be useful to some people.
Everything has limitations, either external or self-imposed, and designing games should not be different. Limits can help make a better game, because the resulting game can be good at something instead of bad at many things.
External limitations are those you can’t control. Be it cultural, technological, etc. You can overcome some of them, but not all. For example, you can gain knowledge on programming or certain cultures, but you can’t make a console render Avatar-quality graphics in realtime.
Self-imposed limitations are those decided by yourself when you’re designing a game, and are not related to your knowledge and skill. For example, you can decide to limit how far the camera can see, how fast a character will move, or if she can jump and fight. These are needed so that the game doesn’t pack “everything but the kitchen sink” in it and loses its identity.
A couple of weeks ago I talked about why I think making a “non-combat” horror game is overrated and pretty much a gimmick to explain why it should be terrifying. However, on the same post I also mentioned Enola has no combat. The reason for that is not because “to be truly terrifying, I must make my player character completely defenseless” but rather simply because, as of today, I totally suck at coding a marginally good AI (meaning an AI that will do anything other than walk mindlessly towards the player).
Rather than having my AS (artificial stupidity), I decided to do away with combat related scenarios, and decided to use different kinds of entities that will pose a threat to the player. For example, we have the “shadow men” who will simply walk towards the player, grab her by the head and slap her (and then kill her if she doesn’t escape). They only appear in short, narrow hallways, so players can’t dodge them, and this is where them walking mindlessly towards the player makes sense (if they appeared in an open area, things would surely not work so well).
Since I don’t have combat, I don’t need to worry about “action moves” or weapons, thus I don’t need to use health, and health management. However not using health means my player can potentially not die, so I needed to find other ways to make the game world a dangerous place. My solution: death traps.
There are a few puzzles in Enola that can potentially lead to player’s death. If a puzzle is not solved, or time runs out, they can be shot, crushed, pierced, etc. This is just another way you can increase tension without actually throwing a zombie or a mutant into the game.
In Enola, players can’t jump. Jumping is a basic function in UDK, but I deliberately turned it off (meaning it was a self-imposed limitation), because it would help me control pacing and momentum. Not being able to jump means players can’t “jump off the second floor” or “jump over tables” instead of going around them. Combined with the walking speed, you can get interesting pacing and such. On the other hand, not being able to jump lets you design levels differently because you don’t need to find ways to use the jumping mechanic, and I can kiss the horrible first-person platforming goodbye.
Old Silent Hill games would always use the foggy environment as a way to hide the fact machines could not render “as far as eyes can see.” However, now machines are powerful enough to render a highly detailed jungle and quasi-photorealistic dudes. Long are the days when you would play Silent Hill and say “I can’t see where the hell I am going!” Sometimes technology is a trap (it’s a trap!!!) because you’re too amazed to see what you can do and forget to ask yourself if you should do it (Woah! I can add water in UDK so we could have a water level in Enola!).
Somewhere in the middle of the development, I removed the fog on the Enola island, so you could see every detail on the island from pretty much anywhere (for example you could stand on one side and see the waterfall on the other side, and the house, and the beach…). While that was cool, it took away all the mystery of the place. There’s more to a game than showing off all the shiny (or not so shiny) graphics, so I put the fog back, improving atmosphere a lot.
With a couple of friends, we have a game project for a school where the guys will need to make a sidescroller game, and a couple of days ago we were thinking what would happen if we added puzzles to it, and then we took away jumping, and added other mechanics. Throw in the need to go up and down, without jumping, and the result can be interesting (or can completely suck!). We’ll see how it goes.
Long story short, good or bad, it can be interesting to see what happens when you make the game “you wanna make” but you take into consideration what your limitations are, and what limitations you want to impose. Of course this can only work in some cases (what’s the point of making an action RPG if you take away combat, for example… unless…).