Sunday, June 12, 2005

Space Crack: Fixing the Turn-based Strategy genre

A discussion of simultaneous turns

Document Note: Each feature in a game design must address a need or solve a problem that occurs with the design.

Introduction
This part 3 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we described a typical person who would play SpaceCrack and some of the requirements the must be fullfilled in order for the game to succeed.. This time we'll look at how to reinvent the TBS game genre.

But TBS games suck!
There are good reasons why TBS games are dying as a genre. The fanboy in me hates to face the music, but as a designer I realize that there are fundamental flaws with the reward schedules in a typical TBS game. Here are some common ones:

  • Multiplayer games take forever: In the typical “I go, you go” turn structure you are waiting to play most of the time. Play for 5 minutes and wait for twenty results in lots of bored players.
  • More players results in longer games: As you add players, the wait gets longer. Boring.
  • The first turn is boring: Inevitably nothing happens in the first turn. Then you end your turn and wait for the other player’s results. Often, it is not until you are four or five turns into the game does it get anywhere close to interesting.
  • Complexity rules: As an old genre, there are lots of genre conventions. Most TBS games have loads of statistics and complex game systems. This is comfortable for some advanced players, but acts as a huge entry barrier for newer players.

It is no wonder that people dismiss TBS games. If you are looking for a quick gaming fix, this is the last genre in the world you’d want to play. Luckily, we have a lovely solution to all these issues.

New and improved multiplayer TBS
The genre has been evolving. My friend Lennart Sas created a TBS game called Age of Wonders. It had an original multiplayer turn structure called “simultaneous turns.” SpaceCrack steals his idea because, quite frankly, it is ingenious. Some benefits include:

  • The first few minutes of the game actually exciting.
  • Game play moves faster compared to traditional turn-based games.
  • It works great with both multiplayer and single player.
  • You can have fast games that are similar to an RTS. You can have slow games that are similar to play-by-email. All with the same basic game mechanics.

Real-time…
The turn structure is a variation on real-time networked game play. As far as the player is concerned the universe is always ‘live’ with the state of the playing field maintained on the server.

When the player logs on, they start getting real-time updates on the state of the game world. If another player attacks a planet, the player can watch this happen. No more waiting, no more convoluted phases.

But not real-time…
The game is divided into turns, during which the players can accomplish a fixed number of tasks using a limited number of Command points.

Players spend Command points in order to perform actions ranging from building a new ship to attacking an enemy planet. When the command points are spent, the player’s turn is over.
The turn structure and command points keep the playing field even. You can’t perform twice as many actions as your enemy. You can’t use your twitch skills to pummel an enemy that stepped away from their computer.

Turn Structure Variations

  • New command points every X time period: The player gets new command points every X period of time. For a short game, this could be every 2 minutes. For a long game this could be once a day. If a player does not spend his command points with the turn time limit, the points roll over to the next turn.
  • New command points when all turns are ended: When every player has hit ‘end turn’ or has exhausted their command points, the server gives out new command points. This means games can last forever if there is a laggard.
  • Mixed: If either the time limit or all players have ended their turn, command points are renewed.

Cool technology that needs to be built

  • Server: There is a server that tracks the state of each game. All calculations of world state are performed on the server.
  • Client: There is a client that can display updates from the server when the world state changes. The client must also be able to submit action that change the world state.
  • Command Management System: There is a system that manages command points and the end of turns.

Example

Document Note: Features are often difficult to visualize without a diagram and a game play example. If you want your design to convince, you need to include clear, emotionally exciting examples of each feature in action.

“Ray logs into his latest SpaceCrack game with his regular playing buddies. He got the new turn notification last night in his email, but didn’t get a chance to play since it was date night.
He has 10 command points available. Looks like Porter is online as well and the other guys have already finished their turns. Ray does a quick glance over the map and the news log to see what has occurred.

He moves a few of his ships towards an enemy planet. The missles fly and he destroys the defending ship. Within a minute of playing, he has launched 4 attacks and taken over 1 planet. He spends a couple more points building upgrades on his new planet and another couple of Command points moving some ships in as reinforcements.

A message blinks and Porter sends him a message ‘Hey, check the Troglis system.’ Ray zooms over to the Troglis system just in time to see Porter’s battle ships knock the planet flying. Daniel, the planet’s owner, is asleep in Sweden but that’s okay. The way the command points work, this isn’t like a RTS where he could have mounted some twitch response. Daniel will see the report in the morning.

Ray decides to save his remaining Command points and hits the End Turn button. Once everyone has finished, there’ll be a new round with a batch of fresh Command points waiting him tomorrow. “

Conclusion
I wanted to get the concept of simultaneous turns up front since it has a major impact on the rest of the design. In the next post I'll cover the basic elements of the game design: Token, Verbs, and Rules.

In other news, I've also been mocking up the graphic style of the game and some of the basic interface systems. I'm doing my mockups in Anark Studio and though I'm biased (I designed the damn tool), it is truely a joy to whip up this sort of thing. I banged out a working pie menu in a couple of hours and I didn't need a programmer. As a game designer who can't code my way out of a paper bag, this is truely an empowering experience.



The next post is up! Read it now.

take care
Danc.