RSS

Monthly Archives: August 2013

Sorcerer

Steve Meretzky was a boundless fount of creative energy which couldn’t be contained by even his official projects for Infocom, many and varied as they were, and spilled over into daily life around the office in the form of elaborate themed parties, games that ranged from a multiplayer networked version of Boggle played over the DEC minicomputer to intense Diplomacy campaigns, and endless practical jokes. (“Memo hacking” became a particular favorite as Business Products ramped up and more and more buttoned-down business types started to appear in the office.) The lore and legends of daily life at Infocom, eagerly devoured by the faithful via the New Zork Times newsletter, is largely the lore and legends of Steve Meretzky, instigator and ringleader behind so much of the inspired lunacy.

Yet there was also another, oddly left-brained side to Meretzky. He was a compulsive organizer and even a bit of a neat freak; his meticulous and breathtakingly thorough archives informed much of Jason Scott’s Get Lamp project and, by extension, much of the Infocom history on this site. Mike Dornbrook, Infocom’s marketing director, calls Meretzky the most productive creative person he has ever met, one who evinced not a trace of the existential angst that normally accompanies the artistic temperament. Writer’s block was absolutely unknown to him; he could just “turn it on” and pour out work, regardless of what was happening around him or how things stood in his personal life.

But there was still another trait that made Meretzky the dream employee of any manager of creative types: he was literally just happy to be at Infocom, thrilled to be out of a career in construction management and happy to work on whatever project needed him. And so when Dave Lebling decided he’d like to write a mystery game and Marc Blank wanted to work on technology development, leaving the critical second game in the Enchanter trilogy without an author, Meretzky cheerfully agreed to take it on. When a certain famous but mercurial and intimidating author of science-fiction comedies came calling and everyone else shied away from collaborating with him, Meretzky said sure, sounds like fun. And when Tor Books offered Infocom the chance to make a series of Zork books in the mold of the absurdly successful Choose Your Own Adventure line, and everyone on the creative staff turned up their noses at such a lowbrow project even as management rubbed their hands in glee at the dollar figures involved, Meretzky took the whole series on as his moonlighting gig, cranking out four books that were hardly great literature but were better than they needed to be. Most gratifyingly of all, Meretzky ripped through all of these projects in a bare fifteen months whilst offering advice and ideas for other projects and, yes, getting up to all that craziness that New Zork Times readers came to know and cherish. Meretzky was truly a dream employee — and a dream colleague. One senses that if management had asked him to go back to testing after finishing Planetfall he would have just smiled and kicked ass at it.

Sorcerer, his sequel to Enchanter and Infocom’s first game of 1984, was, like so much of Meretzky’s work in this period, a bit of a thankless task. He neither got to devise the overarching plot and mechanics for the trilogy nor to bring things to a real conclusion, merely to write the bridge between fresh beginning and grand climax. Middle works in trilogies have always tended to be problematic for this very reason, and, indeed, Sorcerer is generally the most lightly regarded of the Enchanter games. I won’t really argue with that opinion, but I will say that Sorcerer is a very solid, entertaining work in its own right. It’s just that it gets a bit overshadowed by its towering companions, together arguably the best purely traditional adventure games ever to come out of Infocom, while also lacking the literary and thematic innovations that make games like Planetfall and Infidel — to neither of which it’s actually markedly inferior in overall quality — so interesting for people like me to write about.

Sorcerer casts you as the same budding enchanter you played in the game of that name. Having vanquished Krill, however, your star has risen considerably; you are now a member of magic’s innermost circle, the Circle of Enchanters, and protege of the Leader of the Circle, Belboz. Sorcerer opens with one of its most indelibly Meretzkian sequences. You are snug in your bed inside the Guild of Enchanters — but you don’t actually realize that for a few turns.

You are in a strange location, but you cannot remember how you got here. Everything is hazy, as though viewed through a gauze...

Twisted Forest You are on a path through a blighted forest. The trees are sickly, and there is no undergrowth at all. One tree here looks climbable. The path, which ends here, continues to the northeast. A hellhound is racing straight toward you, its open jaws displaying rows of razor-sharp teeth.

>climb tree Tree Branch You are on a large gnarled branch of an old and twisted tree. A giant boa constrictor is slithering along the branch toward you! The hellhound leaps madly about the base of the tree, gnashing its jaws.

>i You are empty-handed. The snake begins wrapping itself around your torso, squeezing the life out of you...

...and a moment later you wake up in a cold sweat and realize you've been dreaming.

Your frotz spell seems to have worn off during the night, and it is now pitch black.

Like the similarly dynamic openings of Starcross and Planetfall, albeit on a more modest scale, Sorcerer‘s dream sequence can be a bit of a misnomer. The rest of the game is much more open-ended and much less plot-driven than this sequence might imply. As you explore the conveniently deserted Guild — everyone except you and Belboz have gone into town to shop for the Guild picnic — you soon realize that Belboz has mysteriously disappeared. And so the game is on, fueled by the same sort of magic-based puzzles that served Enchanter so well. Indeed, Meretzky copied the code for the Enchanter magic system wholesale into Sorcerer, along with some of the same spells, which had to be a great help for someone working on as tight a timetable as he was. Sorcerer‘s one big magical innovation is a set of potions to accompany its spell scrolls, something notably absent not only from Enchanter but also from Lebling’s Spellbreaker, the final game of the trilogy.

Like all of the Enchanter trilogy a very traditional game, Sorcerer is divided into two open-ended areas of exploration, the Guild of Enchanters and a sprawling wilderness and underground map which ultimately proves to house Belboz’s abductor, the demon Jeearr (another thoroughly Meretzkian name, and a character who also turns up in the last of the Zork gamebooks he was writing at the same time). The overall feel is looser than Enchanter, with the first game’s understated humor replaced with a more gonzo sensibility that can rub some players the wrong way. This player, who felt that Planetfall often seemed to be trying just a bit too hard, doesn’t exactly find Sorcerer hilarious but never really found it irritating in the way that Meretzky’s earlier game could occasionally be either. Perhaps the fact that Sorcerer wasn’t explicitly billed as a comedy left Meretzky feeling freer not to force the issue at every possible juncture.

Another Planetfall trait, that of lots of Easter eggs and red herrings, is also notable in Sorcerer, but again to a lesser extent. The useless bits, such as a functioning log flume and roller coaster inside the amusement park inexplicably located almost next door to Jeearr’s infernal lair, are mostly good fun. The sadomasochistic “potion of exquisite torture” is a standout that is just a bit risque for the prudish world of adventure gaming:

>drink indigo potion The potion tastes like a combination of anchovies, prune juice, and garlic powder. As you finish swallowing the potion, a well-muscled troll saunters in. He whacks your head with a wooden two-by-four, grunting "You are playing Sorcerer. It was written by S. Eric Meretzky. You will have fun and enjoy yourself." He repeats this action 999 more times, then vanishes without a trace.

Another great bit comes if you use the aimfiz spell — “transport caster to someone else’s location” — to try to find Meretzky himself:

>cast aimfiz on meretzky As you cast the spell, the moldy scroll vanishes! You appear on a road in a far-off province called Cambridge. As you begin choking on the polluted air, a mugger stabs you in the back with a knife. A moment later, a wild-eyed motorist plows over you.

**** You have died ****

Like any old-school adventure game, Sorcerer is full of goofy and often random ways to die, from wandering into a room that’s missing a floor to getting buried under coins by an overenthusiastic slot machine. Still, Meretzky manages to skirt the letter if not quite the spirit of Andrew Plotkin’s Cruelty Scale through the gaspar spell: “provide for your own resurrection.” Gaspar returns you upon your death alive and well to the place where you last cast it, a handy substitute for the technological rather than arcane solution of restoring a saved game. If nothing else, its presence proves that Infocom was thinking about the arbitrary cruelty of most adventure games and wondering if a friendlier approach might be possible. (Space limitations would, however, always limit how far they could travel down this path. It would always be easier to simply kill the player than try to implement the full consequences of a bad — or simply unplanned for — decision.) Another sign of evolving thought on design comes in the form of the berzio potion (“obviate need for food or drink”), which slyly lets you bid adieu to the hunger and thirst timers of Enchanter and Planetfall. A year later, Spellbreaker would not even bother you with the whole tedious concept at all.

