Designing Games In A Vacuum, Part 2: Units, Walls, and Caps

Continuing the discussion from Part 1 of this series, we’ll discuss some of the unique challenges of a space-based game environment as it relates to unit design for the game AI War: Fleet Command. These difficulties actually helped to bring out some of the more novel features of the game, so in the end I’m quite glad I made the choice to set the game in space (despite all the headaches during the early stages of design and implementation).

Issues
Continuing the list of issues from the first article:

Limited Types Of Well-Known Space Ships
3. Variance between the kinds of spaceships people know about is kind of limited. I mean, even in a franchise as memorable as Star Wars, you basically have a variety of smaller ships, the cruiser/corvette/destroyer classes of ships, and then the really big space stations and weapons like the Death Star. Granted, there are a lot of differences between the various Star Wars ships in terms of handling, control, loadout, etc — these really shine in an action-oriented game — but in an RTS game where you simply order ships around with your mouse, all of those differences start to seem pretty minor.

I knew I wanted dozens or hundreds of ship types in the game, on the order of most terrestrial RTS games, and that just wasn’t looking possible by conventional methods. I mean, in a terrestrial RTS you have units with various bonuses (like pikemen versus cavalry), ranged units such as archers, various sorts of melee units, units that can fly, naval units, units that are good at moving through certain terrain, and on and on. The dearth of real-world examples of different kind of spacecraft with varying abilities was both a challenge and an opportunity for some unique design.

The opportunity was that I could do anything that I wanted, but the challenge was that ships would not be instantly recognizable in the manner of archers or cavalry. I had serious concerns that meaning might be obscured in the way that many of the units in Rise of Legends were difficult for me to remember (What is the difference between Sand versus Fire versus Glass units? What does the Scorpion guy do, versus the Manta Ray?). Don’t get me wrong, I did like RoL, and it’s uniqueness was one of its draws, but in the end there were too many units with too many esoteric groupings and names for me to ever feel really proficient at the game. I didn’t want players to come away from their first few sessions of AI War with that feeling.

No Walls In Space
4. There are no walls in space, but this was a critical element in most of my favorite RTS games. Rise of Nations and Rise of Legends had both excluded walls (presumably due to challenges with pathfinding?), and that had been pretty annoying because it was hard to protect core resource without committing so many military assets that I became weaker on offense. In my experience, when both players in a game were only lightly defended (no walls or force fields or what have you), that made it a rush to see who could crush the other faster.

I wanted to create a longer game with more emphasis on planning, maneuvering and scouting; to me, it’s always been more satisfying to think of a clever way out of a tough situation, as opposed to just having memorized a pre-developed strategy or clicked faster than my opponent. When I want to test my reflexes against others, I play a racer or an FPS (I do love and frequently play those genres, but they are distinct from RTS).

Population Caps
5. In most RTS games, there are arbitrary population caps that prevent players from building an infinite number of units. This means that players tend to gravitate towards the stronger units, which often cost multiple population points because of their strength (1 cavalry or heavy tank takes 2 or 4 population points, etc). I wanted none of this, since my game engine was capable of handling 60,000+ ships in realtime.

However, with no population caps of any sort, this meant that alpha players tended to find the strongest unit and spam it repeatedly. Weaker ships might as well not have even been in the game, for all the use they got. A lot of RTS games seem to have this problem, even the best ones — in Age of Empires III, when I played as the French, I never built anything but Musketeers and Cuirassiers, for instance. Even though I loved that game, the presence of that deadly combination in my favorite civ made the game a lot less interesting for me. In early builds, the same thing was happening to AI War.

Solutions

Quirky Ship Designs
If all the units are too homogeneous, that will be uninteresting and will make the game feel smaller than it is. But on the flip side, if the units are too esoteric, no one will be able to get a firm grasp on what everything means and how it all fits together (my Fleaship kills your Dogboat, but your Dogboat kills my Trianglecraft — obviously, these are completely made up, but you get the idea). I therefore decided very early on in to go with a very practical naming scheme, where each ship’s name evoked its abilities.

