Atari Flashback versus Commodore 64 30-in-1

Computer Camp Catastrophes

Author: Mathew Tschirgi
Editing: Cecil Casey, Matt Barton
Online Layout: Mathew Tschirgi, Matt Barton

Note: The names of campers used in the article are not the actual names of the campers that I taught while working for the computer camp.

While I was in middle school, I attended computer camp during the summer. For two weeks in the summers of 1994-1996, I took classes in programming in BASIC and C++. While this was fun, the dry worksheet approach to learning zapped the fun out of the learning experience. The programming courses distracted me from what I truly wanted to do: design games.

In the summer of 2004, I experienced a sort of role-reversal. I had the opportunity to teach kids workshops in Game Design—precisely the same thing I had wanted to learn almost a decade before. RPG Game Design workshops used RPG Toolkit, a buggy program which allowed users to create their own RPG in the style of the original Dragon Warrior for the NES. Action Game Design workshops used Game Maker, an easy to use program which allowed users to create anything ranging from a remake of Pong to a side-scroller similar to the classic Commander Keen games.

For the Action Game Design workshop, I decided to spend the first few days showing campers how to download images from Google for their games. I also had them create title screens for their games. While this was optional and not included in the curriculum, I thought giving more time for campers to come up with concepts for their games would be more rewarding for them in the end.

Tommy, a camper that was in the 5th grade, was having trouble finding graphics for his game. I asked him if there were any games that he enjoyed playing at home. Tommy stopped for a second, thinking. I left him to think for himself as I walked by other campers computers to see if they were doing OK. John, an older camper that was in high school, downloaded pictures of characters from Inuyasha, an animé (Japanese cartoon) that he enjoyed watching.

I returned to Tommy for a moment, who had stumbled across a website with pictures from the Sonic the Hedgehog games. Now that he had an inkling of an idea to make a game off of, he seemed more engrossed in the project. As the first few days progressed, it was clear that some campers didn’t care about making a title screen. They wanted to get started with making their game.

As different sessions of campers went through the class, I tried to make the title screen design aspect more exciting. Once, I downloaded various pictures of title screens for different video games, trying to prove how important a title screen was to a game because of the impression it gave. Campers that were more artistically inclined enjoyed the title screen creation process more, but everyone appreciated them more when I eventually let campers try out games that other campers had made. A well designed title screen or a catchy title might make more campers attracted to a certain game.

After everyone had a reasonable title screen finished and their initial graphics rounded up, I started giving tutorials on how to use Game Maker to make the hero avatar (the avatar controlled by the player) move left and right. Other introductory tutorials were more complicated, teaching campers how to make their hero avatar jump, how to make enemies move, how to create weapons, and how to make multiple levels.

Notice the large amount of icons used in the Game Maker interface.

This very linear method of teaching was a bit slow to start off with, but once the basic tutorials were completed, campers could go off and create lots of levels of their game without much interference from me. What made things even slower was the nature of Game Maker itself. Instead of typing in programming line by line, campers had to drag icons onto certain areas of the screen to make various aspects of their game work correctly. This drag and drop approach to programming made it easier for non-programmers to understand, but made it rather dull to teach. Rattling off something along the lines of “drag this icon over, then change its value to 9” several times over made some tutorials stale. As things progressed, I could say, “Experiment with the gravity settings to adjust the height of the jump” and most campers would get the gist of what I was talking about.

Tommy struggled with some of the early programming concepts, but eventually got them down. One day he asked me if he could have different buttons control different characters. I showed him quickly how to do such a thing, and he worked on redesigning his initial level so players could guide three separate avatars through it in separate ways. Imagine a simpler take on Blizzard’s The Lost Vikings with Sonic the Hedgehog characters and you can sort of see what direction he was taking.

On the other hand, John was getting burnt out on his Inuyasha side-scroller. His levels were lacking, as if he threw them together in a few minutes. Several times he would be exhausted, sleeping in class. It didn’t help that I had to teach a dozen kids in a classroom where a second class was being taught simultaneously by a different camp counselor. As much as I tried to motivate him to come up with better ideas, he slogged his way through the class. Part of this was personal problems he was going through at home, and a large part of it had to do with this being his second two-week session at computer camp; things were nearing the end and he simply wanted to relax at home instead of taking a class at a camp. This proved to be frustrating, but I feel that a teacher can not force his student to be interested in a subject. It is ultimately up to the student to motivate himself or herself to want to participate

