Despite the impressive list of achievements of open source software, it can be argued that there have not been any world-class games created under the open source banner. Sure, several old games like Doom and Quake have been gifted to the open source community, but there are no comparable original creations in this area. One should not expect this situation to change anytime soon, because the open source development model does not make sense for game development.
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 196×160 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
Let’s use the real-world example of Doom 3. Could this be developed more efficiently as an open source project?
The artists at iD software put hours of work into creating and testing each and every room, pipe, box, or bloody corpse in Doom 3. This is comparable to the hours of work a developer would invest in creating and testing each and every function in a spreadsheet’s math library.
Now, just like testing each spreadsheet function, the artists must continually test each room in the game to make sure textures line up, the scripted actions trigger, the difficulty is appropriate, and so on.
Unfortunately, “content-based” games are a one-time experience. A user can’t experience a game on an emotional level if she is playing through the same level hundreds of times to see minor improvements and new features.
A spreadsheet developer can release a new beta version to testers every week to get feedback on how well the new functions he has implemented perform for the users. The users appreciate the progress and and application becomes more valuable to them with each release.
A game instead becomes less relevant with each minor release. The user pool has experienced it and has already moved on. The developer gets very little benefit from users contributing back to the project because most users do not stay interested in the project for very long.
Doom 3 was quite playable half way through its development cycle. That means with two years of full-time development left, in an open source world, players would already be playing it. Two years is a long time in the gaming world. It would be very hard to keep any sort of public interest alive with weekly test releases where the only change might be that a weapon was tweaked, a room was added halfway through the game, the lighting was adjusted, or load time was slightly reduced. From the audience perspective, games don’t get better gradually. That would be like expecting the general public to sit through the same movie every week for two years as the editing was tuned and small scenes were gradually added. Not only would the
audience not enjoy it, they would also be likely to riot after about six months of showings.
The other main advantage of open source is the ability to build on existing code and art. Now imagine that the developers for our open source Doom 3 can take the art from Doom 2 to use as a base for Doom 3. But this isn’t very useful. The artist can’t load the art for an Imp monster circa 1993 into The GIMP, apply a filter, and suddenly have an amazing 3-d model with bump mapping. In fact, the only area of game development where reuse is a major advantage is the ability to use an existing game engine. But most closed source developers already do this.
Some might argue that the rise of the Creative Commons Share Alike license in the art community might create a pool of art and music that open source game developers can draw from. At a high level, that is true. But almost all games need music, sound effects, and art custom designed to fit the needs and overall feel of the game. Otherwise, the end result will be a game that looks and sounds like a
hundreds of sound clips and pictures put into a blender set on puree.
So does Open Source make sense for games?
World-class game development is hard and getting harder every day. Open source development has many advantages over closed development in many cases. However, these advantages become largely null when developing cutting-edge games. As a result, it is very difficult to finish such a large undertaking using the open source development
Closed source development also has many advantages. Among those is the ability to attract high-caliber individuals and allow them to focus directly on a project for two or more years at a time, without worrying how they will pay their bills. The level of talent may be
very high in the open source community, but most individuals can not afford to spend two years without interruption on one project without compensation, especially one that has a very short useful lifespan when completed.
It is important to weigh the advantages of each model of development before choosing how to approach a particular project. In many cases, an open source approach may yield many gains, but high-end game development is generally not one of those cases.
Where does Open Source fit in gaming?
Of course there are exceptions to every rule. Open source might not be the best choice for developing the next so-called “AAA level” story-based shooter, but it works pretty well for games with unusually long lifespans. And that is exactly where projects like
this have succeeded wildly. Examples include BZFlag, FreeCiv, and FrozenBubble. You can also include the entire multi-player Game Modding community in this category. That is a great example of playing off of the strengths of open development, while avoiding many
of the pitfalls.
It is also possible that someone might come along and turn the open source development system on its head. One attempt that comes to mind is the HappyPenguin Game of the Month model. Each month, volunteers take an existing open source game and try to
flesh it out into a finished product as quickly as possible. While this is a new idea and success has been mixed, projects like this might eventually stumble on a development model that works.
About the Author:
Adam Geitgey is a professional Software Engineer and the author of the open source application SuperKaramba. Special thanks to Shane Rimmer for suggestions and proof reading.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.