RSS

Tag Archives: games series

The Evolution of the (Epyx) Games

The American home-computer industry entered 1987 feeling more optimistic than it had in several years. With the bloodletting of 1985 now firmly in the past, there was a sense amongst the survivors that they had proved themselves the fittest and smartest. If the ebullient a-computer-for-every-home predictions of 1983 weren’t likely to be repeated anytime soon, it was also true that the question on everybody’s lips back in 1985, of whether there would even still be a home-computer industry come 1987, felt equally passé. No, the home-computer industry wasn’t going anywhere. It was just too much an established thing now. Perhaps it wasn’t quite as mainstream as television, but it had built a base of loyal customers and a whole infrastructure to serve them. And with so many companies having dropped by the wayside, there was now again the potential to make a pretty good living there. The economic correction to a new middle way was just about complete. The industry, in other words, was beginning to grow up — and thank God for it. Even Atari and Commodore, the two most critical hardware players in the field of low-cost computing, had seemingly gotten their act together after being all but left for dead a couple of years ago; both were beginning to post modest profits again.

The mood of the industry was, as usual, reflected by the trade shows. The second of the two big shows that served as the linchpin of every year on the circuit, the Summer Consumer Electronics Show in Chicago in June, was a particularly exciting place to be, with more and more elaborate displays than had been seen there in a long, long time. Compute! magazine couldn’t help but compare it to “the go-go days of 1983,” but also was quick to note that “introductions are positioned to avoid any repeat of the downturn.” “Excited but wiser” could have served as the slogan of the show. But an even better slogan for entertainment-software publishers in particular might have been, “The more things change, the more they stay the same.”

I’ve been writing quite a lot in recent articles about the new generation of 68000-based machines that were causing so much excitement. Yet the fact is that the Apple Macintosh, Atari ST, and Commodore Amiga were little more than aspirational dreams for the majority of the mostly young people actually buying games. The heart of that market remained the cheaper, tried-and-true 8-bit machines which continued to outsell their flashier younger brothers by factors of five or ten to one. And the most popular 8-bit machine had remained the same since 1983: the Commodore 64. A chart published in the December 1986 Compute! gives a sense of the state of the industry at the time.

U.S. Home Computer Market -- 1986

If anything, this chart undersells the importance of the Commodore 64 and its parent company to the games industry. Plenty of those IBMs and Apples, as well as the “Other” category, made up mostly of PC clones, were being used in home offices and the like, playing games if at all only as an occasional sideline. The vast majority of Commodores 64s, however, were being used primarily or exclusively as games machines. Many a publisher that dutifully ported their titles to each of the six or seven commercially viable platforms found that well over half of their sales were racked up by the Commodore 64 versions alone. No wonder so many made it their first and sometimes only target. Not all were thrilled about this state of affairs; with its antiquated BASIC, chunky 40-column text, and molasses-slow disk drives the Commodore 64 was far from a favorite of many programmers, so much so that a surprising number developed elaborate cross-compiler setups to let them write their 64 programs anywhere else but on an actual 64. Many others who had had personal dealings with Commodore, particularly in the double-crossing bad old days of Jack Tramiel, simply hated the company and by extension its products on principle. Yet you couldn’t hate them too much: fact was that the 64 was the main reason there still was any games industry to speak of in 1987.

Already the best-selling microcomputer in history well before 1987, the Commodore 64 just kept on selling, with sales hitting 7 million that year. Meanwhile sales of the newer Commodore 128 that could also play 64 games cruised past 1 million. This continued success was a tribute to the huge catalog of available games. As Bing Gordon of Electronic Arts put it, “The Commodore 64 is the IBM of home computing; no one thinks you’re dumb if you buy it.” Of course, this aberrational era when a full-fledged computer rather than a games console was the most popular way to play games in the country couldn’t last forever. Anyone sufficiently prescient could already see the writing on the wall by wandering to other areas of that Summer CES show floor, where an upstart console from Japan called the Nintendo Entertainment System was coming on strong, defying the conventional wisdom of just a year or two before that consoles were dead and buried. But for now, for just a little while longer, the Commodore 64 was still king, and Summer CES reflected also that reality with a final great flowering of games. Love it or hate it, programmers knew the 64 more intimately by 1987 than they possibly can the complex systems of today. They knew its every nook and cranny, its every quirk and glitch, and exploited all of them in the course of pushing the little breadbox to places that would have been literally unimaginable when it had made its debut five years before; plenty of games and other software stole ideas from the bigger, newer machines that simply didn’t yet exist to steal in 1982.