As the presence of amusement parks and casinos next to abducted enchanters and demons would imply, Sorcerer doesn’t concern itself at all with the fictional consistency that marked Planetfall or even, for that matter, Enchanter. Plot also takes a back seat for most of the game. You simply explore and solve puzzles until you suddenly bump into Jeearr and remember why you’re here. Likewise, some of the writing is a bit perfunctory if we insist on viewing Sorcerer as a literary experience. That, however, is not its real strength.

I find Meretzky slightly overrated as a writer but considerably underrated as a master of interlocking puzzle design. Sorcerer is full of clever puzzles, one of which, a relatively small part of the brilliant time-travel sequence in the coal mine, represents the last little bit of content which Infocom salvaged from the remaining scraps of the original MIT Zork. Yet it isn’t even one of the most memorable puzzles in Sorcerer; those are all Meretzky originals. In addition to that superb time-travel puzzle, there’s a fascinating thing that seems to be a maze but isn’t — quite. Both time-travel puzzles and pseudo-mazes were already burgeoning traditions at Infocom; both would remain obsessions of the Imps for years to come. Meretzky does both traditions proud here. I won’t say too much more about Sorcerer‘s puzzles simply because you really should enjoy them for yourself if you haven’t already. They’re always entertaining, clever, and (sudden deaths and one tricky sequence involving a timed mail delivery early in the game aside) fair, and don’t deserve to be spoiled by the likes of me.

Sorcerer shipped in March of 1984 in a box that was fairly plebeian for this era of Infocom. The crown jewel was contained inside the box this time, in the form of the infotater, an elaborately illustrated code wheel that was both one of Infocom’s most blatant uses yet of a feely as unabashed copy protection and so cool that it didn’t really matter. The infotater is today among the rarer pieces of Infocom ephemera. It remained in production for just a few months before Infocom switched to a standardized box format that was too small to accommodate it, and were thus forced to replace it with a less interesting table of information on plain paper.

Sorcerer sold decently, although not quite as well as Enchanter or the Zork games. (The steady downward trend in sales of Infocom’s flagship line of fantasy games would soon become a matter of increasing concern — but more on that in future articles.) Lifetime sales would end up in the vicinity of 45,000, with more than two-thirds of those coming in 1984 alone. It’s not one of the more ambitious games of Infocom nor, truth be told, one of the absolute best, but it is a solid, occasionally charming, playable game. If you find yourself in the mood for an enjoyable traditional text adventure that plays relatively fair with you, you could certainly do a lot worse.

(As always, thanks to Jason Scott for sharing his materials from the Get Lamp project.)

26 Comments

Posted by Jimmy Maher on August 26, 2013 in Digital Antiquaria, Interactive Fiction

Tags: enchanter, infocom, meretzky, sorcerer, zork

Seven Cities of Gold

13 Aug

Shortly after completing M.U.L.E., Ozark Softscape held a week-long brainstorming retreat with their producer from Electronic Arts, Joe Ybarra, inside the Little Rock house that served as their offices. Dan Bunten ^[1]Dan Bunten began living as the woman Danielle Bunten Berry in November of 1992. She died five years later.

In preparing this article, I of course reviewed what I had already written about Dani. I confess it made me cringe a bit. I have long been annoyed by the habit of people who know nothing of her games of using Dani as some generic representative of her sexuality, and wanted to move the focus firmly to her work as a game designer, to leave the politics of gender identity alone and focus on why she was a such a giant in her chosen field. I now realize that in doing so I seemed to dismiss and disrespect the other parts of her story, although I genuinely didn’t intend to do so. A couple of angry commenters who, it seemed to me, wanted to force me into the very narrative template I had been trying to avoid only hardened my position. I continue to want to avoid the standard structure of the genre of “Dani Bunten Berry stories” — but I also realize that they had some points as well. I particularly regret that I never referred to Dani by her female name even in my note at the end of the article. I literally never realized I had done this until my recent rereading, and now understand some objections about how I allegedly considered her unworthy of being referred to by her real name and the like a bit better. I won’t edit the article, as doing so could only make those who commented look unreasonable in ways they really weren’t. Anyway, it perhaps serves as a better lesson just as it is. Know, however, that if I was writing it today I would handle the issue somewhat differently.

That said, you’ve surely noticed that I continue to refer to Dani as “Dan” and “he” in the article above. I understand the logic of those who would say that Dani was always a woman, merely one who was by an accident of birth born into a man’s body. Certainly this is the argument most advocates for transsexual rights would make. For myself, I am all for transsexual rights, but also believe that gender and sexual identity may be more fluid than much transsexual rhetoric would have it. In the end, I have continued to opt for clarity and reality as all of Dani’s friends and colleagues knew it in the 1980s: of her being the man Dan Bunten. Referring to “Dani” and “she” in these articles would be confusing to the reader and at least at some level anachronistic, opposed to the consensus reality shared by everyone around her. I understand that this decision may not seem ideal to everyone, and even that it runs counter to some journalistic style guidelines. If you disagree with it, I can only ask you to believe me when I say it was made in good faith, with no intention to slight. For what it’s worth, reports are that Dani was never offended in the least by being referred to as a man when conversations came around to her years of living as Dan. arrived with a pretty good idea of the game he wanted to make next already in hand. He had recently become fascinated with a monster board game released by those famed purveyors of monster board games, Avalon Hill. Civilization places each player in charge of a single tribe at the dawn of history, about 8000 BCE, and lets her guide it down through the millennia as far as the time of the dawning of the glory that was Rome, about 230 BCE. Warfare plays a role, but Civilization isn’t really a traditional war game; equally important are exploration, culture, economics, and technological advancement. (Of course, all of these factors are inevitably interlinked.) With a scope like that, Civilization is just about as complicated and time consuming as board gaming gets. A full game generally consumes about eight hours even once you’ve learned how to play.

Dan’s colleagues dutifully set aside a day to play the game with him, to see what he was on about. They emerged blinking and befuddled, and not at all sure about the idea of a computerized version. How, after all, were they going to pack all of that complexity and grandeur into their little 48 K Atari 800s? Ybarra was likely motivated by another practical consideration: Civilization belonged to Avalon Hill, who were trying (with somewhat mixed results) to make a go of it in computer games, the place to which a dismaying quantity of their old customers were migrating. They weren’t likely to make it easy or cheap for a competitor to release a computer version of one of their big board-game titles. Better, Dan’s colleagues all argued, to make a more modest original game with some of the spirit of Civilization. This sort of conversation wasn’t that new to Ozark. Dan’s three partners, as well as Ybarra, freely acknowledged him to be a creative genius far beyond their own lights. Geniuses, however, occasionally need to be gently steered down practical roads, lest their Big Ideas overwhelm their sense of proportion; this they saw as part of their own modest contributions to Ozark.

Also in Ozark’s collection of board games was another Avalon Hill effort called Conquistador, a game of “The Age of Exploration: 1495-1600.” In it each player takes control of one of the great European powers as they explore, conquer, and eventually colonize the New World. Late in the game, wars among the players can develop as virgin territory gets harder to come by. It’s only slightly less daunting than Civilization; a complete game usually lasts five hours or so. Still, it felt like a concept that could be more readily pared down to something manageable on the Atari 800, and like one that could inspire a computer game original enough — particularly with a designer of Dan’s creativity on the project — that licensing wouldn’t become an issue. It also dealt with a subject that Dan and his brother Bill had found genuinely fascinating from an early age, when an uncle had given them their first book about the Conquistadors. And so Ozark’s next project was decided by the time the week was out.

Dan, still pining for Civilization, was initially not hugely enthusiastic. After he and Bill collected a tall stack of history books and dove in, however, he started to come around. Once again the Big Ideas started to come thick and fast. He envisioned a game played in three stages, like Conquistador. In the first, you would be exploring and dealing with the natives you encountered, which basically meant either trading and trying to establish peaceful alliances or doing a full-on Cortés and charging through their villages with swords swinging. The second stage would have you founding colonies, establishing permanent settlements and institutions in the New World rather than rushing back to Europe with each new shipful of gold. Finally, these emerging and expanding nations would have to deal with one another. Diplomacy and the results of its breakdown, wars, would ensue. Diplomacy being pretty difficult terrain for a computer opponent to navigate, Dan envisioned a game that, like M.U.L.E., would emphasize multiplayer play while offering computerized opponents merely as practice and fillers for empty human seats around the virtual table.