For a few examples: space tanks are slow with a powerful shot, and have heavy armor; raptors are quick, cloaked ships that are able to pop out with a strong, sudden attack; laser gatlings are little ships with a rapid-fire laser attack; vorticular cutlasses are spinning masses of blades that crash into enemy ships. From the reactions of alpha and beta testers, most people have found it very quick to remember unit names and abilities, despite the huge variety of units that have no real-world or popular media counterpart.

Early ship designs were all over the place — I had no particular goals and so just tried out a variety of ideas to see what was most memorable, different, and fun. After a lot of playtesting and design iterations, I settled into what you see in the final game. There are 28 classes of mobile military ships currently in the game (not counting starships), and these make up the bulk of players’ fleets. Each ship type has some sort of unique ability associated with its name, or some other special combination of stats that makes it fill an individual niche.

This worked out really well, except when it came time to try to balance all of these ships so that they were inherently equal despite being so different — this seemed to be an impossible task, and the ships became more generic the more equal I made them. But when the ships were not equal, my alpha testers were great at finding and exploiting over-strong ships. I’d introduce some cool new ship type, and it would either be completely irrelevant or the powerful new thing that everyone would use and that I would have to quickly nerf.

But I was committed to having variety in this game, as I knew that was one key to longevity and replay value, so I pressed onward with many different designs: electric shuttles, which strike all nearby ships with weak bolts of lightning; vampire claws, which absorb health from ships that they crash into; EtherJet Tractors, crazy-fast cloaked ships that can grab enemy ships and drag them away (the AI is really mean with these on the upper difficulty levels); and 22 other ship types with various abilities, strengths, and weaknesses. I succeeded in creating variety, but unwittingly created a game that was too complex for much of anyone to play — people could remember what all the ships did, but it was paralyzing to try to decide which ships out of a stable of 28 would be the best in any given situation. This made for people just specializing in a few ships (bad), or building a bit of everything completely at random (much, much, worse). It took a few weeks of playtesting for my alpha group and I to come up with the solution for this.

Limiting The Number Of Ship Types Per Game
Up until a certain point in the design, all of the ship types could be built by any player at any time. This meant that players had a dizzying array of options (28 different main ship types to choose from at any time? Even I couldn’t make effective decisions with them, and I designed them). It was actually my dad, who is one of my alpha testers, who suggested that it would make a lot more sense if the number of ship types was more limited in each individual game.

I was initially resistant to the idea, but nevertheless he and I spent several hours hashing out the system for randomizing and unlocking “bonus” ship types that you currently see in the game. Once the design for this was complete, I immediately knew we were on to something. By limiting the number of ship types each player has available at any given time, there is a greater sense of progression to the game (since Advanced Research Stations are captured and new ship types are unlocked), there is greater variety between campaigns (since not every campaign contains every ship type), and the starting options for players are considerably less overwhelming.

If you think about it, this is basically the same sort of segmenting that you get in most other RTS games, where the different civilizations have inherently different units. But in most other RTS games, all of the various civs have to balance out with one another so that there is no dominant civ (and there still tends to be a collection of civs that all the best players use). In AI War you are allowed to select one bonus ship type to start with, but all the rest that you get are not discovered until several hours into the game. Likewise, the ships that the AI uses are dependent on the map you choose, and so are unknown at the start. This different-every-time feature was half of a key feature for AI War’s unit balance, but I didn’t realize it quite yet.

Unbalancing Units On Purpose
With the different-every-time features for bonus ship types, I suddenly realized that I was free to make the ship types as unbalanced as I wanted to. The idea of “fairness” is required in competitive multiplayer games, but many cooperative multiplayer games are unbalanced on purpose. Take a look at the co-op mode in Resistance 2, for instance: there are three distinct player classes, each with distinct strengths and weaknesses. This lets players fill unique niches, which emphasizes cooperation, and it also provides for more variability in each game.

I decided to do a similar thing with AI War, making it so that all ship types are useful in some way, but some ships are more valuable in one campaign than others (depending on what ships the opposing team may have, the strengths of your bonus ship types might be really helpful or not). At the core of this, I knew I wanted the rock-paper-scissors relationship between the standard Fighter, Bomber, and Cruiser ships. These three ship types are in every campaign, and one of those three units is strong against every other ship type in the game. Thus there is never a situation where one team gets a ship type that the other team is completely unable to counter.