Starting today, I want to devote a few articles to chronicling the Commodore 64 at its peak, as represented by the games and companies on display at that 1987 Summer CES. We’ll start with Epyx, whose display was amongst the most elaborate on the show floor, an ersatz beach complete with sand, surfboards, Frisbees, and even a living palm tree. It was all in service of something called California Games, the fifth and newest entry in a series that would go down in history as the most sustainedly popular in the long life of the Commodore 64. If we were to try to name a peak moment for Epyx and their Games series, it would have to be the same as that for the platform with which they were so closely identified: Summer CES, June 1987.

You can get a pretty good sense of the advancement of Commodore 64 graphics and sound during its years as the king of North American gaming just by looking at the Games series. In fact, that’s exactly what we’re going to do today. We’re going to take a little tour of four of the five Games, hitting on just a couple of events from each that will hopefully give us a good overview of just how much Commodore 64 graphics and sound, along with gamer expectations of same, evolved during the years of the platform’s ascendency. These titles were so popular, so identified with the Commodore 64, that they strike me as the perfect choice for the purpose. And they also occupy a soft spot in my heart as games designed to be played with others; they’re really not that much fun played alone, but they can still be ridiculously entertaining today if you can gather one to seven friends in your living room. Any game that encourages you to get together in the real world with real people already has a huge leg up in my critical judgment. I just wish there were more of them.

Let’s start by taking another look at the original 1984 Summer Games, a game I already covered in considerable technical detail in an earlier article. Its graphics — particularly the fluid and realistic movements of the athletes themselves — were quite impressive in their day, but look decidedly minimalist in light of what would come later. Also notable is the complete lack of humor or whimsy or, one might even say, personality. Those qualities, allowed as they to a large extent are by better and richer audiovisuals, would arrive only in later iterations.

 
Few concepts in the history of gaming have lent themselves as well to almost endless iteration as the basic Games concept of a themed collection of sporting minigames. Thus after Summer Games turned into a huge hit more Games were inevitable, even if they wouldn’t be able to piggyback on an Olympics as Summer Games had so adroitly managed despite the lack of an official license. The first thought of Epyx’s programmers was, naturally enough, to follow Summer Games with a similar knock-off version of the Winter Olympics. By this time, however, it was late 1984, and Epyx’s marketing honcho Robert Botch said, probably correctly — he tended to be correct in most things — that a winter-sports game would be a hard sell when they finished it up in six or eight months; at that time, you see, it would be high summer. So they instead turned their attention to Summer Games II, consisting of eight more events, many of which had been proposed for the original collection but rejected for one reason or another. It proved to be if anything a better collection than its predecessor, with more variety and without the cheat of inserting two swimming events that were exactly the same but for their differing lengths. Graphics and sound were also modestly improved.

But the first really dramatic leap forward in those areas came with the next iteration, the long-awaited Winter Olympics-themed Winter Games that followed hot on the heels of Summer Games II. With Epyx’s in-house programmers and artists still busy with the latter, Winter Games was outsourced along with detailed specifications provided by Epyx’s own designers to another developer called Action Graphics. The partnership between the Silicon Valley-based Epyx and the Chicago-based Action Graphics was apparently a somewhat troubled one, with delays caused by poor communication threatening to scupper the planned Christmas 1985 launch. The project’s savior proved to be one Matt Householder, a recently arrived refugee from Atari who would play a huge role in the series going forward. Upon his hiring in July of 1985, his first role became that of Epyx’s official liaison to Action Graphics; he spent many weeks in Chicago pushing the game along to completion. A programmer himself with much experience with videogames, Householder suggested lots of extra little touches, sometimes helped out with technical problems, and, with the deadline ever looming, occasionally advanced the timetable via some artful deletion.