It was all very ambitious. Inevitably, the heartless hand of practicality — largely in the usual form of his partners — started to pare away at it pretty quickly. Stages two and three were excised entirely; this would be a game of exploration and conquest only, not politics or consolidation. You would also be restricted to playing as a representative of Spain and to exploring the lands of South and Central America that were historically conquered by Spain. The name Seven Cities of Gold was chosen as a reflection of this new emphasis on Conquistadors seeking after the wealth of exotic legends to bring home to Spain. Most painfully, it was decided to make the game single-player only, as it was ambitious enough as it was and no one knew quite how to make multiplayer work anyway. Besides, as Ybarra and everyone else at EA — not to mention the failure of M.U.L.E. — were able to attest, for whatever reason there just wasn’t a big market for multiplayer-focused strategy games. With EA and Ybarra sticking so loyally with Ozark despite M.U.L.E.‘s fate, there was perhaps a sense that Ozark owed them the best stab they could make at giving them a hit. At any rate, they owed it to themselves if they wanted to stay in this business; it was doubtful that even EA would continue to fund them if they delivered another under-performer like M.U.L.E. And so Seven Cities of Gold became the first single-player-only game Dan had ever made.

If that was a hard compromise to accept, there were consolations. The overarching Big Idea of Seven Cities, to be emphasized if necessary at the expense of everything else, would be Discovery. Dan had quickly realized when he first played Conquistador that it could not be a true recreation of the experience of exploring an uncharted continent for one very simple reason: the player came into it with a knowledge of the geography of the Americas, and with a bit of cursory outside research could know even the location of the capital of the Inca Empire. To remedy this, he proposed making a random map available in addition to the historical one. The historical map would be there out of obligation and for learning purposes; the real game would have you exploring New Worlds that were truly new to you.

The map generator turned into the most technically challenging element of the entire project. To be worthwhile, the random maps had to be as believable and logical as the historical. They couldn’t, in other words, just scatter landscape and natives about willy-nilly. From the manual:

There is a plate-tectonics model consulted for each creation. Mountain ranges are generated where the plates bump into each other. And secondary ranges (like the Allegheny Mountains on the historical map) may be created as well.

The program also consults a cultural dissemination model for its work. The influences of major civilizations are presumed to spread outward. Consequently, pueblo dwellers generally will be found between city-states and primitive agriculturalists. The model will allow for varying levels of this influence and can thus produce occasional continent arrangements which have no Incan-level civilizations. Alternately, it can make very rich and powerful arrangements, one which, like 16th-century Japan, are highly civilized from coast to coast.

The random-map generator was assigned to Jim Rushing, the purest coding mind at Ozark, who spent some four months struggling with it. It was quite a task for the little Atari; each map took a solid ten minutes of processing to generate. Frustratingly, the end result from early versions was always the same, a continent shaped like a giant peanut. Finally, Rushing found a bug in his random-number generator. Ybarra still recalls vividly the day that Dan called him to tell him that they had generated a believable alternate New World: “The energy and excitement was terrific. Dan was both elated and burnt out, but you could ‘hear’ him grinning on the other side of the phone.” Ybarra now firmly believed they were “creating another masterpiece.”

Indeed, the game is nothing if not elegant. Like in M.U.L.E., you are always embodied in the game by an onscreen avatar who visits shipyards, the pub, and the royal palace, and of course wanders through the New World as your surrogate. This can make it feel as much adventure game as strategy game; Seven Cities is anything but dry or abstract. The overland exploration which forms the heart of the game was inspired as much by Dan’s own experiences hiking the backwoods of Arkansas as his readings in history. He had particularly vivid memories of getting himself lost on occasion, and the relief engendered by coming upon a road or other familiar landmark. Seven Cities can prompt similar feelings as you press ever deep into this vast, unknown continent. The feeling of relief at finding your trusty ship sitting right there where you left it as you stumble out of the jungle with food supplies dwindling is almost indescribable.

But maybe the supreme achievement in verisimilitude is your interaction with the native tribes, as brilliant an abstraction of real-world experience into interface as the auctions of M.U.L.E. When you enter a new village, the inhabitants gather around you, surround you disconcertingly. You can give them gifts or try to “amaze” them by acting the part of one of their gods, but it’s always an uncertain, tentative communication that could erupt into violence at any time. Many times you will find yourself all but forced into massacring a village — or being massacred by them — by an inadvertent push of the joystick or a single panicked shot by a member of your own army who goes out of your control. It’s a superb simulation of how these encounters between two utterly alien cultures without a single word in common between them must have actually felt to the participants, and a lesson in just why they so often ended in violence even when both parties entered them with the best of intentions. Incredibly for a game of this vintage, the natives remember and communicate with one another. Attack one tribe in a region and the others will be much more suspicious. Try to “amaze” a group of natives too many times and it starts to become old hat — and they start to become suspicious.

For the desperately idealistic Dan, who was always eager to instil “a meaningful message,” the moral dimension of these encounters and the impact they would make on the player’s psyche were key not only to his game but to his very sense of his own worthiness as a person:

“The people I admire are the people who went to jail instead of Vietnam, or who go to India to do some good, or who are really committed to the environment. Those are the people who are really admirable. What I’m doing seems less important. I want to make a significant impact in a person’s life.”

Yet Seven Cities doesn’t preach; it leaves you to your conscience. Unquestionably, violence in Seven Cities often does pay, just as in real history, and the problematic nature of this was not lost on Dan:

“Many of the Conquistadors treated the natives horribly. Theirs was an arrogant and prideful approach to a society that had its own history and roots. But to be historically accurate required that we had to include violence. I don’t like the idea of players hurting other things, but there’s no alternative or you’re forcing your own moral decisions on an audience that ought to have a choice themselves.

“Bill and I were real Indian sympathizers when we were growing up. We always sided with the Indians instead of the cowboys. It just seems like such a neat, romantic culture to us, so in tune with the earth. Then to write a game where at least part of the game is wiping out Indians — that’s problematic.”

Seven Cities comments on your behavior toward the natives in only one way: if you get truly savage, the king will eventually tell you to please stop killing so many of them. But these words are never backed by any action, and the priority always remains to keep the gold flowing. The crown refuses to acknowledge that the gold and the killing that produces it are often inseparable. Such halfhearted carping is, as Dan noted, lifted straight from history, where it provided a way for those back in Spain to feel morally absolved while still benefiting from the killing and plundering of their countrymen.

Brilliant as its individual elements are, I do tend to have a problem appreciating Seven Cities of Gold as a holistic game. There is no competitor to play against, unless you count the natives you encounter — and the power imbalance between you and them is ultimately so great that, even if you choose the warlike approach, it’s hard to think of them in that role. Nor is there any in-game way to really lose or win. There isn’t even a definite end-point; you begin in 1495 and receive a rank based on your performance in 1540, but can continue to play on after that as long as you like. After a while the thrill of filling in the map and adding to my counts of missions and ships and rivers and other landmarks discovered starts to fade, and I start wishing for some goals, some sort of more specific direction. Dan himself delivered the following answer to the question, “How do I win?”

However you want. Seven Cities is a process-type game. You go along like real life. Life doesn’t have ends and wins and things like that. It has processes that you go through, and at times you stand back and say, “Hey, I’ve done pretty good so far.” Set your own goals really high and say, “That’s how I win.” Then go for it.

All of which is fine on the face of it, but Seven Cities just doesn’t feel to me like an intentional sandbox game in the mold of the (much later) SimCity. It rather feels like a design which is missing something it was originally intended to have, a possible legacy of the process of paring it down to a manageable project. On the other hand, I’m also willing to accept that this may just be down to a failure of imagination on my part, as the game received stellar reviews in its day and is still loved by many today.

