Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 26, 2014
arrowPress Releases
October 26, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Analysis: Sid Meier's Key Design Lessons
Analysis: Sid Meier's Key Design Lessons Exclusive
May 5, 2009 | By Soren Johnson

[In an essential design column, originally printed in Game Developer magazine, EA Maxis designer and programmer Soren Johnson (Spore, Civilization IV) shares four major insights from design legend Sid Meier on creating truly good games.]

Most game developers are familiar with Sid Meier's dictum that "a good game is a series of interesting choices."

In fact, my co-columnist Damion Schubert started his recent article on player choice (October 2008) by referencing this famous quote.

However, over the course of his career, Sid has developed a few other general rules of game design, which I heard him discuss many times during my seven years (2000-2007) at his studio, Firaxis Games. As these insights are quite practical lessons for designers, they are also worthy of discussion.

Double It Or Cut It By Half

Good games can rarely be created in a vacuum, which is why many designers advocate an iterative design process, during which a simple prototype of the game is built very early and then iterated on repeatedly until the game becomes a shippable product.

Sid called this process "finding the fun," and the probability of success is often directly related to the number of times a team can turn the crank on the loop of developing an idea, play-testing the results, and then adjusting based on feedback.

As the number of times a team can go through this cycle is finite, developers should not waste time with small changes. Instead, when making gameplay adjustments, developers should aim for significant changes that will provoke a tangible response.

If a unit seems too weak, don’t lower its cost by 5%; instead, double its strength. If players feel overwhelmed by too many upgrades, try removing half of them. In the original Civilization, the gameplay kept slowing down to a painful crawl, which Sid solved by shrinking the map in half. The point is not that the new values are likely to be correct - the goal is to stake out more design territory with each successive iteration.

Imagine the design space of a new game to be an undiscovered world. The designers may have a vague notion of what exists beyond the horizon, but without experimentation and testing, these assumptions remain purely theoretically. Thus, each radical change opens up a new piece of land for the team to consider before settling down for the final product.

One Good Game Is Better Than Two Great Ones

Sid liked to call this one the "Covert Action Rule," a reference to a not-altogether-successful spy game he made in the early ’90s:

The mistake I made was actually having two games competing with each other. There was an action game where you break into a building and do all sorts of picking up clues and things like that, and then there was the story which involved a plot where you had to figure out who the mastermind was and what cities they were in, and it was an involved mystery-type plot.

Individually, each part could have been a good game. Together, they fought with each other. You would have this mystery that you were trying to solve, then you would be facing this action sequence, and you’d do this cool action thing, and you’d get out of the building, and you’d say, "What was the mystery I was trying to solve?" Covert Action integrated a story and action poorly because the action was actually too intense - you’d spend ten minutes or so of real time in a mission, and by the time you got out, you had no idea of what was going on in the world.

In other words, even though both sections of the game were fun on their own, their co-existence ruined the experience because the player could not focus her attention on one or the other.

This rule points to a larger issue, which is that all design choices only have value in relation to one another, each coming with their own set of cost/benefit trade-offs. Choosing to make a strategic game also means choosing not to make a tactical one. Thus, an idea may be “fun” on its own but still not make the game better if it distracts the player from the target experience. Indeed, this rule is clearly the reason why the Civ franchise has never dabbled with in-depth, tactical battles every time combat occurs.

However, sometimes multiple games can co-exist in harmony with each other. Sid’s own Pirates! is an example of a successful game built out of a collection of fighting, sailing, and dancing mini-games. However, these experiences were always very short - a few minutes at the most - leaving the primary focus on the meta-game of role-playing a pirate. Each short challenge was a tiny step along a more important larger path, of plundering all Spanish cities or rescuing your long-lost relatives.

Another example of a successful mix of separate sub-games is X-Com, which combined a tactical, turn-based, squad-level combat game with a strategic, real-time, resource-management game. As with Pirates!, what makes X-Com work is that the game chose a focus - in this case, the compelling tactical battles between your marines and the invading aliens.

The high-level, strategic meta-game exists only to provide a loose framework in which these battles - which could take as long as a half hour each - actually matter. One doesn’t fight the aliens to get to manage resources later; instead, one manages resources to get to perform better - and have more fun - in future battles.

Do Your Research After The Game Is Done

Many of the most successful games of all time - SimCity, Grand Theft Auto, Civilization, Rollercoaster Tycoon, The Sims - have real-world themes, which broadens their potential audience by building the gameplay around concepts familiar to everyone.

However, creating a game about a real topic can lead to a natural but dangerous tendency to cram the product full of bits of trivia and obscure knowledge to show off the amount of research the designer has done. This tendency spoils the very reason why real-world themes are so valuable - that players come to the game with all the knowledge they already need.

Everybody knows that gunpowder is good for a strong military, that police stations reduce crime, and that carjacking is very illegal. As Sid puts it, "the player shouldn’t have to read the same books the designer has read in order to be able to play."

