Innovative Techniques: The Draco Legacy

Back in the early 1980's, my high school was donated a Radio Shack TRS-80 (TRS-80, Wikipedia) computer. It had a black-and-white screen, a cassette recorder to save programs and only a few kilobytes of memory. It did come with a built-in version of the BASIC programming language. I sat down with the language manual and began teaching myself programming. One day, the librarian observed that the TRS-80 was too primitive to be able to handle a game like Donkey Kong (Donkey Kong, Wikipedia) By the end of the afternoon, I had created a stick-figure of a gorilla dropping the letter "O" and a series of floors with randomly moving holes. When the letter "O" moved along the floor and reached a hole, it fell down to the floor below it. The librarian looked at it and exclaimed in disbelief, "It's Donkey Kong!".

I was always fascinated by game ideas, reading books, creating my own board games and watching students play Dungeons & Dragons. Computers meant people could play games without a board, pencils and dice. I experimented with a lot of different ideas. One of them was a simple text dragon battle. The dragon and player had a certain amount of health and the dragon made a random action and the player could block or attack. It was around 40 lines of programming, pretty simple stuff. I named the dragon and the game "Draco".

This month, with university students working on exams, marks the 20th anniversary of Draco IV. It was a long road to get there. Draco I was obviously wasn't very fun. Draco II was a few hundred lines of Applesoft BASIC (AppleSoft BASIC, Wikipedia), combining the first game with ideas from Dave Ahl's Camel (Dave Ahl's Page; Camel in More BASIC Computer Games, Atari Archives). The player now had to cross a wilderness while fighting different enemies on every level. This game lives on as an example program for my Business Shell.

Draco II may have been fun but the stategy was very simple and relied too much on chance. Draco III had a terrain generator, a 2D overhead map and a magic system. The player now had to race the clock while exploring the wilderness to find an evil wizard's castle. The player could plan his strategy and could backtrack or try different tactics. Take too long to clear the level and the player lost the game.

Draco IV was my solo project in the fourth year at Brock University, under Prof. David Hughes. Written in Pascal, it expanded Draco III to multiple players, character classes and a more sophisticated monster AI. The player could now interact with monsters in other ways than just attacking them. The graphic routines were written in 65C816 assembly language using my Drawtools animation system. The 65C816 was the same processor used by Nintendo's SNES game console. Assembly language was the only way to do animation in those days. The graphics were primitive by today's standards, the effects were simple, but user interface was so transparent and clean that I've never seen a commercial game with the elegant interaction of Draco IV's user input system.

I had planned a Draco V with more capabilities and a new fractal-based world generator, but to date it's only scribbled notes in a folder. I always say, "when I have free time". But the free time I wait for never comes. And now 20 years have passed.

One of the lessons of making the four Draco games is that developers rely too much on tools and standard API's. Chris Crawford (Chris Crawford, Wikipedia; Chris Crawford's Home Page) says the same thing in his book "On Game Design". Draco II is a short game but there's a lot of richness packed into the source code because, when I wrote it, I asked a lot of "what if" questions. What if crossing a river causes you to lose your magic ring? What if running away was sometimes the best way to win the fight? What if the princess's father ironically rewards you with..."his thanks worth zero gold"? What if the magic items interacted differently with each monster? Does lightning tickle giants?

              if has_item( staff ) then
                 staff_charge := staff_charge - 1;
                 if staff_charge < 0 then
                    staff_charge := 0;
                    put_line( "Nothing happens!" );
                 elsif creature = dork then
                    put_line( "Your blast tickles Dork into fits of uncontrolled laughter." );
                 else
                    put_line( "A bolt of lightning strikes the enemy!" );
                    damage_to_creature := integer( numerics.rnd(4) )+3;
                    if creature = specter then
                       damage_to_creature := damage_to_creature * 4;
                       put_line( "The specter howls with rage!" );
                    end if;
                 end if;
              else
                 put_line( "Wave what?" );
              end if;

Figure: Part of Draco II (Business Shell version)

Draco II is certainly not going to win game of the year, but there was a sense of whimsy, humour, personality and ever-changing situations. In these respects, Draco II is a better game than many of the Massive Multiplayer games. Most MMORPG's are, when you get down to it, pretty monotonous. Endless quests that all look alike, endless grinding. Very little is creative, imaginative or truly "fun". This was spoofed in the mock game Progress Quest, where you create a character and, letting the game run in an open window, it periodically reports how many levels your character has attained while avoiding all that needless grinding. (Progress Quest home page)

Mr. Crawford argues that tools have caused game programmers to become lazy. They rely on level editors, monster editors, animation editors. Everything is data-driven. But that limits the creativity and rich interactions of a more hard-coded, function-driven, rule-twisting game.

Perhaps this leads some game companies with tight schedules and profit-driven executives to avoid creative experimentation. Tom Wujec held a series of experiments with people collaborating to create a tower out of spaghetti, tape, string and a marshmallow. The experiments showed the best solutions were found by either people with background experience or people who worked by iteration. Ironically, Mr. Wujec discovered kindergarten students usually built better towers than average adults: (1) kindergartners build prototypes—they don't need to justify their skills by building from only the problem spec; (2) they don't hold orientation / kick-off meetings were people jockey for power. Mr. Wujec also found out that when a cash incentive was added, no adult could build a successful spaghetti tower. When money is on the line, people become more reckless and ego-driven, desperate to prove themselves, and when that happens, disaster strikes. (Tom Wujec: Build a tower, build a team, TED Talks)

Hidden assumptions are not always made visible until a prototype exposes them. The same may be true of hidden opportunities to create more fun and interesting games, where advantages may only be revealed when a simple prototype is made.

Computer engineers have traditionally held code reuse as an important labour saving technique. Perhaps there is a case from Mr. Crawford and Mr. Wujec for programming that isn't designed for reuse: programming a prototype to be thrown away, or custom-built programming tailored for a specific problem. With my Draco series, I started with a 40 line program, than a 500 line program and so on, each generation revealing weakness in the product solved by the next version. Each version was custom-programmed to create a rich and entertaining user experience. In projects like original games, where hidden opportunities and challenges may not be readily obvious, a game might be written faster and be of better quality if these evolutionary approaches are used.

May 2, 2010