Be that as it may, it seems to me that Seven Cities of Gold is still not so significant as a game in itself as for the frontiers it opened and the new things it dared to try. Its custom worlds, randomly generated at heart but meticulously terra-formed to be as believable as our own, became a staple of grand strategy games to come. Its consistent prioritizing of friendliness and elegant playability — the entire game is controlled, simply and intuitively, with a single joystick, and its manual consumes a scant 8 pages that spend as much time on historical background as game mechanics — served as an object lesson to games that used every key on the keyboard. The random maps, the native-encounter sequences, and the way that the whole game is played in “real time” rather than discrete turns also demonstrated how to take advantage of the unique abilities of the computer, rather than just encoding the rules of what could otherwise be a board game. And of course the moral ambiguity of this whole exercise, in which even peaceful alliances are ultimately made for the purpose of conquer and plunder, is never swept under the rug. Seven Cities has something to teach us about politics and history and perhaps even human nature. It goes well beyond the equipment lists and purely tactical concerns of a typical war game of the sort being pumped out by companies like SSI by the handful by 1984. Trip Hawkins declared that Ozark had pioneered a whole new genre of computer software: “edutainment.”

M.U.L.E. offered many of the same design lessons, but few others were thinking on this level at the time of Seven Cities‘s mid-1984 release. Troy Goodfellow goes so far as to call it “the most influential strategy game ever made.” That’s a bold statement even if we assume he’s implicitly restricting the field to computerized strategy games, but just the fact that Seven Cities is in the running in a world that contains games like Civilization (the computer version) says volumes.

Speaking of Civilization: one of those entranced by Seven Cities‘s innovations was a 30-year-old programmer and designer named Sid Meier, co-owner of a small publisher called MicroProse. Seven Cities and its determination to make strategy and history attractive and approachable became the inspiration for his breakthrough title, 1987’s Pirates!. The embodied interface of that game, which blurred the lines between strategy, adventure, and RPG while always making you feel that you are there, is lifted straight from Seven Cities; even the fonts and whole visual looks of the two games are similar. If Pirates!, generally acknowledged as one of the best computer games ever created, is even better than Seven Cities of Gold, it’s also true that it never could have existed without it, as Meier himself would happily admit. Later still, of course, Meier would manage what Dan never quite could, bringing all the complexity and grandeur — and then some — of the board game Civilization to the computer in an amazingly accessible way. Again, the road to Sid Meier’s Civilization could only have passed through Seven Cities of Gold.

While it may be most notable for the games it influenced, it’s also possible to say something about Seven Cities of Gold that is all too unusual in Dan Bunten’s career: the game was a hit in its own right. EA’s faith in their backwoods savants paid off at last, as Seven Cities sold at least 150,000 copies, five times the numbers done by M.U.L.E. and enough to make it EA’s biggest new game of 1984, in versions for the Atari 8-bit (the original and always the one that Dan himself saw as definitive), Commodore 64, Apple II, IBM PC, and eventually the Macintosh and the Amiga. Most of these ports were done by Ozark themselves or people within their circle. The Apple II version, for instance, came courtesy of a young University of Arkansas student named Mark Botner who spent the summer of 1984 working with them. He makes those days in the big house by the lake sound like an idyllic summer romance:

“What fun we had that summer. We would take a walk every day around Broadmoore Lake while our programs assembled for 15 minutes or so. We flew model airplanes, floated model boats in the lake, and played many different games. And, we actually got Seven Cities Of Gold ported to the Apple II!”

They were good times indeed. Suddenly the world was onto Dan Bunten and Ozark Softscape, as they (and particularly he) found themselves in constant demand for interviews, mentioned among the elites of the game industry.

While we leave our friends to enjoy a welcome taste of fame and fortune, you might want to try Seven Cities of Gold for yourself. If so, feel free to download the definitive Atari 800 version for use in the emulator of your choice.

(Finally, sources, which are largely the same as that last article: Dan wrote a column for Computer Gaming World from the July/August 1982 issue through the September/October 1985 issue. Those are a gold mine for anyone interested in understanding his design process. Particularly wonderful is his detailed history of Seven Cities of Gold‘s development in the October 1984 issue. Other interesting articles and interviews were in the June 1984 Compute!’s Gazette, the November 1984 Electronic Games, and the January 1985 Antic. Online, you’ll find a ton of historical information on World of M.U.L.E. Salon also published a good article about Dani ten years ago. The sadly now defunct Dani Bunten Berry Memorial Site is full of anecdotes and tributes, including the quote from Mark Botner which I used above. And see the site of the (apparently stalled) remake Alpha Colony for some nice — albeit somewhat buried — historical tidbits.)

Footnotes[+]

Footnotes
↑1	Dan Bunten began living as the woman Danielle Bunten Berry in November of 1992. She died five years later. In preparing this article, I of course reviewed what I had already written about Dani. I confess it made me cringe a bit. I have long been annoyed by the habit of people who know nothing of her games of using Dani as some generic representative of her sexuality, and wanted to move the focus firmly to her work as a game designer, to leave the politics of gender identity alone and focus on why she was a such a giant in her chosen field. I now realize that in doing so I seemed to dismiss and disrespect the other parts of her story, although I genuinely didn’t intend to do so. A couple of angry commenters who, it seemed to me, wanted to force me into the very narrative template I had been trying to avoid only hardened my position. I continue to want to avoid the standard structure of the genre of “Dani Bunten Berry stories” — but I also realize that they had some points as well. I particularly regret that I never referred to Dani by her female name even in my note at the end of the article. I literally never realized I had done this until my recent rereading, and now understand some objections about how I allegedly considered her unworthy of being referred to by her real name and the like a bit better. I won’t edit the article, as doing so could only make those who commented look unreasonable in ways they really weren’t. Anyway, it perhaps serves as a better lesson just as it is. Know, however, that if I was writing it today I would handle the issue somewhat differently. That said, you’ve surely noticed that I continue to refer to Dani as “Dan” and “he” in the article above. I understand the logic of those who would say that Dani was always a woman, merely one who was by an accident of birth born into a man’s body. Certainly this is the argument most advocates for transsexual rights would make. For myself, I am all for transsexual rights, but also believe that gender and sexual identity may be more fluid than much transsexual rhetoric would have it. In the end, I have continued to opt for clarity and reality as all of Dani’s friends and colleagues knew it in the 1980s: of her being the man Dan Bunten. Referring to “Dani” and “she” in these articles would be confusing to the reader and at least at some level anachronistic, opposed to the consensus reality shared by everyone around her. I understand that this decision may not seem ideal to everyone, and even that it runs counter to some journalistic style guidelines. If you disagree with it, I can only ask you to believe me when I say it was made in good faith, with no intention to slight. For what it’s worth, reports are that Dani was never offended in the least by being referred to as a man when conversations came around to her years of living as Dan.

30 Comments

Posted by Jimmy Maher on August 13, 2013 in Digital Antiquaria, Interactive Fiction

Tags: atari 8-bit, dan bunten, electronic arts, seven cities of gold

How Things Work: Commodore 64 and Summer Games Edition

09 Aug

I’m always trying to convey a sense of the audacity and creativity of hackers of the early PC era, who made so much out of so little. I include amongst this group both the hardware hackers who created the machines themselves and the software hackers who took them to places even their creators never imagined. In that spirit, I thought today we’d look at how the Commodore 64’s hardware team managed to make it do some of what it could given the technical constraints under which they labored, and how the software team who created Summer Games at Epyx found ways to make it do even more than they had fully considered. So, much of this article is for the gearheads among you, or at least those of you who’d like to understand a bit more of what the gearheads are on about. If you’re a less technical sort, perhaps you’ll be consoled by learning about some of the softer factors that went into the Summer Games design as well. And if that’s not interesting, hey, you can still watch my wife and I (mostly I) fail horribly at various Summer Games events via the movie clips.

This is, by the way, my first attempt to make use of WordPress 3.6’s integrated video capabilities. You’ll need an up-to-date browser with good HTML 5 support to see the clips. Hopefully my site won’t choke on the bandwidth demands. We’ll see how we go.