It really puzzled me why younger kids consistently were more creative than older kids in my workshops. I think part of it might be because younger kids have so much less going on in their lives. A younger kid can work on his game for the hour or so every day in class and just focus on making it the best game possible. Older kids might be thinking about a girl they like at school, what’s happening in the latest episode of their favorite animé, and other topics more important to them than the rinky-dink side-scroller they are working on. Older kids tended to focus on things from more of a technical angle while younger kids focused on things from more of a creative angle.

The RPG Game Design class had its own unique kinds of challenges. An RPG is much more complex kind of game than an Action Game, but in some ways creating one was easier. To get an avatar to move around the screen in RPG Toolkit was much easier than in Game Maker. On the other hand, their actual software had several bugs in it. The nastiest bug managed to make the game campers made in class not work on their computers at home. Needless to say, this made more than a few campers upset.

RPG Toolkit is more straightforward, but is a good deal more buggy.

Teaching RPG Game Design was similar to Action Game Design in that you had to build off of certain concepts. Campers started learning how to create maps, then how to link them together, then worked on statistics for their avatars, then worked on creating items, and so forth. The faster pace of things made more campers interested in RPG Game Design than Action Game Design.

Due to the more story-intensive nature of RPGs, the concepts campers often came up with were more interesting as well. Lucy created great graphics for her game which dealt with a female warrior having to ally with a dragon in order to fight against evil dragons. Susan came up with a plot in which the player controlled Nick York, a male warrior who had to defeat evil cats in order to find the Magic Sweet Potato!

Though there were not many female campers, they were consistently more creative than the guys. Guys focused on making interesting dungeons or ugly monsters instead of crafting an interesting story. I think this is because girl gamers are more interested in stories in games than most guys. This also tends to be true when it comes to animé, a type of fandom that usually has a high amount of gamers in it as well. I’ve noticed that girls get wrapped up in the complex over-arching plots and relationships of characters in the shows while guys are more interested in the fight scenes or busty beauties which populate the shows. Obviously, this is not true for everybody, but I do tend to think that girls respond to situations on a more intellectual level while guys respond to situations on a more gut-reaction visual level.

Regardless of the quality of the games that different campers created, most of them enjoyed the process. It was great to see the kids get excited playing their own game and playing games they their friends had made. Some kids got so into making their game that they worked on it during their free periods. Making games in a “game toolkit” or “level editor” is not as complicated as programming from scratch, but makes game creation much easier for the average person to get into. As a kid, I would have had a lot more fun making a side-scrolling level than programming IF…THEN loops in Q-BASIC!

Letting kids make games on their computer lets them do something productive. They are creative something to suit their fancy instead of lounging back playing somebody else’s creation. Even if they don’t stick with making games, the experience of creating something on a computer for others to enjoy stresses a positive side of technology: using it for education. Various message boards on game design or geared to specific level editors thrive on the Internet, helping aspiring game designers from getting stuck on certain problems. It’s an easy enough hobby to get into and is well worth a try for those wanting to make their next gaming experience a little bit more personal…

Finish Him! Where have all the Fatalities Gone?

Author: Mathew Tschirgi
Editing: Cecil Casey, Matt Barton, Bill Logiduce
Online Layout: Cecil Casey, David Torre
Screenshots: Cecil Casey, David Torre

Fatality from Mortal Kombat 2 (Arcade)
©1993 Midway

Fighting games are still a fairly popular video game genre. Mortal Kombat: Deception managed to become Midway's fastest selling games selling over a million units. Despite their popularity, fighting games are a genre that has shown little innovation over time. Sure, they have moved from 2-D to 3-D, but basic game play mechanics have remained virtually unchanged. We're going to examine the lack of innovation in the Street Fighter and Mortal Kombat franchises, then take a closer look at a trio of fighting games that tend to innovate instead of merely replicate what has come before: One Must Fall: 2097, Bushido Blade, and Super Smash Bros.

Before we begin, I'd like to give my definition of a fighting game. Fighting games are so varied that they should be classified into three different sub-genres. 2-D Fighters, like Capcom's Street Fighter franchise, are games in which your avatar has to fight against computer/human avatars one-on-one in an arena in a 2-D environment. 3-D Fighters, like Namco's Soul Calibur franchise, are games in which your avatar has to fight against computer/human opponents one-on-one in an arena within a 3-D environment. Beat-em-Ups, like Capcom's Final Fight franchise, are games in which your avatar has to fight against multiple avatars in a series of levels in either a 2-D or 3-D environment.

This article is going to focus on 2-D and 3-D Fighters. Try not to be too upset if your favorite game isn't covered-if you want to suggest a good game that I might have glanced over, please do so with the instant feedback option at the end of the article or send me an e-mail.

Street Fighter 2: Champion Edition (Arcade)
©1992 Capcom

