- Aug 1, 2003
- Sid Meier, Firaxis
- Bill Roper, Blizzard North
- Brian Reynolds, Big Huge Games
- Bruce C. Shelley, Ensemble Studios
- Peter Molyneux, Lionhead Studios
- Alex Garden, Relic Entertainment
- Louis Castle, Electronic Arts/Westwood Studios
- Chris Sawyer, Freelance
- Rick Goodman, Stainless Steel Studios
- Phil Steinmeyer, PopTop Software
- Ed Del Castillo, Liquid Entertainment
Brian Reynolds, Big Huge Games
Throughout his illustrious career as a programmer and game designer, Brian Reynolds, now president of Big Huge Games, worked alongside Sid Meier at Microprose and Firaxis on such remarkable strategy games as Colonization, Civilization II, and Alpha Centauri. His latest project is Rise of Nations. Read more about this game, published by Microsoft Game Studios, at http://www.bighugegames.com. It seemed a simple task for Reynolds to list his best advice for strategy game designers and support these words with an example from past or current projects:
Get something running in the first month that you can actually play. (It doesn't matter if graphics aren't so great.) With Civilization II, we had the game to where you could play it all the way through over a year before it shipped (even though it was all-new code from the original Civilization). We knew that we needed to play and try out all the new things we wanted to add and that we'd need that much time to get the balance and AI tuned. For our current game at Big Huge, we had something playable by our first milestone, even though all we were actu-ally required to "deliver" was a design document.
Strategy games are extremely complex to designalthough the individual components look deceptively simple, having a lot of "simple" moving parts makes for a very complex overall balancing task. It's easy to look at a strategy game and say, "I could make this better; I'd add this and this and this," but very hard to actually integrate lots of new parts into a game system without breaking the things that were already fun. To balance all the moving parts correctly, there's no substitute for actually playing your own gamethe combinatorial explosion from all the moving parts makes it impossible to truly anticipate or tune results "on paper" in a design document. The sooner you get your game running, the sooner you can actually get to work on making the game fun and making it balanced. Both fun and balance tend to be taken for granted by novice designers. They think, "If I make a game about topic X and it has features A, B, and C and technology J, then it will be fun," but as it turns out, fun and balance both take a lot of hard work.
Each strategy should have both a unique strength to make it cool and a unique weakness to keep it from being too powerful. "Rock, paper, scissors" is the best model for game balance. Our current real-time game is based around a "rock, paper, scissors" model for game balance. That is, unit A is really strong against unit B, but weak against unit C; whereas B is weak against A and strong against C, etc. That way, no unit is so powerful that it's "unbalanced." Also, all units are strong against something, so they're cool to build in the correct context.
Play your game regularly. If you have multiplayer [capability], get that running early so that you can balance it. By the time our new game ships, we'll have had our multiplayer running for at least 18 months. We've built a special "multiplayer lab" with eight workstations side by side (it's modeled on the lab we saw at Ensemble Studios), and we run at least one multiplayer game a day thereoften several. We have "novice days," "pro days," "intermediate days," "free-for-all days," and so fortheveryone in the company signs up and plays. Everybody in the company gets to see their own work interacting with the rest of the game, gets to see the "big picture," and has a chance to contribute to the design and balance. The progress on design and game balance was dramatic once we got the lab in, and we have plenty of time left.
Most of Brian Reynold's advice in this book is found in the chapters on programming (see Chapter 11, "Programming Theory") and artificial intelligence (Chapter 12, "Artificial Intelligence [AI]"), as well as on how best to break into the industry (Chapter 21).