For your custom home arcade machine needs, visit here and use Coupon Code: DREAM220



Remember me

Sponsored Links
Awards Received
PC Mag top 100 award.
Hackers, Slackers, and Shackles

Hackers, Slackers, and Shackles: The Future of Free Software Game Development

Author: Matt Barton
Editing: Mat Tschirgi, Cecil Casey
Online Layout: Don Ferren
Special Thanks: Daniel Horn, Mike Boeh, Matt Matthews, Richard Stallman

Creative Commons License
The following text (not including illustrations) is licensed under a Creative Commons License.

Type This by Seb Brassard

Figure 1: Type This by Seb Brassard © 2005

So far, we videogamers have been mostly unconscious of the ongoing battle between proprietary and free software developers.i After all, most of us were introduced to gaming either by locked machines in darkened video arcades or by mysterious consoles with likewise mysterious carts. Few folks had the faintest clue how the software driving these wonderful contraptions operated. Those of us with a computer gaming background were better off. Even though early personal computers from Commodore, Atari, or Apple came with hard-wired proprietary operating systems, and plenty of software was available only in binary form, countless computer gamers of the 70s and 80s spent their evenings typing in and often learning from source code printed in magazines like Creative Computing. While it's not uncommon to hear a few old enthusiasts carrying on about the "good old days" of searching for that one critical, show-stopping typo into the early morning hours-only to find out a month later that the problem was the magazine's fault-most folks would've been far happier if they could have just bought the program in binary form and saved themselves a Carpal Tunnel operation. Of course, one has to keep in mind that these were the days when mass reproduction and distribution of software wasn't nearly as well developed and efficient as the magazine industry. It was cheaper to print a collection of software in book or magazine form than to include copies on cassette tapes or floppy diskettes. Besides, this was also a time when most computer marketing campaigns focused on the educational and creative aspects of their products. The reason parents bought their offspring a computer instead of a game machine was so they could learn enough to land a high-paying job in the booming tech industry. If computers could get a few good ol' American white boys to the moon, there was good reason to believe they could get Johnny and Jenny into college and beyond.

There are a few things worth pointing out here. First, computers like the Commodore 64 came standard with a form of Microsoft BASIC (yes, Bill Gates had his hand in the cookie jar even back then). BASIC stands for Beginners' All Purpose Symbolic Instruction Code, which is a fancy way of saying that, basically, BASIC is pretty basic. Any clever kid could figure out how to do some pretty nifty things with BASIC in no time. As you might expect, most kids made two kinds of programs: Games and more games. As Eugene Jarvis, creator of the popular but difficult Defender game put it, "The only legitimate use for a computer is to play games." I tend to agree, though I would change the "play" to "create."

The bulk of the early computer programming books were dedicated solely to gaming, and for good reason: Games were, and continue to be, the best and most creative way to learn about computers, software, mathematics, science, and even life itself-it's certainly no coincidence that the basic stuff of life, DNA, turns out to be expressed in code. In more ways that most of us pitiful specimens of homo ludens realize, the line between reality and virtuality is getting pretty thin. I think the best evidence of this is that most of us are quite comfortable with the notion that the majority of our monetary wealth exists as invisible bits traveling back and forth among what we hope are damnably secure electronic databases. We've moved from the gold standard, to the paper standard, to the digital standard. Can you imagine trying to convince a store-clerk in the 1800s that his descendents would be paying for merchandise with small plastic cards with magnetic strips on the back? Let's not even get into the concept of PayPal. We've come a long way, and, believe it or not, we have videogames to thank for most of it.

Now, learning is never an uphill battle; you either enjoy it or you never get good at it. Every good teacher knows that excited or interested students learn better than bored ones. One way to make sure they'll be interested is to present the subject in the form of a game. Chances are, if you can't make a game out of it, it isn't worth learning anyway. Good games, like good novels, do more than entertain: they teach us skills and give us insight into life, the universe, and everything.

The point I want to make in this article is that videogames ought to play a primarily active role in making us smarter individuals. We need to avoid games that offer only a tightly-controlled, thoroughly passive experience. To get there, we need to start turning away from proprietary software and embrace free software.ii We also need to pay more attention to movements that convert "passive players" into "creative players," that is, projects that enable players to play a vital role in a game's present and future development. To make my case, I'll talk a bit about the history of software development and describe some really interesting free software and open source videogame projects in development today. As you probably realized, I'm pretty excited about the possibilities opening up for some really innovative videogame development-not by monolithic dinosaurs like Electronic Arts, but by teams of creative people, young and old, who are coming together all across the world to ensure that the next generation of videogames will not only be more fun to play, but more friendly to change and innovation.

The Games that Hackers Played

Any videogame historian worth his ASCII knows that we wouldn't have a tenth of the wonderful software we have today if it weren't for hackers. In fact, I'd be surprised if we would even have personal computers. Now, it's important to note that by "hackers" I'm not referring to criminals who get their jollies breaking into corporate websites or others with nothing better to do with their time than "crack" the protection on proprietary software. These types have done very little to stimulate progress and in fact have hampered it just as much as the greediest and stupidest CEO. No, the hackers I have in mind are fellows like Steve Russell, one of the fellows responsible for Spacewar. Spacewar was one of the legacies passed down to us by "Tech Model Railroad Club," an early hacking group based at MITiii. When Russell was programming Spacewar, there were no personal computers, no game consoles, and very little idea that software was something that could ever make somebody rich. After all, there were very few computers actually in existence, and lumbering hulks like the PDP-1 cost upwards of a hundred thousand dollars and wouldn't look very good in your living room.

Many hackers have remarked about how much faster software innovation occurred without lawyers. Steven Levy, author of Hackers, tells us that in those days, even critically important programs (printed on ticker tape or punch cards) were simply stored in an unlocked drawer and made available to anyone who could benefit from them. Hackers earned the respect of their peers by improving these programs; if the "hack" was good enough to be incorporated into the growing body of software, the hacker rose in stature. The end result was that software improved in leaps and bounds as other hackers strove to impress their colleagues with their wizardry. Each successful hack upped the ante.

Spacewar is an example of what happens when game programmers are unfettered by copyright or non-disclosure agreements. Here's Steve Russell on the matter:

