(Eric Ries has now started re-tweeting this series, so I will take that as tacit approval from the master. He’s in British Columbia in two months, giving a series of talks on Lean Startupsin Vancouver and somewhere in Kelowna, so there is a slim possibility that this is just a ruse to lull me into security while he takes time out of his busy schedule to hunt me down and shoot me with a blowgun.)

When last we left our hero, he had just discovered that it was possible to make a lot of money by shipping software that sucked. This, of course, was nothing new to our hero; now, however, he was confronted with the fact that this might not be a bad thing after all.

So here’s the skinny.

What I failed to realize about IMVU in 2008, and now realize in 2011, is that it doesn’t actually matter, as a programmer, what I think of the client. It could, in fact, have been a million times worse. The key thing about IMVU is this: do customers want to buy it? As it turns out, customers did. Not only do customers want IMVU, but customers actively want to spend time building content for IMVU, and investing real currency in IMVU’s microtransaction based virtual economy… and this is a gold mine. Nobody could possibly have predicted, in fact, that this would be a gold mine. I think the people involved with IMVU are as shocked as anybody else that people are shelling out money, REAL money, to dress their virtual avatars up as vampires and werewolves.

The success of IMVU inspired what, for lack of a better term, we will call the Lean Startup philosophy. There’s a lot of stuff you can read about Lean Startups – again, I will redirect your attention to Eric’s blog – but, from where I stand, the Lean Startup approach can be distilled into three basic principles.

1. You have no idea what your customer wants. Your customer does. Ergo, you should ask the customer.
2. Figure out what your minimal viable product is. How little work do you have to do in order to ship a product? Figure out how you can do as little as possible, build the bare skeleton of the application you are trying to produce, then get it out the door and start charging people money for it.
3. Once you have started shipping a product, you can then figure out what the customer wants. The customer will tell you what they want. (IMVU does little experiments to find out what the customer wants.) Once you can figure out some little bit of what the customer base wants, write it, then immediately ship the new version of your product. (Eric calls this “Continuous Redeployment.” Again, huge swathes of material have been posted to the IMVU website and Eric’s blog about IMVU’s approach to doing this. Everything that IMVU does with Agile, Unit Testing, and automatic build-smashing programs has to do with this philosophy.)

We can make this short and pithy: Ship early, ship often, and build what the customer actually wants.

Somebody should put that on a T-Shirt. There is more to being a Lean Startup than that – leveraging technical debt to get started quickly, using open source technology to make your life better, using metrics to figure out what the customer actually wants – but those are the big three ideas.

My mistake, in thinking that IMVU’s product sucked, was considering it from my perspective as a programmer. IMVU used Cal3D, an open source animation library, to quickly get content up and running. Cal3D, to put it bluntly, has issues. I could probably write a character library at least as good as Cal3D in a couple of weeks, and my version would have whiz-bang features like inverse kinematics and multiple animation blending. The original founders of IMVU, not being specialists, couldn’t do this. It would probably have taken them about three to four months, during which time they would have had a learning experience and then run out of money. From a technical perspective, of course IMVU’s client sucked. The renderer was glued together with duct tape and rubber bands, the network backend was, probably, a series of tubes, and so on and so forth… but none of this mattered. What mattered to the users of IMVU was that, at long last, they had a way of finally interacting in a virtual world where their avatar could look like Sephiroth from Final Fantasy 7, if Sephiroth went to Hogwarts… and they were willing to pay for the privilege.

As time has gone on, IMVU has taken steps to address its technical debt load. I don’t agree with all of the decisions I hear about – for instance, embedding Adobe’s entire Flash Player in their rendering pipeline as a way of cheaply manufacturing customizable user interfaces – but I’m not on the ground floor and so it’s not really like I have an informed base to comment from. What’s more, the customers are happy, and they’re buying virtual goods.

Now that we have talked about lean startups, let’s talk about lean game development. To my mind, the original people to try a lean startup methodology were the developers of Mount and Blade. Mount and Blade was developed by a team of two developers over the course of several years. It has bubbled through a number of beta releases; each time a significant new release was made, the developers bumped the price. If you got in while the going was good, you would now own a very good game for a very low price. At this point, Mount and Blade’s developers have now released a sequel to their original title, which is really just a continuation of their previous work on Mount and Blade; it can be had for $29.99. A publishing deal has been signed with Paradox Interactive; you can get Mount and Blade, and its sequel, for $39.99. Not bad for a game that started off with something like a $1.99 price point.

Who else is running a Lean Game Startup? Well, let’s see:

– Minecraft, recent Indie Darling, which made its creator into a multimillionaire overnight. All of Minecraft’s development has been in the public idea, and new releases are sent off quickly and rapidly.
– Dwarf Fortress, less-recent Indie Darling. Dwarf Fortress started development in 2002, and shipped in 2006, which means that Toady’s rate of progress to a first release is actually about the same speed as Dredmor’s. Nonetheless, the fine crew at Bay 12 Games have released several versions of everybody’s favourite mining simulation game, and each one is progressively more refined.
– Angry Birds. Angry Birds started off as a reasonably small game. People bought it, and were pleased when the developers of Angry Birds, Rovio interactive, started releasing small updates every two months. Angry Birds is by no means a sophisticated game. You launch birds! A physics simulation runs! Pigs die! Nonetheless, Rovio built it quickly, released it, and is now using it as a launchpad for … everything.
– Overgrowth, by the boys at Wolfire, has been in development for just over two years. Every week, as regular as clockwork, a new build of the alpha goes out to their customers. They’ve just started to get combat working. It’s exciting.
– Natural Selection 2, which has had an open beta for paying customers. Every week, almost as regular as clockwork, a new build goes up on Steam.

