Meta-design

All Genres are Doomed

Well, mostly.  But headlines like that are great for stirring up controversy.

The game industry has seen a number of genres die out over the course of its lifetime.  Some of these deaths have been due to technological advantages, but I’d argue that most of them haven’t.

Flight Sims

Flight sims are a great example.  Sure, they still sell a few copies, but mostly to actual pilots or old grognards of the genre.

But they didn’t start that way.  One of the first flight sims, Flight Simulator (a descendent of which is still published by Microsoft), was a landmark title for its day (1979!).

Soon after Flight Sim came the combat flight simulator games, most notably F-15 Strike Eagle by Microprose in 1984.  For the next decade, flight simulators were released constantly, across all genres, and with increasing graphics and realism.

Sometime in the mid 90s, the genre started to die.  Fewer titles came out, and the ones that did started to sell more and more poorly.

So, what happened?

The early flight sim games were complex, but not so much that they could not be grasped by an average person.  Any game simple enough to run on a Commodore 64 has a certain ceiling to its complexity!  However, as the genre grew older, players became accustomed to certain features, and demanded more and more realism.  And this made the genre much more inaccessible to new players.

As an example, F-15 Strike Eagle started players out in the sky, with a loadout, and a couple of enemies directly in front of them.  Shoot ‘em down!  Even the flight model was simplistic, in comparison to modern sims.  Landing was often optional.

In a late-era game, however, the player would have to sit through a briefing, make plans for how to approach the target, decide on a loadout, launch the plane, deal with multiple radar modes, etc…

And the genre started to sell less copies (but to very rabid consumers), and become a small niche where it was once a major genre.

Lifecycle of a Genre

Genres seem to go through a few major stages in their lives.  This model can, generally, be applied to just about every genre in existence.

Inception

Genre lifecycle starts with inception.  Somebody has an idea for a groundbreaking game.  It isn’t much like any other game previously seen, even if it shares a few things in common.  It generally won’t sell many copies, but it’ll get a relatively large share of buzz. 

The game may not be particularly well balanced at this point, but it’s a new experience, and accessible to a wide variety of players.

Growth

The second game in the genre comes out, either a sequel to the first one or a similar game from a competitor.  Either way, this game will represent a major upgrade from the original.  It will generally fix the rough spots of the first one, add a few new features, and be a lot more fun than the first.

This game will start to gain a larger market, and the genre will grow a following.  This will also happen for a few subsequent releases.

Peak

At this point, the genre will have pretty well refined itself to a razor’s edge.  To keep players interested, game developers will start to add additional features on top of the game.  At some point, this additional complexity will start to put off new players to the genre - it’s a little hard to get into the game, but worth it once you’re past the learning curve.

Decline

Additional features are keeping the old fans buying new games, but new players are so overwhelmed with the complexity that they find the game boring.  Since the folks making the games are usually the biggest fans of the genre, they tend to dismiss these complaints as people wanting "dumbed-down" games - ignoring the fact that the "dumbed down" versions are what got the developers interested in the genre in the first place.  Sales numbers start to dwindle, and revenue to make the games starts to dry up.

Death

The genre has died, outside of a few low-budget, independent titles.  People will frequently say things like "<genre name> sucks, those games are boring."  Grognards boot up the old versions of the games, and find ways to tweak the data files to come up with more content.

Rebirth

"Hey, remember those flight sims we used to play when we were teenagers?  Wouldn’t it be cool if someone made a game like them, and just stripped out all of that complex crap that took 5 hours to learn but didn’t really do anything?"

Avoiding Genre Death

Don’t be Afraid to Remove Stuff

Evolution is a neat thing.  In addition to adding stuff, evolution can also remove things that no longer serve a purpose.

Every feature you add changes the game.  And it may make some previously-needed features utterly irrelevant.  Getting rid of useless features is a great way to keep the complexity of your game under control, giving the grognards new things to play with while keeping overall complexity under control for new players.

Ease ‘em In

This can be hard to do, especially in some games, but incrementally exposing the complexity to users is a great way to have complexity in the game, while not hammering newbies with it immediately.

The biggest catch here is making sure that the "intro" period is either short enough that more experienced players can zoom through it, or enjoyable enough that they don’t mind.

Also keep in mind that there’s a difference between "inexperienced" and "low-skilled."  A veteran fighting-game player may struggle with a new game if he doesn’t know the movelist and new concepts.  However, once he gets up-to-date, he’ll probably be a relatively good player.

Build in Layers

Sometimes, the best answer is to build upwards.  Leave the core game more-or-less untouched, but add in additional layers of gameplay above the core.  To add complexity to a flight sim, you can require more buttons and management in the cockpit - or you can add a strategic layer that has to be managed that impacts, and is impacted by, your success and failures in the cockpit.  The strategic layer stops the new player from being overwhelmed initially in the cockpit, while still giving the advanced player more to think about.

