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.

• First Post: Introduction
• Previous Post: Using Planets to Build Territories

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.