While you’re waiting (hopefully not too long) for the videos to load, let’s consider the basic visual capabilities of the Commodore 64: a palette of 16 colors at a resolution of 320 X 200. Those capabilities are, to say the least, modest by modern standards, but they actually present a huge problem when paired with another key specification: the 64 has just 64 K of RAM memory. This is all there is to work with; there is no separate bank of video memory, as on a modern computer. Everything — programs, data, the contents of the screen, and miscellaneous other things like buffers for the disk drive — must draw from this pool.

Now, a modern programmer wishing to represent a 320 X 200 screen with 16 colors in memory would probably just store it as a series of pixels, with one byte devoted to each pixel and storing a value of between 0 and 15 to represent that pixel’s color. This approach, known as bitmap graphics, is straightforward and eminently flexible, but there’s a problem. Consider: a 320 X 200 screen has exactly 64,000 pixels. In other words, by devoting one byte to each pixel we’ve just filled our entire 64 K of memory with a single screen.

Let’s consider then. Even a modern programmer, if she’s a more efficient sort, might note that we only actually need four bits to store a number between 0 and 15, and could therefore, at the cost of a bit more confusing layout, pack two pixels into every byte. That reduces consumption to a little under 32 K — better, but it’s still untenable to devote half of our precious memory to the screen.

It’s because bitmap graphics are so demanding that only high-end machines like the Apple Lisa and Macintosh used them by default at the time of Summer Games‘s release. And, notably, even those 68000-powered machines only displayed black and white, which reduced the requirement from four bits per pixel to one — a simple on-off, black-or-white toggle. Let’s consider the alternative that the 64’s designers, as well as those of many other machines, employed in various ways: character graphics.

In its default mode, the 64 subdivides its screen into a grid of character cells, each 8 X 8 pixels. Thus there are 40 of them across and 25 down, corresponding to the machine’s standard text display. Elsewhere in memory are a set of up to 256 tiles that can be copied into these cells. A default set, containing the glyph for each letter, number, and mark of punctuation in addition to symbols and simple line-drawing figures, lives in ROM. The programmer can, however, swap this set out for her own set of tiles. This system is conceptually the same as the tile-graphics system which Richard Garriott used in the Ultima games, but these tiles are smaller (only the size of a single character) and monochrome, just a set of bits in which 1 represents a pixel in the foreground color, 0 a pixel in the background color. The latter color is set globally, for the whole screen. The former is specified individually for each cell, via a table stored elsewhere in memory.

So, let’s look at what all this means in terms of memory. Each cell on the screen consumes one byte, representing the number (0 to 255) of the tile that is placed there. There are 1000 character cells on a 40 X 25 display, so that’s about 1 K consumed. We need 8 bytes to store each tile as an 8 X 8 grid of on-off pixels. If we use all 256, that’s 2 K. Finally, the color table with the foreground color for each cell fills another 1 K. We’ve just reduced 32 K to 4 K, or just 2 K if we use the default set of character glyphs in ROM. Not bad. Of course, we’ve also introduced a lot of limitations. We now have to build our display, jigsaw-puzzle style, from our collection of tiles. And each cell can only use two of our total of 16 colors, one of which can be unique to that cell but the other of which must be the same for the entire screen. For someone wishing to make a colorful game, this last restriction in particular may just be too much to accept.

Enter multicolor character mode. Here, we tell the 64 that we want each tile to be not monochrome but drawn in four colors. Rather than using one bit per pixel within the tile, we now use two, which allows us to represent any number from 0 to 3. One of these colors is still set individually for each cell; the other three are set globally, for the screen as a whole. And there’s another, bigger catch: because we still only devote eight bytes to each tile, we must correspondingly reduce its resolution, and that of the screen as a whole. Each tile is now 4 X 8 (horizontally elongated) pixels, the screen as a whole 160 X 200. Even so, this is easily the most widely used mode in Commodore 64 games. It’s also the mode that Scott Nelson (little brother of Starpath co-founder Craig Nelson) chose for Summer Games‘s flag selection screen.

But… wait, you might be saying. Surely the colorful screen shown above doesn’t always use the same three of the four colors within each tile. In fact, it doesn’t, and this introduces us to one of the keys to getting the most out of the Commodore 64: raster interrupts.

The picture on a cathode-ray-tube television or monitor is generated by an electron gun which moves across and down behind the screen, firing charged electrons at phosphors that coat the back of the screen glass. This causes them to briefly glow — so briefly, in fact, that the gun must paint the screen 60 times per second for televisions using the North American NTSC standard, or 50 times for the European PAL standard, in order to display a stable image without flicker. After painting each line of the screen from left to right, the gun must move back to the left to paint the next. This split second’s delay can be exploited by the Commodore 64 programmer. She can ask the machine to generate what’s known as a raster interrupt when the gun finishes painting a given line. She then has a few microseconds to make changes to the display configuration before the gun starts painting the next line. She can, for example, change one or more of the three supposedly fixed colors, as Scott Nelson does to generate the screen shown above.

But let’s say we don’t want to deal with trying to create a picture using tiles. The Commodore 64 actually does also offer a bitmap mode of sorts, albeit one with restrictions of its own that allow it to reduce the memory footprint from an untenable 32 K to a more reasonable if still painful 9 K. Here an 8 K chunk of memory is allocated to the bitmap, with each bit representing the status (on or off) of a single pixel. The foreground color represented by an “on” pixel is once again determined by a 1 K color table, with the colors still sorted into 8 X 8 pixel blocks. This leads to the most obvious oddity of the 64’s bitmap mode: the bitmap does not run all the way across the screen and then down, but rather across and down through each 8 X 8 cell that is assigned a given foreground color.

For those willing to trade resolution for colors, there is also a multicolor bitmap mode, which, like the multicolor character mode, treats each two bits as representing a single pixel of one of four possible colors. Horizontal resolution is accordingly reduced to 160 pixels. This mode is, however, more flexible than multicolor character mode in its choice of colors. Another area of memory, of 1 K, is allocated to a collection of color pairs for each cell, each pair packed into a single byte. Thus we can freely choose three of the four colors found within each cell without resorting to raster interrupts or other tricks. Total memory devoted to the display in multicolor bitmap mode amounts to 10 K.

That may not look like much at first glance, but for a programmer trying to shoehorn a complex game into 64 K it’s quite a sacrifice indeed. For this reason, and because its other restrictions could make it almost as challenging to work with as character mode, bitmap mode is not used as often as you might expect in Commodore 64 games. Summer Games is, however, a partial exception, employing bitmap mode in quite a number of places. For instance, Stephen Landrum’s opening-ceremonies sequence uses a multicolor bitmap. This sequence also demonstrates another critical part of the 64’s display hardware: sprites.

Doing animation by changing the contents of screen memory is very taxing on a little 8-bit CPU like the 64’s 6502, not to mention tricky to time so that changes are not made in the middle of screen paints, which would result in ugly jerking and tearing effects. Sprites come to the rescue. Indeed, their presence or absence is a good indication of whether a given machine from this era is pretty good at playing graphically intense games (the 64, the Atari 8-bit lines) or not (the Apple II, the IBM PC). A sprite is a relatively small graphical element which is overlaid onto the physical screen, but independent of the bitmap or tile map stored in memory. It can be moved about quickly at minimal cost, just by changing a couple of registers. The display circuitry does the rest.

The 64 offers eight sprites to the programmer, each exactly 24 pixels wide by 21 tall. The image for each is stored in memory as the usual grid of on/off bits, for the modest total of 64 bytes used per sprite. An on bit represents the sprite’s color, of which each has exactly one; an off bit represents transparency, so that whatever is on the screen behind shows through. This means that the 24 X 21 pixel size is not so arbitrary as it may first appear; a smaller sprite can be displayed simply by turning off the unneeded pixels.

There is also the inevitable multicolor sprite, which gives us three foreground colors to work with at the expense of half of our horizontal resolution. In this mode, the sprite is effectively just 12 X 21 pixels, but each pixel is now twice as wide as before, resulting in the same physical width on the screen. As in multicolor character mode, the second and third colors are fixed across all sprites in this mode.