I started out with a little prototype that just flew the spaceships around. Pete Sampson added a program called Expensive Planetarium that displayed stars as a background. Dan Edwards did some very clever stuff to get enough time so that we could compute the influence of gravity on the spaceships. The final version of that was done in the spring of 1962. (From Kent, 19)

Spacewar wasn't the only game that benefited from free software development. In 1972, a programmer named William Crowther had a brilliant idea: He'd write a role-playing game that could be played on a computer. Written in Fortran for the PDP-10 computer, Crowther's Adventure traveled the Arpanet (the precursor to the Internet) and was soon installed on machines all over the country. Four years later, another programmer named Don Woods found the code and decided he'd like to make some improvements. He managed to track down Crowther, who was quite happy to give Woods his permission. Finally, a third programmer named Jim Gillogly got his hands on this code and, with Woods and Crowther's blessing, ported the code to C. Unfortunately, in 1981 the collaboration hit a bump when a fourth collaborator, Walt Bilofsky, ported the code to the IBM-PC. Bilofsky, rejecting the concept of free software, decided that his port ought to copyright and sell the software. After agreeing to pay Crowther a "small royalty," Bilofsky and Woods released an "official version." On his personal website, Bilofsky boasts that "Although many versions of Adventure were both sold and freely distributed, and although the game spawned an entire segment of the software industry, we were the only company ever to pay Crowther and Woods anything." He doesn't bother to mention that Crowther never asked for anything. Still, we shouldn't be too harsh; to my knowledge, neither Bilofsky nor Woods made a serious effort to keep people from copying and sharing the code to the game, and folks were still playing with the source code as late as 1996, when Paul Munoz-Colman released a 370-point version for DOS.

Fans of Linux might be surprised to learn that the operating system it's based on, UNIX, was a byproduct of a hacker's efforts to play his favorite game. In 1969, a Bell Labs programmer named Ken Thompson was having some problems getting a game called Space Travel to display properly on his GE 635. Thompson decided to port the game to the PDP-7 computer. In the process, Thompson developed a "a floating-point arithmetic package, the pointwise specification of the graphics characters for the display, and a de-bugging subsystem that continuously displayed the contents of typed-in locations in the corner of the screen," innovations which would lead directly to UNIX. This story shows just how critical the connection between game-playing and creativity can be, and how having access to source code--in this case the code to the game Space Travel--is to technological innovationiv.

Surprisingly, though the history of software programming indicated that innovation and development were flourishing, Bill Gates was gradually able to convince those who didn't know better that all of this freedom and access to source code was retarding the production of good, quality software. In his book The Road Ahead, Gates tells a very different story of the early history of software development:

In the early years of selling Altair BASIC, our sales had been far lower the widespread usage of our software suggested they should be. I wrote a widely disseminated "Open Letter to Hobbyists," asking the early users of personal computers to stop stealing our software so that we could make money that would let us build more software…But my argument didn't convince many hobbyists to pay for our work; they seemed to like it and used it, but preferred to "borrow" it from each other.

The "Open Letter" Gates refers to is a work of rhetorical sophistication. In this letter, we already see a great deal of the powerful rhetoric that would allow him and his ilk to gradually erode the freedoms enjoyed by the hackers. Unlike the countless hackers who came before him, Gates saw programming purely as a means of getting filthy rich. Rather than share his knowledge for the betterment of society, Gates wanted to secret it away and protect it--both functionally by keeping the secrets of its working to himself, and ethically by convincing other computer enthusiasts that it was wrong to share. "As the majority of hobbyists must be aware," Gates writes, "most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?" Indeed, almost thirty years later, we are still asking ourselves that question. Indeed, the only people who seem to know the right answer to it are billionaires like Gates, whose shoddy and unstable products like Microsoft Windows and Microsoft Office have consumed the lion's share of the market and severely inhibited public innovations in the industry. Gates wished to shackle hackers; to tame their youthful exuberance and channel their creative energy into a sickly form from which he could squeeze maximum profit.

How did Gates successfully convince so many hackers who had personally benefited from the openness of software that chaining it up was a good idea? The answer is, of course, that he didn't. Gates' target was not the hackers who had cut their teeth on machines like the PDP-1 and knew firsthand how quickly software improved when allowed to be free. Gates owes his success to the personal computer manufacturers and the thousands upon thousands of new programmers who were first introduced to computing in the form of closed-source, proprietary operating systems like Microsoft Basic and MS-DOS. These new users had no idea what they were missing; why should software be free? The old hackers foolishly looked at these waves of new computer users with contempt; after all, their pitiful little consumer boxes paled in comparison to the giant mainframes they were accustomed to working on. Later, when it became obvious that software could be sold as surely as hardware, most hackers abandoned their ideals and jumped on the bandwagon, signing non-disclosure agreements as fast as their new bosses could draw up contracts.

However, not all the hackers were so quick to toss away their freedom. There, amidst the falling turrets of the cathedral stood a righteously indignant young man whose personal integrity and philanthropy would always trump the base desire for mere physical wealth. That man was Richard Stallman, whose significance we are only now beginning to understand. Stallman has come to represent the Free Software Movement, whose principles stand in stark opposition to the legal morass that permeates and retards modern software development. Stallman's argument is that software should be free; not free as in zero-cost, but free as in free speech. Dismissed by many as a hopeless dreamer or scorned as a dangerous rebel, Stallman has resisted the pressures put on him to conform to proprietary development. Now, the success of GNU/Linux and countless other free software projects has prompted many programmers to take Stallman's philosophy more seriously. This article is an attempt to explore the implications of the free software movement for modern games.

The history of software into the mid-80s is a demonstration of the ineffectiveness of proprietary software development. As bloated software companies flooded money into Congress--that shameful practice of state-supported bribery we call "lobbying"--stronger and finally tyrannical intellectual property law formed, and innovation suffered. Innovation became the exception rather than the rule. Programmers receded into the background and the tailored suits stepped forward. Software development was now a business whose profits depended on keeping source code secret, excluding access to only those willing and able to pay for it, and eliminating competition by securing state-supported monopolies in the form of "intellectual property rights." The folks who bought this software became "end-users," or, to put it more accurately, "dead-end-users." They were permitted to use their programs only by paying, and could use them only as their corporate owners dictated they should be used.

