May 302006

I’ve had a design rolling around in the back of my head for a while, involving the Chinese five elements – wood, fire, earth, metal, and water. I’ve always been intrigued by the cyclic interactions of the five elements, and how they could be used as elements in a game. In the generative cycle, wood burns and becomes fire, fire turns into earth (ash), earth generates metal, metal melts and becomes liquid (water), and water creates wood again; in the complementary destructive cycle, metal destroys (chops down) wood, wood consumes earth as it grows, the earth can be used to block the flow of water, water quenches fire, and fire melts metal. The connections can seem a bit strained if you think about them too much, but for the most part, they’re intuitive, and have some nice effects when applied to gameplay – they represent two sets of pre-existing rock-paper-scissors relationships, and each element has a number of correspondences that can be used to add flavor.
Cycles of the Five Chinese Elements
My design was originally intended to be a board game – perhaps using an Icehouse set and a chess board – but after some fiddling around and pondering, I decided that it was more suited to implementation as a puzzle-type game on the computer. I had a free day over the long weekend, so I scribbled out a page or two of notes, and started throwing together something that I could knock out in pyGame or Flash in a few days. I taught an introductory game programming class or two at ACC over the last year, so I have a simple object-oriented framework to build on. After a day or so of refactoring and rejiggering (and a little bit of programmer art), I have a basic prototype that I can start really working with. There’s a splash screen and a startup menu, data and image loading, the game loop, screen rendering, a simple game controller that manages user input and updates the world, all the things that make life grand.

Obviously, this initial version is far from playable, much less fun to play. There’s no real game logic or collision detection or anything implemented yet. However, it is a useful start. From here, I can start dropping in gameplay elements one at a time, to see what works and what doesn’t. The game that I have sketched out has four different states for each element – as an item that can be carried and used by the player, existing passively in the world, active in the game world and affecting the other elements, or “harvested” by the player. Active elements grow and change over time, interacting with other elements in the playing area; the player must use the “item” incarnations of the elements to control and manipulate them. The player also has a certain amount of “Qi” that they may use to activate or alter elements in play, and may be able to be replenished at a shrine somewhere in the level. There will be a few other components to play with, to add a little more complexity as the game progresses, but I’d like to keep things as simple as possible for the first go around.

Wu Xing initial prototpye screenshot

As you can see from the screenshot above, each element has a radius or field of effect – I was originally going to just make this yet another simple tile-based puzzle game, but we’ve already got plenty of those, and I wanted to try something a little different. So, instead of pushing rocks and picking up keys and hitting switches and whatnot, the player has to work with these mushier, more volatile elements. In addition to the cyclical interactions between the elements, each element that exists on the playing field will have additional effects – the player may not be able to cross an area filled with water, for example. These are still in the process of being defined, and I should have a better idea of how they’ll work as the prototype evolves. The goals for each level will be something along the lines of harvesting a certain number of “dead” items from the elements in play, or creating and maintaining a specific balance or ratio of the element for a certain amount of time, among others.

Obviously, there are many directions this design could go. This is the danger of jumping right into an interactive prototype – you can spend a lot of time tweaking and adding shiny bits and making a fun toy to fiddle with, but it’s also easy to lose sight of your design goals for the game, and get lost in the process of building and adjusting things that aren’t central to what you hope to accomplish. I know that this is one of my major weaknesses – I’ll blaze ahead when a design is fresh and exciting, throwing a bunch of things together until I have something that’s just barely amusing, and then lose interest, because I’ve lost focus, and the game is never completed. Fortunately, I’ve developed a few techniques to overcome these blocks… but that’s for next time.