A sprite can be pointed to different addresses in memory for its image between screen paints, creating the possibility of making animated sprites which cycle through a sequence of frames, page-flip style. Likewise, single- and multicolor sprites can be placed together and moved in lockstep to create larger or more complex onscreen figures. In the sequence above, the runner is made from three single-color sprites, each of which cycles through 14 frames of animation. (If you’ve played Impossible Mission, he may look familiar to you: he is in fact the same sprite as your avatar in that game, which Dennis Caswell happily shared with his colleagues.) The flames are four multicolor sprites, each with four frames of animation. And each of the eight doves is a single single-color sprite of eight animation frames.

But… again, wait. That’s far more than eight sprites in total, isn’t it? As you may have guessed, Landrum uses raster interrupts to reconfigure and thus reuse sprites as each screen paint proceeds. With the addition of such tricks the 64’s effective limit becomes not eight sprites in total but no more than eight sprites horizontally parallel with one another.

Let’s take another example, this time one showing an actual, interactive event in action: Stephen Landrum’s pole vault. I have my usual mediocre performance in the clip that follows, but my wife Dorte kicks some ass and actually demolishes our old world record.

The screen you see here is another multicolor bitmap. The vaulter is made up of three single-color sprites, which cycle through seven frames of animation as he runs and are then changed appropriately to reflect his state after he goes airborne. The pole is three single-colored sprites and the crossbar is a single multicolored sprite, as is, surprisingly and cleverly, the stationary top of the nearer (right-hand) upright. To understand this last, we have to understand the 64’s concept of sprite priority. Sprites are numbered from 0 to 7. If two sprites overlap one another, the sprite with the lower number is drawn on top of the one with the higher number. Landrum uses this property to easily create the illusion of the jumper passing behind the nearer upright as he soars through the air.

You might have noticed that the pole, the crossbar, and the upright are all quite large. This is down to yet another feature of the 64’s sprite system. It’s possible to expand a sprite vertically or horizontally or both, doubling its size (but not its resolution).

The pole vault is not quite as polished as most of the events, which may be a sign that, as one of the later events completed, it was a bit rushed. There’s some odd artifacting in the pole, for instance. And there’s a wonderful bug that lets you vault under the crossbar on its highest setting, creating a world record for the ages.

The two swimming events, which were started by Randy Glover but finished by Landrum following the former’s abrupt resignation, are the most complex in Summer Games. They’re largely an exercise in rhythm; you have to press the joystick button as your swimmer’s arms enters the water, then release it when they emerge. I’m awful at it, but Dorte is pretty good.

The clock at top right is formed from six single-color sprites, each swimmer from four. The rest of what you see here may begin to illustrate how crazy you can get with raster interrupts. Each paint begins with the 64 in single-color bitmap mode. This allows the text (“Ready… Set… Go!”), which is drawn and erased directly into the bitmap, to be rendered in the higher resolution. But then, just as the electron gun reaches the top of the stands, the screen is changed to a multicolor bitmap.

Glover and Landrum use a technique known as double buffering to make the scrolling as smooth as possible. There are actually two bitmaps in memory, one of which is always being displayed and the other of which is being updated by the CPU for the next step in the scroll. When the time comes, the two are swapped, as the 64’s VIC-II graphics chip is pointed to the other in the pair. Well, it’s almost that simple. Complications arise because the poor 6502 just doesn’t have time to completely redraw a screen in memory for every pixel of scroll. Luckily, it doesn’t have to. The VIC-II also has what are known as horizontal and vertical fine-scrolling registers. They allow the programmer to shift the bitmap that appears onscreen by from 1 to 7 bits to the right (as in the swimming events) or down. Since this will create an ugly empty zone at the edges of the display for which the computer has no pixel data to display, another register lets the programmer expand the size of the border slightly to cover these cells — the width of the screen is reduced from 40 to 38 columns, or the height from 25 to 24 lines. Now it’s possible for Glover and Landrum to scroll the screen eight pixels before having to swap to the alternate bitmap, giving the CPU time to make said bitmap. Double buffering is rather unusual to find on the 64, as it’s horrendously expensive in memory. And indeed, the swimming events use virtually every last byte.

But that’s probably enough tech talk for today. Just for fun — and because if you got through all that you’ve earned it — let’s look at the other events in somewhat less exhaustive (exhausting?) detail.

The two running events have their origin in Starpath’s old Supercharger decathlon project, but were brought to the 64 and completed by Brian McGhie. Like virtually everyone at Epyx, he had no particular knowledge of or burning interest in Olympic sports. He therefore relied on a stack of old Sports Illustrateds to try to get the look of his runners and the stadium right. The events are very similar in appearance, but unlike the swimming events very different in execution. The 100 meter dash is a notorious joystick killer. You have to move the stick back and forth as quickly as possible — nothing more, nothing less. The 4 X 400 meter relay, by contrast, is the most cerebral of the events, a game of energy conservation and chicken. I’m unaccountably good at both, much to Dorte’s frustration.

Interestingly, the scrolling in these events is implemented in an entirely different way from that in the swimming, illustrating how very much Summer Games is really a collection of individual efforts brought together under one banner. McGhie uses a multicolor character screen, and rather than using double buffering updates the hidden border areas on the fly to… but I promised to stop with the tech talk, didn’t I?

The diving event is yet another of Landrum’s. The diver here rather disconcertingly never surfaces after entering the water, simply because Landrum ran out of time.

Skeet shooting was a joint project of John Leupp, Steve Mudry, and Randy Glover prior to his departure. They originally planned to show the shooter on the screen, as in all of the other events, but found it difficult to work out a practical way of implementing the event from that perspective. So skeet shooting received the only first-person perspective in Summer Games, and the poor shooter was left out entirely.

Finally, there’s the gymnastics event — really just a vault — by Mudry. In an example of the, shall we say, casual approach to box art that was so rife in this era, the Summer Games box shows someone doing a handstand.

If nothing else, this article has hopefully conveyed what a tricksy machine the Commodore 64 is, full of hidden capabilities and exploitable quirks. Learning to make it dance for you requires considerable time even if you have examples to follow. If you don’t… well, small wonder that its games were just beginning to come into their own in 1984, the year it had its second birthday. And Epyx and companies like it were barely scratching the surface. In a couple of years Summer Games would look downright quaint.

You can download the original Commodore 64 Summer Games and its manual from here if you like, for use in the emulator of your choice (I recommend VICE). Unlike most of the disk images floating around the Internet, this one is pristine, with the original set of world records, so you and your friends and/or family can make your own records — which is about 20% of the fun of playing Summer Games — rather than be shamed by the performances of obsessed teenagers from two or three decades ago.

We’ll continue to observe the Commodore 64 scene with interest in future articles. But next we’ll check in with a group of Atari 8-bit loyalists: the backwoods savants of Ozark Softscape.

(This article draws again from the Epyx retrospectives in the July 1988 and August 1989 issues of Commodore Magazine. Technical details of Summer Games were drawn from the Commodore 64 design case study which appeared in the March 1985 IEEE Spectrum. I also lifted the diagram showing the 64’s unusual bitmap mode from there. For what it’s worth, my favorite 64 technical reference is Mapping the Commodore 64 by Sheldon Leemon. And if I may be forgiven a blatant plug, do check out my book on the Amiga if you’re interested in the sort of technical details I’ve delved into in this post. Some of what I go into in the book actually apply equally to the 64, and I explain basic concepts, starting with what a bit and byte actually are, much more fully there.)

32 Comments

Posted by Jimmy Maher on August 9, 2013 in Digital Antiquaria, Interactive Fiction

Tags: c64, commodore, epyx, games series

From Automated Simulations to Epyx

04 Aug

When Robert Botch joined Automated Simulations as director of marketing just as 1982 expired, it wasn’t exactly the sexiest company in the industry. They were still flogging their Dunjonquest line, which now consisted of no less than eleven sequels, spinoffs, and expansions to Temple of Apshai. More than a year after co-founder Jon Freeman had left in frustration over partner Jim Connelley’s refusal to update Automated’s technology, the entire line was still derived from the same BASIC-based engine that had first been designed to run on a 16 K TRS-80 back in 1979. It was hard for anyone to articulate why someone would choose to play a Dunjonquest game in a world that contained Ultima and Wizardry. And, indeed, Automated’s sales numbers were not looking very good, and the company had stopped making money almost from the moment that the Ultima and Wizardry series debuted. Still, that hadn’t prevented them from benefiting from the torrents of venture capital that entered the young industry in 1982, courtesy of the pundits who were billing home computers as the next big thing to succeed the game consoles. But now the investors were getting worried, wondering if this stodgy company and their somewhat pedantic approach to gaming had really been such a good risk after all. Thus Botch, whom Connelley hired under pressure to remake Automated’s image.