Games still have great potential to educate, just not in the ways that many educators expect. While designers should still be careful not to include anything factually incorrect, the value of an interactive experience is the interplay of simple concepts, not the inclusion of numerous facts and figures.

Many remember that the world’s earliest civilizations sprang up along river valleys -- the Nile, the Tigris/Euphrates, the Indus -- but nothing gets that concept across as effectively as a few simple rules in Civilization governing which tiles produce the most food during the early stages of agriculture. Furthermore, once the core work is done, research can be a very valuable way to flesh out a game’s depth, perhaps with historical scenarios, flavor text, or graphical details. Just remember that learning a new game is an intimidating experience, so don’t throw away the advantages of an approachable topic by expecting the player to already know all the details when the game starts.

The Player Should Have The Fun, Not The Designer Or The Computer

Creating story-based games can be an intoxicating experience for designers, many of whom go overboard with turgid back stories full of proper nouns, rarely-used consonants, and apostrophes. Furthermore, games based on complex, detailed simulations can be especially opaque if the mysterious inner workings of the algorithmic model remain hidden from view. As Sid liked to say, with these games, either the designer or the computer was the one having the fun, not the player.

For example, during the development of Civilization 4, we experimented with government types that gave significant productivity bonuses but also took away the player’s ability to pick which technologies were researched, what buildings were constructed, and which units were trained, relying instead on a hidden, internal model to simulate what the county’s people would choose on their own.

The algorithms were, of course, very fun to construct and interesting to discuss outside of the game. The players, however, felt left behind -- the computer was having all the fun -- so we cut the feature.

Further, games require not just meaningful choices but also meaningful communication to feel right. Giving players decisions that have consequence but which they cannot understand is no fun. Role-playing games commonly fail at making this connection, such as when players are required to choose classes or skills when "rolling" a character before experiencing even a few seconds of genuine gameplay.

How are players supposed to decide between being a Barbarian, a Fighter, or a Paladin before understanding how combat actually works and how each attribute performs in practice? Choice is only interesting when it is both impactful and informed.

Thus, in Sid’s words, the player must "always be the star." As designers, we need to be the player’s greatest advocate during a game’s development, always considering carefully how design decisions affect both the player’s agency in the world and his understanding of the underlying mechanics.

Related Jobs

Giant Sparrow
Giant Sparrow — Playa Vista, California, United States

Lead Artist
Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

Digital Extremes
Digital Extremes — London, Ontario, Canada

Generalist Programmers
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States

Unity Engineer


Ian Fisch
profile image
Great stuff. I've been caught up in the small change iteration loop myself. I make a small change to a parameter that to me is really impactful, but an average user would probably never notice. I wait for the next build, do a playtest, and receive the same complaints that I received before I made the change. Very true

Joel McDonald
profile image
"One Good Game Is Better Than Two Great Ones"

Shouldn't this be: One Great Game Is Better Than Two Good Ones

Simon Carless
profile image
Joel, actually, I think not, as is explained: 'In other words, even though both sections of the game were fun on their own, their co-existence ruined the experience because the player could not focus her attention on one or the other.' So even if the two game (parts) are great, if they co-exist, it's bad.

Ted Brown
profile image
These articles always make me hungry for more encapsulated wisdom. Habit forming knowledge nuggets! Thanks Sid & Soren!

Michel Carroll
profile image
Pure genius.

Some of these ideas were chaotic twirls in my head until this article concretized them for me.

Thank you


Steven Conway
profile image
Great article, though I think the Total War series proves that 2 great games can co-exist as equals within one product.

F. Taloots Marghezeeeele
profile image
Mr. Johnson should also have learned another lesson: Listen to your beta testers and don't release a bunch of vaporware product features.

We spent months telling Firaxis that the networking support in Civ4 was terrible, sub-par and totally underdeveloped. It was one of the worst networked games I've seen over the Internet -- literally worse than Age of Empires, an RTS game that was on store shelves more than 6+ years before Civ4 was out.

It's really still very astonishing to me that Firaxis didn't really seem to care, issued no statements or apologies on the matter and simply pointed the finger at their partner Gamespy as the source of all ills in their shoddy network performance.

After 10+ years of gaming and past experience with the original Civ series, I appreciate the anecdotal experiences encapsulated in this article, but I will never buy a Soren Johnson or Sid Meier game again. I'll stick to Blizzard and others who get networking right and immediately respond to problems in post-production, rather than leaving their playerbase to languish for months until 'the massive update' comes (which inevitably did nothing to ameliorate the problem anyway).

Bart Stewart
profile image
I'll guess that most folks here won't disagree much with these rules of thumb.

I did have some questions, though.

1. "One good game is better than two great games" -- how should this rule be applied to massively multiplayer online RPGs, which typically cater to multiple playstyles?