Per-Type, Per-Level Ship Caps
One of my early design goals for the game was to make it so that all ships that you can build at the start of the game are still useful at the end of the game. Many other recent RTS games are also doing this sort of thing, but usually that’s with a veterancy system that seems a little bit too opaque for my taste (and which really only seems to work well with small numbers of units). By contrast, in Supreme Commander players would often still need to build Tech 2 units even when building Tech 3 units, just because the Tech 2 units were so much cheaper and faster to make.

Instead of putting so much scaling into cost and time to build, instead I implemented a per-ship-type population cap. Not only was this per type, it was also per technology level of each type. So you can build perhaps 180 Mark I Fighters, 140 Mark II Fighters, 120 Mark III Fighters, and 90 Mark IV Fighters, for instance — and similar ratios for Bombers, Cruisers, etc. This was the final piece of the balancing puzzle. By limiting the number of each type of ship that could be built, I insured that players would have to utilize ALL of their ship types, and all levels of each ship type, throughout the entire game. So even at the very end of a campaign, players are still building Mark I ships in addition to the Mark IV versions.

Real commanders quite often have to deal with outdated equipment or underperforming units, and I wanted to simulate that in a game. Choosing where to place your best units, and where to put your weaker, more outdated ones, creates a whole new strategic challenge (my favorite novel, Ender’s Game, also discusses this as an issue). Rise of Nations had done something similar with their increasing-costs per each unit of a type built, but those were irrespective of technology levels so far as I recall — it made you have a reasonably balanced army (unless you were really resource-rich), but it didn’t make you use older tech in addition to the new.

There were many other advantages to this system, such as making the acquisition of Advanced Research Stations even more important (they effectively increase your pop cap as well as the types of ships you can build). It also let me make certain ship types even more powerful, since I could then give them a lower pop cap to balance it out. And for the really weak, inexpensive, swarm-style ships like laser gatlings or infiltrators, I could give them a cap that was 6x higher than normal. All that contributes to some pretty impressive differentiation between ship types, and kept them from feeling too generic and similar to each other.

Space-Based Substitutes For Walls
In the context of an RTS game, what are walls, really?

#1. A way to prevent enemies from coming at your defensive positions from all directions.
#2. A way to slow down enemies.
#3. A way to choose the most likely locations for battles.

Before I started thinking about walls in these more abstract terms, I had actually implemented a unit called Magneto Lanes (basically space walls), but those never really felt right or made much sense. The better solution, the one that you see in the actual game, is tractor beams. Tractor beams are a familiar technology from literature and film, and they meet the criteria for #2 and #3 above. Tractor beams are not indestructible (neither are walls), but they provide a way to slow down oncoming hordes. Of course, each tractor beam can only block a limited number of ships, unlike a wall, so that changes the dynamics some while keeping the same basic idea — change like that can be refreshing.

The other part of the walls puzzle, the solution for criteria #1 above, was choke points. Basically, criteria #1 is just referring to player-made choke points, but if there are already choke points available then the players can just exploit those instead of making their own. As it happened, there were already excellent choke points available in the game in the form of wormholes. Without wormholes creating bottlenecks for entry into planets, tractor beams would be vastly less effective, but in combination they are able to provided all the same basic protections as walls in a slightly new way. Thus, tractor beams evolved from a tiny little ship with some side interest, to one of the core mechanics of the game.

In Conclusion / The Harshness Of Space
Being able to take a familiar genre niche (walls), and substitute something less familiar that nevertheless fills the same basic niche (tractor beams) has been really exciting. There have been a few other opportunities for me to do this in AI War, such as the way knowledge is gathered and unlocked (tech points are generally something that you don’t have to get from specific locations in an RTS game, but that is the case in AI War), the way build queues are managed (central controls make it easy to make quick, large-scale economic decisions), the way manufactories work (in place of a market), and others.

Not one thing on that list was in the original design documents for the game, but rather came about through playtesting and seeing how the space environment, the wormholes, and the multi-planet galaxy maps interacted. To me, this is pretty much the entire case for iterative development — I could never have thought of these things up front. Space is a harsh environment for astronauts to work in, and in a metaphorical sense that has held true for me with regard to designing this game. However, some of the best stuff is invented in space, out of necessity moreso than enterprising spirit. I’m glad I took the journey!