Botch’s first assignment was to visit the Winter Consumer Electronics Show in Las Vegas that January, with Dunjonquest titles in tow to display to the crowd on a big-screen television rented for the occasion. Botch, who knew nothing about computers or computer games, didn’t much understand the Dunjonquest concept. He could hardly be blamed, for just trying to figure out which one you could play was confusing as hell: you needed to already have Temple of Apshai to play these additional games, but needed Hellfire Warrior to play those, etc. He was therefore relieved when another employee handed him a disk containing a straightforward, standalone action/puzzle game for the Atari home-computer line called Jumpman, a sort of massively expanded version of the arcade classic Donkey Kong with thirty levels to explore. Unusually for Automated, who usually developed games in-house, its presence was the result of an unsolicited third-party submission from a hacker named Randy Glover.

Randy Glover, developer of Jumpman

Botch was such a computer novice that he couldn’t figure out how to boot the game; his colleague had to tell him to “put it in that little slot over by the computer.” But when he finally got it working he fell in love. The rest of the show turned into an extended battle of wills between Botch and Connelley. The latter, who was determined to showcase the Dunjonquest games, would “come over, yell a lot, and tell me to take the disk out. Whenever he left the room, I’d load the program in again.” The crowd seemed to agree with Botch: he left CES with a notebook full of orders for the as yet unreleased Jumpman, convinced that in it he had seen the only viable future for his new employers.

The embattled Connelley saw his power further eroded the following month, when the investors brought in Michael Katz, an unsentimental, hard-driving businessman with an eye for mainstream appeal. He had spent the past four years at Coleco, where he had masterminded the launch of some very successful handheld electronic games as well as the ColecoVision console, which had just sold more than 500,000 units in its first Christmas on the market. It was first agreed that Connelley and Katz would co-lead the company, but this was obviously impractical and untenable. In a scenario that could have easily happened to Ken Williams at Sierra if he had been less strong-willed and business-savvy, Connelley was being eased out of his own company by the monied interests he had welcomed with open arms. Seeing which way the wind was blowing, he left within months, taking a number of his loyalists with him to form a development studio he named The Connelley Group, which would release a couple of games through Automated before becoming free agents and eventually fading away quietly.

Katz, Botch, and the other newcomers were thus left alone to literally transform Automated Simulations into a new company. Automated had for some time now been branding many of their games with the label of “Epyx,” arrived at because their first choice, “Epic,” was already taken by a record label. No matter; “Epyx” was a better name anyway, proof that even a blind-to-PR squirrel like Connelley could find a nut every now and again. Katz and Botch now made it the official name of the reborn company, excising all trace of the stodgy old “Automated Simulations” name. Gone also would be the nerdy old Dunjonquest line which positively reeked of Dungeons and Dragons sessions in parents’ basements. They would instead strive to make Epyx synonymous with colorful, accessible games like Jumpman, aimed straight at the heart of the mass market. The old slogan of “Computer Games Thinkers Play” now became “Strategy Games for the Action-Game Player,” and they hired Chiat Day, Apple’s PR firm and the hottest such in Silicon Valley, to remake Epyx’s image entirely.

Jumpman itself made a good start toward that goal. It was a huge hit, especially once ported to the Commodore 64. One of the first games to really take proper advantage of the 64’s audiovisual capabilities, it hit that platform like a nova at mid-year, topping the sales charts for months and probably becoming the bestselling single Commodore 64 game of 1983. It alone was enough to return Epyx to profitability. Unsurprisingly given commercial returns like that, from now on Epyx would develop first and most for the 64. They also hired Glover to work in-house. Before the end of the year he had already delivered a cartridge-based pseudo-sequel, Jumpman Junior, to reach ultra-low-end systems without a disk drive.

But now Katz had a problem. Other than Glover, he lacked the technical staff to make the Jumpmans of the future. Most of them had left with Connelley — and anyway games like their old Dunjonquests were exactly what the new Epyx didn’t want to be making. Then Starpath caught Katz’s eye.

Back in 1981, two former Atari engineers, Bob Brown and Craig Nelson, had founded Arcadia, Inc., eventually to be renamed Starpath after the release of the Arcadia 2001, an ill-conceived and short-lived games console from Emerson Radio Corporation. Drawing from friends, family, and former colleagues, Brown and Nelson put together a crack team of hardware and software hackers to make their mark in the Atari VCS market. Their flagship product was the marvelously Rube Goldberg-esque Supercharger, which plugged into the VCS’s cartridge port and added 6 K of memory (which may not sound like much until you remember that the VCS shipped with all of 128 bytes), new graphics routines in ROM, and a cable to connect the console to a cassette player. Starpath developed and released half a dozen games on cassette for use with the Supercharger, most of them apparently quite impressive indeed. But problems dogged Starpath. The company lived in constant fear of legal action by Atari, whom Brown and Nelson had not left on particularly good terms, in response to their unauthorized expansion. It did eventually become clear that Starpath had little to fear from Atari, but for the worst possible reason: the videogame market was collapsing, and Atari had far bigger problems than little Starpath. By late 1983 Starpath was floundering. Katz swooped, buying the entire company for a song and moving them lock, stock, and barrel from Santa Clara, California, into Epyx’s headquarters in nearby Sunnyvale.

Katz had no interest in any of Starpath’s extant products for a dead Atari VCS market. No, he wanted the programming talent and creative flair that had led to the Supercharger and its games in the first place. If they could do work like that on the Atari VCS, imagine what they could do with a Commodore 64. The Starpath folks would prove to be the final, most essential piece in his remaking of Epyx.

One of Starpath’s programmers, Dennis Caswell, had been playing around with ideas for a platforming action-adventure game before the acquisition. Indeed, he was already at work trying to animate the running man who would be the star. It was decided to let Caswell, who had three Supercharger games under his belt, run with his idea on the Commodore 64. He says his elation at the platform change was so great that “I unplugged my [Atari] 2600 and threw it out of my office and into the hall.” Working essentially alone, Caswell crafted one of the iconic Commodore 64 games and one of the bestselling in the history of Epyx: Impossible Mission.

Starpath had also been working on a decathlon simulation. In fact, it was far enough along to be basically playable. They discussed porting it to the 64, but the capabilities of that machine quickly led them to think about something more than just a simulation of track and field. Why not use the luxury of 64 K of memory and disk-based storage to simulate a broader cross-section of Summer Olympic events? With the 1984 Summer Olympics coming to Los Angeles, it seemed the perfect game for the zeitgeist, with exactly the sort of mass-market appeal Katz wanted from his new titles. He thought it a brilliant idea, and even went so far as to approach the Olympic Committee about making it an officially licensed product. He found, however, that Atari had long before sewn up the rights, back when they had been the fastest growing company in America. Epyx therefore decided to do everything possible to associate the game with the Olympics without outright declaring it to be an official Olympics simulation. They pushed the envelope pretty far: the game would be called Summer Games, would begin with an opening ceremony and a runner lighting a flame to the strains of “Bugler’s Dream,” would offer medals, would (as its advertising copy proclaimed) let you “go for the gold!” representing the country of your choice. Such legal boundary-pushing became something of a habit; witness Impossible Mission, which plainly hoped to benefit from an association with Mission: Impossible. (This in spite of the fact that Scott Adams had already been forced by the lawyers to change the name of his third adventure from Mission Impossible to Secret Mission.) In the case of Summer Games, Epyx likely got away with it because Atari was in no financial shape to press the issue and the Olympic Committee, never the most progressive institution, was barely aware of home-computer games’ existence. To this day many people are shocked to realize that Summer Games is not actually an official Olympics game. It all speaks to Katz’s determination to create games that felt up-to-date and relevant to the times. Yes, sometimes that could backfire, leading to trying-way-too-hard titles like Break Dance. Much of the time, however, it was commercial gold.

