Thursday, April 24th, 2008
Incremental Development for Games (Is Hard)
Out of Touch
For those who don’t know, the game industry (or at least my chunk of it) is generally about 10 years behind the rest of the software world. We’re still leery of crazy ivory tower concepts like “memory management”, “testing”, and “going home at 5:00 PM”. Where your hip Web 2.0 company is all aflutter about DSLs, duck typing, and continuations, my company is a little more:
Brown: I have just received a telegraph from Jenkins discussing something he calls, “the Ess Tee Ell“.
Watson: Desist your crazy Moon Man talk or I shall be forced to give you a drubbing!
It’s not that we aren’t trying. We’re just a little more East Berlin circa 1950 than the rest of the software world. One concept that has crossed our Iron Curtain recently is this thing called “Agile Development“. I can’t say we really know what it means, but it is very interesting to us.
Games Are Hard
You see, developing a new game is really hard. On top of the technical reasons (pushing the graphics hardware, strict quality control) and the business ones (cutthroat competition, difficult profitability), there’s this other little thing called “fun”.
If you’re making business software and it’s a pain to use, you can still be totally successful because people need to use your stuff to get their job done, like it or not. And your software can be totally unoriginal because people don’t want to have to learn new things. Unoriginality is actually a bonus.
Over in Magical Game Land, though, we aren’t so lucky. We’re trying to get people to shell out hard-earned cash for something that, by definition, they don’t need. So we have to make sure it’s more fun to play than whatever else they could be doing. We have to make sure we’re offering them a new experience, otherwise they’ll just play an older game. At the same time, our new game has to be easy enough to learn that it’s enjoyable within the first 30 seconds.
On top of this, budgets and player expectations continue to rise, so the chance and cost of failure keeps going up. Because of this, if a game’s going to suck, we need to know as soon as possible so we can correct course or bail out.
Enter Agile Development
Agile development means a lot of things to different people, but the key part I want to talk about is the idea of building a game incrementally through a series of small changes. This idea that a month into the cycle you have a fun playable game already and you just build onto that is very appealing because it means we can immediately get feedback on what parts work and what don’t.
For a micro example, imagine you’re building a chess-like game. In a typical waterfall-like model, you won’t be able to actually play the game until all the different pieces are designed and implemented. And then you can play the whole thing. Sometime in alpha, after you’ve burned most of your budget. Better hope the game is fun!
With a more agile method, you’d be able to play the game early in the cycle with a couple of pieces, and then gradually add in more pieces throughout. You’ll be testing some core mechanics early in and can change things if they don’t work.
Uh-Oh
Even that tiny example hints at the pitfall ahead: games are all about balance. Chess is unplayable with just two kings and some pawns. Without the other pieces, it’s a fundamentally different game.
So now we’ve gone from “nothing to play” to “playing a totally different game that may or may not reflect the final game”. Ouch.
This is where games are different than other software. If you’re making a word processor, adding right-justification doesn’t somehow “unbalance” left-justification. Features are fairly isolated from each other and don’t compete. In a game (in the game theory sense), every feature or capability affects the overall strategy and equilibrium.
Building a game incrementally is like trying to build a hanging mobile by hanging it up first and then hanging successive pieces onto it.
Solutions?
I suspect this is one of the fundamentally hard parts of designing a new game. That sense of “everything works in harmony” is irreducible to some extent. I’ll point out a couple of ideas to at least carve at the problem a bit.
Separate the Core from the Peripheral
If we’re designing minimal abstract board games, there aren’t a lot of “peripheral” features. In computer/video-games it’s a bit different. Non-interactive set decoration, some UI, extra games modes, etc. all surround the core “mechanics” of the game. So, even if you can’t do the core mechanics incrementally, you can at least do them in one lump and then tack on the additional stuff afterwards.
Be careful here, though. Even seemingly trivial things like UI or VFX can have a massive impact on the usability of your game.
Matched Pairs
If you’re starting with a balanced game and you need to add features while keeping it balanced, one obvious solution is to try to add them in opposing pairs. For symmetric games like chess, this is fairly simple: implement the same piece for both players. For other games, it gets trickier.
If you’re adding speed boosts to a driving game, you might be able to match it by also adding slowdown and damage for hitting the walls at the same time. For an RPG, giving the player a new attack may require also adding monsters that resist it.
Accepted Retuning
Most games, on top of the feature set itself, have a lot of precise tuning of numbers that happens to make it fun. Those numbers have to be tuned relative to the current feature set. Adding a new feature can essentially detune them. If you give your hero a shotgun, all of the sudden it may be time to double the enemy’s health. Make the AI smarter and your hero is toast.
If a fun playable game at all points through the cycle is important, it may be worth accepting that you will need to frequently retune the same values as the feature set changes. To some degree, this is “throwaway” work, but if it gives you a better ability to evaluate your game, it may be worth the effort.
Reduce Innovation
Of course, all of the above assumes you’re making a game with actually new mechanics. If you’re making chess on the other hand, it doesn’t matter if the game sucks with just kings and pawns. You know by the time the rest of the pieces are in it will be cool. So the safest option is just to rely on the established formula of your game’s genre, and save your innovation for peripheral features.
April 24th, 2008 at 8:47 am
I disagree here somewhat; in, say, a platformer, once you get minimal functionality, you can do incremental development of, say, the types of baddies, or of types of special objects or even ’special moves’ (like sonic the hedgehog’s ’spin up’). So what starts out as ‘moving a guy from left to right across the screen’ progresses to ‘allow hills’, ‘allow jump’, ‘allow falling’, ‘add bad guys that you can jump on top of to kill’, ‘add objects with effects’, ‘add tunnel entrances to move between maps’, ‘add throwing things to kill bad guys’, … and suddenly you’ve got a decent Mario Brothers clone.
I think it doesn’t have to be *fun* at each step along the way, it just has to be *usable*, by which I mean you should be able to fire it up and try out the new thing. This will help you get immediate feedback that ‘oh, jumping is too high, need to tweak those numbers down’ and ‘the bad guys need to have multiple AIs because jut tweaking this one up makes it too hard too fast’ and etc.
Basically, being incremental lets you test as you go along.
Tweaking for ‘fun’ is, IMHO, better done at the end, once you have all the pieces. Heck, you may need to make more pieces - or abilities, or whatever - but now you’ve got a way to get immediate feedback on your new tweaks.
April 24th, 2008 at 9:57 am
> I think it doesn’t have to be *fun* at each step
> Basically, being incremental lets you test as you go along.
If you combine those two statements, what that implies is that you can test some things, but you cannot test fun. In games, that’s often the most important thing to test (and one of the key motivators to try agile).
I agree that you can do incremental development as far as adding features, but you lose the insight needed to change course if the fun-ness of your game is off track.
> ‘oh, jumping is too high, need to tweak those numbers down’
It may be that jumping is too high, or just that levels that take advantage of that haven’t been created yet. Or jumping enemies aren’t in yet.
Let’s say you tune it down. But then later when jumping enemies are in, you realize you do need it to be higher. But now that it’s higher, levels designed around the assumption that certain platforms couldn’t be reached are now reachable. So those have to be touched.
That may be the best solution given the circumstances, but involves a lot of money-burning rework.
April 24th, 2008 at 10:52 am
>That may be the best solution given the circumstances, but involves a lot of money-burning rework.
How is it money burning when it is a cost that directly effects how well your game sells? To me money burning would imply an unnecessary step rather than the step that seperates the games that do well from the games that do poorly.
April 24th, 2008 at 11:44 am
All of the problems you mention can be solved by good planning, and most of the tweaking you mention as being so hard or troublesome is exactly what goes on anyway.
Anyone who has played a game in alpha, or even beta, knows that the actual game is not really that much fun or well balanced then, especially the case in MMPOGs. The levels, baddies, behavior, powers, and in fact everything else usually get tweaked if not outright changed!
No amount of developing or planning will fix a bad idea, but good planning will show these kind of problems.
Agile Development isn’t a fix for bad management.
April 24th, 2008 at 12:22 pm
When you define exactly what fun is, then you can test it.
If Agile is good/better (a statement I will not defend or attack here), then I submit that moving from your current non-Agile methodology where it’s impossible to truly test “fun” to an Agile methodology where it’s impossible to truly test “fun” is still progress.
April 24th, 2008 at 12:30 pm
It’s not about whether or not you can test “fun” or other things very early in a project development cycle using Agile methods. It’s more about how much success you were having by waiting until the end to integrate and test.
April 24th, 2008 at 1:54 pm
> How is it money burning when it is a cost that directly effects how well your game sells?
That’s a good way to look at it. Unfortunately, at least at my company, they look at it as money burning if you’re authoring content that doesn’t end up on the game disc. From their (shallow) perspective if you tune a number twice, the first value is wasted effort.
April 24th, 2008 at 1:58 pm
> No amount of developing or planning will fix a bad idea
Correct. So the goal then is a process to find out if your idea is bad as quickly as possible. With the possible exception of some really rare designers, I don’t think many people can do that based on documents or plans. You have have something to play.
The question then is how quickly can I get something up and running that accurately represents the final product. With agile, you get something up and running fast (better than waterfall), but I’m not sure to what degree it represents the final game. With most software, 50% of it can be 50% useful. With games, I think 50% of your game mechanics implemented is about as fun as a jigsaw with 50% of the pieces.
April 24th, 2008 at 2:01 pm
> When you define exactly what fun is, then you can test it.
Testing for fun is easy, way easier than testing for security or scalability.
What’s hard is finding out if the results of testing the fun of your first sprint tell you something useful about the final game.
April 24th, 2008 at 4:06 pm
you didn’t even read the page you linked to. the berlin wall was built in 1961, way after 1950. you could have written “paris” instead, for that matter.
April 24th, 2008 at 10:20 pm
[…] has been fairly busy, lately, and I keep meaning to get back to writing something here. Well, today something got me going enough to actually stop and write again. Imagine, if you will, a large number of […]
April 25th, 2008 at 4:34 am
Great post!
> Testing for fun is easy, way easier than
> testing for security or scalability.
Not sure if I agree. Testing for fun is hard! How do you test a game for fun? Can you really judge your own game after you spent days and weeks developing it?
April 25th, 2008 at 6:38 am
> Can you really judge your own game after you spent days and weeks developing it?
That’s a good point. Certainly familarity can bias you some (especially when it comes to usability) but it’s still pretty easy to tell if you like the game or not. Having been on games that definitely were and were not fun, I think there’s a pretty clear difference. It’s as simple as noticing that that when you’re testing a change, you keep playing just a little bit longer.