Making games more cheaply
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.
31 Responses to “Making games more cheaply”
Sorry, the comment form is closed at this time.
I think you can simply rename it “How to make games” 🙂
You summed up pretty much how I would describe the perfect project! (which I have not seen in existence yet… In the games industry!)
Best game production article I’ve read to date. Thanks.
Raph, I’ve been thinking hard about prototyping for the past week. No docs, no graphics, no code. More like a board game/rpg style prototype of different game aspects first. Maybe I was picking up your brainwaves. Ha!
What about “keep it short”? You are correct that hard crafted level design takes longer to make than procedural design (this is a somewhat funny way to put it but you know what mean). But I’d rather play a small number of concise, clever levels than a large number of inexpressive, repetitive levels, and that’s something best achieved with handcrafted levels. Though if you want to go the handcrafted route, you need to keep it short.
Loved the article, here’s some thoughts.
If someone gets only 15 bugs per KLOC, they aren’t counting everything. 100 defects per KLOC is a very good figure. Presumably you have a process in place that will find most of them before release.
Every programmer I’ve ever known wants to write new code from scratch. Not just game programmers. I think there’s some sociology behind this, the status reward for writing new stuff is just so much higher than it is for modifying existing code. Everyone wants to be John Carmack. Understanding this, I think managers can better address the social needs of their programmers and mitigate their impact.
Sometimes, entire modules do need to be rewritten. But not nearly as often as people want to do it.
I believe that point 2 was instrumental in making WoW a success. You could run that game on almost any crappy old machine. And it got a huge subscriber base. No correlation there…
Raph
Excellent article and points well made as always.
These points are not just side notes they should become mantras of all top level management and guide strategic and tactical thinking at all games studios.
Add these to work of Steve Blank, Eric Reis and Sean Ellis ad you have a new type of games company, management and product development play book.
Outstanding points. I’ve watched so many burn themselves out by reinventing the wheel instead of making a game, or they spend so much time on tech that they never become happy enough to release.
Take advantage of everything out there – tools, google, tutorials, people – and create!
All of this makes sense to me, Raph.
In regards to bleeding edge graphics, many players such as me also have “old” systems (i.e. more than a year old 😉 that can’t run as smoothly with those new graphics. Some can’t even run them at all. I hate it when a new game slows down my MacBook…
All of this makes sense to me, Raph.
In regards to bleeding edge graphics, many players also have “old” systems (i.e. more than a year old 😉 that can’t run as smoothly with those new graphics. Some can’t run them at all. I hate it when a new game slows down my laptop…
It is your last point that I resonate with — I felt that at Skotos we could prototype and test a real social game experience very cheaply (under $50K), and that the lessons and experience from that could guide a AAA development. When Sony bought our “Grendel’s Revenge” game I thought that this vision might finally happen, but I doubt now that they will do anything with it.
I’m frustrated with state of AAA games today — for instance the new Star Wars just feels like WoW in its play fundamentals. We need to experiment more with fun and play, and we are not.
— Christopher Allen
I love that you put “stop chasing bleeding edge graphics”. Too true, too true. I wish this could be a sign over every game god work station. Stop, stop! Make them go to Best Buy, get whatever is off the rack there for $750, and realize *that* is what most of us have. That we are not going to buy parts on Newegg and build it ourselves.
Right now, I can’t see a thing in Second Life since my good computer crashed with at least a newer Best Buy graphics card, and I’m on an ancient (4 year old) machine. I can’t see the sculpties or the mesh, of course, the new gizmos.
I’m trying to understand myself why I hit a wall on all Facebook games or any kind of new game or even any kind of new thing in Second Life which I’m most attached to. Even my beloved Sims paled for me on FB. Something just overloaded and fell over — the annoying messages from friends, the reloads, the inability to do stuff, but just the mindlessness of the cow-clicking. At least in your first island game after Metaplace, finding the jewels on the beach took a little effort but not *too* much effort and you could talk to other real people.
Also, this: “There is this myth that “code rots.” But code does not rot. What rots is our ability to read it.”
Every time I see prim drift on an old building in SL, I wonder…what is it that has caused this? And why doesn’t it get fixed on updates? The mathematical precision with which things are built…but then weird gaps and breaks appear in them over time. What, the numbers get old and slide?
15 bugs/KLOC?
100 bugs/KLOC?
Clearly yall are not being stingy enough in your peer reviews 😛
“If you give me a thousand lines of code written by the hand of the most honest of men, I will find a thousand reasons in them which will hang him.” -Cardinal Richelieu
Cheers!
In my experience, code DOES rot. Whenever you add any new feature, the codebase as a whole gets worse. To combat this rot, you have to have really good process, or really good coders, preferably both. And it’s not cheap anyway. That said, reusing code in the sense of using a good third-party engine/library is the wise thing to do – let engine vendor have this team of highly talented coders to add features to the engine. You’d still have rotting codebase for game-specific code, but it will be smaller and, by definition, not very reusable.
Great way of putting it! Running a company specialized in game prototyping (PreviewLabs), we always recommend our customers to make a rough first prototype of each game idea before eventually iterating further on a prototype. After all, it doesn’t make sense spending more time on a concept that isn’t the one standing out from the other concepts…
Systemic design, thank you for that!
Tools are easy. UI is hard. My favorite creation tools are incredibly complex, baroque, and chock full of obscure features that apply only to specific instances… under the hood. From the user perspective, you wave a wand and magic happens. The subtleties don’t become apparent until you need them, and they organically become part of your vocabulary.
An easy, simple tool is great… for easy, simple jobs. But if you’re asking me to paint with a brick, don’t expect the Sistine Chapel.
“Code does not rot” – It’s not true. Code becomes obsolete, stale and “rotten” as your focus shifts. Architectures created for quake1 won’t make much sense today, even if the game genre is the same. Hardware changes. Design changes. Code will still work, but our job is to deliver results, not to have the machine execute code, and rotten code might very well work but not help us deliver what we need.
I agree though that “what rots is our ability to read it”. That’s a big factor indeed. People go, the company itself changes, having a big chunk of “unknown” code is a huge liability. It actually does not matter much if it’s working, it does not even matter much if it’s bug free. If no-one understands it, it’s worse than bugged code that is well understood. Well understood code is easy to change, to shape in order to deliver the results we want. It’s easy to bug-fix. Opaque, mysterious code is hard to change, makes creating new features a chore, slows down the entire team, and its bugs are way harder to fix.
You count the number of bugs per line of code, that information is not really useful, or at least, it’s unfair to consider only that metric. If you want to make a fair assesment, you should consider that maybe rewriting a piece of code might create more bugs, but it also might (hopefully) create more understanded code, which will lead to less bug for subsequent features implemented on top of it, and that will lead to easier to fix bugs.
Also, often legacy code ends up being much, much bigger than it could be. Old features are left behind, systems becomes less and less orthogonal, you spend much more lines of code per feature, iteration time becomes slower. And iteration time is everything, especially if you are chasing aestethics!
@Prokofy Neva,
Honest answer to why that particular effect happens: it’s probably due to the use of floating point numbers for geometries. I recall a really good article building from “What Every Computer Scientist Should Know About Floating-Point Arithmetic” (http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) that related it, with images, specifically to common problems and anomalies in 3D computer graphics. (As usual, I can’t find this article now, for which I apologize.)
In short, the mesh might be fine, the stored data might be fine, but if some new land areas are added and the site of the building is moved further away from the zero point, this sort of thing can be expected to happen. As just one hypothetical.
Angelo, what you’re saying is that code doesn’t rot — our needs change, and our execution environment changes. That’s not the same thing.
I am not saying “don’t refactor” “don’t rewrite” and “don’t ever write new code.” I am saying that we as a community prefer writing new code (from scratch, without reference to the original) to refactoring and maintaining. Sure, there’s a breaking point. But especially if you’re not doing something radically new like vast outdoor environments or chasing the latest graphical bells and whistles — Quake 1 code would probably work fine to make most FPSes today!
I agree delivering results is the job. The fastest way to deliver results is going to be using the hammer you already have, not making a new hammer from scratch every time.
Sadly, code does rot, and what causes it to rot are hardware and OS specs changing out from under it. If code could sit on a stable foundation, it would never rot.
Hardware rots, too, and for the same damn reason. I’ve got a perfectly functional slide scanner. There is nothing physically wrong with it. It needs to talk to a SCSI port, but those are still available. Unfortunately, the drivers for my slide scanner have rotted — they were written for XP and won’t work on Windows 7. The company isn’t interested in writing new drivers for an old scanner. Because the drivers have rotted, the scanner itself has rotted. I now have to throw away a perfectly functional slide scanner. Infuriating. Small wonder the West is seen as decadent.
Surprising how much of this applies to designing boardgames, particularly prototyping.
I used to spend hours building boards, cards, rules, &c. to get a new design on the table only to find it fails in the first five minutes. Now I trend toward the minimalist and reuse a large number of common components (pawns, cubes, rules templates, and so in). Once the design proves itself, I can move on to building more functional prototype.
The opposite is true when we go into play testing phase with a design (“beta testing” if you will). We find that having a good prototype helps our play testers focus on the game design rather than being taken out of the game fumbling with poorly made cards and limited board. Here also I have developed a library of reusable templates and some common methods that tend to get a prototype together in rapid fashion.
Finally, procedural content is something that is faced all the time in board game design as well. Good examples include tie-breaking and selecting start player. Spending too much time trying to improve these procedures rather than focus on the core design is a waste of time. Get the core design working first and find unique ways to break ties later. Similar to building initial prototypes, spending a lot of time here when the core design is not tenable is a waste of effort. Get the design working with off the shelf procedures for tie breaking. Players are not looking forward to a new game because it has unique tie-breaking procedures, they are interested in good thematic games with simple rules that create a wide variety of tough strategic decisions.
Don Beyer
SDR Games (SDRGames.com)
Ernest, see today’s post. 🙂
https://www.raphkoster.com/2012/01/06/more-on-making-games-cheaply/
I think every programmer should do a stint making small games. Games on one month production cycles meaning from idea to shipping in a month to 6 weeks. You’d be amazed how much fat you cut and how much efficiency you learn. You also discover a lot of the obstacles that hold you back doing large games.
I would add #7 cut down process. I’ve seen companies spend more time on process than on production. Its pretty sad when you spend the whole day closing bugs and you don’t write one line of code.
Regarding the rotting of our ability to read code…I would add that many developers choose not to read code at all. Clearly, programmers love solving puzzles. Learning how to use a code base written by someone else is very difficult to do when that code base solves the puzzles one is most interested in. Ergo, everyone writes their own FPS engine which, sadly, means less investment is actual product.
[…] has been publishing a number of interesting articles lately (I didn’t link to his post about making games more cheaply, but it was a good read that I would recommend to all of you), and his latest article about […]
[…] is no reason why game devs shouldn’t strive to make games more cheaply, and that can be accomplished by incorporating the Lean Startup method into their production […]
[…] has been publishing a number of interesting articles lately (I didn’t link to his post about making games more cheaply, but it was a good read that I would recommend to all of you), and his latest article about […]
[…] forward to face the next arena. Simply repeating this formula throughout the game gets tiresome. A recent post by Raph Koster discussed some differences between content-based and systemic design. The […]
[…] Making games more cheaply […]
[…] Making games more cheaply […]
[…] 6. Как сделать прототип быстро (Кайл Гэблер) 7. Как сделать игру дешевле, прототипируя (Ральф Костер) 8. Геймдизайн за 4 часа (Джонатан «Cactus» […]