Although it is not the most popular 2-D Fighter anymore, one of the more important ones is Capcom's Street Fighter franchise. The first game in the series isn't as well known as its sequel. While you can only choose from two avatars, the Japanese Ryu and the American Ken, it did let you fight against a variety of opponents who had special moves in a variety of international locations. Pulling off special moves in Street Fighter was a bit tricky, but you could kill your opponent in one or two hits!

While most 2-D and 3-D Fighters have a variety of standard punches and kicks at their disposal (one button might make your avatar throw a Weak Punch while another button might make your Avatar throw a Strong Kick), special moves were secret attacks that knocked off a lot more damage than regular attacks. To perform one, a player had to memorize a combination of joystick movements and button presses; to have Ken or Ryu toss a Hadoken (a blue fireball) at another avatar, the player had to roll the joystick a quarter circle clockwise towards the opposing avatar (moving the joystick in a fluid motion from down, to down-towards, to towards), then press one of the Punch buttons.

Such special moves sound simple when written out, but often took several tries to nail them down. Before the Internet made it easy for any stumped gamer to grab a FAQ, gamers had a few different options to track down the latest special move. A few arcade machines had basic special moves printed on the case itself. Clever gamers could try out random moves while playing a game, hoping to stumble upon a winning combination (though Street Fighter pioneered the Hadoken special move, nearly every other 2-D Fighter released afterwards used the same button combinations [quarter circle forward, then punch] for fireball special moves). Those wanting the quick and easy way out would purchase an issue of Game Pro or Electronic Gaming Monthly to see if they had the latest special moves printed in the newest issue.

Karate Champ (Arcade)
©1984 Data East (source: Wikipedia)

This is not to say that Street Fighter was the first 2-D Fighter to feature a lot of these options, but it was arguably the first one to do it well. Data East's Karate Champ featured your avatar fighting against a computer opponent in some varied locations, although there were no special moves. Konami's Yie-Ar Kung Fu had much more varied opponents with a cartoony quality that undoubtedly influenced Capcom's muscular yet stylized look in their Street Fighter franchise.

Street Fighter II: The World Warrior was the first game in the series that most people are familiar with. Allowing players to select from a whopping eight different avatars of different nationalities (ranging from the hulking Russian Zangief to the demure Chinese Chun Li), the game play was a bit more involved than Street Fighter. Each character now had several different special moves, some of which were more difficult to pull off than others. It was a huge hit in arcades around the world.

Capcom milked this franchise for all it was worth, but ultimately not improving the game play by much. Street Fighter II: Championship Edition allowed players to play as the four boss characters while Super Street Fighter II introduced four new avatars to the mix, including the Bruce Lee-inspired Fei Long. Regardless of the extra avatars players got to choose from, the game play didn't change a whole lot-there might have been a few new special moves, but ultimately you had to move around, block, punch, kick, or complete special moves until you bested your opponent.

Later on Capcom introduced the Street Fighter Alpha series (known as Street Fighter Zero in Japan), which was a prequel to the first Street Fighter game. It introduced more complex combo systems, meaning players could link their attacks in proper succession to score more damage on their opponents, but game play was the same song, just a slightly difference dance.

As Street Fighter II was gaining in popularity, several other companies came out with competing 2-D Fighters. Without a doubt the most influential of these was Midway's Mortal Kombat series. Visually what set this one apart from the crowd was that the graphics for the avatars were captured frame by frame from prerecorded full-motion video sequences, giving the characters a more realistic look. This technique was pioneered in Midway's abominable Pit Fighter, a 2-D Fighter with cheap AI where one could win through button-mashing (pressing random buttons in order to win a match) as opposed to actual skill.

Along with photo-realistic graphics, designers Ed Boon and John Tobias brought plenty of blood and gore to the table. Practically every punch or kick delivered a cheesy flow of red blood from the opposing avatar which splattered onto the ground. When you won two rounds against your opponent, you had a chance to finish them off with a Fatality, an ultra-violent special move which often dismembered or annihilated the opposing avatar in a memorable way.

Despite public outcry aimed at the level of blood and gore in the game, game play was straight from the Street Fighter II mold. Controls were noticeably stiffer, with special moves relying more on tapping the joystick than the smooth rolls required for Street Fighter II. Fatalities in particular were a pain to pull off, requiring your avatar to stand at a specific position on the screen while punching in the different key combinations.

Friendship from Mortal Kombat 2 (Arcade)
©1993 Midway

