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 8x8 monochrome grid.
Hardware improved. It is much more difficult to
make a nice looking sprite when you have a 32x32
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.