The Fall of Waterfall

To me, game development has always seemed like business application development-plus. Game development comes with all the trappings of general software engineering with the added problem of not only having to be functional, but also fun. Beyond that, there are also the elements of art, audio, and story that we inherit from the film industry. Therefore, I couldn’t help but find it interesting when David Gregory kicked off a recent Gamasutra article on iterative development with these words:

Building interactive fun is a very different problem than building any other type of software, because “fun” can’t be planned: you can’t schedule a project with waterfall, execute the schedule perfectly, and expect to get a fun game 100% of the time at the end.

David is right on at least one count— you can’t plan fun— but I think what he fails to realize, or at least failed to point out, is that software development in general is already a tremendously difficult task to plan right from day one, and we as an industry inherit all of that baggage and create even more. Frederick P. Brooks told it like it is back in 1975 when he explained how the waterfall simply falls apart once projects reach a certain size. It’s simply not a viable method for developing software; but why then was it ever adopted in the first place?

In the early days of software engineering, people looked at the process of software creation just like any other engineering task— you start with the design, build the foundation, bring pieces together to construct the whole, test its reliability, and proclaim it finished. As scopes grew larger and stakes got higher, software engineers started to realize that building software is not like building a house, after all. Indeed, as Brooks explained, software isn’t actually built at all, rather it is more akin to being grown.

The problem? Requirements change, designs change, even visions change. The more clients begin to see their products coming into fruition, the more they realize that it isn’t what they need. Some key functionality may be missing, or perhaps something just can’t be done within a reasonable timeframe for a reasonable cost. Whatever the reasons, more often than not, it happens.

So what’s the solution, then? For most companies, it’s adopting good iterative processes and adhering to established best practices. For game development, we need to take it a step further. Our work is very much like IT development, but in some ways even more necessitates the use of practices that reduce failure, show consistent progress, and make the product as good as the vision that gave birth to it.

Getting past that initial head-scratching statement, David’s article does a good job of addressing a lot of the major issues surrounding iterative development and how to make the most of it with game development. So definitely, go check that out and tell me your thoughts.

For next time, I’ll try to have something to talk about besides other people’s opinions.

Developers and Publishers: The Business of Creativity

Recently I’ve taken issue with popular game development website Gamasutra for featuring editorials by “game developers” that seem more focused on making sensational statements than making sense. Probably the best opinion piece to come along and contrast this syndrome in a long time, however, is industry veteran Keith Boesky’s recent article concerning the rough life of the independent console developer. For those of you who aren’t familiar with this man’s legacy (as I wasn’t before reading the footnote at the end of the article), Keith was once president of publisher Eidos Interactive and has a provocative blog filled with such delightful commentary as this:

I really don’t know what happened in the discussions [concerning a potential takeover of Eidos Interactive], but just for the fun of it, let’s make some drama. Imagine prospective acquirers, sitting at the table with a “beleaguered” company thinking they have the upper hand. Rumors of two bidders circulate, and then all of a sudden one’s parent company misses it’s quarter and drops out. Since there is no one else at the table, and the company cannot survive without cash, Warner feels strong. A low ball equity heavy offer is made, the press release indicated the offer was turned down because the equity component was too high. They reason Eidos has to take it, it is their only option right? Wrong. Cuban missile crisis time.

Suffice it to say, if you’re at all interested in the business side of the industry (as anyone remotely involved with making games should be), then you should check out this man’s site.

Anyhow, on to the article at hand.

The fact of the matter is that today, risk is a much larger factor in considering potential investments in game concepts than at any other point in our industry’s lifetime. If a game is a financial success, it’ll get a sequel, regardless of the story’s potential for such a thing (see Bioshock). If it flops, so ends the franchise along with any planned narrative continuation (see Advent Rising). No publisher is willing to shell out $10 million on good faith alone, nor should they. Developers need credentials, some proof of concept, and enough rhetorical merit to prove their game can not only be made, but make money as well.

Keith addresses a few of the fears surrounding our industry’s venture capitalists, and why they’re leading to this morass of creativity those game designers with nothing better to do are so disconcerted about.

. . . publishers want to see working demos, proofs of concept. More burn rate without revenue or commitment. They ask for these further risk mitigating elements because they enter into every negotiation, and every deal like they are committing to build the f*cking pyramids. The reality is, they are not.

I’ll avoid quoting the entirety of Keith’s article in favor of suggesting you just go read for yourself and tell me what you think. I will, however, follow this sentence with what is essentially the moral of Keith’s well-told story:

I am not advocating buying every opportunity or reducing the scope of developer due diligence. I am saying to Mr. Experienced Product Guy, if your gut tells you this game will be fun and the developer has a track record, f*ck the sales dude and go with your gut. Start a long and lean pre production process. For a relatively small amount of money you can see if the game comes together. If it looks good, staff up and build. If it does not, you are not out very much money.

Games are a costly investment, one that could easily blow up in your face if things turn south, but do they really need to be? Publishers who have their developers commit to reasonable, mutually agreed upon milestones can ensure that their investment is made as the game fulfills its vision, and the coming returns are seen by everyone as it happens.

Following this model, the only hurdles developers have left to overcome are ensuring that they adhere to best practices and deliver on what they promise. I believe that independent developers can establish their ethos through a long history of just making games. Start small, establish a fan base, and as revenue grows, so will credibility, until the time is right to go for that big project. The trick is staying afloat until that day finally comes. Marketability and creativity are two sides of the same coin. No game that is truly great can have one without the other and still make a company prosperous.