Saturday, July 2, 2005

Space Crack: Ships

Introduction
This is part 8 of an ongoing game design document written as a blog. Be sure to catch up on previous posts. In the last installment, we extend the concept of player-created environments with the notion of territories. This time we'll talk about ship tokens and try to solve some of the major issues associated with complex unit management in turn-based strategy games.

Space ships! Gotta love 'em
I like to think of ships in SpaceCrack as sharp pointy sticks that you toss at your unfortunate enemies. They are horribly beweaponed (a word found in Hitchhiker’s Guide to the Galaxy) and the larger nasty ones can smack into little planets with a satisfying crunch. This visceral level is how I want my players to interact with ships.
  • Ships are produced at planets.
  • Ships can be launched at a nearby undefended planet and conquer it.
  • If the planet is defended, the two ships will fight to the death, with the winner taking all.
  • The existence of ships at various planets creates another strategically important layer of topography in the game environment.
Attributes of a Ship
Ships have the following attributes
  • Ownership: A ship always belongs to a specific player. There are no independent ships.
  • Health: A ship has a certain amount of health. When a ship takes damage, its health decreases.
  • Power: The more power a ship has the more damage it can do.
  • Ship Upgrades: Ship upgrades float around your ship and give it extra powers.
Common problems
One of the most enlightening exercises a designer can go through is trying to explain how a game system works to a new user. I usually start out with the disclaimer, “This is a really easy concept once you’ve played it a few dozen times.” When building effective game system, complexity is easy. Simplicity is hard.

When dealing with attack units such as our lovely ships, TBS games run into three main areas of immense complexity:
  • Production
  • Movement
  • Stack Management
Considering our two minute constraint, these systems take too long to learn. It is time to purge the complexity and rebuild them in a simpler fashion.

A Simple Ship Production System
Ship production needs to be easy as well. I played around with several methods of building unique ships and it all gets messy quite quickly. One brainstorming technique I use that is often quick productive is to ask “What is the simplest interface that would accomplish this task?”

In this case, there is a single button in the form of a ship platform. Click the platform and a ship is built. The only thing simpler is automatic ship building, but on first pass, it doesn’t seem like it would give the user enough meaningful choices.
  • If you click on a ship platform, it will create a ship of the same attack power as the planet. More powerful ships are larger on the screen.
  • A ship is produced instantaneously. No waiting, baby.
  • The spaceships costs crack and command points to produce. Big ships cost more crack.
Let us summarize ship production as a risk / reward sequence:
  • Action: Click on a ship platform to build a ship.
  • Reward: If you have enough resources, you get a ship! This increases the potential player actions and helps them win the game. Sweet.
  • Failure: Since command points are limited, choosing the wrong location to build a ship presents a substantial opportunity cost.
A Simple Ship Movement System
Ships can only travel to adjacent planets. You can move one hop and that is it.
  • Select the ship by clicking on it.
  • Selection icons will appear beneath nearby planets that can be traveled to. If the player selects a destination planet, the ship will move to the planet.
I played around a bit with ships being able to take multiple turns to reach a planet. This is a common practice in the TBS genre. However, long travel times goes against the short risk / reward cycles I’m striving for in the game.

By limiting ships to move only one planet at a time, we build a game with pacing is closer to Pac Man than Risk. You build up a big ship and then go a’ conquering, munching up planets by the half dozen each turn. We have a great short term risk / reward sequence:
  • Action: Click to move a ship to a new planet.
  • Reward: If the planet is undefended, bing! You get a new planet and more resources your next turn.
  • Failure: Since command points are limited, moving a ship to a bad location has a large opportunity cost. Also, if you misjudge and attack a planet you can’t beat, then your attack force is decimated.
We also remove an entire set of systems for tracking movement, showing partial player movement that occurred at the beginning of the turn, etc. The system can only care about what is happening right now, not what will happen in the future.

