Wednesday, July 6, 2005

Space Crack: Starting the game and ending the game

This is part 10 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we talked about the use of stub mechanics and how they can be used to create a simple combat system. This time we'll apply some additional stub mechanics and learn an important lesson about iterative game design.
Starting the game and ending the game
We are almost done with the basic of the game. I've been designing the game from the middle out by dealing with all the standard midgame elements such as combat, production, etc. There are two elements on the outer edges of the experience left:
  • Starting the game
  • Ending the game
A note on process
Once these two systems are finished, we'll have described all the initial systems needed to play a simple game of Space Crack. This is when the real fun begins. Everything so far has been game design 101. The result is a passable, but by no means memorable strategy game. Once we have a prototype up and running, I can start adding some lovely meta-game mechanics to our plain-jane core. It is at this point that Space Crack will rapidly evolve into more than just your typical war game.

My goal at in this post is to define quick and dirty stub mechanics for both the start and the end game. The sooner we can get to a prototype, the better.

Starting the game: A stub mechanic
The start of the game demands a large amount of design. This is the first experience the player has with the game and poor design can ruin the entire experience before they even start to play. For now, IÂ’m going to create a simple stub mechanic, but be assured that we will revisit this topic in the future.

All games start at a webpage on The player is presented with a friendly screen that asks them to invite their friends to a quick game of Space Crack. There are three UI elements
  • Emails: A list box where the game initiator can type in email addresses
  • Play Time: A time and date gadget for selecting the time at which they will play.
  • Submit: A submit button that sends the start game request to the central server.
Once the game request is submitted, all players get an email telling them the time to play and the rules of the game. The email contains a unique URL to their particular game.
  • If the link is clicked before the start time, a clock appears showing the time counting down until the match begins. When the time reaches zero, the game begins.
  • If the link is clicked after the game is started, the player is added to the middle of the game and their map displays the current status of the game world.
All email addresses and game sessions are also captured in a database for future reference.

Starting the game: What is missing
We are naturally missing a lot of elements. I'll record these in a quick list for future notice. One of the distinct 'dangers' of a stub mechanic is that you forget it is just a temporary fix. When we are play testing later, this list can help jog our memory.
  • Instant start for players with no friends
  • Help screens
  • Favorites list of frequent players.
  • A strict privacy policy
  • Ability for players to name their character or have a persistent log-in
  • Email verification system to ensure a clean database
  • Game type options
Finishing the game: A stub mechanic
Finishing the game also deserves its own section. The end of a multi-player game is where most of the player's decisive impressions of the game are formed. A big goal of the design is to have people play again. If the end game is boring or the reward system at the end punishes players too strongly, the result is often the dreaded phrase,"Well, that was great, but let's play Counter Strike next time."

Our stub mechanic for "winning the game" is rather straight forward. The first player to capture all the planets wins. It is one of the worst winning conditions available, but will work for early prototyping.

When the winning condition is met a message is sent to all players:
"Player X has conquered the galaxy. Well fought! Do you wish to challenge the same group of players to a rematch?"

Clicking yes, sends you to the start game screen with all current emails filled in. You are only allowed to start one game with the same group of people in a 24 hour period. This prevents everyone clicking "yes!" at once.

Finishing the game: What is missing
We are naturally missing a lot of elements. A quick list includes
  • Mechanics that ensure an exciting end-game.
  • Reward mechanisms that incent players to play again.
  • User feedback mechanisms, full game instrumentation and logging.
The Ultimate Game Design: A deadly game design sin
At this point, some of you are likely asking "Who is this lazy game designer?" On the surface, I've intentionally designed a game that has gaping flaws. In reality, I've rushed towards a design that can be prototyped. And with good reason.

As game designers, the foundational game mechanics can be the least exciting part of a game. The real fun begins when you start imagining what you can do with all these basic systems. My notebook is filled with feverish schemes that add layer upon layer to the original concept, buildinmonstrosityl monstronsity called The Ultimate Game Design. Stellar mechanics, physics, fusion weapons, special encounters, crazy plot twists! Just thinking about it gives me shivers of pure intellectual pleasure. Or something like that.

The natural problem with the Ultimate Game is that it requires infinite resources to create version 1.0. When I hear stories about a game that took 5 years to be released, I cringe. This was a team with poor project management and a fundamental lack of understanding of iterative game development. It happens far too often.

I would argue that death of most indie games is the mismatch between existing resources and ambition. This isn't captured in post-mortems because of the inherent survival bias in such reporting techniques; post mortems only describe the games that got out the door. There are vast quantities of unfinished games lying on hard drives. The start of the ultimate RPG. The laborious FMV intro to the next great shooter. A design document describing the best MMOG (ever). So much work and so few results. There is a better way.

The trick is to use stub mechanics and create a simple, complete set of game mechanics that can be easily prototyped. This development strategy, though not as intellectually stimulating as the Ultimate Game Design, has some solid benefits:
  • Easier early project approval: If you are relying on others for task such as programming or art, they are much more likely to approve a small time investment than a large one.
  • Increased chance of completion: By keeping the scope small, you decrease the chance that external factors will disrupt your development.
  • Shorter feedback cycles: Long design periods result results in complex systems that are difficult to maintain and adapt. A quick prototype will often let you fix your most egregious design errors early on. This dramatically reduces the risk of creating a crappy game that simply isn't fun to play.
  • Improved marketability of the ultimate design: A design document is the single worst method of selling a game ever devised. A playable game is the single best method of selling a game. By creating a prototype, you are creating a powerful marketing tool that can be used to gain resources for future expansion.
We are at a major point in the design where all the design elements are in place to create our first prototype. In the future, my posts are going to split into two categories:
  • Prototyping existing design mechanics
  • Discussing the larger vision of the game.
Both of these topics should be a lot of fun. The first should give us some down and dirty insights into how the various rules I've put forth survive impact with real world players. The larger vision of the game builds on the core game mechanic and turns a rather simple design exercise into a highly polished and addictive game that will eat up years of our player's lives.

Here's a taste of some of the vision elements I'll be covering in future posts:
  • Using story as a meta-mechanics: Adding emotional impact to a game that is currently far too generic to have mass appeal.
  • The upgrade system: Expanding combat such that it is more interesting for long term players.
  • Starting the game: A discussion of the game front end from a game mechanics perspective. The front end is the game.
  • The end game: Adding game systems that make the end game more exciting so that people want to play more often.
On the prototyping front, my goal is to create all the game elements as nicely modeled and animated state machines. This comes down to existing resources. My skills lay primarily on the artist side of things. I'll need to illustrate the various game systems as clearly as possible so that I can give a programmer this design on a silver platter.

Lots of things to work on. :-) Til next time...

take care


  1. You need cut scenes!! ;-P


  2. I was going to let you take care of the cut scenes. ;-)

    I actually have a fun article coming up that talks about the use of plot within a game. You'd enjoy it (and perhaps even disagree with the fundemental premise. :-) So far I've figured out how to add romance, rivalry, revenge and a couple more major emotions to Space Crack.


  3. The effectiveness of simple game designs was demonstrated well in Battle for Wesnoth. The game design had the rule, "a feature would be added only if [the designer] knew immediately how to implement it."