Tactics for Game Design Part 4

Concept Art by Kevin Anderson

Game Design is similar to the design process of building a car. There are many systems to be developed and many stages of development. Taking this analogy further, cars have a body shell, primary parts, like the engine, fuel system, brake system, and electrical system, not to mention the interior, tires, stereo, paint, safety features ... You get the idea. The car we drive every day takes thousands of people coordinating for years to design, develop, and manufacture a product that does all these things, hopefully well. Of course, these systems need to be designed before the engineers can develop anything or manufacturing can meet specifications for functionality and quality.

The previous game blogs talk a lot about things to think about, plan, and avoid when game developing. Ultimately, the end result is what counts, and meeting those consumer expectations are what planning and product management does. 

With all that, let's take a quick tour of developing a real-time strategy game.  Real-time strategy games are huge projects that work on many levels. Units move around in tactical combat, there are often highly visual combat systems that give players an exciting spectacle in every battle, and there are various light RPG elements woven into the unit development, technology, and maybe even a risk-like metagame in which multiple missions count for something. In addition, the combat missions may have cut-scenes, and there may be skirmish and multiplayer modes to top all of that off. You can get tired just reading about all the features!

Design Treatment: Genre and Major Product Features 

Understanding the genre and picking out what areas are "gold standards" are essential in game pre-production. For example, developing a Porsche-killer is very different than a Toyota Sienna minivan-killer. Taking on Starcraft 2 toe-to-toe is probably not a great idea for a small indie group. However, doing a subset of the Starcraft feature set can be a clever target for the aspiring indie. You can decide to make a variation of one of the many popular arcade games like Marine Arena or Nexus Wars.  

Design Document: Game Systems

Like blueprints and specifications for a car, we should provide a road map for the development team to follow. In game development it is hard, if not impossible, to really describe the fun in document form without playing the game; therefore, we target 80% of the features of the game ... and, of course, the document should be updated to reflect the numerous changes along the way. 

Here are a list of game elements and game systems to design for a typical RTS:

• Units, Buildings, and Weapons
  • Detailed Stats, Including Leveling
  • Descriptions of All Units
  • Effects of All Units
• Technology and Unit Development Chart
  • Detailed Stats
• Story and Characters
• Major Features: Reward System, Character Development System, Inventory System, AI System, etc.
• Game Play Modes: Campaign, Scenarios, Multiplayer, Mods, etc.
• Map, Mission, and Scenario Details
• Target Platform(s), Performance, and Languages
  • For PC = OS, RAM, CPU, Direct X Support, Controller Support, etc.
• Setting Options: Keymap, Video Resolution and Effects, Input Options, Sound
• Narration and Overlay Text
• General Art Direction
• General Sound Direction

And so on. The goal of the design doc is to lead the team in the right direction. It is not a specification doc, typically, but it could be. Usually, the art lead will take this doc and develop the art bible, and the programming lead will take this design doc and develop a technical spec or technical design doc.

Typically, the design treatment and design doc are developed during the pre-production phase and in parallel with developing game play prototypes, locking down the technology, concept art, and recruiting/training the team. 

For Infinium Run, we followed this pre-production design model, and it has been mostly successful. We rooted out a lot of features early on because of the analyses we did on the marketplace, competition, feature, fun factor, and work needed to complete with a small team. Having said that, it is usually best to balance the written word with working prototypes and lots of testing with consumers and the team. We've had 2 prototypes, and we learned a ton from them, but we probably could have used twice as many! 

Next Blog: RPG Development 

Twitter @Dex_CodexWorlds

Questions? More Info?

Send me an email at dexterc@codexworlds.com