Return of the Independent Game Developer?by chromatic
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.)
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.
Return to ONLamp.com.