A Simple Stack Management System
Stack-based unit control systems irritate me. The typical TBS game gets bogged down in building, tracking, ferrying, redirecting, grouping, splitting, and attacking. In the immortal words of Napoleon Dynamite, “God.”

TBS games love managing large amounts of troops in a complex fashion. Heroes of Might and Magic has a hero system for ferrying troops back and forth. Age of Wonders has a stack system for creating little parties. But I’ve always found grouping to be horribly unintuitive for new players. “Oh, just select the unit, look in the little other window and click on the icon to deselect a sub-unit. Now select a new destination, unless the destination is an existing stack whose total number will be more than 8.”

These extra interface details are too much for a quick and dirty game that I need to teach in less than 2 minutes.

Super Ships!
The SpaceCrack solution is a blatant simplification of the problem. The root of stack based systems is the assumption that you have groups of unique units. Let us make our lives easier by throwing that assumption out the door.
  • Ever planet only ever has one ship.
  • Ship can only move from planet to planet.
  • When you move two ships onto the same planet, they merge together into a bigger ship.
  • When you attack an enemy ship, only one ship survives as the victor.
So you can build a super ship by merging together a bunch of little ships. Upgrade merge in a logical manner. What all this boils down to in the interface is one click to build a ship and one click to move it. You can never split ships apart.

The result is a very simple interface, but deep strategic and tactical implications. Let us summarize stack management as a risk / reward sequence:
  • Action: Move a friendly ship onto another friendly ship
  • Reward: You get a bigger ship! This increases the potential player actions and helps them win the game. Sweet. If you merge a ship at the right location, it can form a powerful point of attack or defense.
  • Failure:
    - Moving ships around takes command points so there is a strong opportunity cost if your actions have no impact on the world.
    - Building a powerful ship in the wrong location is can be useless if it is far from the combat zone.
    - If you merge the wrong ships, you can leave key planets undefended.
Conclusion
The ship token design attempts to simplify many traditional aspects of the Space TBS game genre. Simplifying is hard work and I wouldn’t be surprised in the least if these systems end up having multiple revisions before the game is finished. However, we are starting with some good foundations. These are lessons that can be applied to any game design:
  • Start with the simplest interface possible to accomplish the design goal
  • Design with risk / reward sequences in mind. Pacing matters.
  • Don’t be afraid to question the core assumptions of a traditionally complex system
Next up I’ll be looking at Combat. I’ve been building this game design a bit backwards.

take care
Danc.

3 comments:

  1. You mean: 'In the immortal words of Napoleon Dynamite, “Gosh.”'

    ReplyDelete
  2. I like the way this is going!

    It sounds reminiscent of an excellent but rather abstract (despite an overt hard sci-fi background) boardgame called 4000 AD, which has some similar mechanics - might be worth a look if you can find an antique copy anywhere.

    In particular, 4000 AD has a combat system where all ships at a planet are added up, and the player with the highest total vapourises the ships of the other player - which seems quite close to the ship merging you've talked about. Makes for very simple combat resolution, and you can weigh up fleet strengths quite easily.

    One question: Do you think that a big combined ship is as appealing a playing piece as a fleet full of many little ships? I can see the reason for merging them and I like it, but it kind of misses out on the fun of throwing piles of tokens around.

    Like 4000 AD, I would think you run the risk of dryness - but things like the spinning planets and proposed coolness of ships ought to be able to provide the necessary moisture... Certainly other sci-fi boardgames (Die Sterrenfahrer, for example) have combined personality with abstract mechanics to good end.

    Good luck!

    ReplyDelete
  3. **Also, if you misjudge and attack a planet you can’t beat...**

    I'm curious as to how this will happen. If a ship's size determines it's power, then you just have to make sure that you've got the bigger ship. On the other hand, in Go, there is never a situation where you "attack a planet you can't beat" so maybe you're game won't include this. Still, the uncertianty of combat (and the luck factor) are both things that are interesting in beer-and-pretzels party games. They diminish the skill factor, so that even the family monkey can win sometimes. I assume this will be covered in more depth in Combat.

    ReplyDelete