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.
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
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 www.spacecrack.com. 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.
- 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.
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.
- 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 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.
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.
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.
Lots of things to work on. :-) Til next time...