Limited Scope

Add additional features, but limit areas where they can be used.  If Mario can only fly when he eats the right mushroom, then it’s very easy to make sure that the players never have to worry about flying, fireball-shooting, metal, ice, bee Mario - only one extra set of features can be active, or generally even available, at once.

This also makes content easier to develop, as you don’t have to worry about every combination of abilities in every scenario.

Know What’s Important

When looking at adding or removing features, know what’s important to your game, and what’s not.  Look at the decisions you want your players to make, and make judgements based on that.

Every feature you add will change what the important things in your game are.  If you take an RPG that’s mostly about strategic battles, and add a lot of items, you will shift some of the focus to item-gathering.  That’s not a bad thing, just be aware of it.

Avoid Busywork

If a feature that is being considered only adds steps that must be followed, instead of allowing for different decisions to be made, don’t add it.  You’ve added no real value to the game, while adding complexity to the user.

Similarly, if a new feature is only useful in some situations, don’t make the players deal with it all of the time - leave it as an extra option to be used if the player needs it.  For instance, if making a sub dive normally sounds off a dive alarm, great.  Players shouldn’t have to do that, it should just happen.  However, if there’s a reason a player might not want to sound of the dive alarm, then you can leave it open to the player to do so or not. 

If not sounding the dive alarm is only useful in a small number of situations, and is dangerous otherwise, though, then sounding the alarm should be default and automatic, unless the player specifically specifies not to.  Not only does this avoid a checklist of things the player must do at every step of the game (making the game feel more like work, and less like fun), but it also allows the player to be unaware of the dive alarm toggle until he actually needs it, removing an unnecessary complication from the player’s mind in the early stages of learning the game.

Keeping Them Alive - Civilization

Not all genres have to die - it’s just the natural progression.  To keep a genre alive, you have to be aware of the genre lifecycle (at least in a general sense) and take measures to prevent the decay and death of the genre.

Civilization was heading down the road of genre death.  Even as a player of Civ I, Master of Magic, Alpha Centauri, and a smattering of Civ II, I found Civ III simply overwhelming.  Too much information was thrown at me from the first second of gameplay.  Even buying the game, I played it about 45 minutes.

Enter Civ IV.

Civ IV did an excellent job of keeping the genre alive.  The initial resources, units, and techs to consider were limited, and very clear in what they did.  Many of the more advanced options only came into play later, and individual citizen assignment only was brought up if you deliberately clicked into the cities.

In addition to simply having easier AI, lower levels of difficulty also lowered the impact of factors that would normally have to be dealt with and managed - health, happiness, taxation.  They still existed, providing players with a gentle introduction to them, but upping the difficulty a few notches forced players to deal with the full brunt of them, having been made familiar at the easier levels.

Additionally, the unit counts were reduced, and replaced with the ability to customize units with additional bonuses.  This gave players the ability to have specialized units if they wanted them, while still only requiring them to deal with a few base unit types.  Some of the specializations were simple bonuses, so if players did not need or understand the more niche specializations, they did not have to worry about them.

And yet, all of these factors were available for the player to delve into at any time.

While I don’t have particular sales figures, I don’t think it’s a coincidence that CivIV has won numerous awards and generated several add-on packs.

Complexity Kills, Not Depth

Genres tend to become more complex over time, and this leads to their doom.  The key to keeping your genre alive is to actively manage the complexity of the games, and how that complexity is presented to new players.  New players are the life blood of any genre.  If you exclude them, you are committing a slow suicide.

Design
Meta-design

Comments (1)

Permalink

Reflective vs. Predictive Design

A little meta-design here.

I’ve described (hopefully!) a number of tools that can be used to analyze design, and to help determine why games are fun, or not.

There’s two main ways you can use these tools.  You can use them to predict your gameplay, or you can use them to analyze your gameplay.  I call this predictive vs. reflective design.  These correspond to open loop systems vs. closed loop systems, as described in Managing the Design Factory.

I highly recommend you use reflective design, and avoid doing too much predictive design.

Many factors that impact gameplay are not apparent up-front.  Trying to quantify all of those factors before you start work is a difficult task at best.  Additionally, games are complex, chaotic systems that are notoriously hard to “get right” the first time.

This doesn’t mean that you shouldn’t do any up-front design.  At a high level, it’s worth trying to make sure that your design is vaguely right - make sure that everything has at least some level of a counter or balance point.

But, instead of spending a year writing documents, write a game.  Even if it doesn’t have every feature you think you’ll want, get it running and playable.  See if your basic assumptions are correct.  Make it work, make it fun.  Add things to make it more fun (or take them away!).  And, through this process, gather data.  Tons of data.  Log everything, store it in a database, and analyze the data.

And when you’ve got a real idea of how your game is being played, you can use the tools I’m describing to determine why it’s being played that way, and how to make it better.

Meta-design

Comments (0)

Permalink