The State of Game Development
On August 3, 2004, Doom 3 was officially released by iD software after four years of work by some of the most talented individuals in the gaming industry. Interviews with the development staff report that from early 2004 until the recent release, 80 hour work weeks were normal and Sunday was the only official day off in the iD offices.
It would be an understatement to say that things have changed in the gaming industry over the last twenty years. Doom 3 had a four-year development cycle and an all-star development team. This may be slightly atypical, but two-year development cycles and teams of 50 or more are commonplace these days. In 1984, the average Atari 2600 video game was created by one programmer in three months. A banner title might involve two or three programmers and an artist working over a six month period.
So why do games take so long to bring to market these days?
There are some obvious answers to this question. Games today are many times more complex than games were even a few years ago. Recreating every three-dimensional point of a complex cave environment is going to take an artist several orders of magnitude more time than dropping a few rough dots on an Atari 2600's 196x160 screen and calling it a cave environment. Similarly, producing a full 5.1 surround sound track for a modern game requires sound engineers and advanced programming libraries. Triggering a few blips and bleeps is much easier.
But there are also some less obvious reasons for longer development cycles. In the old days, a programmer with a text editor and a few programs could create an entire game. However, to create all the complex content and code required for a modern game, programmers and artists need powerful tools such as 3-d modelers and advanced debuggers. Unfortunately, programmers and artists often have to use general purpose tools that are not at all well suited to game development. And when domain-specific tools do exist, such as in console game development, the tools are often unstable and immature due to the short life span of any particular console system. A multi-platform console world further complicates development by multiplying all of the issues of developing for a single platform by the number of platforms on which you intend to deliver your game.
An excellent summary of these issues can be found in the article Game Development: Harder Than You Think by Jonathan Blow.
But through all of this, one very important thing hasn't changed much. In 2004, just like in 1984, most players buy a game, play it for a while, and then move on. With the exception of a few genres, the lifespan of a single title is very short. The number of hours required for a brand new player to finish "Super Mario Bros." and "Metal Gear Solid 2" are about equal. But the amount of man hours that went into the creation of each is not even comparable.
Open Source is not an Advantage in Game Development
It is clear that building a top-quality game is harder than ever. The amazing amount of work required, the short schedules, and the need for experts in many domains all combine to make game development one of the most challenging areas of software development. Will developing a game as open source make things easier?
Open source works best as a development model when the useful lifespan of an application is very long. It allows many users to benefit from the application and provides an opportunity for users to become volunteer developers, thus furthering the project. The continued interest of the public drives the developers long after personal interest or utility has faded. This is the state of maximum efficiency for open source and provides two huge advantages over closed development: Users give back to the project and developers can directly build top of all of the code that has gone before them. Unfortunately, neither of these advantages exist in a meaningful way for open source games.
Most games, by their very nature, have a relatively short lifespan. This is natural. A game provides the user with an experience, but ultimately the user moves on. Since a single user is only interested in the game for a short period of time, it is unlikely that they will contribute much back to the open-source project.
In a modern game, the majority of work is involved in creating the art and story assets, not the programming. While there are plenty of open source game engines around, the bulk of a game must be created from scratch. Creating world class art and music is hard and you can not build on what has gone before you in the same way that you can with software. You can take the code for an algorithm, improve it, and use it to solve a problem. You can't directly take a musical score from an older game, change a few notes, and have a better score. You will just have an odd piece of music that sounds like a poor version of the original.
Let's use the real-world example of Doom 3. Could this be developed more efficiently as an open source project?
- "Open Source Games, Page 1/2"
- "Open Source Games, Page 2/2"