The Lone Coder Reflections for the Unsung Linux Saviours
by Ken O. Burtch
Innovative Techniques: The Draco Legacy
"We're going to use CMMI. It's a model for developing a process to create a
framework. Or it might be a process for creating a framework to make a
model. There's no budget for training, so we'll be relying on guessing more
-- Pointy-haired Boss, Dilbert, March 13, 2010
Back in the early 1980's, my high school was donated a Radio Shack TRS-80
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
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
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." );
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!" );
put_line( "Wave what?" );
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
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.