The bobsled was a particularly problem-plagued event. The original conception would have had the riders pushing the sled to get it started, just like in the real thing, but no one could quite figure out how to make it work. Householder made an executive decision to just excise that element entirely in favor of making the rest of the event as good as possible. Note in the video below how the clouds in the sky also move when the bobsled goes through a curve. This late Householder-prompted addition is a classic example of a little touch of the realistic whose presence might not be noticed but whose absence almost certainly would — perhaps not consciously, but only as a feeling that something is somehow “off” with the experience. Note also the music that now plays before this and all of the other Winter Games events to leaven the somewhat sterile feel of the original Summer Games.


The bobsled is actually quite graphically spare in contrast to some of the other events in Winter Games. See for example the biathlon, the most time-consuming single event to appear in any of the Games games and one of the most strategic. The speed of the targeting cursor in the shooting sections — and thus the difficulty of each shot — is determined by your heart rate when you arrive. Success is all about pacing yourself, setting up a manageable rhythm that keeps you moving along reasonably well but that also lets you make your shots. According to Householder, “It was put in there to make something completely different. It breaks up the pace of the other events, which are more tense, action/reaction type of things. You have to learn a different set of skills.” Barely a week before the deadline, Householder, bothered that the shooting just somehow didn’t feel right, suddenly suggested adding a requirement to eject the spent round and cock a new one before firing. They managed to shoehorn it in, and it does go a long way in adding verisimilitude to the experience. It’s not so important to make a game like this realistic per se, but to make the player feel like she’s really there, to capture the spirit of the event, if you will.


The original plan for the graphic depictions of this event was, as with the bobsled, somewhat more ambitious than the final version. The skier was to be shown from different angles on every screen, a scheme that Householder quickly excised in favor of a consistent if less graphically interesting side view. The lush backgrounds were inspired by photos of the actual event taken at the 1984 Winter Olympics in Sarajevo, recreated freehand by artist Steve Johnson. I must say that I love the winter-wonderland atmosphere this event and, indeed, much of Winter Games conjures up. Like the opening and closing ceremonies, the bobsled, and a couple of other events in Winter Games that clearly take inspiration from the Sarajevo Olympics, the biathlon is made bittersweet today by the knowledge of what was in store for so many of those sites and, more importantly, for the people who lived near them.

Having now covered most of the Olympics events that seemed practical to implement on a Commodore 64, there was some debate within Epyx on the best way to consider the series after Winter Games; it had turned into such a cash cow that no one was eager to bring it to a close. Marketing director Robert Botch suggested that Epyx effectively create their own version of the Olympics using interesting non-Olympic sports from all over the world, under the title of World Games. Householder ran with the idea, proposing turning the game into a sort of globe-trotting travelogue that would not only let the player participate in the unique sports of many nations but also get a taste of their cultures.

World Games

You’ll notice in the World Games screenshot above an advertisement for Continental Airlines, perhaps the first of its kind in a game that wasn’t itself blatant ad-ware and yet another example of Botch’s prescience as a marketer. If the times were changing, though, they were still changing slowly: Continental was able to buy this exposure in a game that would end up selling hundreds of thousands of copies by providing Epyx with nothing more than a handful of free tickets to Disney World for use in contests. On the other hand, perhaps Continental paid a fair price when one starts to consider demographic realities; the young people who made up the vast majority of Epyx’s customers generally weren’t much in the market for airline tickets quite yet.