The original design brief for Summer Games called for ten events. The team also very much wished to include head-to-head, real-time competition wherever the nature of the sport being simulated allowed it. Beyond that, they would pretty much make it up on the fly; even the events themselves were largely chosen in the moment. The Starpath programmers’ talents were augmented by Randy Glover of Jumpman fame and Epyx’s first full-time artist, Erin Murphy. They were all under the gun from the start, for Katz wanted them to have something ready to show at the 1984 Winter CES, barely six weeks away when the project was officially green-lit. They worked through the holidays to deliver. Epyx arrived at CES with a very impressive albeit non-interactive opening-ceremonies sequence, fairly playable 4 X 400-meter relay and 100-meter dash races (both partially adapted from Starpath’s old decathlon project), and a diving event. At the show they learned that they had more competition in the (pseudo-)Olympics genre beyond Atari. HESWare, an aggressive up-and-comer not that dissimilar to Epyx who were about to sign Leonard Nimoy as their spokesman, showed HES Games. The prospect pushed Epyx to make sure Summer Games both met its planned pre-Summer Olympics release date and was as good as they could make it. To help with the former, the original plan for ten events was reduced to eight, principally via the sacrifice of weight lifting (fans of which sport would have to wait until 1986’s World Games to get their due). To help with the latter, more resources and personnel were poured into the project.

Even as this happened, attrition, a constant at Epyx, also became a concern. Katz’s new Epyx could be a rewarding place, but also an unrelentingly intense and competitive one, full of mathematical athletes convinced they were the smartest people in the room and all too happy to demonstrate it at their rivals’ expense. The spirit of competition extended beyond working hours; hundreds of dollars changed hands weekly in epic games of poker. Even some of Epyx’s brightest stars eventually found the company’s testosterone- and brainpower-fueled culture too much to take. Thus Starpath co-founder Bob Brown, finding Starpath’s new masters not to his liking, left quite soon after the acquisition, and Randy Glover, who had been assigned to the swimming events, abruptly left not long after CES. The swimming events were taken up by Stephen Landrum, the biggest single contributor to the project as a whole, who also did the opening ceremonies and the diving and pole-vaulting events.

It had been decided early on that Summer Games would let you compete as the representative of any of a variety of nations, complete with flags and national anthems to play during the medal ceremonies. Since it obviously would not be possible to include all of the 140 countries who would participate in the real Olympics, Epyx was left with the question of which ones should make the cut. Beyond the big, obvious powerhouses of the United States, the Soviet Union, and China, commercial considerations once again reigned supreme here. Katz had begun signing deals with foreign distributors, pushing hard to get Epyx’s games into the vibrant British and steadily emerging Western European software markets. Epyx reasoned that players in these countries would want the opportunity to represent their own nation. Thus relative Summer-Olympic non-factors like Norway and Denmark were included in the game, while potent teams from parts of the world that didn’t buy computer games, like East Germany, Romania, and Yugoslavia, were omitted. Most of the countries included had never been visited by anyone at Epyx. They sourced the flag designs from a world atlas, and called consulates and sales connections in Europe to drum up sheet music for the various anthems. Many of those anthems had never been heard by anyone working on the game; if some sound a bit “off” in tone or tempo, perhaps that’s the reason. For the coup de grâce, Epyx couldn’t resist including their own company as one of the “nations,” complete with a national anthem that was actually the Jumpman theme.

Summer Games was nearing the final crunch time on May 8, 1984, when the Soviet Union initiated a boycott of the Los Angeles Games in a rather petty quid pro quo for the West’s boycott of the 1980 Moscow Games. (The people who were really hurt by both gestures were not the governments of the boycottees but a generation of athletes on both sides of the political divide, who lost what was for many literally a once-in-a-lifetime opportunity to compete against the true best of their peers on the biggest stage their sports could offer them.) Epyx quickly decided to leave the Soviet Union in their version of the Olympics. After the game’s release, they reached out a bit cheekily to the Soviets in real life. Botch:

We sent the Russian [read: Soviet] embassy (in Washington, D.C.) several copies of Summer Games for the Commodore 64. An enclosed letter stated since they would not be competing in the regular Olympics, at least they could participate in our version of the Games. This package was eventually returned to us with a thank-you note, because they only had access to Atari home computers. Our marketing people quickly replaced the Commodore software with Atari material and sent it back. I always wondered if they enjoyed the game, because we never heard from them again.

Epyx’s bigger concern was the same as that of everyone involved with the Los Angeles Games, whether directly or tangentially: what commercial impact would the boycott have? It seemed it must inevitably tarnish the Games’ luster somewhat. In the case of both Summer Games and the Olympic Games themselves, the impact would turn out to be less than expected. The latter has gone down in history as the most financially successful Olympics of modern times, while Summer Games would become — and this probably comes as anything but a spoiler to most of you — one of the bestselling computer games of the year, and the first entry of the bestselling series in the history of the Commodore 64.

Katz was determined to get Summer Games out in June, to beat HES Games to the market and to derive maximum advantage from the pre-Olympics media buildup. The team worked frantically to finish the final two events (gymnastics and skeet shooting) and swat bugs. They worked all but straight through the final 72 hours. Disks went into production right on schedule, the morning after the code they contained had been finalized.

Summer Games went on to sell in the hundreds of thousands across North America and Europe, thoroughly overshadowing the less impressive Olympian efforts of HESWare and Atari, the latter of whose games were at any rate only available on their own faltering lines of game consoles and home computers. It would be ported to a variety of platforms, although it would always remain at its best on the Commodore 64. Together with Impossible Mission and a racing game developed by the indefatigable Landrum and Caswell called Pitstop II, both also huge worldwide smashes, Summer Games completed the remaking of Epyx’s image and made of them a worldwide commercial powerhouse. Being for the most part conceptually simple games without much dependence on text, most of Epyx’s games were ideally suited to do well in non-English-speaking countries. Combined with Katz’s aggressive distributional push, this was key to making Epyx one of the first big entertainment-software publishers that could be said to be truly international. With so many potential customers to serve in emerging new markets and several new hits in addition to the still popular Jumpman, sales in 1984 soared as Epyx enjoyed almost exponential growth in earnings as the months passed.

We’ll continue the story of Epyx later, but for now I’m not quite done with Summer Games. Next time I’d like to do something I haven’t done in a while: dig into the technology a bit and explain how some of the magic that wowed so many back in 1984 actually works. It will also give us a chance to get to know the Commodore 64, a computer whose importance to gaming during the middle years of the 1980s can hardly be overstated, just a little bit better.

(The bulk of this article is drawn from two lengthy retrospectives published in the July 1988 and August 1989 issues of Commodore Magazine. The pictures of Randy Glover comes from the April 1984 K-Power.)

27 Comments

Posted by Jimmy Maher on August 4, 2013 in Digital Antiquaria, Interactive Fiction

Tags: c64, epyx, games series

Support this Blog
If you value this blog, please think about supporting it by becoming a Patreon patron or via a one-time PayPal donation. Thanks!
```
 
```
Digital vs. Analog
Visit this site’s companion site, The Analog Antiquarian, for chronicles of worldly wonders.
Ebook Library
Here you’ll find collected in ebook format for offline reading most of the articles already published on this site.
Hall of Fame
A chronological list of the games and other interactive curiosities that I’ve found most fun and interesting over the years.
Table of Contents
Read this blog in chronological order, like a book.
Social Media
Receive announcements of new articles by following DigiAntiquarian on Bluesky or on Mastodon.
My Books
My Projects
Search
Search
Calendar
August 2013

M T W T F S S

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30 31

« Jul Sep »
Email
maher AT filfre DOT net

The Digital Antiquarian

Monthly Archives: August 2013

Sorcerer

Seven Cities of Gold

Footnotes[+]

How Things Work: Commodore 64 and Summer Games Edition

From Automated Simulations to Epyx

Support this Blog

Digital vs. Analog

Ebook Library

Hall of Fame

Table of Contents

Social Media

My Books

My Projects

Search

Calendar

Email