Return of the Independent Game Developer?

Eugene, Oregon is a surprising little powerhouse of game development.
Originally home to now-defunct Dynamix, it still boasts a handful of
experienced developers, managers, and artists. These days, it's home to
Garage Games, the folks behind
the popular Tribes 2.

Eugene is also the home of the (potentially) annual Independent Game Developers
Conference. Conceived in the middle of September, this early November
event drew around a hundred artists, developers, fans, and press to three
days of talks, demos, and conversations. As Garage Games sponsored the
event, there was a notable bent toward their own community, but that may
be a function of the rapid planning.

Because this was the first such conference (at least in recent
memory), much of the schedule was devoted to justifying its existence.
The reason most often stated was philosophical: there's a sense that it's
just a matter of time before an independent game really makes its mark on
the world. After all, the roots of modern gaming come from founder-lead
companies such as Origin and id. Less explicit is the idea that Garage
Games has understandable commercial concerns. The Tribes 2 community was
very well-represented, and the company plans to market services for
independents.

One such service is code licensing. Tribes 2 is built on the Torque
game engine; an attractive, cross-platform 3D engine with an affinity for
outdoor spaces. Much like other A-list titles (Unreal Tournament and
Quake), the engine can be -- and has been -- reused in other games.
Garage Games recently announced licensing terms that would let independent
developers use Torque in their own games for a virtual pittance. Other
proprietary engines go for hundreds of thousands of dollars.

Of course, Torque is not the only option for a would-be developer with
bigger dreams than bank accounts. The Open Source world is producing a
staggering arsenal of engines and tools -- Crystal Space, WorldForge, and Cube 3D, to name a few. The
idea of adding on to an existing engine also isn't new. Doom flourished
with third-party maps. Modifications for Quake and Half-life took on
lives of their own, leading to commercial releases. The release of the
source code for Doom, Quake, and Quake 2 produced active communities and
add-ons. (Features of later engines have even been backported to earlier
ones.)

Open Source and gaming don't occupy the same niches, though. While
finding programmers is reasonably easy, finding artists and composers for
open source games is difficult. Few game types can get by without art or
sound. As well, the notion that developers write software to scratch
their own itches may not translate well into games. The aesthetics of
games are harder to quantify than the pragmatics of utilities.

Still, there are some similarities between open source and independent
game developers. The first is the nature of the commercial publishing
world. The second is the development process. To succeed, independent
game developers must learn the lessons of successful open source projects.

The Game Publishing Industry

According to the keynote by Garage Games' Jeff Tunnel, the gaming
industry brought in $9.3 billion last year -- in other words, a billion
dollars more than U.S. box office receipts. About two-thirds of
this money went to the console arm, with the rest going to the PC market.
Recent years have seen a great deal of consolidation -- most of the
profits seem to be concentrated in the hands of a few publishers. As the
pie grows larger and the slices grow smaller, the major players tend to
take fewer risks. Sequels and proven formulas rule the day.

Publishers provide three important assets that independent developers
must either provide themselves or go without. First, they offer
ancillaries and distribution channels. Few developers will find stuffing
boxes, printing manuals, and burning CDs as interesting as designing or
coding. These costs are estimated at five to six dollars per unit.

Publishers also provide funding, though often at the cost of control.
They often dictate the direction of a project and sometimes claim
ownership of characters and franchises. Unless you have an amazing
contract (and, likely, an unbelievable track record), accepting money from
a publisher will mean compromising on features, release dates, and
concepts.

The final benefit of a publisher is to provide marketing and sales
opportunities. Product placement in Wal-Mart, surprisingly, can represent
additional sales of 20 to 30 percent. Of course, the buyer may choose
only 15 out of a stable of 100 titles, cursing the remainders with far
lower sales productions. Still, very few independent studios have the
means to fund television commercials or full-page ads in the appropriate
magazines and journals.

The Independence Strategy

Tunnel's thesis is that the current climate favors a resurgence of
independent development. Whereas Richard Garriot had to write Akalabeth
in Assembly in 1979 -- photocopying manuals, and selling diskettes via
mail order -- things are a little easier now.

Distribution is the easiest problem to solve. Increasingly ubiquitous
Internet access alleviates this need somewhat, and burn-on-demand CD
resellers can fill in most of the rest of the gap. (There are
similarities to Linux distributors offering ISO images or even read-only
access to source code repositories.)

Marketing is also achievable, though it takes some creativity.
Distributing demos is easy, if you can afford the bandwidth, and
word-of-mouth spreads pretty well. It's possible to achieve a much better
ratio of advertising dollars to customer, though with a budget of $0, even
one customer would make an asymptotic graph. (Remember, statistics lie.)