Much as the documentary tone of the travelogue-style descriptions might lead you to believe otherwise, the Epyx design team was made up of a bunch of young American males who weren’t exactly well-traveled themselves, nor much versed in global sporting culture. They chose the majority of the sports in World Games by flipping through books and magazines, looking for things that seemed interesting and implementable. They then designed the events without ever having actually seen them in real life. This led to some bizarre decisions and outright mistakes, like their choice of barrel-jumping (on ice skates!) as the supposed national sport of Germany; absolutely no one in Germany had any idea what they were on about when the game came out. Their original plan to make soccer penalty kicks Germany’s national sport would have hit closer to home, even if a love for soccer is hardly confined to that country. But it proved to be technically infeasible.

With Epyx’s in-house programming team once again too busy with other projects to take it up, World Games was again contracted to outside programmers. This time a company called K-Byte did the honors, albeit under much closer supervision, with the art and music supplied by Epyx’s own people. Freed as they were from the rigid strictures of traditional Olympic disciplines and a certain fuddy-duddy air of solemnity that always accompanies them, the designers, artists, and programmers were able to inject much more creative whimsy, even humor. See for example what happens when you screw up badly in Scotland’s caber toss.


Speaking of screwing up: Epyx’s designers managed to completely miss the point of the caber toss. Athletes participating in the real sport are judged on aesthetics, on how cleanly and straightly they toss the caber. The objective is not, as in World Games, to simply chunk the bloody thing as far as possible.

The music tries its best — if, again, only within the limits of Epyx’s international awareness —  to echo the “national music” of each country represented. The bagpipe sound is quite impressive in its way; listen for the initial “squawk” each time the instrument changes pitch, so like the real thing.

But Mexico’s cliff-diving provides perhaps the best illustration of how far Epyx had come already by the time of World Games. It’s superficially similar to the diving event from Summer Games, as seen in my very first video above, but the difference is night and day. I speak not just of the heightened drama inherit in jumping off a rocky cliffside as opposed to a diving board, although that’s certainly part of it. Look also at the improved graphics, the addition of music, all of the little juicy touches that add personality and interest: the way the diver fidgets nervously as he waits to take the plunge, the way you can send him careening off the rocks in various viscerally painful ways, the seagull at the bottom of the cliff who will turn and fly off if you wait long enough. (Rumor has it that it’s possible to hit the seagull somehow if you botch a dive badly enough, but I’ve never succeeded in doing so.)


California Games, the fifth entry in the series and the culmination of the audiovisual progression we’ve been charting, was done completely in-house at Epyx. Indeed, it was also inspired much closer to home than any of the games that had come before. Walking through Golden Gate Park one weekend, watching bicyclists and skateboarders doing tricks for the crowds, Matt Householder’s wife Candi suggested that Epyx should use those sorts of sports in their next Games game.

But there’s a bit more than that to be said about California Games‘s origins, in terms of both universals and the specific context of the mid-1980s. In the case of the former, there’s the eternal promised land of California itself that’s been a part of the collective mythical landscape of Americans and non-Americans alike almost from the moment that California itself existed as a term of geography: Hollywood, Route 66, Disneyland, the Sunset Strip, the Beach Boys, palm trees, hot rods, surfboards, and of course bikinis and the sun-kissed beach bunnies who fill them out so fetchingly. (Botch wouldn’t be shy about incorporating the latter elements in particular into his marketing campaign.) “Go west, young man!” indeed. California Games combined this eternal California with a burgeoning interest amongst the young in what would come to be called “extreme sports” that saw many a teenager picking up BMX or half-pipe skateboarding. The first proposal that Householder submitted actually skewed much more extreme than the eventual finished product, including wind-surfing, hang-gliding, and parachuting events that were all excised in favor of some more sedate pursuits like Frisbee and Hacky Sack. He also proposed for the collection the almost instantly dating appellation of Rad Games; thankfully, Botch soon settled on the timeless California Games instead.

Which is not to say that California Games itself is exactly “timeless”; this is about as clearly a product of 1987 as it’s possible for a game to be. At that time the endlessly renewable California Dream was particularly hot. Even the name California Games, timeless or no, also managed to evoke the zeitgeist of 1987, when California Coolers and the California Raisins were all the rage. The manual includes a helpful dictionary of now painfully dated surfer and valley-girl slang.