Of course, there are many readers who will rightly call me to task on this point. I'll stop for a moment here and address what I expect will be the most common objections. "Are you serious when you say that there have been no recent innovations? Are you blind? Look at how far graphics have come!"

If we compare a game like Spacewar to Half-Life 2, it's hard to deny that there has been significant innovation, and I don't intend to. There have been significant innovations in hardware over the years which have allowed software designers to make their images more realistic. Surely, we can't call it a breakthrough in software when it's the hardware that makes the difference. What's even more critical here is to realize the hardware industry is free from the creative restraints imposed by copyright law. Eric S. Raymond, author of The Cathedral and the Bazaar, puts it best:

The world's best example of the benefits of freedom in business is a comparison of the computer hardware business and the computer software business. In computer hardware, where freedom reigns for both suppliers and consumers alike on a global scale, the industry generates the fastest innovation in product and customer value the world has ever seen. In the computer software industry, on the other hand, change is measured in decades.

Of course, someone may well object that hardware is protected by another body of powerful law called the patent system, which are in some ways even more draconian than copyright law. However, history shows us that computers with "open standards," such as the IBM-compatible computer, ultimately triumph over computers with proprietary standards such as the Commodore Amiga or the Apple Macintosh. The reason for this is easily explained under elementary economic capitalist principles. Under capitalism, innovation flourishes only when competition drives it. A company with no competition has no reason to waste its resources in improving its product, whereas a company with significant competition has to work very hard to drive down costs while improving the quality of the product. Consumers benefit immensely when there is a Best Buy across the street from a Circuit City. The open standard of the IBM-compatible won out because hardware manufacturers were allowed to compete with each other and thus offer consumers a better deal. If the same had been true of software all this time, I'm convinced we'd be playing games on our own holodecks by now, and some of us might be doing so on an intergalactic starship.

I challenge anyone else who defends the status quo to show me some innovative new titles from the major developers. If we remove those embarrassing games owing their existence to a "license" from a hit movie (or even a suck-bomb!) and the dreary sequels of sequels, I daresay we might find a few games that we might loosely describe as "innovative." We usually hear a lot about them because they are so very rare and thus worth celebrating. The vast majority of titles will be the near-identical members of narrowly defined "genres." Another first-person shooter is released and because millions of dollars went into its development and promotion, we're supposed to hail it as a miracle of modern science. If there were truly paradigms broken in Half-Life 2, Halo 2, and Doom 3, I'd love to hear about them.

I started this article with a discussion of the early days of personal computers and how they served primarily an educational function. More than one excited child caught the programming bug and went on to create dazzling new videogames and other programs. Unfortunately, many of these children had been taught to guard their code and refuse to share their innovations with others. Business-savvy coders learned to release their games only as executable files, and then later as copy-protected executable files. They'd taken a page from console gaming. It's worth pausing a moment here to reflect on the differences between console and computer gaming.

Console gaming might be better described as "closed gaming." The systems are proprietary and the games are typically delivered in proprietary formats on proprietary media. All of this is designed to limit what the user can do with the system. The argument, of course, is that such restrictions are necessary for software development. After all, if the industry can't keep people from making their own copies of games, no one will be willing to spend $50 for the latest titles and the developers will lose money. Stiff, impenetrable copy protection is necessary to keep unauthorized people from accessing the software-a "pay to play" model that many people assume is a great motivator for innovation. After all, the cost of developing an A-list title can run upwards of $5 millionv. Such incredible production costs can only be met by attracting some rather wealthy and willing investors. Investors survive by minimizing risk and maximizing gain. Put away the myths of venture capitalists as risk-taking daredevils willing to hop on every promising new project that shows up on their doorstop. Any idea, no matter how potentially innovative, is shutdown the moment it appears risky to investors: "Just take that great movie property we just bought and make another Halo, the kids love it."

Again, such talk begs a lot of questions. First, a good deal of that $5 million worth of production costs is spent in ways that hardly promote innovation, such as licensing, marketing, insurance, and other types of "overhead" that just wouldn't impede a free software programmer. Other costs, such as the recruiting of voice talent or professional musicians, may add some cool frills, but can't be shown to truly add innovation to game development. Ask a programmer if she's ever been offered some innovative suggestions by a member of the marketing staff--but not when she's in the middle of drinking a Coke. The modern game industry is about as good at making videogames as the modern film industry is at making films. Crossroads, anyone?

We tend to see less innovation in the console market precisely because of their increased security. The public is inhibited from making illegal copies of games, but they are also inhibited from feeding their ideas into the development of new ones. The public is silenced and denied a voice; they aren't even allowed to see how the games they love so much were made. Historically, the public hasn't liked having secrets kept from it, particularly when those secrets play such a critical role in producing their culture. A good example of what happens when the public gets fed up with such tyranny occurred in 1517, when an angry monk nailed a scathing critique of the corrupt and overweening Catholic Church to a church door in Wittenberg, Germany. The same man forever ended the proprietary nature of Christianity by translating the Catholic Bible from Latin, which was only understood by priests, into the vernacular, which could be understood by anyone who could read. His name was Martin Luther, the Richard Stallman of his agevi.

Reclaiming Creative Computing

Today, a great deal of "dead-end users" are rediscovering the fundamentally liberating and empowering roots of their computers. They are beginning to understand software as something to interpret as they see fit, and learning how to code and modify programs as well as execute them. These new hackers are, as anyone might expect, radically different than those who came before them, yet they have a few powerful advantages: There are a hell of a lot more of them, and they have the Internet.

There are plenty of good and thoroughly bad books out there about how the Internet will change our society. Some of these claims are just as preposterous as the wildest science fiction. Still, there is one way the Internet has changed a good many of us that can't be denied--it's brought a lot of folks together to share ideas and information who would otherwise never have met, much less built commercial-quality software together. Perhaps the groups that have most visibly benefited from this newfound communication are the modern hackers, more commonly known as free software programmers.

