selectparks - OSnews on Open Source Game Dev

OSnews has an article on open source game development by Adam Geitgey, developer of desktop utilities for the KDE project. I don't know how it is that he came to be writing about such a topic, but he raises a few valid points, and several bad ones..

Adam is right in assuming that on a per-game basis there are difficulties in open team development, but he makes the mistake of thinking this has anything to do with open-source game development itself. He's absolutely right in saying that there are very few, or no, commercially successful titles derived from open team development. The term 'open-source' applies to a way of licensing code for free and easy distribution and/or manipulation. It doesn't relate to anything else other than in a very loose analagous sense. You can't make an 'open-source film', though you can make a copyleft film for instance.

Open-source code has advantaged many game development teams in that they aren't forced to reinvent the brick; they can simply use and redistribute great code written by someone else. Examples of this are really boring things like a sound manager, communications layer or texture processing tools.

Tons of open-source code libraries are used already in commercial projects for this reason: OpenGL, Python, Ruby, SDL, DevIL, OpenAL, Java to name a few. To what level of open-source development is he talking about here? Is he using mistaking term 'open-source' to mean a publically developed game? Secondly, whether or not a development team release the code for open development during the development cycle is their business, and in many cases is unwise given the possible loss of focus on a specific development project. Why would you want 500 people working on writing an engine for a AAA Second Person Fish Throwing Game? You wouldn't. Instead Adam assumes that opensource development always implies community development, let alone during the game production cycle:

"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.

I don't know why he doesn't see the alternative option of releasing the source after the game has been released, to be further developed later. This is a way of retaining control of the project, it's obligations to the inaugural release date and to the publishers. Open-source development mustn't be confused with collaborative or open team development, it's just really well suited to this way of working where programming is concerned.

Open Source is a term given to sourcecode that is released under a license sufficient enough to allow public development and distribution. Whether a project is developed in a closed environment or not doesn't define whether it is or isn't open-source in itself.

On a commercial level, what is the developed engine really worth other than its re-use value? How much money can a game developer make on licensing out an engine they have made? ID software and Epic Games might be licensing their source out to developers with some success, but really no one else is (though many are trying). Looking at the list of takers for ID's Quake3 engine, few can afford, or justify, the $US450,000 ticket on the code. It is simply out of the reach for almost everyone, and those that can afford it would often rather bring their own pie to the table. For this reason, Open Source game development is practical and integral to the future of independent gaming; small teams with innovative ideas can actually afford to make a game without having to work with expensive proprietary code already rigged up for making a certain kind of game. However even large companies like Activision are recognising real advantages in releasing the source of their engine for the big selling game CTPII, after the development cycle. This is so a community of developers can freely extend the development of the engine after the market life of the project for use by the originators, or anyone else later.

"On 28 October 2003, Activision released the source code for Call to Power II. This part of our CtP2 section is dedicated to the CtP2 Source Code Project: the collective effort by the Apolyton CtP2 community to document and improve the source code of the game."

Anyway, it is really a question of critical mass in the source pool. With enough free source available (including libraries, API's and whole engine projects) to make nearly any kind of game, as is happening right now, small to medium teams can quickly develop a specific project with the primary budget being dedicated to human labour, not licenses and legalities.

Companies like Radon Labs have really cottoned onto ths, and looking at the commercial games derived from their own Nebula engine, open-source game development is really working, and working commercially for the developers.

Aside from the topic of engine code, Adam says that a core problem is that the game-data is too expensive to produce to simply give away. Not being source, but being assets, it seems silly to consider this at all, though I'm not sure I understand what he means to say here. Does he really mean 'shareware' data? Ironically, it's on the level of separating the engine from the assets that viable business models can be built out of open source game projects.

Looking at the way that ATARI dealt with the successful Linux Client for Neverwinter Nights reveals a productive trend toward this end. Game data is sold, the game client is free (though in their case not open-source). Ryzom are doing the same, though their engine is open source.

While being a good base for discussing the problems of open team game development, I am a left a bit confused by what Adam means by an 'open-source development model' as though it's something applied to any form of collaborative work. Is this just a funky tabletop term I should have picked up at CalArts or Ars Electronica?

Read the article here.