The biggest issue is financial. Tunnel strongly believes that
independent developers can survive if they build smaller games and find
their niches. The Mac platform, he claims, is undertapped -- though he
rapidly pointed out that Apple's upper management doesn't believe in
games. You may want to sell a million copies of a game you developed over
three years for $10 million, but you'll have a better chance of selling
20,000 copies of -- let alone finishing -- a game that takes six months to
develop for $5000.

As well, independence offers other advantages. There's a larger
opportunity for creativity and fewer deadlines. There's much less
pressure -- an independent game that sells 25,000 units is a big hit, not
a huge failure. No one can fire you for missing an arbitrary deadline or
because the major publishers tend to follow a boom-and-bust employment
cycle.

Tunnel believes that the flexibility an independent studio has will
lead to great success. With open source tools and opportunities for
Internet collaboration, two barriers to entry are lowered. Independents
will still bear the risks themselves, and the potential rewards are
smaller, but the initial investment is time, not time and
money.

Overall, the message is one of cautious optimism. Few, if any,
independent developers will produce games rivaling the
blockbuster-hopefuls, with multi-million dollar budgets and TV spots
during Buffy the Vampire Slayer. There's room for quite a few
well-crafted smaller games that sell from between $4.95 and $14.95,
though. Traditional studios have nothing between the latest $59.95
shoot-em-up and the free as in beer Flash arcade conversion.

Buy, Borrow, or Build

From the development side, one of the most important questions is
where to start. Should developers write their own game engine? Should
they modify an existing Open Source engine? Should they license code from
someone else? Is there somewhere in between?

With the increase in reusable game engines comes a trend toward
componentization driven by scripting. In other words, the most efficient
parts of the engine (graphics, sound, I/O, and maybe physics) are treated
as black boxes, written in languages such as C, C++, or pixel shader
languages. (These languages are considered low-level, as they expose many
details of the underlying hardware.) Game logic continues to move toward
an embedded scripting language.

The subject came up in two separate sessions during the conference.
First, Garage Games' Tim Gift described the use of Torquescript in the
Torque engine. (Garage Games plans to push even more game logic into
scripts in the future.) Later, EA's Andy Hook demonstrated C#,
concluding that it offers several advantages for game development.

Torquescript is a typeless, bytecode-compiled language that describes
game objects. It's highly portable, as the interpreter is built into the
game. It provides sandboxing and other security features. Even better,
it supports a large mod community -- writing effective Torquescript is
easier than writing the corresponding C++, as the language is highly
interactive, quick to produce new features, and lends itself to rapid
prototyping.

On the con side, the language is tied strongly to the Torque engine.
General programming knowledge applies, but the syntax and libraries have
their own domain-specific peculiarities. The language supports little
more than what the original game needed, and Torque's architecture heavily
affects the language.

Andy Hook was very impressed with C#. His biggest kudos were for the
development environment -- in his eyes, Visual Studio .Net is highly
impressive. Speed is less of an issue, especially when compared to its
cousin, Java. Hook reinforced the idea of writing speed-critical
components in C, C++, or Assembly.

C# has a few drawbacks, however. First, it's tied to a Microsoft
toolchain. Though there are implementations that run on FreeBSD (and Mac
OS X), as well as reimplementations for GNU systems, it remains to be seen
how easily developers can avoid Windows-only components (especially when
linking to DirectX components). Second, though it's based on the mature
C++ and the maturing Java, it's a relatively new language. Third, it's
unproven and is more general than a game-specific language.

That last point may be an advantage, however. It's not clear that
inventing a highly-specific language will be general enough for
interesting new mods game developers never intended. Language design is
tricky, and it takes different skills than engine design. Existing
languages such as Lua, Ruby, and Python are mature, capable, and easily
embedded. As well, Parrot is
promising as a toolkit to build new languages. (I've
participated in experiments to extend Parrot to support multimedia
libraries such as SDL.)

Summary

These comments presuppose PC gaming -- or at least something resembling
it. It's unclear how consoles will fit in with independent development.
It's possible that adding broadband adapters and hard drives may grant a
foothold to independent and hobbyist developers. The tools aren't yet in
place, though.

Given the attendance and hallway conversations and considering the
last-minute notice, there's quite a bit of interest in the area of
independent development. Some is geared toward producing open source
games, but more is devoted toward working with the existing publishing
model. Some of the same features and tools that make open source
development successful make independent development possible, so expect to
see independent developers suffer similar growing pains.

The much-vaunted componentization that's never really quite taken off
in non-game development may have a foothold here. It's hard to beat
Torque's licensing costs, but there are enough open source engines that a
few will eventually reach the point of suitability. Driving efficient,
cross-platform components with a mature, dynamic, embedded language may
produce a new renaissance in game development.