It's doubtful that Linus Torvalds really knew what he was getting himself into when he announced that he was "doing a free operating system" on a USENET group in 1991. With a degree of humility and nonchalance that has become characteristic of the grand high priests of the free software movement, Torvalds has come to represent all that is good and right with modern software development. Under his gentle stewardship, Linux has grown from a small hobby project into a free software juggernaut that even has Bill Gates quaking in his boots. The overwhelming success of Linux has inspired countless other programmers to join him in taking back control of software development from the greedy hands of the mega-corporations. The majority of new applications posted at Freshmeat, a bulletin board for open source project announcements, are utilities and applications, yet games are becoming more common. One of the projects you might find there is Vega Strike, an action space-simulator project founded by brothers Daniel and Patrick Horn.

Vega Strike screenshot

Figure 2: Vega Strike screenshot

Daniel says he got his inspiration for Vega Strike from the DOS game Privateer, a game which those of with a bit more historical background will recognize as a descendent of Elite, the classic Firebird space trading and combat simulation. All of these games follow a similar premise-the player becomes the captain of an intergalactic spaceship which can be used for good or ill-it's really up to the player to decide whether to play the game as an honest trader or a voracious pirate; it's more than a little apposite that one of the biggest open source game projects is based on one of the most "open gameplay" games. Some of Vega Strike's innovations to the genre include a powerful multiplayer option, the ability to manage a whole fleet of starships, and plenty of interesting missions. But what's really innovative is that, unlike the previous games in the genre, Vega Strike allows fans to not only play the game, but get to help out with its ongoing development!

Originally, Daniel didn't intend for Vega Strike to be open source. Like most gamers turned programmers, he'd grown up with closed-source, proprietary gaming, and had dreams of selling "secret bits." All that started to change, however, when Daniel discovered Linux and open source software development. "As I learned about Linux," Daniel told me, "I realized that this was how it had to be. This is what would differentiate me from my competition." Like all free software developers, Daniel made a deal with his fans-he'd give them access to his source code, and, in return, they'd help improve and extend it. It didn't take long for the project to attract some strong talent, including another free software developer who had been working on another open space simulator. "He tried my game, realized it was further along, and joined my project," said Daniel. Although participation ebbs and flows, Daniel figures there's always at least 3 or 4 coders working to improve, refine, or debug the program. However, most of his contributions don't come from coders, but from artists-graphic wizards who want to use Vega Strike to realize their artistic visions. Others contribute by writing stories, composing music, inventing missions, or working on the manual, which is stored on a special type of website called a wiki. The wiki allows anyone who wants to edit the manual.

I asked Daniel if he felt there was any money to be made in free software development. "If I wanted to make money, I'd have to start over. I would probably just delete all the downloadable files and take off the source code and just offer that with a CD. People could re-distribute it, but probably wouldn't." This model has worked for a great many other free software developers, who find that most people appreciate the convenience of ordering a quality CD rather than download such huge files (particularly if they are limited to slow internet connections). Even with the source code and files available for free online, Daniel has still managed to sell $200 worth of CDs. The tactic of selling CDs and various accessories (manuals, books, T-shirts, coffee cups, etc.) to support free software projects is a common one; Richard Stallman adopted it early-on to support his Free Software Foundation and various GNU projects.

Another possibility Daniel raised was releasing the code under a free software license, but copyrighting the images, sound files, and storylines of the game. "It takes a lot of work to make a saleable game from just an engine," said Daniel. "Having a good data set is the difference between a bad game and a good game." However, there is a catch to this scheme: Many artists currently working on the project would be unlikely to offer contributions if they knew someone else would be profiting from them. I emailed Richard Stallman and asked him what he thought about this model. He replied in the affirmative:

A game scenario can be considered art/fiction rather than software. So it is okay to split the game into engine and scenario, then treat the engine as software and the scenario as art/fiction.

This compromise between free software and proprietary software seems to have its advantages. Developers would still be able to profit from their work while sharing their code base. Thus, budding programmers would have the opportunity to study from the masters. Even if these programmers decided to create and sell their own games based on this code, their games would likely feature substantially different graphics, sounds, and storylines and thus not unfairly compete with the original. In the event that a programmer did deliberately copy these materials, he or she could be sued for copyright infringement.

Finally, another model Daniel proposed was to initially release the game under a proprietary license and keep the code closed, but later, after it had exhausted its sales potential, release the code to the public. Daniel cited Id software as an example of this policy. Id released their original Doom game as closed-source shareware; fans were required to purchase the full version and were not free to share it. Eric S. Raymond mentions the same game in his essay "The Magic Cauldron":

The technical and market trends raised the payoff from opening the source; Doom's opening of specifications and encouragement of third-party add-ons increased the perceived value of the game and created a secondary market for them to exploit. At some point the payoff curves crossed over and it became economically rational for id to shift to making money in that secondary market (with products such as game-scenario anthologies) and then open up the Doom source. Sometime after this point, it actually happened. The full source for Doom was released in late 1997.