Here’s an important note: from a technical perspective, both Minecraft and Dwarf Fortress are awful. Dwarf Fortress will just choke with seventy or more dwarves, and the game itself is full of bugs. The bugs are usually fun bugs, but they’re bugs nonetheless. Minecraft was written by somebody who is not an expert on working in 3D, and it shows. On complex worlds, Minecraft will lag, and will lag brutally. Riding a boat, for instance, is a particularly slow experience. More generally, Minecraft’s renderer is inefficient, operating primarily by brute force, and there are a number of ways it could be faster. Minecraft itself, in many ways, is also very ugly. If I wrote the Minecraft renderer, I would probably use a marching cubes style surface extraction algorithm, and spatial hashing for a compact representation of the voxel world, and I would probably do a number of clever things to speed things up and make it prettier… and I would probably never ship the resulting product, and would lose out on the opportunity to make millions of dollars. I can’t comment about Overgrowth or Natural Selection 2, but I am sure that they have their set of technical sins that they will have to bear. Both Notch and the Toady One have decided to go out and build a product that they can release now, and to deal with the technical problems later. In the mean time, they’re going to go out and build a game that is fun, and they’re going to make sure it’s fun before they start optimizing and thinking about clever ways to perform iso-surface extraction. Technical debt! Gotta love it.

(Here’s another thing about the Wolfire guys that is worth nothing: Overgrowth runs on the back of a *lot* of open source code. The Wolfire folks use open source packages for physics, scripting, and even their user interface. (I’m somewhat skeptical about their decision to write their entire UI in HTML5 using Awesomium, but we’ll see how that one pans out. They’re certainly getting great mileage from it.) Natural Selection 2 also uses open source libraries for physics and scripting. If you crack open Angry Birds, you will see the excellent Box2D physics engine – which is freely available, and ready for you to give it a spin – staring back at you. This is one of the other guiding principles of a lean startup: to heck with Not-Invented-Here syndrome, start duct-taping code together!)

(Dungeons of Dredmor… well, the Dredmor codebase is basically a bunch of open source libraries attached with small pieces of string. We use libexpat for our XML needs, we use SDL for our rendering needs, we use a handful of other open source libraries for everything from audio playback to image loading… and these are things that I don’t have to write.)

Let’s also look at some indie games that are not lean. Here is some indie vaporware:

– Infinity, The Quest For Earth. I started following these guys in 2005 back when I was working for Derek Smart. It is now 2011, and no release is in sight. (Derek, incidentally, released something like six games in the intervening six years.)
– Fez. Fez has been in development for a long, long time. Here is a teaser trailer from 2007. It won a bunch of IGF awards in 2008. It is now 2011. Apparently, Fez is getting released for XBLA in 2011. We will see.
– Sushi Bar Samurai. After being selected for the Penny Arcade Expo in 2008, development now appears to be dead. Casey Muratori is, without a doubt, one of the best programmers in my passing circle of acquaintances, but… well, these things happen. It’s just sort of depressing.

Could a lean startup release model have helped these three titles? Perhaps. The little trickles of information that their developers are content to release indicates that, yes, various versions of the games in question have existed, and maybe various versions of the game could start being released to customers (albeit with the promise of future upgrades, leading to a completed work.)

Some mainstream video games could also, perhaps, have benefited from an opportunity to release early and often to the public, and then to incorporate massive customer feedback to figure out their mistakes:

– Epic Mickey, by Junction Point Interactive. I am singling this out because every single review of Epic Mickey higlights the fact that the camera model that Junction Point chose to use is broken, broken, and broken. Third person cameras are a hard problem, and we may never know the exact story of why Warren Spector – who should know better! – chose to ship a game with such a disastrous camera. There may have been external pressures to hurry up and ship. We will never know. What we do know is that by not identifying, and fixing, the broken camera, Junction Point Interactive did not sell as many units of Epic Mickey as they would have hoped. As a result, half their development team got laid off. Would early exposure to real users have revealed this major, major issue? Possibly.
– Final Fantasy XIII, by Square Enix: despite being critically praised for technical innovation, everybody who reviewed Final Fantasy XIII agreed that, well, it wasn’t a game that people actually wanted to play. Following the game’s release, Final Fantasy XIII’s Director, Motomu Toriyama, decided to complain that Square’s customers did not “correctly appreciate the game.” I’m mystified by this one.
– Final Fantasy XIV, also by Square Enix, and probably the most disastrous MMORPG launch in recent history.
– Duke Nukem Forever. (Here, anything would be an improvement.)

This is to say nothing of the countless mainstream game titles that never launch, or that are never even announced. Projects silently, quietly, die in the background, and nobody ever notices. I have previously lambasted people selling Scrum and Agile to the game development industry as sellers of “snake oil”, and I stand by this statement. Claiming that any approach to software development is a silver bullet is… well, it’s a lie, plain and simple.

That said, with the current state of AAA development being what it is – a big, awful mess where you throw millions of dollars at a 24 to 36 month development cycle in an attempt to get your title out the door – it is tempting to look at what Lean Game Development would look like. It may not be for every game, but isn’t it an interesting idea? Why not launch the bare bones of a game, see what your customers want in a game, and then use this knowledge to refine the product? Why not raise the price as you go, to promote early adoption? Why are we committing ourselves to this notion that a game must be released as a grand, unified product that represents the distillation of one game developer’s vision, produced in isolation and cunningly labored over for months and years, until it is released into the world… all without any idea as to whether or not customers will actually want to buy the game, and without any idea about whether or not the game is actually fun?

Why not, indeed?

Next Installment: We imagine what a lean game might look like, and we learn that Valve Already Did It (after completely, and utterly, screwing it up.)