Potential Blog

There have been no posts for a while, as I have retreated to my cave of solitude to contemplate game design.

I’ve found game design to be more mentally exhausting than software development. When building software, my mental process is all about separation and isolation of responsibility and functionality. The computer science terminology is high cohesion with the pieces loosely coupled.

Since my mind is wired this way, I naturally apply the same process to game design. That is, I try to break down the overall gameplay into small, independent components. However, I’m starting to wonder if this is not entirely appropriate.

A game can be divided into sub-systems (characters, items, combat, etc.). Certainly they all play off one another, but I’m finding that I cannot design these systems with any degree of isolation. For example, weapons cannot be designed without considering the direct impact on both characters and combat.

Consequently, delving into game design requires a great deal of focus. The entire game system must be continually reviewed from top-to-bottom, while refining each sub-system. This explains why game design is so mentally exhausting.

From my software design background, I’ve become adept at breaking down large problems (this project, for example). With more experience, I expect to discover more mentally efficient game design techniques.

For now, I am left with these questions to ponder:

• Is game design a fully artistic process; something that cannot be engineered?
• What type of process do other game designers follow?
• In larger game studios, how is game design managed as part of the overall development process?
• When will my game actually be fun to play?

I don’t yet have as defined a game design process as my software process, but I’ve evolved a simple methodology for recording and refining my game design ideas. The technology needed is a pen, a journal, and a wiki. The process involves three activities:

For one, I write down (with the pen, in the journal) every random gameplay thought, with little regard for feasibility or conformity to the rest of the design. From my technical background, I tend to auto-cull things that would be impossible to implement. From my board game background, I tend to prefer strategic mechanics, rather than fuzzy “wouldn’t it be cool if” concepts.

The second activity also involves a pen and a journal (I use the same one from above). The goal is to refine the random thoughts into coherent game mechanics. Terminology like “attributes” and “weapons” and their interactions must be defined. The goal is to draft and refine the game systems.

The final activity, which I had underestimated, is concisely documenting the final game design. This phase forces decisions, exposing gaps and conflicts. If you can’t play the game in your head from these designs, and design the software, then there is something missing. I’ve found that a wiki provides the best balance between formality and flexibility.

All of these activities happen more or less at the same time. This is not a sophisticated requirements tracking system, and document versioning would be needed to coordinate design and software teams, but this works for my team of one.

Overall, this methodology seems rather obvious, but it’s important to be aware of the process, and write it down. Unless something is well documented, it cannot be well understood.

After making some progress implementing new game features, I found myself leafing through my design journals to extrapolate the final design decisions. To solidify the ideas, I’ve spent a few days codifying the design in a wiki (DokuWiki with Dokubook template). Now I have a more rigorously defined design. There are still gaps (the 20% of the unfinished design mentioned earlier), but they are more clearly exposed, so I can code around them.

The most fundamental design change is to the character attributes. From a gameplay standpoint, the character system should feel more “classic.” Simply put, raise your attributes to become better at things. Strategic decision involves which attributes to raise, and what equipment best compliments them. From a technical standpoint, this affects many of the core content objects (characters, creatures, and items).

The new attributes have been implemented, but not integrated with any logic that uses them. As soon as I can, I will release a new client, so Alpha playtesters can at least see the character changes.