Doom is clearly one of those games we might describe as "innovative," or, at the very least, "influential." Very few games can claim the honor of establishing an entire genre, and, though first-person shooters (including Id's own hit Wolfenstein 3D) had been around for some time, Doom was the first to reach truly critical mass. Ironically, Doom was also responsible for establishing establish Microsoft's DirectX as a valid platform for PC gaming. Here's the story according to Brad King and John Borland:

Microsoft technology didn't have a good reputation for multimedia applications…In hopes of breaking through the skepticism, a talented Microsoft programmer named Alex St. John went to John Carmack and asked if the company could make a version of Doom that ran on DirectX. Carmack agreed and gave St. John the Doom source code, and a team of programmers was hired by Microsoft specifically to work on the projectvii.

I'd like to think that Id felt guilty about helping Microsoft get such a stranglehold on the PC gaming market and offered its Doom source code in a plea for forgiveness. DirectX, like so many other Microsoft products, turned out to be a Trojan horse for free software developers. An alternative that every programmer should know about is SDL, which offers game programmers like Bob Pendleton "a library that lets me write code without having to worry about a lot of legalities and that doesn't force me to pay a small fortune in royalties if I come up with something that has commercial value."

After having such a fruitful discussion with Daniel Horn, I decided that it would only be fair to get the alternate perspective. I decided to contact Mike Boeh of Retro64 for some insight into the world of proprietary independent game development. I was drawn to Mike's work for a number of reasons. Besides the fact that Retro64 makes some amazingly professional-quality games, they are committed to reviving that creative spirit so prevalent during the Commodore 64's reign. Independent developers like Mike often have a tough time competing in a market dominated by mega-corporations with million-dollar budgets. Successful indy developers survive by avoiding direct competition and concentrate on areas the major developers ignore. Retro64 specializes in simple and addictive games that require neither sophisticated hardware nor significant time investment; Mike's three criteria for a new game is that it be easy to learn, totally mouse controlled, and "addictive or therapeutic." That last quality, of course, is the most evasive, yet there is little doubt that Mike has learned to recognize and incorporate it into his games. Games like Cosmo Bots, Platypus, and Bugatron offer a fundamentally different gaming experience than mega-games like Half-Life 2. Mike has become successful enough at selling his games via the Internet that he can support himself and his family-a hallowed goal for all indy developers.

Cosmobots Screenshot

Figure 3: Cosmobots Screenshot

Mike's development strategy is much different than Daniel's. The games at Retro64 are proprietary. Instead of offering entire games for free, Mike releases playable demos as a way for players to "try before they buy." In short, Mike is doing what the major developers are doing, only on a much smaller scale. Mike argued that what most people don't know about game programming is that there's plenty of grueling work involved. Most would-be indy developers lose interest soon after developing a prototype:

The barrier of getting a game done is the size of the task. You have to write such a lot of code. Cosmobots took about 9 months. It's easy to get lost along the way. If you have a wife and a child, it's hard to stay focused. It's cool in the first couple weeks when you get your little prototype done, and then the real work starts. When I first started Retro64 I had a day job, then I switched to part time. Otherwise, I wouldn't have been able to get it done.

Though there is lots to love about game programming, tedium dogs it at every step-debugging, or searching for game-stopping malfunctions in the code, is often a long, excruciating process, as is "polishing," or taking the game from a rough beta stage to completion. Mike also invests plenty of capital in his projects by contracting graphic artists and musicians.

Though Mike is officially a proprietary programmer, he admits readily that free software development has produced some fine products, such as Apache, the server software he uses for his website, and has benefited from sharing source code with other indy developers. Nevertheless, he rejects free software development out of fear that other, less scrupulous developers would use it to easily create knock-offs that would compete with his own games.

Even if I had the licensing in place, it would be difficult. I've had knockoffs already. I had a game called Z-Ball that somebody cloned. I've even had people clone my website. They'd take the slogan from my website, "Where the fun is never old," and change it a bit so that it said "Where fun is never old." They'd also steal the layouts and the graphics.

Whether or not a game is a clone or a legitimate derivation is more complex than one might guess. For example, Mike's game Cosmo Bots obviously borrows a lot from the older commercial game Qix--the game is even advertised with the phrase, "Fans of Qix and Jezzball" will love Cosmo Bots. Mike differentiates his practices from ripping-off, a sort of "shameless" cloning in which another developer uses the same graphics, level design, story, or music from another game: "If you look at my games and the games in the original genre, they're so different, and so loosely based on the concept that I don't feel I'm doing anything shameless." Thus, most developers, whether free or proprietary, recognize that a certain freedom to borrow is acceptable and often necessary.

The cardinal sin of cloning is false attribution, which occurs whenever another developer tries to fool unsuspecting users that his games were actually made by someone else. The problem with false attribution is not only that the original developer might lose some money in sales. What's far worse is that if the false product is low-quality, it might destroy or at least damage the original developer's reputation. A similarly vile practice is what Mike describes this practice as "hijacking," or trying to boost a game's sale by giving it the same name as an established game:

Many people enjoyed Bugatron and tried to make a game like it. The games they made were so bad it didn't matter. I'd be more upset if people took the name. They might hijack my game. If people named their game Z-Ball, and got Google ranking, and if their game was similar to my Z-Ball, it might trick people into buying their game instead of mine.

What's most important to Mike is protecting his good name, which customers associate with quality games and drives them back to try his new games. False attribution is also frowned upon in the free software community and is considered a serious violation of hacker ethics. Arguably, reputation is even more important and valued in free software development, since the key reward for a good hack is the prestige and recognition it wins from other hackers. Hackers who "fork" a project, or take it in a new direction than the current developers, are expected to give it a new name, regardless of the licensing agreementviii.

Unlike most major developers, Mike isn't worried about the unauthorized distribution of the full versions of his games on peer-to-peer networks or illegal websites. The rationale is simple: People who want to copy his games will find a way to do it. "The core audience that buys my games doesn't want to take the security risk and go to warez sites. Those people are never going to buy my game anyway." Mike's choice of audience-mostly men and women in their 30s to 40s-lack the time, energy, and knowledge to secure unauthorized copies, and when the game is only $20, seeking out an unauthorized copy hardly seems worth it.

Mike sees the cultural and societal value of releasing free source code to the public, and admits that he would like to donate the source code of his older games to the public when they are no longer profitable. "If it's not selling well, why not?" asked Mike.

Matt Matthews is one man who has been asking developers this question a lot lately. His website, Liberated Games, is dedicated to offering free and legal downloads (often with source) of games that have outlived their commercial potential. Matt, also known as Curmudgeon Gamer, is a math professor who realizes the educational value of code, and has chastised developers who have released their binary code without the accompany source code: "The rule is: free as in beer isn't good enough to ensure the survival of a game for the future; free as in Free, however, can make a game live forever." Matt pointed out in an interview with me that programmers can still learn invaluable tricks by studying the source code, even the code of older games on vintage hardware:

Through examination of disassemblies of these older programs, hobbyist programmers have not only relearned the art of programming the Atari 2600, but have even learned a few new tricks. While these programmers are clever enough that they could have reinvented a lot over time, they no doubt benefited from having available a rich library of existing code in the form of Atari 2600 ROMs.

Matt argues that the severely limited development environments like the Atari 2600's spurred programmers to produce truly innovative code: "Learning how those feats were pulled off is instructive as it shows what can be done if you optimize your code and exploit your hardware to the fullest." One of the most celebrated geniuses of all time, Sir Isaac Newton, said something very similar back in 1675--"If I have seen further than other men, it is by standing on the shoulders of giants." Matt has made efforts to contact copyright owners and ask them to consider releasing their games under a public license so that new programmers can stand on their shoulders. The process is long and tedious, but at least a few major publishers seem to be warming to the idea.

One reason Matt started Liberated Games was his distaste for "Abandonware" sites. Abandonware sites like BH Legends and Home of the Underdogs offer free downloads of commercial games that have fallen out of production. Home of the Underdogs explains their rationale on their About page:

We believe that providing games that have been abandoned by their publishers, while technically illegal, is a valuable service to the gaming community because these games are in danger of disappearing into obscurity, and their copyright holders no longer derive any revenues from them.

Though a complete discussion of the ethics of abandonware is beyond the scope of this article (I'll save that discussion for next time), I'd encourage anyone interested in the subject to read the Scratchware Manifesto and consider its points. Matt's take on "abandonware" is that, while it's noble and arguably justifiable to make efforts to preserve these games, making them freely available for public download is not.

Free Software Sells, but Who's Buying?

I hope that this article has at least convinced a few aspiring and established game developers to consider the benefits of releasing the source code along with their binaries. Such additions would not cost much, and would likely increase and extend innovation all across the software industry-after all, videogames typically lead the industry in innovation. I'd also like to think that a few folks might re-consider some of the other principles of the free software movement; in particular, the commitment to enriching our communities and letting gratitude triumph over greed or bureaucratic impotence. After all, the game-buying public is what makes the proprietary game industry possible; why not make some small concessions? Why not "fertilize the soil" with useful source code? The long-term benefits are incalculable and thoroughly exciting.

Many proprietary game developers have recognized the creative desires of countless gamers. They have responded by releasing construction kits and promoting the growth of "modding communites" on the Internet. The response to these concessions has been enormous and has obviously greatly prolonged the shelf-life of many games. The stunning work performed by some gamers has rivaled (and arguably excelled) the developer's; take Counter-Strike as the textbook example. Valve saw the popularity of this fan-created module and decided to release it as a standalone game. While recognizing the "value add" of such communities to their game properties, few developers seem willing to take the logical next step and release the source code itself. Tellingly, "source code leaks," that is, unauthorized distribution of source code on the Internet, are becoming more common. It seems that the industry can respond to this threat in one of two ways: One, by vamping up security and ruling with an iron fist, or two by "going with the flow" and shifting their paradigms.

Let us consider briefly what would happen if Valve Software had released its own source code. Keep in mind that I'm not talking about data sets like graphics, sound files, story boards, and the like-just the "engine," or the code that puts all of these data sets together to make the game playable. Would the consequences of releasing this code prove fatal to the game's sales? Doubtful. After all, relatively few people would care to look at it anyway--the great majority would be quite content just buying the game. The people that would be interested in and would benefit from access to the code are aspiring and established programmers, who could greatly profit from studying it. The result would be an enrichment of the programming community--which would quickly lead to a surge of radical ideas as programmers quit reinventing wheels and focused on what hasn't been done--innovation. In short, "open sourcing" projects like Half-Life 2 would likely lead to much better games, which would result in much better sales and happier end-users. As for the argument that releasing source code would make the game too susceptible to piracy--I think Machiavelli, author of The Prince, said it best: "The best fortress that exists is to avoid being hated by the people." Substitute "copy protection" for "fortress" in that quotation and you have a stunning revelation. The best copy protection is to ensure that gamers respect and value your company. Every person the RIAA or MPAA sues makes the public that much more bitter and sympathetic to pirates. If they refuse to modify their strategies or economic models-in short, if they refuse to negotiate with the public, I have little doubt that eventually their empires will fall.

To succeed in a software economy increasingly being seized by free software and open source developers, proprietary game developers need to do some serious soul-searching. Public image is important. Reputation is important. In short, what's important is that they convince the public that they're offering a fair deal.

I see two ways that game developers can flourish in the post-proprietary economy. One is by shifting to a "service model," which is essentially what Valve's Steam is all about. The future of this model is clear: Giveaway the game (with the code), and charge for access to excellent servers. If such services can offer quality support at an affordable rate, there will be no honest reason why someone would try to cheat the system. For the same reason that honest folks would get upset if they heard of someone stealing electricity or cable, they'd put the pressure on others to obey the law and not cheat it. It's important not to ignore this pressure; it's a corporation's greatest asset. Of course, what will be lost if the majority of major game developers switch to such a system is the "stand alone" game beloved by so many PC gamers. There will be little financial incentive to produce a game like the original Baldur's Gate, for instance, since the "sell of secret bits," as Eric Raymond puts it, won't be viable in a post-proprietary economy. To make money, the game developers will have to sell a "game service" that works rather like cable television.

Another approach is the "public patronage" model. This model is based on the old "noble patron" system of earlier times, when wealthy persons would commission great public works of art in return for recognition and a testament to their fine taste. Forms of this system still exist; for example, the federal government offers grants to fund research projects and the like that are highly desirable, yet not imminently profitable. The National Endowment for the Arts is a federal program that specifically awards grants to artists. With the right kind of pressure and representation, NEA grants could be awarded to game developers who could demonstrate the cultural relevance and importance of their project. Of course, another approach might be to appeal directly to the public rather than seek a federal grant. A well-known and established developer like Bioware, for instance, might publish a detailed description of a project on its website and ask people to contribute the necessary funds for its production. This would likely lead to a sort of "bargaining game" with patrons who would argue about the necessity or desirability of certain features, the game's direction, and so on. The source code would likely be published along the way, and Bioware would do well to listen and accept good contributions from talented programmers. Obviously, Bioware would listen most carefully to the patrons who donated the most money, but the public would still have plenty of power in such developments. When the game was finally finished, the binaries would be released under a public license so that everyone could enjoy it.

I will conclude this article with the observation that the future looks pretty bright for free software game development. The Internet has made the old proprietary software model increasingly vulnerable. The culture industry as a whole will be forced to reckon with the power of cheap, easy, and well-encrypted anonymous file sharing that will ultimately destroy any corporation unwilling to compromise or change. The software industry is uniquely poised to assume a leadership role in the transition to a free economy, where the public is encouraged to distribute works at its own expense and convenience. Meanwhile, game developers will learn how to provide useful services that the public will be happy to purchase. If all goes well, who can doubt that the recording and film industries will follow its example? We look forward to an era of increased freedom and a richer, better society.


i I choose the term "free software" instead of the more common "open source" for a rhetorical reason. For a good reason to do likewise, see this essay.

ii The terms "open source" and "free software" are rhetorical choices describing similar software development strategies. The key difference is that "free software" carries with it a certain ideology that all software ought to be free (as in free speech), whereas "open source" is more neutral and arguably more appealing to business. In this article, I've used "open source" and "free software" based on the term the developer in question prefers. I'm very tempted to just use the term "free source" and be done with it, since what matters is whether or not the source code is available and what end-users can legally do with it.

iii For more information, see Steven L. Kent's The Ultimate History of Videogames.

iv The information for this section comes from Bell Labs' Unix history pages.

v See this article at CNET.com.

vi The metaphor of Catholicism vs. Protestantism can be quite useful in understanding Proprietary vs. Free Software. We might think of Microsoft as the Catholic Church and Bill Gates as the Pope. They sanction all interpretations of their Bible, i.e., the code-base, collect tithes, and attempt to fight off heretics with recourse to law. Meanwhile, we might think of the Free Software Movement as Protestantism and Richard Stallman (or Linus Torvalds, take your pick) as Martin Luther. There, the idea is to interpret the code for yourself, it being the duty of all end-users to take an active role in understanding and applying the Bible's teachings.

vii King, Brad and John Borland. Dungeons and Dreamers. Emeryville, CA: McGraw Hill, p. 131.

viii For more information, see Eric Raymond's The Cathedral and the Bazaar.

email to someone printer friendly >> List articles in this category
<< Back to articles front page

This article has been rated:  8.7 - 4 votes
Comments ...
bullet Molloy | 10 Jan : 15:24
Comments: 10

Registered: 30 Mar : 13:50
That was a fine article. In the last few years I've been getting largely sick of mainstream gaming. Modifications like The Specialists, Zombie Panic, Day of Defeat and The Battle Grounds have done far more with the FPS genre than 10 years of commercial releases.

And they're satisfying in 20 minute bursts. The likes of Half Life 2 go on for 20 hours. What a horribly bloated experience. I don't have the attention span for something that long. It's a sequel anyway. Who are they to saying their game is worth 20 hours of my time? No film or music album makes those kinds of demands. It's like watching the extended LotR trilogy back to back, twice.

One of the projects I'm most looking forward to at the moment is Spring Engine. The first release is coming out next month. The aim of the project is to get all the content from Total Annihilation, including third party units, maps and mods, running in the engine and build from there.

I'm not very up on open source games but wouldn't releasing the source code for many titles destroy their multiplayer community? People would be able to create indetectable hacks and cheats.

bullet Matt Barton | 10 Jan : 15:48

Comments: 169

Well, it's like a double-edged razorblade, Molloy. Sure, with the source in more hands, you know more people may try to make hacks and cheat. On the other hand, you also have that many more eyes on the code who can spot security holes and patch them up. If someone does break through with a cheat, you have more people willing and able to rush in and correct it. With proprietary, all you can do is wait for one company (whose team is likely outsourced to Bangladesh) to notice the error and get around to fixing it (on top of all the billion other things they're working on).

The proprietary model tries to be secure by being secret. The free software community tries to be secure by being secure. That's about all there is to it, really.

bullet Bill Loguidice | 10 Jan : 16:23

Comments: 307

That's the first time I've heard someone talk about a good game being TOO long, Molloy. Interesting. Personally I can only play my games in short bursts, so game length is not usually a factor for me, but most complain when a game DOESN'T top 20 or more hours. I'd rather have an 8-hour great game than a 20-hour good game myself. Nevertheless, without having played it, I find your criticism of the time investment required for Half-Life 2 to be an odd one. There are many ways that games can be compared to other forms of media, but value based on time investment is not one of them. Simply put, we expect games, modern or classic, to have near infinite usage (play) in comparison to books and movies, which can only be enjoyed a finite number of times. It's the simple difference between interactive and passive entertainment.

bullet Matt Barton | 10 Jan : 18:07

Comments: 169

NOTE: Someone was saying on Slashdot that I had "misquoted" RMS and was misleading my readers. I find it interesting that someone could accuse me of misquoting an email he/she does not have access to!

Here is my reply. You may find it interesting as well:

Misquoted, eh? Well, here's the exact question I asked RMS via email:

Do you think the four rights should apply to games as well? Or do you think of free software as being limited mostly to applications, operating systems, utilities and the like?

His response:
They apply to all software, including game software. However, a game scenario can be considered art/fiction rather than software. So it is ok to split the game into engine and scenario, then treat the engine as software and the scenario as art/fiction.

See my speeches on Copyright vs Community for an explanation of what that means.

In another email, he wrote the following:

All software should be free, but I don't think all art needs to be free.

So there you have it. Misquote? I don't think so.

bullet Molloy | 11 Jan : 04:54
Comments: 10

Registered: 30 Mar : 13:50
I think you'll find most people are very touchy about game lenght. Most believe a game can't be too long. Which is crazy. Any experience can be too long. Game design needs an editor. I grew up playing arcade games. They had to grab you in 30 seconds or you moved on to the next one. Back then when a game was designed 90% of the features got thrown out to ensure you didn't miss the games hook. What you leave out is ten times as important as what you leave in.

I don't find playing a 20 hour game in 20 minute bursts satisfying at all. If the game is structured as 5 hours introduction, 10 hours middle and 5 hours finale then you don't get a cohesive experience in 20 minute bursts. Trying to structure and pace 20 hour games (never mind build them) is incredibly difficult. Nobody tried something like that 15 years ago (Hell, you could finish many 16-bit RPGs in 6 or 8 hours) and I don't see why they should now.

The lenght of a single playthrough isn't a measure of longevity. In fact, most games at the moment are damaging their longevity by being too long. Who wants to replay and experience that's 80% filler?

You can play the same level of Counter Strike over and over. Thousands of people are playing it every day and they play the same 5 or 6 levels. But the situations and the kind of play possible in those areas is infinite. You get a different experience every time.

Games are trying to imitate passive media by having storylines and an epic scale. The games are playing us and we're just along for the ride. What happened to the HL2 previews where the guards would hammer down the doors occasionally? In fact, what happened to the intelligent combat from HL1 or Halo. I found there was very little of it in HL2. Situations played out in the same, linear, predicatable way they do in every FPS, except the corpses flew about in a realistic fasion. I'd rather HL2 were a couple of hours long, left out the appalingly poor plot (and it was appalling, they didn't bother resolving any plot lines or character development at the end) and made it a different experience every time. That's longevity.

bullet mewse | 11 Jan : 06:53
Comments: 1

Registered: 11 Jan : 05:49
I suspect that I have been trolled, but.. I'm a professional games programmer and also a FOSS-enthusiast.

I'm absolutely stunned that you would even consider suggesting that the only major difference between Half Life 2 and Space War was the hardware upon which it ran. You know better than that. It's amazingly dismissive of the huge talents and skillsets of the dozens of highly-trained people who worked on the game. All props to Steve Russell for Space War, but frankly, if you're suggesting that nothing has changed but the speed of the hardware since then, you don't have the slightest idea what you're talking about.

When you suggest that Valve release the source code to Half Life 2, as that would lead to better games with better sales, you entirely ignore that the better games and sales would be achieved only by Valve's competitors and not by Valve. With that in mind, explain again why you think Valve should do this, other than that you want to see it and use it for yourself?

To me, it seems like madness to suggest that companies begin relying on patronage in order to create games which would then be given away for free. As you state, it would require being endowed by a government agency (with all the beaurocracy and corruption that entails), or complicated negotiations with members of the public. How could this possibly be an improvement over a company merely producing the game it wants to produce, and selling it on the free market? What would you suggest the company do when such patronages fall through? Do they fire their employees? Do they have employees in the first place? Where does the talent come from, and why do they stay with such nonexistant job security? And are you truly suggesting that a project designed by committee by the public at large would be 'innovative' in any way?

I realise that you like FOSS. It's evident from your very first sentence (incidentally, there's no battle going on between FOSS and proprietary game developers, no matter how much you'd like for there to be one. We target entirely different niches). I realise that you view the FOSS vs. proprietary software thing as a religious fight, even going so far as to devote a paragraph-long footnote to the topic.

But it isn't one.

If you want to make games, make games. You don't need our permission or our tools; after all, you have access to the same hardware that Half Life 2 does.

And as you say, that's all that's changed since Space War. The rest is just software. FOSS can write it just as easily as we can, right?

So get to it.

bullet davyK | 11 Jan : 08:04

Comments: 76

Registered: 19 Jan : 08:40
I think it is obvious that there is room for both parties (there has been up until now after all).

To me, the real "battle" is between software developers and publishers. In the "old days" when games were developed by small teams and individuals, the products were engineer lead and not market lead. Games were produced because the guy coding it thought it was cool.

With proprietary development, we have marketing people identifying sectors and specifying what is to be produced - this at times can create great games but not necessarily revolutionary games. Marketing is all about bigger and better - not new.

Then we have the homebrew guys churning out their own stuff (sometimes open source, sometimes not). This is where I would expect the new stuff to come from but unfortunately we usually just get bigger and better remakes of older games such as Super DX-Ball.

In the middle we have the modders - using engine-based games to create new games from proprietary products.B ecause of the quality of the tools available and the engines, we get high quality stuff quite different from the original product.

The problem, to me with open-source is that the process of having an idea or clever piece of coding translated into a working product is not as simple as it seems. Tight team structures are required to get finished stuff out of the door - and I don't think the open source environment with its plethora of personalities and egos can do it was well.

bullet davyK | 11 Jan : 08:11

Comments: 76

Registered: 19 Jan : 08:40
I'm actually a fan of open-source and strongly believe in it existence - however I also believe in the proprietory model too and I beleive that they can feed off each other.

I'm a non-game developer and the thought of writing code for free is not always particularly attractive. However, it is not unreasonable to think that something written some time ago could not be made available for free - with an option of the release of the source code which at that point would only be of student/hobby-level interest.

bullet zlynx | 11 Jan : 18:51
Comments: 1

Registered: 11 Jan : 17:13
I thought that you were a little unfair to id Software. You smacked them for helping Microsoft launch DirectX but did not give them any credit for releasing their game engines under the GPL. The source code for Doom II, Quake, and Quake 2 is all open source now, thanks to id.

You can find it here:

bullet Matt Barton | 11 Jan : 19:12

Comments: 169

Okay, so you didn't read this part?
At some point the payoff curves crossed over and it became economically rational for id to shift to making money in that secondary market (with products such as game-scenario anthologies) and then open up the Doom source. Sometime after this point, it actually happened. The full source for Doom was released in late 1997.

I have a lot of respect for id, as I do for anyone developer who challenges the status quo and does things that seem uncalled for from a pure marketing perspective.

bullet Scullyx | 28 Nov : 17:59
Comments: 1

Registered: 28 Nov : 17:51
I´m part of a group intended to promote free software. We think your article is very interesting and you want to translate it to spanish to upload it in our web page (www.loosersjuegos.com.ar) We notice it´s under Creative Commons License, but still we wanted to ask for your permition to do it.
Thanks you very much,

bullet Bill Loguidice | 29 Nov : 12:06

Comments: 307

Matt no longer participates in Armchair Arcade, but he meant what he said about the Creative Commons license, so feel free to do what you intended with the translation. You can contact the author as well by doing a search on his name and sending a message to his latest e-mail address about it. Still, I'm sure he'd be nothing but flattered.

You must be logged in to post comments on this site - please either log in or if you are not registered click here to signup
All editorial content © 2003 - 2006 Armchair Arcade, Inc., all rights reserved unless otherwise indicated. All trademarks and copyrights are retained by their respective owners. No content is to be removed or reused from the Armchair Arcade Website for commercial purposes without explicit permission from the principal Armchair Arcade editors, or the original trademark or copyright holders. Armchair Arcade, Inc., is not responsible for the content of any external sources or links. Further, endorsement of any external sources or links is neither implied nor suggested.