- Introduction
- Why games are different
- Games are drawn, not programmed
- Commercial games for free
- My engine runs faster than yours
- Random advice for game hackers
- Acknowledgements
- About the author
Everyone agrees that Linux needs to have more games. Recently it has even started to look as if it might get them, as Loki gears up to fill the void by porting successful Windows titles, but there are some problems with this rosy scenario. For one, the Loki games are just closed ports of commercial products, which is not at all what the Free Software crowd would like to see. For another, where are the bazaar mode alternatives that the Open Source enthusiasts say we are supposed to be so good at creating for ourselves? Hackers like to work on things that are cool. They will do boring, necessary work every now and then, but only after all the more interesting options have been exhausted (just look at how the Linux GUI environments consider themeable checkboxes to be at least as important as having a usable file selector). Games are cool, and most programmers enjoy writing them, and yet this is one area where Linux is lagging far behind the commercial offerings available on Windows platforms. At first glance, this doesn’t seem to make a lot of sense. In this article I will explain why I think that games are fundamentally different to most types of software. I will suggest a few reasons why an open source approach could nevertheless make sense for a commercial game developer, and also point out what I see as the major stumbling blocks that are making it hard for hackers to produce a commercial quality game.
In his essay “The Magic Cauldron”, Eric Raymond argues that “software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry”. Games, however, are part of the small subset not covered by this “largely”. They do not have support costs. Interoperability and reliability are irrelevant. There is nothing to be gained from a process of peer review and incremental improvement, when the revenue from a commercial game comes almost entirely in the first month after release. The average user wants their software to be reliable, flexible, and most importantly, predictable. If you design everything according to the principle of least surprise, people will be happy with it, and are very likely to go on using the same program for years on end. Game players, on the other hand, want to be entertained. They demand a constant turnover of new games, and place a high value on novelty and originality. Most of them will settle for novelty alone if you can’t manage to come up with anything truly original (witness the continuing popularity of genre titles like first person shooters and car racers), but nobody is interested in a game that looks too much like something they’ve already played. Counting “different” as more important than “better” flatly contradicts the whole point of how bazaar mode software development works, and that’s why we haven’t yet seen any spectacular games coming from the Internet. As a case in point, I recently finished playing Grim Fandango, which is a truly superb adventure game by Lucasarts. The only glitch was a brief period in the middle of the game, when performance ground to a halt and it became almost unplayable. This was probably some sort of memory management or caching error that was causing it to constantly reload the same data from the CD, and if I had the source, I’m willing to bet that I could have fixed it within a few hours. I don’t think I would have bothered, though, because by the time I’d repaired this problem, I would have already finished the game. There is very little motivation to spend time improving a program that you will never again want to run, and even if I had been able to send a patch back to Lucasarts, the rest of the world would have finished the game before they could get around to making a bugfix release. This industry is fast paced, and the developers will be hard at work on their next project probably even before the first title hits the shelves. There is no point in enhancing something that has already become a piece of history. In “The Magic Cauldron”, Eric Raymond suggests a number of possible models for making money from an open source product. A few of these are potentially relevant to games, but most are not. At some point it may be possible to use free games as a way to sell online multiplayer services, but at the moment this only applies to a few specialized genres (eg. Ultima Online), and the potential revenues are unlikely to cover development costs unless you also charge for the client software. You can’t use free games to sell hardware, given an environment where Nintendo, Sega, and Sony are already virtually giving away their hardware in order to sell games. You can try to develop brand recognition, but although this is a big issue for most publishers, it doesn’t translate directly into revenue because your franchise consists of a string of game sequels, rather than other products which can be sold on the back of a free game. Some of the more hardcore gamers might like to think that this could work, but as far as the general public is concerned, games borrow from popular music and film cultures, not the other way around (Lara Croft notwithstanding 🙂 So it looks grim. Collaborative, incremental development processes don’t work too well for one-shot, sales oriented products, and commercial companies have nothing to gain from freeing their sources when there is no continuing development overhead. With this in mind, I believe that open source will only become relevant for games once people realize that the underlying technology is actually a very different thing from the game itself.
Once upon a time, programmers sat in bedrooms and wrote Space Invaders. It didn’t matter that they lacked any artistic ability, because nobody can do good graphics in an 8×8 monochrome grid. Hardware improved. It is much more difficult to make a nice looking sprite when you have a 32×32 grid and 16 different colors to choose from. Game companies hired artists so the programmers wouldn’t have to bother about this. Games started to look much nicer. Hardware improved some more. Some bright spark figured out how to fake a 3d rendering engine so that it would run quickly enough on a standard PC, and quickly became very rich. Many other people jumped on board and started faking their own engines, inventing a constant stream of better and better tricks to make it run faster, look better. Some people became rich, while others did not: the competition was intense. Because these engines were so dependent on clever programming hacks, the particular choice of rendering method made a huge difference to what was possible, and the artists just had to do the best they could with whatever technology the programmer gave them. These days, any idiot can write a 3d engine. You call routines from your favorite 3d API, and the hardware does all the tricky stuff for you. So what if it runs too slowly: next year the machines will be faster, and it will all be ok then. Of course there is still a role for skilled programmers, and a well written engine can run several times faster than a more simplistic version, but in the end it just doesn’t make all that much difference. So what if your hyperparabolic quadriwhatsit buffering scheme has some amazing property that hasn’t even been invented yet, because in the end, it all comes down to what your artists are able to do with it. A good game artist can do wonders with a few polygons and a texture map, while a poor one will make an ugly game, no matter how technically advanced your engine might be. The role of the programmer now consists of writing good tools and trying to make life as easy as possible for the artists and level designers, rather than leading from the front with state of the art technology. If you don’t believe me, consider what Valve did when they licensed the Quake engine from ID Software. Half Life was a huge success, not because of the underlying engine, but because of the level design, the enemy AI, and most importantly, the immersion in a vivid and convincing environment. They probably had to make quite a few engine enhancements in order to do all this stuff, but it was the stuff that sold the game, not the enhancements themselves. The interesting thing is that nobody seems to have realized quite how important the artists and level designers have become. Just take a look at their average salaries: it isn’t at all unusual to find a group of equally talented programmers and artists working together on a team, but with the programmers earning an order of magnitude more for their labors. If asked, most managers will explain this as a result of skilled programmers being much harder to find. But great artists are equally rare, and just as essential to the success of a project. The real difference is that it is very obvious when someone can’t program (because the game doesn’t run), whereas it takes a subjective value judgment to tell whether an artist is any good. I think that most game artists are underpaid, and most programmers are way overpaid. This being so, if I was a game development company I would be looking really hard to find ways of reducing my programmer salary expenses. One obvious approach would be to open source your engine, and let other people improve it for you. Free software projects are equally likely to undervalue the importance of having good artists. Partly this is because there just aren’t all that many artists hanging around in hacker circles, so everyone has got used to making do without, but it may also be because hackers tend to be suspicious of superficial appearances, priding themselves on knowing how to do obscure and powerful things with pure textual information. Which is all very well, but games are primarily entertainment, not art. My kid brother likes pretty explosions.
In order to make money from your game, you need a product that you can put on the shelves and sell to people. I believe that in many cases, an open source approach may be a useful way to develop the code that lives inside this box. You are unlikely to ever see a bazaar style interaction with your final users, who will play your game once and then forget about it, but if done right, you may well be able to co-opt other game developers into helping to improve your codebase. Note: in a few very exceptional cases, the most successful titles can benefit from users porting them to new platforms and enhancing them with new levels, weapons, etc. This can happen even with closed source products (eg. Doom and Quake mods), but experience shows that it only works for the most successful 0.001% of games. A number of other developers have tried to encourage this sort of user involvement by releasing level design utilities, but these efforts have tended to be met with a stony silence. It seems to me that the most sensible strategy would be a two pronged approach. You sell a shrink-wrapped product to one set of users, while giving away your sources to another group of people, who are your peers working on different game development projects. This is significantly different to the classic Linux model where all users are potential co-developers, but it makes sense if you split the development process into two conceptual parts. Start thinking of your job as being to supply game engines and tools to the artists and designers on your team, who will then then use this system to create the product that is sold on the shelves. Open source ideas might not apply very well to the end product of commercial game development, but they work superbly for reusable infrastructure projects like a game engine, where your artists are the users. Current game projects don’t have anywhere near this clear a split, but things are clearly moving in that direction. The only reason we can’t do this today is because nobody has yet written a flexible enough engine, but that is exactly what open source, internet style development is good at. Most game companies have developed a number of in-house utilities, editors, file converters, and in some cases actual code libraries. These are often very rough and highly specialized for a specific task, but would be a prime candidate for open sourcing. If you take the small amount of extra trouble to write these tools in a slightly more generic way, there is a very good chance that other people will take up the burden of improving and maintaining them for you. Likewise for the support code used in the game itself: basic things like resource management, text plotting, and object rendering get written over and over again, because the old version is never quite flexible enough to work in the current project. If these things could be done once, properly and openly, it would save a great deal of wasted time for everyone. Some companies have tried to standardize these things internally, but usually don’t have the resources to do a suitably thorough job of it. This sort of helper project is all very well, but the real bonus will be if you can convince other developers to build their entire games on top of your engine, so you will be able to gather up their enhancements for use in future products of your own. You need to find a balance between keeping enough material back that you will still have something to sell, while giving enough away that other developers will find it attractive. If you just release a few sources without the infrastructure and support data needed to compile and experiment with them, this is unlikely to be picked up by anyone else. One approach would be to release the sources, along with data for the first couple of levels, under an open source license, while selling the remaining level data as your commercial product. To other developers, this looks like an open source system that can easily be adapted for their own needs. To users, it doesn’t look any different to the current tradition of making the first couple of levels available as a free demo download. Another option would be to keep the more specialized parts of the game source private, while releasing the generic components in library form. This probably feels safer to people used to thinking in terms of closed source and intellectual property, but I believe it is actually a much worse idea. Such libraries would need extensive documentation, example programs, and at least some level of support before they would be useful to anyone else, which almost certainly isn’t something you want to get involved with. If you release a complete buildable and runnable copy of your game, on the other hand, it can to some extent serve as its own documentation, so this work will be greatly reduced. No matter how you do it, extreme modularity will be crucial. The idea is that you will be able to gather up any improvements for your own later use, but this isn’t going to work if the code splinters in a million different directions. Since you know for a fact that everybody will be changing the top level, game specific parts, you need to make sure that these are extremely well separated from the sections you are wanting to reuse. I would suggest building it as a number of individual libraries that are then linked into the game itself, encouraging people to see these libs as reusable code that must be kept in sync with your master version, no matter what hacks they are doing on the rest of the program. In “The Magic Cauldron”, Eric Raymond indirectly suggests a third possibility, when he points to Doom as an example of a game that was initially valuable intellectual property but later became open source. I think he is mistaken about this, though, because he failed to realize exactly how fast the game industry moves. By the time ID released the Doom source code, it was not only well understood, but everyone had moved on to the next-but-one generation of rendering technologies. Opening the code was a nice gesture on their part, and it was certainly interesting to get a look at the innards of such a classic game, but ID waited until this was no longer relevant to what people were working on at the time. A couple of projects have grown up around enhanced versions of the Doom code, but these already have a flavor of retrocomputing about them, more in line with the emulation of classic arcade machines than with current game developments. I would argue the exact opposite: if you want to open source any game code, you have to do it straight away. If you wait a year, your code will only be relevant to people who’s technological development is a year behind you, and they will feed you the sort of enhancements that you were working on yourself a year ago. This defeats the whole point of the exercise: it is a nice philanthropic gesture, but you won’t gain any practical benefit from it.
ID Software has made a lot of money by licensing their game engines to other developers, so for them, going open source would hardly seem sensible. I think they would still be able to sell their own games under an open source model, and they would benefit from a lot of free ports and extra hardware support, but there would be no way for them to keep that licensing revenue from other developers. The crown jewels of intellectual property are alive and well, and viewings can be arranged if the fee is large enough. ID is significantly different to most people, though, because they are concentrating entirely on the multiplayer deathmatch market. Deathmatch play is an exception to the rules because it works more like a sport than a normal game, depending on muscle memory, repetition of a few basic learned actions, and usually taking place in a very limited number of arenas. Serious deathmatch players are likely to stick with the same game for years on end, and although they will buy and play new singleplayer games for variety, they go back to their longstanding favorite when they want some multiplayer action. It is very rare for anyone to replay the same level in a singleplayer mode, but every deathmatch player has their few personal favorites. The sports parallel is especially obvious if you look at the team culture of the Quake clans. In a sport, the interest comes from what you do, rather than where you do it. A rectangular area of grass and an inflated bit of leather has been sufficient equipment for the last couple of thousand years, and Quake is unlikely to change this. Varied and complex environments are not especially relevant, so although ID can make an incredible amount of money by selling technical improvements of the same basic concept, this is a single huge market in which other companies can only hope to profit after they manage to topple the reigning champion. For most developers, it is more appealing to stick with more traditional types of game, rather than risking a failed attempt at taking over the deathmatch sport market (this is different to sports simulations, which are in fact games. Huh 🙂 The key distinction is that games thrive on variety and complexity: think storylines, action cards, and a little plastic dog staying in an overpriced hotel, rather than a bunch of guys running around in a field. To sell a game on purely technical merits is really, really hard. It takes years of development and massive R&D costs just to reach parity with the current state of the art, and there is no guarantee of getting a payoff at the end of all this. Most companies don’t even attempt it, preferring to develop a “good enough” engine, and then concentrate on making a good game with it. In this situation, intellectual property is meaningless, and there is absolutely no reason not to open up that source code. You have nothing to lose by giving away secrets that don’t exist, and everything to gain if collaborative development can move your technology just that little bit closer to perfection. Paradoxically, the technical market leaders are also usually the most open about how their software works. John Carmack regularly updates his .plan with detailed accounts of the latest developments and ideas relating to his engines, and all the basic techniques used by Quake were described in print long before the game itself was released. There is plenty of paranoia and excessive secrecy in the games industry, but for some reason this seems to be concentrated in places that don’t actually have all that many secrets to hide. One explanation for this seeming contradiction is that as a breed, game coders tend to have somewhat oversized egos. If you have technology that everyone else covets, you can stroke your ego by parading it in public. If you are only using standard and widely understood techniques, on the other hand, it is all too easy to mentally exaggerate the value and originality of your work. The marketing department loves this sort of idea, and will start spooning it out to any passing journalists, and the next thing you know your programmer ego has swollen beyond all proportion, and the cycle repeats. Egos are harmful to any kind of software development, but especially fatal to collaborative work. All game developers, regardless of whether they are contemplating an open source approach, would do well to introvert a bit and see whether they might be suffering from this deadly contagion. You wouldn’t believe how many times I have seen people insist that they can’t rely on malloc() because it will cause fragmentation problems, only to replace it with their own memory manager that fragments far more seriously than the one from libc! Actually, a lot (perhaps a majority?) of commercially developed game code is really bad. And I mean _really_ bad. I’ve written plenty of this myself, so I can speak as something of an authority here 🙂 Games are developed to a rigid deadline, with the knowledge that once they ship, that codebase is finished and you will never have to touch it ever again. Early on in a project you do all the right software engineering things, because after all, you are going to be working with this code for the next 18 months or so, and this will be easier if you have a solid framework to build on. Come 2 am on a Sunday morning, though, with a month to go until the deadline, no end in sight, and a pile of bug reports a mile deep, all that stuff goes right out the window. Who cares if this bug is actually a symptom of a basic design flaw, as long as you can patch over it? Who cares if that patch introduces other more subtle problems, because as long as you can get it through the next few months of testing without anybody noticing them, it will be finished and you won’t have to worry about it ever again. If you work in the games industry, and think that your software is valuable intellectual property, stop and ask yourself: are you honestly worried that other companies might gain a competitive advantage from your code, or are you just embarrassed to let them see it?
This section is aimed at internet game hackers: industry professionals should go away now. This is the bit where I forget about the nice idea of getting commercial developers to give away their sources, and concentrate instead on the truly fantastic idea of writing better sources ourselves. This is my chance to point out various things I’ve noticed while observing and participating in game related projects on the net, and mention a few things that I think may currently be getting in our way. In terms of general gaming infrastructure, there are two important things currently missing from Linux: a high performance 3d API, and a quality editor for building 3d meshes. The API issue is well on the way to being resolved, thanks to the great work being done on MESA and XFree86 by people like Precision Insight, but without a good modeling package, game developers are stuck having to use expensive commercial software in a dual boot configuration (before I get flamed to pieces for this, yes, I know that there are several 3d modelers for Linux, but none of these come even remotely close to what is needed for quickly building quality game artwork). So, somebody needs to sit down and do for 3D Studio Max what the Gimp did for Photoshop. That is a couple of years of hard coding, and you won’t get your name on the credits of any hit games for it, but it is probably the single best thing anyone could do to raise the profile of Linux as a game development platform. The problem with writing games on the net is that good ones need to be designed around a consistent style, artistic vision, or whatever you prefer to call it. They need to have a carefully graduated progression of difficulty from one level to the next, and there has to be a fixed point in the development cycle at which you can say “ok, this game is now complete”. In other words, they work better in cathedrals than bazaars, and it can actually be quite harmful to have hundreds of people with different ideas all pulling in their own directions. Most programs gain strength by integrating all these various ideas, but with games you are usually better off letting each new idea have separate life in a game of its own. It is obviously impossible for one person to make a commercially polished game singlehandedly, so it is tempting to ask for help on the net and try to put a big team together. All my experiences to date convince me that this is a big mistake, though, for two reasons. One: although you may well get a lot of response to this type of request, you are unlikely to find more than one person who agrees on what type of game they want to make, so you will waste all your energy in pointless debates, ending up a year or so later with a great logo, a fancy website, and no game. Two: in order to attract other developers to an open source project, you need to have a plausible promise of what it might someday become. A post on usenet can never be plausible, though, because without code to back it up, this is just hot air. You certainly don’t want to start your project by attracting the sort of people who get excited about hot air. It seems to me that a more useful approach would be to look at the strengths of internet software development, and try to capitalize on these. Unix is built on a basis of standard protocols, a solid infrastructure, and many small pieces that somehow combine to produce a working system. Experience shows that hackers are good at building things like this, and also that most of the really successful projects started out as small, personal hacks, and only later grew to world dominating proportions. The games industry is notoriously bad at things like infrastructure and modular code reuse, but we will get a lot further if we model our work on what we are good at, rather than what game programmers on other platforms are bad at. Our community is by no means incapable of the sort of stylistic design and constant search for novelty that games require: just take a look at themes.org. And there is something very important to be learned from that site. UI themes are often produced by non programmers, working on their own in a relatively short timescale, and they tend to be used for a while but then forgotten as people get bored and move on to something new. Not at all unlike a computer game, and I suspect that the most successful open source games will end up working very much like an Enlightenment theme. Smart programmers will write engines, probably building upon many layers of support technology written by other smart programmers, and then the final games can be produced over a period of weeks or months by anyone who has a good idea and knows how to draw. Individual game teams will consist of at most two or three people working together very closely on a shared concept, while the grand scale collaborative work happens on the lower levels that enable them to do this. If you are one of the people who think that Linux should have GNU written in front of it, you probably don’t want to get involved with writing open source games, because that sort of thing is likely to happen a lot. You will spend a couple of years writing a superb game framework, only to find that although the latest hit title does have your name buried away in a readme somewhere, all the kudos is going to the guy who modeled a new version of Lara Croft with bigger breasts. On the plus side, though, if you get the engine right it has the potential to live for much longer than just one game, which is not something that tends to happen with the way games are currently developed. It is no coincidence that my suggestion for how best to write free games is exactly the same as my suggestion for how commercial developers can benefit from open source: if we can make this kind of a game development framework, and especially if we can make it portable between Linux and Windows, that would do wonders to make game companies start thinking about opening up their sources and putting their games on Linux. Anyone who was around in the days of the Atari ST and Amiga is probably thinking that this sounds very much like the old game construction kits, and remembering just how useless those were. But several things have changed since then. As hardware improves, the details of any given implementation have become far less of a limiting factor on what you can do with it, so code reuse becomes more feasible. And being open source, the framework is just a place to start, rather than a box which you have no way to reach outside. But perhaps most importantly of all, we have a number of extremely good scripting languages just sitting around waiting to be embedded. Commercial game developers periodically figure out that high level scripting might make their life easier, but they keep doing it wrong. Either they invent their own specialized languages that are too limited to be really useful, or they use something based on C, in which case they might just as well have written the whole thing in C in the first place. Hacker culture, on the other hand, knows a lot about scripting systems and configurable programs, so we can do this the right way. A word of warning: I’m a little bit concerned to see that some people are working on what look like exact clones of existing games. I just paid a visit to linuxgames.com, and after filtering all the references to Doom, Quake, and Loki from their news page, this left information about three original games, and three clones (of Wipeout, Lemmings, and Civilization). I certainly can’t argue with the judgment of whoever chose those three games as being good ones to clone, but I do dispute the value of doing this at all. Exact duplicates are never going to convince people that Linux has better games than Windows: we need to show people things which they haven’t already played five years ago. There is nothing wrong with copying a genre or borrowing a good idea, but why not try to add a few new ideas along the way, so that you will end up with an improvement rather than an exact copy? And please take the word “clone” out of your project descriptions. This looks like a case of hackers being too honest for their own good, because no matter how true that word may be, it won’t help your cause either with the users who are looking for an exciting new game, or with the lawyers who own the original copyrights. When Nintendo drags you into court with a look and feel lawsuit, it will be much easier to argue your case if you made your plumber some colors other than blue and red, and didn’t say “Mario Clone” at the top of your website! Ultimately, I believe the future of games on Linux will depend on our egos, or rather upon our lack thereof. Game programmers are traditionally very bad at trusting anyone other than themselves to write useful code, but open source development will only work if we can grow up enough to leave this attitude behind us. In this day and age, writing yet another asm optimized texture mapping loop will do very little to advance the cause of getting some quality games running on our favorite OS. But there are plenty more useful things which haven’t already been done, so get to it!
This essay was directly inspired by the writings of Eric S. Raymond (esr@snark.thyrsus.com). I am also indebted to Arron Shutt (version8@ashutt.demon.co.uk) for some fascinating email discussions about the relevance of open source to commercial game projects.
Shawn Hargreaves (shawn@talula.demon.co.uk) makes his living writing commercial console games (http://www.talula.demon.co.uk/xg2/). At weekends, he hacks on free software (http://www.sunsite.auc.dk/allegro/).