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.

A Different kind of Video Game Review

I wanted to precede my soon-to-be regular video game reviews with a short discussion about scoring in game reviews, and an introduction to my particular method of scoring.

Being that more often than not, the focus of the game review reader is on the score more so than the content of a review, I feel it’s an important first step in discussing game reviews to discuss the scoring. It is unfortunate, when you think about it — that people who get paid for their journalistic merits and objective criticism might as well just be paid for their ability to assign arbitrary 1 through 10 values to pieces of software (with levels of subjectivity agreeable to their audience). It is unfortunate, but probably inescapable, as I see it.

The problem is there are just too many games, generally costing upwards of $50. Many people (such as myself) look to reviews to weed out the unworthy so we don’t end up blowing $60 on a flashy new shooter with mediocre gameplay; but I don’t have time to read every review on the planet, obviously, so I set a kind of bar with review sites I trust and the scores they give out. For example, if a game gets a 7.0 from [SOME WEBSITE I TRUST] and I haven’t heard of it before, then I don’t waste my time reading up on why it’s just average. Of course it’s possible the reviewer hates something that I might like about the game (as that’s just the nature of entertainment: it can’t be all objective), but when there are hundreds of games that fall into that category of “might not be bad, but isn’t exactly being praised as good either”, then scores start to matter more than content.

So now that I’ve spelled out the nature of my consternation towards the realm of game reviewing, I’d like to now explain how I hope to distance myself from that world entirely while still prattling on about the quality of games.

First and foremost, as a one-man operation, I don’t intend to be the Ford Motor Company of video game reviews. Enough sites exist to review most every game on the market, and by only reviewing games as I see fit, I hope to make the content more important than the score.

That much was obvious, I think, but perhaps slightly less obvious is that I also intend to write my reviews from the standpoint of a developer speaking to other like-minded developers. The takeaway from these reviews should not be, “Wow, that game sucks, I won’t be buying THAT any time soon!”, but rather, “Wow, that idea was horrible in concept and in practice, I will never be so foolish as to design a mechanic THAT asinine and contrived!” The focus of my reviews will be to talk about [game] design patterns, conventions, innovations – that sort of thing; things that we as developers can look at and hopefully analyze to make our own products better.

Now then, without further ado, here’s the rundown of my scoring system, with categories, weight, et al:

General:

Essentially, the scoring itself will be based on the traditional 1.0 to 10.0 scale (a variant on GameSpot’s old method of rating games, which I happened to think was incredibly clever). The crux of what makes this system different from the slew of other internet game review systems, however, is that the final score will not be some random number I think up in my head, but instead a calculation of several numbers I think up in my head aggregated together to make a number I hadn’t thought up at all.

Scores themselves are divided into five sub-categories. Each category has its own 1 through 10 value for the particular game (no decimal places, to make things easier on me) and its own weight in the final score. I do this because I want the final score to be a very exact (and thereby, hopefully, more objective) value that’s comprised of smaller parts with simpler values (so I can take it piece by piece and say something like, “The core gameplay was superb, but the aesthetic qualities were just mediocre”). Therefore, the score won’t be some testament to my astounding ability to fabricate numerical value from thin air, but instead a reflection of all things said in the review itself.

The system is, of course, subject to change over time, and I’ll update the formula, review scores, and tag stating “last modified on [SOME DATE]” each time that happens. In many ways, the scoring system is just an experiment to try and get the most accurate scores (by my standards) for games, and like all experiments, when it fails, you need to revise it and try again.

Categories:

The score is broken down into five categories listed here from most weight (in the final score) to least:

Foundation (or Core/Primary Gameplay) – this is the basis for the entire game, or in other words, the fulfillment of the high concept. The essential questions of this category are: How is that which the game was built upon (and thereby, what you should be spending most of your time doing) fun? Is it solid in concept and execution? And, can you do it again and again and not get bored?

Design (or Secondary Gameplay) – working off the concept of core gameplay being a “foundation”, the secondary gameplay then becomes that which is built on top of and around the basic foundation, or the design. How is the gameplay used in the surrounding world? In what ways does the game expand upon the basic premise to keep things interesting as the game goes on? How creative are the ways in which the player is forced to work with this core gameplay? Killing the Covenant in Halo is a fun thing to do time and time again, but how fun would it have been if the entire game were set in a dark, underground tunnel? Certainly it was one of the biggest criticisms of the first game that you saw the same corridors time and time again, but very rarely do I see a good place for people to knock off points in a scoring system for that.

Aesthetics – this is the place for graphics, visual art, audio, story, and anything else that doesn’t directly interact with gameplay, but rather serves to make the experience more engaging without directly affecting the way the game is played. Here, however, we may notice an overlap where other systems would make things simply black and white. Take the game Guitar Hero, for instance. To most review systems, the soundtrack in that game might be considered part of some generic “audio” category, but here it wouldn’t fit into aesthetics at all, as it directly affects gameplay. The different song choices with varying levels of inherent difficulty (“I Love Rock ‘n’ Roll” is a far cry from “Bark at the Moon”) is what secondary gameplay is all about; and the quality of the songs themselves greatly contributes to how much fun you have playing them. Aesthetics might be your avatar shredding on stage or the way the game tells you when you miss a note (does the song cut out, just the guitar, or do we simply hear a generic “bad note” sound), but the music itself is all gameplay here.

Embellishments (or Tertiary Gameplay) – this is where all the little things that keep completionists happy come into play. The little unlockables, easter eggs, or just depth of the world are all considerations here – for example, the ability to buy new guitars in Guitar Hero or unlock new trophies in Super Smash Bros. Not every game has these things, but in just about any case they’re nice to have and help keep players coming back for more. This isn’t aesthetic, as it’s still about player-game interaction, just on an almost superficial level in many cases. It’s not just about small things, but rather any part of the gameplay that doesn’t center around or expand upon the high concept.

Innovation – some might say that this category is far too significant to be the bottom of the list, and perhaps some might even say that it shouldn’t be on here at all. I think advancing the status quo for games is important enough to merit it being a factor in any game review written for game developers as a reminder as to how far we’ve come and where we’re going; yet I don’t think it’s necessary to make an amazing game. Little innovations are usually what matter most in this day and age – the refined cover system in Gears of War, the regenerating health bar in Halo – so by and large the commentary for this category will center around those kinds of things. The big purpose of this category more than anything, however, is to say that in order for a game to truly be a 10.0, it must not only be outstandingly fun to play, but also push the boundaries of convention.

Formula:

Finally, here’s the actual formula (again, subject to change) for my scoring system:

Foundation = F

Design = D

Aesthetics = A

Embellishments = E

Innovation = I

F*.50 + D*.20 + A*.15 + E*.10 + I*.05 = Final Score

( Last Updated: 03/21/2008 )

And that’s it. I’ll be using this system in the reviews I make in the weeks to come, so I look forward to seeing how it works in practice as opposed to simply in theory. If you have any thoughts on the matter, please don’t hesitate to share them.

Foreword

Just as a quick introduction about myself, my name is (for those who missed the header at the top) Travis Addair, and I’m a Computer Science major at Northern Arizona University interested in software engineering and actively engaged in ongoing computer/video game development with my father plus a few friends.

The purpose of this blog will be to discuss various projects I’m working on and to comment on some of the new developments/trends going on in the software and game development communities. There may be a few other thoughts and ramblings sprinkled in from time to time, but by and large I intend to keep this as my nexus for the professional rather than personal side of my life, except in instances where the two might overlap.

Stay tuned in the days to come for news on the current “big project”.