There are basically two big things that drive a lack of innovation in games.

The first of them is risk minimization. The second of them is risk minimization.

The reason I say “two” is because some forms of mitigating risk are undertaken with intentionality: purposely making a game that is a clone, for example. This isn’t always a bad thing — sure, sometimes it is done in order to capitalize on a market trend, but other times it’s done to learn how a given genre works, and in that scenario it’s a common and vital tool in a designer’s toolbox.

But this post is about the second sort of risk mitigation, which primarily centers around the fact that as games get more ornate, they get more expensive to make. High upfront costs push you naturally and inevitably towards incremental changes, with the biggest risks being taken on content rather than game systems. This is a pattern that leads inevitably towards “genre kings” — and the stage after genre kings tends to be stagnation and loss of audience reach.

So how can we as an industry keep costs down? Well, here’s my take, somewhat more elaborated from my now long-ago presentation on “Moore’s Wall.”

1. Stop rewriting code. Engine reuse, library reuse, etc.

There must be a 95% overlap in what the code does between all FPSes, but somehow FPS developers have giant programming teams.

There is this myth that “code rots.” But code does not rot. What rots is our ability to read it. If code worked in the past, it is going to keep working unless something in the input changes. The real reasons that code breaks over time are because we a) fail to update it b) update it too much and let it get crufty and byzantine. It is rare that this cannot be fixed with a refactor.

It’s been said by Steve McConnell (in Code Complete) that an average programmer is going to generate 15-50 bugs per 1000 lines of code. Regardless of whether you agree with the notion of measuring “bugs per KLOC”, the fact remains: in well-maintained code that has seen constant use, this figure should decrease over time. In a from-scratch rewrite, it is virtually certain to reset the bug count.

The standard argument against all this is “my game is special” or “we need all these new features.” Well, tight scope is an enhancement to creativity. Figure out a way to work with what you have, and you will probably get more creative output than you would have gotten with all the feature adds.

2. Stop chasing bleeding edge graphics. Chase unique aesthetics instead.

There are many reasons why chasing bleeding edge graphics is an issue in holding costs down.

• It almost always increases the amount of steps in the artist tool chain, and frequently also increases the amount of training and expertise the artist needs to have (thereby increasing the amount you have to pay them).
• It is almost always experimental to some degree when pursued as a competitive advantage, because cutting edge graphics is active research. If you have to triage and select one area to invest in for risk mitigation, it should be in your game system design.
• If you acquire the system instead, then you’re almost certainly driving costs there too, by requiring a bleeding edge engine version that probably costs full price from your engine vendor.
• It almost certainly doesn’t help you in brand differentiation, so you ironically end up spending more on marketing, not less thanks to your unique instantly identifiable look.

Bottom line: great art direction beats great graphics technology any day, and it’s cheaper.

3. Embrace tools.

It’s astonishing how many game teams shortchange tools — even in larger companies where the economies of scale make this a no-brainer. Granted, good tools designers are hard to come by.

If I had to get across one fundamental lesson on tools design, it would be “stop making tools for pros.” Pros shoot themselves in the foot more than inexpert users do. They have a propensity to push at the boundaries of what is possible and discover edge cases, or to bring their own backgrounds and agendas to the problem (“this library should work according to this particular programming philosophy” or “the editor has to look just like Unreal” or whatever).

In any project, 90% of the work is in the basics. Invest in that. Make awesome tools, with friendly frontends, for the basics. Data entry, map making, lighting, importing assets, setting up animations. This is stuff you want to be able to hand off to a junior person if need be, because of the sheer volume of it. You are virtually guaranteed that at some point, a non-expert is going to be maintaining or editing this stuff.

Don’t build in the ultimate awesome advanced tools into there. They get used a tiny fraction of the time, and you only want the experts messing with that stuff anyway. Leave the 10% on command lines, or let the experts use their custom made SQL-backed Excel spreadsheet for game balancing, or whatever.

Tool complexity — and therefore tool power — is actually a barrier and cost increaser.

4. Embrace procedural content, of all sorts, just don’t count on it being the answer to everything.

Procedural content is generally bland & repetitive, and players see through it given time.

It’s also something computers are very very good at.

It may be hard to believe today, but ragdoll animations were once in the province of “procedural content.” There’s hardly an artist or games programmer alive who doesn’t apply procedurally generated noise to stuff. Particle systems usually have a random number generator in them. I could go on and on. Get creative with where you can make use of procedurally generated stuff.

You can’t make your whole game with it. But handcrafting every detail is a great way to never finish.

5. Embrace systemic game design rather than content-driven design. It is harder to do but makes for games that have longer life with less content.

Particularly in the AAA games market these days, it can be hard to remember what system-driven game design looks like, because we encounter it so rarely. Puzzle games are probably the last major bastion of this design approach to have serious visibility to gamers.

But the fact is that a systemic game design is far more likely to be played decades from now than any content driven game design. For one, it probably embraces procedurality. For another, it probably eschews the graphics arms race. For a third, it tends to have less special case code than a content driven game and is therefore easier to write, easier to maintain, and easier to reinvent and extend.

Every major game genre is born from an initially systemic approach, even the most content-heavy ones like adventure games.

Don’t get me wrong, systemic game design is hard. Harder than replicably pouring content into a fixed mold, because it entails your creating the mold as well. But the key here is that in an competitive market, a fresh systemic design will require less content investment than using someone else’s systems and putting your own content in — because then you have to provide n+1 volume and polish of content than the title you cloned/reimagined.

And if you hit the jackpot of systemic game design — a game that has enough emergent properties and strategies to keep generating fresh scenarios from the system — then you will have actually created more content hours than a static approach.

The key in systemic approach is, as I have said before, in attempting to create NP-hard problems.

Side note: some may object to this emphasis on the grounds that the prevailing free-to-play business models are premised on selling small quantities of content. Well, guess what — the best and most lucrative F2P games are built on solid systemic foundations, not on static content. Think collectible card games, for example. In addition, the best virtual goods are consumables, which again points back at a systemic core game, rather than a content-driven one.

6. Embrace prototyping. Make your game playable and fun before you have any art. Stop writing big design docs.

Big design docs are useless. There, I said it. Trying to build a game off of one is like trying to recreate a movie from the director’s commentary track. They are largely castles in the air. The only time that big design docs serve a real purpose is when they are describing static content.

Embracing prototyping is a huge mental barrier for people. But it is what gets you to that long-lived self-refreshing systemic game design. You can prototype almost any game with some dice and some index cards. And plenty of ideas that sound good on paper turn out to suck when tried out for real.

Prototypes properly done are cheap. Prototyping is whistling five melodies and seeing which one you remember the next day.

Anyway, that’s my recipe.

Edit: I wrote a follow-on post in response to some common comments.