LIKE (lik) prep. Insert anywhere you like, like, in any sentence, in, like, any context. Used most effectively when upset: “it’s, like, geez…” Or the coolest way to use “like” is with “all” (for more description). “It’s, like — I’m all — duuude, you’ve got sand in your jams.”

Replacing the chance to represent a country, Olympics-style, that had persisted through World Games are a bunch of prominent 1987 brands, some of which have survived (Costa Del Mar, Kawasaki, Ocean Pacific, Casio), some of which have apparently not (Auzzie Surfboards and Ray-D-O BMX, my favorite for its sheer stupidity). All paid Epyx to feature their logos in the game, with those willing to invest a bit more getting more prominent placement. Yes, Botch was figuring out this in-game-advertising thing fast. See for instance the logos plastered behind the skateboarding half pipe.


California Games was the first title in the series for which Epyx could draw on a fair amount of direct personal experience. Enthusiasts of the various sports inside the company demonstrated their skills for the cameras, the resulting video used as models for their onscreen versions. Some of the less athletic programmers and designers also had a go by way of getting into the spirit of the thing. Householder notes that “I nearly broke my skull a couple of times” on a skateboard in the Epyx parking lot.

To see how far Commodore 64 games came in less than four years, look at the colorful-in-both-senses-of-the-word surfing video below, with its gags like the shark. (A cute dolphin also shows up from time to time, albeit not so often as the shark and never, alas, when you’re trying to make a video.) Notice how the music, a rock song this time, plays during the action now to elevate the whole experience. The bagpipes and the like may have been impressive, but rock and roll was to be the sound of California Games, with Botch even managing to officially license “Louie Louie” for the title screen. And notice how the little surfer dude is an individual with his own look and, one might even say, personality, in comparison to the faceless (literally!) papier-mâché silhouettes of Summer Games.


California Games became an even bigger international hit than the previous four games in the series, one more symbol of the power of the California Dream. Epyx now had 200 employees, and was possessed of an almost unblemished record of commercial success that made them the envy of the industry, their catalog including not only hit games but also their Fast Load cartridge that many Commodore 64 owners considered indispensable and a very popular “competition-quality” joystick. But California Games would mark the end of an era. The downfall of this company and series that had been able to do no wrong for years would happen with stunning speed.

Nor could the Commodore 64 itself keep going forever. Having reached its peak at last in mid-1987, with programmers beginning to get a sense that it just wasn’t possible to push this little machine, extraordinarily flexible as it had proved to be, much further, the downward slope loomed. We, however, will stay perched here a little longer, to appreciate in future articles some more of the most impressive outpouring of games ever to grace the platform.

(Sources: Family Computing of September 1987; Commodore Magazine of July 1988 and August 1989; Commodore User of February 1986; Compute!’s Gazette of December 1986; Compute! of December 1986 and August 1987; Retro Gamer 46 and 49.

Such was the popularity of the first five of the Games that the property still holds some nostalgia value to this day, seeing periodic re-releases and revivals. The latest of these is from the German publisher Magnussoft, who have versions available for Windows, Macintosh, and Android. I must say, however, that there’s little left of the original feel in such efforts. I prefer to just play them in an emulator on the old Commodore 64. An intrepid fan who calls himself “John64” has packaged all five titles onto a cartridge image who loads and plays almost instantly in an emulator like VICE. I take the liberty of providing the cartridge here as well along with all of the manuals.)

 

Tags: , ,

How Things Work: Commodore 64 and Summer Games Edition

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 place 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.

Commodore 64 startup screen

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.

Summer Games country 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.

Bitmap mode on the Commodore 64

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 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 releases 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 24 to 23 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.)

 
 

Tags: , ,

From Automated Simulations to Epyx

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

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 businessmen 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.

Epyx

Jumpman itself made a good start toward that goal. It was a huge hit, especially once ported to the Commodore 64. One of 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 long 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 testoserone-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 boycotees 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. Blotch:

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

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 was 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.)

 
 

Tags: , ,