Purity in games design

I've been having an interesting discussion with a friend of mine. We've been talking about aspects of various games in various genres, and I think I've hit upon a realisation about my own preferences (both in games design and in the games I like to play). I could give big lists of what I like and don't like, but there's a common factor in a lot of it, and that's what I call "purity". It's a kind of minimalism in the amount of "things" (be that pieces, skills, actions, objects) presented to the player. Purity, to me, doesn't mean that the game is simple, or shallow, but that the rules and interactions presented to the player seem straighforward and limited at first, but further explanation reveals a lot more complexity.

I'll give some examples: Chess is a fine game, but with a 64-square board, 16 pieces per player (of 6 different types), all of which have different movement rules, and other rules as well (like en passant, promotion, and castling), there's a lot to it. Okay, it's hardly over-the-top game design, but compare it to something like Go, a game played on a 361-place board, with one type of piece each, where the pieces never move. Arguably Go is the more complex and subtle game. A favourite board game of mine is Nine Man's Morris, where each player has 9 pieces, there are 24 places pieces can move to, the rules are not dissimilar to tic-tac-toe, and the result is a fiendishly, brutally beautiful game of pattern recognition and opportunism. In the world of computer games, Lemmings was a masterpiece, requiring you to learn every subtlety of the eight skills available to you to get through the levels. Lemmings 2: The Tribes provided 51 skills, and although it was a fun game, it felt rougher and looser and shallower for all its various skills. By the time you'd learnt what a skill did, there weren't often further levels that surprised or challenged your preconceptions about what it could be used for.

Archer Maclean's Mercury on the PSP was a puzzle game which impressed me greatly (and, as you might imagine, is something we're looking further into with regards to how to construct our own puzzle designs). Its basis is one of those annoying "get the ball-bearing out of the plastic maze" games you get in Christmas stockings, except that the ball-bearing is made from mercury, and there are a few more elements. The mercury can change colour by combining or going through "paintshop" type objects, and certain triggers and switches are colour-coded. Throw in a few physics-based objects like conveyor belts (and a whole pile of design smarts), and you've got yourself 84 levels of really pure puzzle/physics goodness.

I could go on waxing lyrical about games which feature this kind of purity, but from a design point of view it's perhaps more informative to think about where it comes from. There seem to be two main rules here:

1. Introduce a small number of "things" (objects, skills, powers, etc) which are the player's toolset for solving the puzzles in the game (or are the things which provide the barriers which provide the puzzles, in the case of something like colour-coded gates). Ensure that, on the surface, these "things" are easily-understood, and seem at first glance to be quite straightforward and well-defined in their potential uses.
   
2. As the game progresses, find ways to put these "things" into new contexts and combinations, to make players see them in a new light and start to interact with them in ways they hadn't considered before. The joy of "pure" game design is not to surprise the player with a new object, but rather a new way to perceive an object which they'd previously considered familiar and knowable.

The key to this appears to be to imbue an object with properties whose use only becomes apparent in certain situations. For our game, consider the humble and much-maligned videogame cliche of the crate. I don't know if crates will feature in the final game, but they were the first test objects to go into the engine just because they're so simple: A rigid box which obeys the laws of physics. What could we do with a crate?

• Crates can be stacked, to provide a "staircase" to higher points on the level
• They can be used to activate pressure pads
• They can be pushed into an open door which is on a timed mechanism, to stop it closing
• They can block up gaps, to prevent (or inhibit) paint from flowing into certain areas, or to build a makeshift dam
• They can float, providing stepping stones across a treacherous lake of paint
• They displace paint, so dumping crates into a vat could displace enough paint to make it overflow
• They can weigh down one end of a seesaw, or be dropped onto it to catapult an object on the other end.
• They can work their way into large cogs or gears to stop their movement
• They can be shattered under sufficient strain, for situations where a solid-but-not-indestructible object is needed
• They can catch fire, and burn/boil things around them
• They can be thrown/fired at enemies
• They can be used to hide inside, to avoid guards, or to get mailed deep inside the fortress of the Main Bad Guy
  
• They can be deconstructed, and re-nailed together to form a Trojan Horse
• Imagine barrels! Like a crate, but they can roll!
  
• They can contain health and/or ammo ;)

There are probably many more uses for them, and no doubt some of the uses listed above are not applicable to the game we're making. But it serves as a nice example of an object that seems mundane on the surface but which could be used differently in a variety of different contexts and scenarious, hopefully creating some level of joy and surprise in the process. A "pure" game design only needs a few elements like this, working in combination, to provide a lot of different possible puzzles and experiences.

Of course, then it becomes an arms race between the imagination of the game designer and that of the player, to see who is best at thinking up alternative uses for familiar objects, but isn't that part of the fun?

Six Months' Work

Okay, so it doesn't look like much, but (like Transformers) there's more than meets the eye here. Or rather, exactly as much as meets the eye. Click to embiggen (a bit), should you so desire.


This neatly (if unimpressively) shows what's been going on in the Lemon Scented Shed since the video we did in March. It's the same old test level layout, but with a few differences:

• More particles. 10,000 of them, to be precise (compared to the meagre 3,000 in the video). And they're an awful lot more efficient, and an awful lot more stable and less prone to "explode" than they were before. Fluid physics is always a balancing act between looking cool and behaving stably, but there were broken parts of the underlying maths which have now been fixed.
• A sensible framerate. We "fudged" the framerate a bit in the last video - in reality the game was struggling to make 20FPS. Now, with more than 3 times the amount of paint, we rock a steady 30FPS as a minimum.
• Paint-coloured paint. What you're seeing there is a mix of blue and yellow paint, which mixes to make green, which is what you'd expect from a subtractive substance like paint. Previously we were working with a "light based" RGB colour system in which you got yellow by mixing red and green, and if you mixed yellow and blue you got white, which is clearly not intuitive for paint. Now we're using a pixel shader to convert to an RYB colour wheel like they probably taught you in school, and also gave the paint a nice cartoony black outline.
• The beginnings of a GUI system. The "Hello World" in the top left corner shows that the GUI library (Guichan - we tried using CEGUI but it was far too cumbersome and not at all friendly to add to the project) is in and working. The next step is to expand that into a rudimentary level editor so that we can start building interesting toys and combining them into new test levels in order to prototype and "find the fun". We're quite excited about the prospect of doing that part.

This, hopefully, represents the end of the first really difficult stage. Building toys and levels and gameplay is something which should happen a lot more quickly, relatively speaking, so this should start actually looking like a game (albeit one with horrible programmer art for a while) before too long. Exciting times!