Software development according to Game Dev Story

A few days ago I found out about Game Dev Story at this list of meta games (hat tip to Lila Fontes). As the name suggests, it’s a game about having and running a game development company. Seeing as I’ve been interested for a long time in the idea of using software development simulators to understand our assumptions on software development, I decided to go ahead and spend a few bucks to see what it was about (exclusively in the interest of research, of course!).

Game Dev Story screenshotAs a game it’s entertaining but bland, and I wouldn’t really recommend it. It’s addictive, but in a bad way, like potato chips are addictive—you keep wanting to play one more turn, and one more turn after that, and you end up asking yourself why did you waste several hours on a mediocre game. So it’s probably better to stay away from it.

But seeing it as a snapshot of what some game developers think game development is like (or rather, as a snapshot of what they portray a cartoon of game development to be like), I had lots of fun. So how is software development according to this game? Some slightly cynical observations:

Game development follows a bizarre waterfall process. The phases seem to be Inception (where you choose what kind of game you’ll develop; more on that below), Design (you hand in your choices to a trusted employee, and she works based on the idea), Development (where your employees mainly add to the Fun and the Creativity of the game), Post-Alpha Release (emphasis on Graphics), Post-Beta Release (emphasis on Sound), and Debugging (where your employees clean out the bugs added in the previous phases. Its quite possible that the phases are like that mainly for gameplay reasons, and I’m sure most game developers would agree they are just silly.

The requirements are really simple. They’re just about choosing the type and genre of the game you want to build. For instance, Robot Shooter (I’m disappointed that Ogre Racing didn’t do very well…). The designer will take it from there. This phase takes zero time.

Group dynamics (and coordination) are not a factor. Everyone just brings in their attributes (in the case of game development: programming, scenario creation, graphics, sound, and stamina) and gets to work independently. Your success depends almost entirely on aggregated individual genius. There are no coordination overheads or conflicts—the mythical man-month is not mythical at all.

You always know how many bugs are there. No need for any kind of testing, because you have perfect knowledge of the quality of your product.

It’s fairly easy to ship bug-free code. As a manager, it’s just a matter of waiting a little longer until all bugs are sorted out. Debugging, by the way, never introduces bugs of its own.

Heavy turnover is not a problem. In fact it’s encouraged—you use your first employees as stepping stones to get the first couple of products out to the market and get enough money to hire better people, whom you’ll fire to get the real stars. You could also level up and train your employees, but it seems to take too long and too much. New hires don’t have a ramp-up problem; they are immediately productive. Laid off employees don’t take product or organizational knowledge away with them.

One-hundred-and-twenty-hour work weeks are great. When your employees get tired, they go home to rest a little. If your product is in trouble, though, you can always bring out energy drinks. Your employees’ energy will be completely restored, they’ll pull an extremely productive all-nighter, and carry on as efficient as ever once the effect is gone. You can repeat this as many times as you wish, if you have enough energy drinks in stock. Your employees will never ever quit. The only aspect in which there is an element of burnout, perhaps, is that if you ask the same person to take care of an aspect of a product for the second time in a row, they won’t feel as inspired as the first time around.

The boss does nothing. He (it’s always a he) just sits back and sees the rest of the team work while the millions and awards roll in. Commentary on the value that CEOs bring to a company aside, this seems like a dubious strategy for a budding start-up.

I could go on—there are actually some bits of the “simulation” that I liked, such as the fact that generalists are much better for your company than specialists (they can contribute with many aspects of the product and can alternate responsibilities with their peers)—but I think you can get the idea with this. What interests me here the most is to see what aspects of software development people think should be modeled, and how do they see their own profession: in a way it’s a form of theory-building. If you know of other games that do this kind of thing (besides SimSE, which I tried out a few years ago), I’d really like to hear about them!

About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Organizations, Software development. Bookmark the permalink.

7 Responses to Software development according to Game Dev Story

  1. Regarding with addictiveness, it is not something new as it is documented at xkcd:

  2. Pingback: Tweets that mention Software development according to Game Dev Story | Catenary --

  3. Rory Tulk says:

    This particular game looks a lot like another entry in the wave of ‘social games’ found on facebook and that lot. Jonathan Blow as some interesting things to say about this style of design

    I hope that most of your observations are not true of actual game development IRL. Have you found (or are you looking) for interesting dev processes in this space? Agile even? Agile should be down right simple if the requirements are actually very simple (a fun ogre racing game 🙂 )

    • Jorge Aranda says:

      Well, Game Dev Story doesn’t have the “social” component, and fortunately it doesn’t intrude into your non-playing time (you can pause it, and you don’t need to interrupt your work to go promote your next in-game game to ensure good sales). But I think Blow is right (thanks for the link!), in the sense that game designers have figured out how to take advantage of our cognitive reward systems to get us addicted to the games we play.

      I haven’t studies game companies yet, but I’d love to!

  4. Wow says:

    Taking it a bit too seriously? It’s a cheap-o game… (snip) No personal attacks, please –Jorge.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s