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 model.
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.
- "Open Source Games, Page 1/2"
- "Open Source Games, Page 2/2"