Mortal Kombat did very well in the arcades, spawning several sequels. Unfortunately, much as Capcom did with their Street Fighter series, Midway went for more cookie-cutter game play instead of trying something truly unique for their sequels. Mortal Kombat II offered a wider selection of avatars to choose from, as well as a satirical take on the Fatality known as a Friendship (the most memorable of which had the Jean Claude Van Damme inspired Johnny Cage whip out a photograph and autograph it to his "biggest fan"). Mortal Kombat 3 offered an option to charge towards your opponent and Animalities (finishing moves which turned your avatar into an animal which would attack your opponent; these stemmed from the false rumors that you could do Animalities in the original Mortal Kombat), but it brought nothing terribly new to the table.

Mortal Kombat 4 took the series to 3-D, with rather simplistic polygonal graphics and sloppy controls. Mortal Kombat: Deadly Alliance upped the ante with better graphics, giving the game more of a darker feel than Mortal Kombat 4, but also introduced a host of new avatars to pick from. The marketing for the latest game in the series, Mortal Kombat: Deception, was rather odd since it focused more on the various side game play modes (including one which was a blatant rip-off of Capcom's Street Fighter 2 spin-off, Puzzle Fighter).

So we've taken a brief look at how the Street Fighter and Mortal Kombat franchises managed to grow in popularity while failing in advancing the game play mechanics to any noticeable degree. Why did Capcom and Midway keep things so similar in their games over time? Probably because it's the safest thing to do-if you change the game play of a sequel too much, it just pisses off the new fans while alienating newcomers to the franchise.

Just take a look at Shigeru Miyamoto's The Legend of Zelda: The Adventure of Link. The second game in the Zelda franchise is not a fan favorite because it changes the overhead exploration game play into a side-scrolling action title with RPG elements. Where the original game focused on solving puzzles in dungeons with light action elements, the sequel was almost pure action. Though the game still sold well, it's not what most gamers would rank as their favorite Zelda game.

One Must Fall: 2097
©1994 Epic MegaGames

One of the more innovative 2-D Fighters was Epic Megagames' One Must Fall: 2097. Having a sci-fi setting in which players had robot avatars which fought each other to the death, the single player mode was rather interesting for a couple of reasons. One of these was the RPG elements added to the game-depending on how many points your avatar scored, your avatar earned different amounts of money. This money could be spent on upgrades to the statistics of your robot, adding an element of strategy to the game-having the chance to work on balancing the various statistics for your fighter made the game that much more interesting. Another novel element of the game occurred between rounds. Commentators gave a play-by-play on your match with stills from your fight, making the illusion that your robotic avatar was fighting in a TV show that much more convincing.

Bushido Blade (PSX)
©1997 Squaresoft

Squaresoft pulled off a more realistic take on 3-D Fighters with their Bushido Blade series. Set in medieval Japan, players controlled their mostly Japanese avatars armed with various Japanese weapons. Unlike most fighting games that gave players a life bar, Bushido Blade took a more realistic turn. Your avatar could die by the sword (or spear, or gun) after only a few hits. One well placed hit could knock your avatar out in a single blow. This really put a new sort of energy into the fighting, making a match between two skilled players look more like a ballet than a bloodbath. Katanas would clash as one avatar fought the other, and knowing that one wrong move could doom the other player made matches that much more invigorating.

Super Smash Brothers (N64)
©1999 Nintendo

Nintendo took an arguably more simplistic take on the 2-D Fighter that made the genre more accessible to non-gamers with their Super Smash Bros. franchise. Limiting attacks and special moves to a few simplistic button presses injected a healthy dose of fun into the genre. Anyone from a toddler to a stoned college student could pick up a controller and master the moves in a matter of minutes, which was a refreshing antidote to the increasingly complicated special moves, combos, and fatalities found in other 2-D Fighters. Having Super Scopes, Pokéballs, and Hammers randomly drop on the playing field also helped mix things up a bit, making a fighting match less predictable than usual.

While fighting games overall have lacked in the innovation department, a few have stood out from the crowd. Unless a genre truly continues to reinvent itself it will die, or at least hobble along supported by die-hard fans. Just take a look at the graphic adventure, a genre that flourished in the late 1980's and early 1990's (including such great titles as LucasArts' Day of the Tentacle and Sierra Online's The Beast Within: A Gabriel Knight Mystery) until a glut of bad titles and lack of innovation (most of them copycats of the overrated, yet best-selling, Myst) delivered the genre a shotgun blow to the face. The real question is can fighting games be creative in a contemporary environment where the bottom line matters more than creativity? If gaming history has proved anything, it's that no genre stays consistently popular for long.

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

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

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.ⁱ 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.ⁱⁱ 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 MITⁱⁱⁱ. 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 innovation^iv.

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 million^v. 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 age^vi.

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.

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 project^vii.

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.

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 sa