2. Regarding research, the principle of avoiding the tendency to require players to memorize an encyclopedia's worth of research nuggets -- the old "I've suffered for my art, now you will, too" problem -- seems reasonable. But this seems to be not so much an injunction against doing research before the game is done as a guideline for how to communicate that research to players.

Maybe a better way to summarize this would be something like, "Any research data not turned into gameplay should be optional." The "Civilopedia" in Civilization is a good example of this principle in action.

3. How were the four design rules described in this essay applied to the design of Spore?

Frank Lenk
profile image
On the contrary: I think the Total War series perfectly exemplifies Soren's point. I've always been haunted by the feeling that I'd be having way more fun playing either the RTS battle game OR the turn-based empire-building game, rather than juggling both at once. The fact that both games are extremely well done only makes their conflation more frustrating; they share zero skills, so being good at the one does not increase one's involvement in the other. And they're about equally time-consuming, so neither can be considered a mini-game respite from the other.

Rob Bergstrom
profile image
The old Super Nintendo game Actraiser combined a civilization-style God-game with a side-scrolling action platformer. Somehow it worked. I heart that game.

Theo Tanaka
profile image
@Rob: Maybe it's because both sides of the game didn't require you to remember what happened in previous stages in order to complete the current one. But if you wanted to play more of the action stages, you would have to endure the civilization-style game, and vice-versa.

"How are players supposed to decide between being a Barbarian, a Fighter, or a Paladin before understanding how combat actually works and how each attribute performs in practice?". I always think about this when I have to make initial choices in a game. How am I supposed to know which race I want to be, if I don't know what that choice is going to mean for my experience? I think japanese developers tried to ammend this problem in games like Final Fantasy Tactics, where you begin the game as a generic apprentice class, but then after a while you have to choose which class to evolve, and again you fall in the trap of not knowing which choice suits the best for you.

Daniel Tebbutt
profile image

To your first question, I would say that most MMORPGs already allow you to focus quite specifically on your playstyle of choice. If a player were forced to spend over half their time experiencing other playstyles then this rule should probably step in?

Aaron Casillas
profile image
Yes! Big read mechanics and systems first, if you find your team working on foot IK versus blast curves, damage systems, fx or just a plain spawning scheme, then stop and think about the player! Prioritize those features that the player will notice first and last. Another great rule of thumb, think about what an engineer can work on for 1 hour that will keep everyone else working for a week or two. Great article!

Mike Lopez
profile image
The first rule ("Double it or halve it") is really about determining your effective range of parameter tuning and is a major step that should be discovered prior to actual play balancing. I learned this back when tuning thousands of parameters and balancing all the physics, AI and gameplay systems on multiple versions of Road Rash.

To truly master play balancing the system designer needs to explore each parameter or set of related parameters to determine the the effective range of useful change. What is the most the system can be pushed up and down to provide results which will be useful in the game on anything from weapons to units to vehicles. Doubling and halving the values is a quick way to map out this effective range before narrowing down further into quarters and smaller values as necessary. Once the effective range is determined then changes can be made in proportion to the entire range of values. For instance, if a traction parameter on a vehicle has a hypothetical effective range between 1 and 100,000,000 then making tuning change in increments of 5 will likely have little effect so instead the designer should opt to make changes as a percentage of the overall effective range.

Next it should be determined if the effects change linearly or logarithmically so one must determine the effect of an identical change at various points over the effective range (say a change of 5% of the total range at 3 points near the top, bottom and middle of the range). It may be hard to measure that so there is a lot of subjective determinations there but that is what makes a great systems designer so valuable. If an effect is known to be relatively linear then the designer can easily map out how various entities should vary over this particular parameter (i.e. different suspension spring/dampening values over an entire set of cars; or different motion limiter values over a set of weapons).

I am actually sketching out a play balancing article on this very subject as I am periodically surprised how this is not such common knowledge among designers.

Luis Guimaraes
profile image
One more good thing to learn: Play as much games as possible and get what they do right and wrong, then develop your instincts to emule the feeling of a game feature since the idea comes up at your brainstorming session.

Altug Isigan
profile image
What is explained under "one good game is better than two great games" is a well know principle in scriptwriting. Basically the question you have to ask yourself is: "what is the core of this game about?". If you try to tell more than one story you face the risk that the story deviates from the initial conflict and ends up somewhere "out of bounds". This is also a matter of perspective. A sample question about perspective would be: "Is this challenge about the daughter who tries to cure her sick mother, or is it about the sick mother who tries not to be a burden on her daughter?" The answer will change the stories priorities dramatically and if the writer is not clear about, how do you expect that the player will be? It's very easy to mix up perspectives, to cause deviation in the story, and confuse the player about his role and goals. Only if you don't screw up the perspective issue, will you be able to keep the player as the star of the game, because you will place him into the right position/perspective and keep her in that one role that the game is meant for.