Gaming Open Source

By: Dee-Ann LeBlanc
Monday, October 3, 2005 12:18:55 PM EST
URL: http://www.linuxplanet.com/linuxplanet/reports/6030/1/

Opening Ceremonies

Open source software and code pops up within the game industry in numerous ways. On one end of the spectrum there are, of course, the open source games that many of us know and love like FreeCiv and Tux Racer. On the other end are the proprietary games whose source has been opened such as Quake III and other games from Id Software. In the middle are games that might incorporate open source software either within them where legally possible, in the operating systems they run on--some Massively Multiplayer Online RolePlaying Game (MMORPG) worlds run on Linux and the various free BSDs for example, or were built using open source tools.

While attending a Women in Games International event, the opportunity to discuss open source with people actually in the industry came up. Among the attendees were a good cross-section of artists, programmers, publishers, managers, and more, some already in the industry, some going to school in order to build their skills, and some hoping to step over from their current jobs into games.

Open Source Code in Games

The more technical and business-oriented attendees were aware of open source, though some had misconceptions. For example, one speaker when asked about open source said that no serious game company would use open source components, because they had to be in turn open sourced back to the community. When it was pointed out that it completely depends on the license the code was open source under, the speaker then said that who wants to have to pay lawyers to go over all of the licenses?

These statements point out a need for continuing education for the programming and management public on what open source is and how to use it. As open source becomes more commonly used more legal departments will already have their own trusted internal or external analyses of the various licenses as well, which reduces both the time and expense of having to deal with such issues. On the other side of the coin, it behooves the open source community to look at the long list of licenses and consider how simplification--or at least avoiding spawning a never-ending stream of them--could help with open source adoption.

The Open Source Institute's (OSI’s) Statement on License Proliferation shows that the Open Source Institute, which is responsible for approving official open source licenses, has in fact begun to address these issues. According to Laura Majerus, Legal Affairs officer for the OSI, progress has been made in this vein. For starters, they are encouraging people to use existing licenses instead of creating new ones.

They are also in the process of creating a license wizard program that will help developers choose which license is right for their project. In order to reduce the number of licenses currently in use, they are encouraging license creators to “de-recommend” some of their own licenses to shrink the pool. Intel has done so for its Intel Open Source License, Sun has de-recommended its Sun Industry Standards Source License, Larry Rosen has de-recommended the older OSL and AFL licenses, and Jabber has de-recommended its Jabber Source Software License.

Majerus also points out that license proliferation actually has many different meanings depending on the confusion and difficulties particular people run into. She cites, “Some people focus on the large number of OSI-approved licenses and say that it's too hard for people to choose among them. Others point out the difficulty of doing legal reviews for open source customers if an open source project contains pieces that are each covered by different licenses. Others point to the difficulty of deciding how so many licenses interoperate and whether they can be used with each other.” Hopefully reducing the number of licenses in use and further education efforts from OSI and others will help to ameliorate these problems.

However, there is also a completely different reason that open source code has not typically made it into mainstream games, that has nothing at all to do with licensing, FUD, or anything else. Many speakers at this conference commented that game programmers seem to have this base need to "reinvent the wheel" rather than using existing code and libraries. This includes a resistance to using proprietary products such as existing commercial middleware--engines for handling physics, graphics, character animation, and more, that game developers can purchase rather than building on their own--so in fact this issue doesn't entirely or even mostly hinge on open source per se. There are many in the game industry who would like to see more middleware come into use in order to reduce the time and cost involved in building absolutely everything from scratch when this often isn't really necessary.

Open Source Tools

There is more to open source than just raw code. Those who don't choose to use open source code in their games still might end up using open source tools in game development, as server platforms, as office programs, and more. One new game company, Edocero, has used open source on many levels in order to make it possible for them to build and release their first game on a limited budget. In the office, the company uses OpenOffice.org for their document processing needs. The larger savings, though, came in the form of using Blender to actually develop the game.

The advantage of using Blender for a brand new game company is that this open source, free software acts as a modeling program, an animation program, and a game engine. Modeling software is used to create the three dimensional objects that will exist in the game, everything from rooms to characters things they’ll be picking up. Animation software is then used to bring those objects to life. The game engine’s job is to create and manage the world for the objects to live in. Blender’s strengths are in modeling and animation. For a simple game, Blender can act as a game engine with no problem, but with much more powerful software freely available such as Quake III’s now GPL’ed engine, many people would choose this alternative when possible.

This three-in-one combination--no matter what open source game engine is used--packs a powerful punch when trying to get a first product to market without breaking the bank. Even given the reluctance of many game programmers to use other people’s code, which typically comes into play with the game engine and other components, free modeling and animation software is a crucial help to newcomers to the industry who have incredibly limited budgets.

Add on open source tools like the OpenOffice.org office suite, the Apache Web server, Linux for file serving and backend worlds (in Massively Multiplayer Online Games, for example), ogg vorbis for royalty-free audio formats, cross-platform libraries (such as OpenGL, libSDL, and openAL), Python for a free programming language, and more, and the massive cost of building games can be reduced at least on the software side. Since the major expense in games is typically paying the artists, animators, programmers, designers, testers, and more, this savings can at least help a new company focus on those important people elements and might make the difference between having to skimp on what could be a beautiful design or budget for extra hours to really do a great job.

As some of the other issues are dealt with, perhaps more open source code will make it into commercial games as well.

About the Author

Dee-Ann LeBlanc is the Desktop Editor for Linux Today and LinuxPlanet as well as the author of Linux for Dummies, 6th Edition and numerous other computer books and articles. Between books, articles, and training, she keeps her finger on the pulse of how and where people are using Linux.