To catch up on the story to date, you can view the archive here.
On reflection, I remember why I put RÅdïp aside. It’s because in the summer of 1994, I went professional.
My relationship with RSD goes back almost to the moment I received Game-Maker in fall of 1992. I soon finished my first game, and as solicited by a box insert I sent the game in for comment. After some awkwardness I struck up a rapport with the people behind Game-Maker and began a long correspondence. They would send me new builds and games from other users (some of which seem to now be the only surviving copies); I would offer bug reports and show them what I was up to.
Right off they ladled me with positive feedback and ignored any teenaged social awkwardness — something to which I was unaccustomed. They liked A-J’s Quest enough to release an early version with a slideshow demo of Game-Maker.
In the summer of 1994 RSD phoned me about a major revision to the software. Although there was still room for improvement, the update addressed many bugs and concerns and added enough features that a user’s games could feel almost self-contained. What’s more, the new Game-Maker would be on CD-ROM.
You may remember that before AOL watered down the concept, CDs were precious. To get a CD pressed was like getting a book published. CD-ROMs were new enough that every demo disc or shareware anthology felt important. Encyclopedias, medical guides, NASA photo archives — they all were tangible things, worth collecting. When someone said they were putting out a CD-ROM, it still meant something.
So that was nice; a big upgrade to my tools, published on CD-ROM. I offered my usual services, and RSD said they had a little more in mind. In 1994, 650 megs was enormous. To justify the disc, they needed to fill the space — so to drive up the value of the package, they wanted content. They wanted library sounds, images, tiles, sprites — and they wanted games. They meant to fill a shareware directory with user-designed games, but they also wanted their own sample material.
At first I didn’t quite understand what they were asking. I tensed up, and racked my brain for games that I could spare. I figured I wasn’t too attached to Cireneg’s Rings or Linear Volume, so I offered those. There was a pause. “Okay,” they said, “but we were hoping you could give us something… good.”
Slowly the lightbulb flickered to life. Oh; they wanted me to draft some original games. That was no problem. I could do that. We agreed on a deal for non-exclusive rights, and I got busy. Over the course of a month I designed six games, plus assorted content. For that, plus the use of Cireneg’s Rings and Linear Volume, they paid me a modest but fair fee — the first money that I ever earned.
Although any intelligent theory was still years away, this summer job was sort of a watershed for me as a designer. Whereas before I was simply puttering, this commission gave me the excuse to get serious. I made plans, I set goals, and I produced content on a schedule.
Nearly all the content that I designed, I designed for a reason. My first priority was to demonstrate Game-Maker’s abilities in the best possible light. To do that, I tried to fill in the cracks of the existing demo catalog. Each game would display a different genre or technique, both to show the software’s flexibility and to illustrate some design concepts for the user — both basic and advanced. This decision often meant challenging myself to try things that I had never considered, and would not otherwise have been motivated to explore.
For instance, my first submission was an experiment called Glubada Pond. Charitably you could call it a cross between Bubble Bobble and Ecco the Dolphin. At least, I think those were my points of reference. When I reverse engineer my thought process, I think the game developed from my problems with Pac.
Part of the idea of Pac was that I wanted to try something else besides the Miyamoto-fueled location-based sense of progression. Since Donkey Kong, and especially Super Mario Bros., the whole concept of videogame progression has been a matter of “I am here; I need to get there.” When you get there, the journey is over. When the journey is over, the story is over. When the story is over, you win. I’ve written about this before.
Although Miyamoto is deeply informed and influenced by Toru Iwatani’s work in Pac-Man, and indeed Pac-Man introduces a large element of exploration-based development — inasmuch as the player needs to explore every inch of the maze to call it done — Pac-Man works off of a simpler sort of win condition. Eat all of the pellets, and you move on. This is an evolution of earlier board-clearing conditions, dating back to Breakout but really entrenched, particularly in the Japanese industry, with Space Invaders.
I hadn’t thought all of this through; I just knew that with Pac I wanted to try something different and maybe more essential than I had been doing to that point. The results left me unsatisfied. The only way for success to hinge on clearing the scene rather than reaching a specific location was to block off the location with a door that would unlock if the player brought to it every item in the level. The problem here, aside from inelegance, is that there is no built-in way to reset the player’s counters upon death — and at the same time there is no way to retain the level’s status after the player’s death. So if the player dies, the character retains all of the benefits of having collected the items, yet the items are back in the environment to collect again. You can see the problem here.
Glubada Pond is, then, a second shot at the idea. Instead of Pac-Man, the progression is based on Bubble Bobble (which is itself closely based on Mario Bros., which in some ways is a throwback on Miyamoto’s part to the design of Pac-Man). More immediately I’m guessing I was inspired by Data East’s Tumblepop — one of my arcade staples at the time. Again I’m sure I didn’t think about it too deeply, but you can trace most hop-n-bop games back to Bubble Bobble and Bubble Bobble is the more iconic game to riff on. So that was probably my mind’s trajectory at the time.
You swim around and spit tiny bubbles at monsters; the monsters become trapped inside. Pop those bubbles, and they will leave super-dense bubbles. Collect enough of those, and you can open a treasure chest somewhere in the level. Collect the coins from that, and you can insert them in the coin-operated exit door. I’m sure I didn’t reason this sequence out ahead of time.
The player has the same problem/benefit as in Pac, in that it is easy to die and allow any collected bubbles to roll over. In this case I let it go. Although there is a complex system for restoring hit points, inspired by the bottled fairy business in Link to the Past, there are no extra lives — so if the player dies, any buffer bubbles serve as a consolation prize rather like the carry-over Options in Life Force or Gradius V. You may be dead, but at least you’re ahead. Speaking of which…
As I have mused, Game-Maker wasn’t made for shooters; the best attempts that I have seen only sort of work. My only previous attempt had been a clear failure, so at least I was devoid of false confidence. As it turns out, this may be the best starting point.
Whereas Nejillian Flux was basically a tribute to Konami’s Gradius, for Zark I looked to the Gradius spin-off and NES sequel Life Force. That, and Taito’s Darius II — or as I knew it from its Sega Genesis port, Sagaia. Maybe a bit of Natsume’s Abadox.
Zark came out better than its predecessor, largely because I broke down everything that I felt went wrong the first time. With Nejillian Flux I had no idea what I was getting into, so I dove head-on into design using the same techniques that I had for action-adventure games and platformers. When the engine failed to accommodate my whims, I butted heads with it until I lost and was forced to compromise — poorly. By comparison I planned Zark with full mind of Game-Maker’s limitations. This may be the first time that I employed such foresight, and I might not have had Nejillian Flux come out well.
One big change is with the weapon sequencing. In Nejillian Flux, the player could collect various power-ups that would give the ship new and varied abilities. Ostensibly stronger abilities replaced lower ones until the player was out of repetitions, at which point the weapon would default down a notch to the next most powerful weapon. This was fine, except that the weapons had no obvious sequence; as in Gradius each of the abilities served a different purpose. If the player picked up a flame weapon, yet the ship’s existing bubble weapon was arbitrarily ranked higher, then the player would only see the benefit of the flame weapon if the bubble weapon happened to run out of ammo.
It’s not a big deal, and it was the best that I could do with the checklist I had and the engine I was given, but this arrangement feels sloppy and unresponsive. From the player’s perspective, who is to say which weapon is objectively better — and why can’t the player just use the new weapon immediately? A lack of an immediate response also can make it unclear what exactly the power-ups do. By the time the player’s weapon defaults enough to make the new weapon viable, assuming that even happens, the player may not at all connect the ship’s weird new behavior to that power-up from a level or two before.
So let’s stop with the a priori and see what we can make of the materials at hand. If the only way to change or upgrade a character’s attack while retaining the same attack button is to design an attack hierarchy, then instead of tossing in any old weapon idea that I like, let’s make a proper hierarchy. For a rough model, I looked to Sagaia.
In place of the salad bar power-ups from Gradius, where the player collects arbitrary energy orbs to move a cursor from box to box and then selects a power when the correct box is highlighted, the Darius series has a linear upgrade path. Get a few red capsules, and your single shot turns to a double. Eventually you’re shooting simple beams and projectiles in all directions. There is never a real choice of weapon; there is simply a more powerful and elaborate firing state. Usually you attain it gradually; sometimes you can leap ahead a few notches.
Thus for Zark I designed a tiered weapon system. At its most powerful, the player’s ship fires in all directions at once. Each notch along the way is associated with a number; each number has its own associated item. Get a #2, and your weapon upgrades to level 2. Get a #4, and you leap up to level 4. Then pick up a #3, and — well, nothing happens. Why not? Because 4 is greater than 3, and you’re already at 4. It’s not a perfect solution; it’s not a bad one.
An even bigger area of improvement is the level design. There are at least three interesting developments here: the use of space, the use of tiles, and the use of colors. Of those, the most immediate and dramatic is the use of space.
To get around the issue of fixed and looping map dimensions, the levels branch off diagonally. Occasionally this means different routes to the same destination. When the levels remain linear, this creates substantially more space for scrolling — rather like that Mr. Wizard segment where the child cuts a hole in a sheet of typewriter paper, large enough to step through. So long as the ship keeps moving to the right, all the player need do is rock the ship up or down to account for the angled field.
While designing the organic-themed second level, which involves flying through the interior of an unknown monster, I hit on the notion of seamless barriers. By this I mean, rather than building an uneven tunnel out of discrete background tiles, to design an unbroken “skin” using at least twelve tiles (four flat surfaces, four diagonal surfaces, four “plugs” for where unlike surfaces join). Beyond the lit surface of the skin is darkness. Combined, the tiles can wrap around to trace any shape. For any special situation, special tiles can arise.
The effect of this design is a sense of elegance and polish. The screen is rid of visual clutter, and focused on the actual path ahead. The levels also feel more coherent; both deliberate and naturalistic. That sounds like a contradiction, but the sense is that things are where they need to be, and that anything unnecessary is absent or invisible. Compare the flood-lit grid of Super Mario Bros. to the shadows and highlights of Sunsoft’s Batman, and you see what I mean.
Even though Super Mario Bros. is the clearest possible example of elegant level design, its elements feel arbitrary. You have a collection of a half a dozen tiles, any of which might be moved a space or two in any direction. It’s almost like shuffling a deck of cards. You could design a card game around building Super Mario Bros. levels. It would only take a half an hour to nail down the rules.
The NES version of Batman feels largely of a piece. It seems to have its own geography; in place of distinct arrays are indivisible setpieces composed of big hunks of urban matter. It’s almost like a prototype for the arcade and Genesis versions of Capcom’s Strider.
All of the presentation in the world won’t make up for lousy level design, but atmosphere has as much of an effect on the player’s experience as the logic at hand. It’s all about focusing the mind where you want it to be and limiting opportunities for it to stray where you don’t. Usually that is a matter of verisimilitude, which is largely a matter of context: what behaviors make sense within the situation presented. If any individual tile may hold its own secrets, as in Zelda or Metroid, then that mystery and potential play into the moment-to-moment atmosphere and logic of the game. If the only thing that can matter is the route at hand, then it is visual overkill to do more than trace the outline of a boundary.
Something that I did learn and apply from Zelda, Metroid, and Mario is the effect of a simple change of color. In the 1980s and early ’90s, designers would regularly swap the palette to wring extra use from both enemy sprites and background tiles. The blue Octorok takes twice as long to kill as the red, and moves twice as fast. The brown, dried-out forest is more dangerous than the fresh, green one. You get to cram twice the variety into a game at a minimal cost of space, and give the sense of distinction or variety within an individual class of monster or terrain.
You know intuitively that different colors evoke and are associated with different moods. “Warm” colors — red, orange, yellow — make an image feel hotter, cozier, and more vibrant. “cool” colors — blue, indigo, violet — tend to evoke detachment, chilliness, isolation, and stillness. Green is a weird one, as it is technically a cool color but its implication can vary from calm and safety to disease and wrongness.
A curious case study here comes when you skin the same geometry with a different color set. A blue Octorok feels colder and more distant than a red one, therefore more threatening. Coming out of a maze of dead blue rocks, a golden tunnel feels almost magical; now the walls are bursting with light and life, and something important is bound to happen at any moment. You have broken on through to the other side, if you will.
These are the same tiles, the same rocks and joins and gargoyle faces. The only difference is the color, yet they have a totally different psychological affect, particularly in contrast with other color schemes. Although the primary reason for the palette swap is to save precious cartridge space, the consequence of seeing the same shapes in a new light is a sense of deeper understanding to their properties or to the change in narrative context that goes along with the swap in palette.
There is therefore value in designing an ambiguously variable palette: red can be cleanly swapped with green or whatever other color to change the game’s nuance from area to area, without need to create a whole new tile set. There is an elegance in minimalism, that is worth exploring before you start to add on extra junk.
So, level three is a palette swap of level two. In other news it is, I believe, here that I began to experiment with larger monsters. The thing is, Game-Maker’s engine and tools only allow monsters of exactly 20×20 pixels — and their behaviors are very simple. To make larger monsters means splitting the monsters across several 20×20 monsters that behave exactly in sync. If the player should kill one of the monsters, or perhaps a particular monster that is more susceptible, it then needs to emit some kind of “mop up” monster that can scoot around and kill all of the other monster parts.
My success here was limited. I littered the levels with large, moving background elements — and they were fine. They were also invincible, and fairly simple. At this point I had no idea how to approach bosses under these limitations, so they just amounted to large, static blobs of monster parts. Kill one, and an aimless explosion will swirl around to engulf the other monsters — occasionally missing a piece or even birthing an all-new cockpit or nose cone, due to a bug in the monster engine.
As I designed and submitted this material, the underlying software was in transition. Whereas I built the first games in an earlier stable version of Game-Maker, I built the final ones on increasingly stable versions of the new engine. Often RSD would go back and patch my earlier games, to bring them up to the level of the later ones. Some of those adjustments, like a couple of cutscenes added to Crullo: Adventures of a Donut, I only noticed fifteen years later.
Crullo is a curious one. It is here, I believe, that I began to go overboard with Deluxe Paint‘s gradient fills. I had developed a technique for drawing all of my sprites and background tiles in Dan Silva’s program, and had found the process both much faster and much easier than fiddling with RSD’s (generally well-made) Block Designer.
Deluxe Paint remains one of the best tools for editing low-res pixel art, and the most useful of its successors are basically enhanced ports or tributes for Windows. Its most heralded feature, rightly so, is its Brush feature — which basically allows the user to scoop up parts of an image, turn them into rubber stamps, and save them for later. When you add in the manipulation tools for those brushes, the ramifications of this feature are endless.
Less famous yet just as important is Deluxe Paint’s palette system, which is heavily slanted toward gradients. Establish colors A and B, twenty spots apart on the palette, then click a button to generate a smooth transition of twenty colors between them. You can then define and save this range as a gradient, and use it as you would a normal color, to paint, fill, spray, and whatever else. If you choose to fill, there are several powerful options as to how to distribute the gradient within the fill area.
If you know little about highlights and shadows and you’re a little bit lazy, it is easy to form a dependency on these fills. They look pretty good, and they only take a few clicks. They are also very distinctive; you can find their artifacts in nearly every VGA game, retail or Shareware, produced between 1989 and 1995.
Crullo was where I decided to use these fills for every visual element. I figured that to do so would make my games look professional — and it was so simple. Granted, the results were very consistent; it was clear that all of the elements had a common origin. In retrospect, they also look rather sloppy and generic — and at times so consistent that it can be hard to tell elements apart, for all the dithering.
As was my pattern, Crullo was derived from its character, a powdered doughnut with a jelly filling. Previously I had based a few games on inanimate objects. This particular doughnut began as a full-sized Deluxe Paint illustration that I shrank down and turned into a brush, and then later incorporated into an earlier game as a monster. It was a given that the game would incorporate monsters, and so it was a given that Crullo would need a way to attack the monsters. Thus, the addition of a jelly filling that Crullo could squirt out as a squid might squirt his ink.
As an aside, I was really confusing the doughnut situation. By no means was Crullo an actual cruller; more of a Hostess cake ring. Neither are these cake rings typically filled with jelly; jelly doughnuts tend to be a puff pastry with no center hole.
Anyway, because the protagonist was a doughnut I chose other baked goods for the antagonists — croissants, bagels, English muffins, water biscuits. As it was also a given that the game would contain item pick-ups, I filled the levels with Sonic-style rings of various colors; rings, because of the doughnut theme.
I dove right into videogame cliche by giving Crullo a missing girlfriend to rescue, and by sending him through a series of castles themed after the elements. I never really reflected the levels’ themes in their design; the only difference between a water level and a wood level is the appearance of the background tiles.
I also had not yet clicked on the idea of designing a tight control scheme for the character and then building levels around the character’s abilities. As with my earliest games, I figured that it was enough if it was technically possible to progress. The harder it was, the more I felt that I was getting something over on the player. Why I felt this was a good thing, and what I thought I was proving, I’m unsure.
While I was busy going pre-Photoshop crazy with the visuals, I also decided that the sound could use an impersonal touch. Whereas my earlier games had involved laboriously recorded and manipulated sound and voice effects, edited in a line of programs ending in Cool Edit Pro (the predecessor to Adobe Audition), I felt that it would be more professional to record sounds from a Radio Shack keyboard. RSD had asked for more musical effects, and clearly a game about a doughnut was the place for Casiotone.
The result is a disconcertingly cold soundscape, that feels incongruous with the game’s concept and the rest of the presentation. Between the lifeless, echoey sounds punctuating every action and the impersonal, mass produced levels that don’t even particularly acknowledge the character or its properties, Crullo feels a little eerie. Distant.
Despite this, the game seems popular in some circles. I keep getting hits from message boards in South America, and at least one fellow seems to use it as a test game for new ports of DOSBox. Again also, RSD saw fit to keep fiddling with the game and to include it with a demo of their software. I guess there must be something to it.
Before Crullo, I had already attempted ten other platformers. You would think with that experience I would have been on a roll. Instead, I think I just fell into a pattern too early. Even if my techniques were flawed, and I was coming at design from the wrong angle entirely, I thought I knew what I was doing and so I was designing on cruise control. Every shortcut that I could find to streamline the process, I would exploit as far as I felt like bothering. Spending too much time on a single project meant a delay until I could focus on something else, so there was always a rush to just finish things. The time for learning was over. With Crullo, the rush was all the more urgent. Here, for the first time, I had money to worry about. Money, and a schedule.
After three fairly ambitious, if short, games my energy was at an ebb — yet I had to keep going. For my next trick I would further explore the idea of palette swapping. The Patchwork Heart consists of four levels, three maps, three color schemes, and a big jumble of design concepts.
Really the idea was to see how much variety I could milk out of a minimum of minimally designed elements. The character is a simple golden sphere, shaded with Deluxe Paint’s gradient fill. Aside from the death sequence, I think there may be three frames of animation. All four levels use the same pool of background tiles. The monsters are all borrowed from Zark (so in turn I decided that Heart was an indirect sequel to or spin-off of the earlier game). The backgrounds are repetitive as hell, though they do employ some of the unbroken-line design of Zark.
Within these tight boundaries, I kind of went crazy. I am still unsure how I arrived at some of the design decisions. Although the character has barely any animation, when it moves it emits trailing monsters in the form of motion waves. These waves are as powerful as the character’s main beam attack, allowing some close proximity defense as well as some visual interest. Defeated enemies crumble into pools of blood; in a nod to Wolfenstein 3D, the player can then drink the blood to gain or recover life. Oh, and in case the player gets stuck there is a suicide key.
With a mind to both Theseus and the philosopher’s stone (perhaps as combined by Carl Barks), whenever the character touches a hard surface, the surface turns to gold. Initially this property merely seems curious; the player may be tempted to touch as many surfaces as possible, to make a mark on the world. In stage three, the power becomes more important.
The first two levels, and the fourth, are all traditional platformers. The first two are actually the exact same level, repeated with one weird and minor difference. At the end of the first level, the player is granted a super jump ability. The game makes no effort to signal this event. Halfway through the second level, the player has one opportunity to use the power. Miss it, or mess up, and the player is stuck forever. Succeed and continue on to the third level, which uses the same background elements to present a top-down maze. The character can move freely in all four directions.
Here’s where Theseus comes into play; given the Midas touch, the player can and most likely will mark every path along the way — thus turning the typical frustration of a maze level into a sort of a cathartic cleansing operation. There is no losing your way when you know everywhere that you’ve been.
Despite the minimal effort involved, I got very positive feedback to The Patchwork Heart — and I don’t just mean all of the weird Russian websites that pounced on the game. When I spoke to RSD on the phone, the CEO told me he liked the game more than Peach. At the time I had trouble believing that. Perhaps I should have listened, and taken a hard look at what I did right.
Peach the Lobster is a total opposite to the minimalism in Heart. This was my most ambitious game to date, and I was so proud of it. If The Patchwork Heart was one of those papers that you write at 2:00 AM on the due date, that mysteriously earns you a commendation from the professor, Peach is one of those masterpieces that you labor over for weeks and that lands with a relative thud.
To my thinking, RSD needed a mascot. It was 1994; what game company didn’t anthropomorphize its brand? RSD did okay with Penguin Pete and Smiling Savage Pete Pipeman, but I felt the need for something more dynamic — more like Sonic the Hedgehog. That, I decided, would be my penultimate game: the one to put RSD on the map.
This was going to be a serious, professional project; the centerpiece of my work for the CD-ROM. That meant employing Deluxe Paint to an extent that I never had before. Rather than hand-animating the character and monsters, I took a leaf from Wolf Team’s Earnest Evans and individually drew each limb and body section. Or, rather, I drew the outlines of body parts and then used the gradient fill tool to shade them. I then used Deluxe Paint’s brush rotation tools to assemble the parts into frames, and imported them into Game-Maker as sprite sets.
As pastiche goes, Peach was as literal as I could make it. I put the character in a track suit, because Sonic is all about running. All of the items are stored in computer monitors. The first world is similar to the Green Hill and Emerald Hill Zones; the second resembles the Labyrinth and Aquatic Ruin zones. The level intro slates are based on Sonic‘s Zone introductions. There are a few hints of Castle of Illusion and Altered Beast, but basically Peach is a Sonic clone that makes Jazz Jackrabbit look bold and original.
The game is focused through a blend of myopia and tunnel vision. I tried for visual consistency by overusing Deluxe Paint’s tools, but I failed to design the levels around the character’s animations — so often the player needs to glitch the game to proceed, or cannot possibly foresee an upcoming hazard.
I tried for clean animation by scientifically breaking down the sprites into segments, but I failed to think through what I was animating. All of the monsters are 20 pixels high or shorter, and Peach fires his weapon around 20 pixels from the ground — meaning that the player can rarely hit anything.
As in Zark there are a few multi-block monsters, but they are static and completely devoid of animation or meaningful player or level interaction. Their main virtue is that they happen to be large.
I did plan ahead to ensure that most of the enemies are ducks of some sort — but why ducks? The protagonist is a lobster. Why a lobster, for that matter? (And where are the rest of his legs?) What exactly was I doing, and why?
For all the time that I spent on wiring it together, Peach is a remarkably disjointed game. I was so focused on copying someone else’s game that I failed to mind whether that mission made sense with the tools at hand, and I paid even less mind to the shape and cohesion of the game that was actually developing as a result of my efforts. Peach is an inept copy because Game-Maker wasn’t made for a game like that; it is an incoherent game because I paid less attention to what I was doing than to what I wanted to achieve.
This wouldn’t be the last time I trusted technique and technology over my own artistic judgment; it is one of the more overwrought and under-thought examples. Regardless, it seemed to gain some traction in the MS-DOS canon. Peach is one of just a few Game-Maker games listed on Mobygames. So far as I know, it’s the only Game-Maker game used for official testing of DOSBox. In other circles, Peach is sort of an ironic meme.
The game must also have struck home with its publishers, as RSD soon refitted Peach with a new intro area and some slideshows, then distributed it as a playable demo for Game-Maker 3.0 — much as with A-J’s Quest, years earlier. This time, though the game itself became the demo.
I was unaware of these machinations. I just knew that the window was closing quickly, and that I wanted to finish up one more game before my deadline. A clean half-dozen; I felt that was respectable. I believe I asked them to wait for it; I had a simple idea, and I knew that I could finish it in a few days.
Clyde & Zeke is a game about two ducks. It consists of one map, a small tile set, a simple character, one enemy creature, two power-ups, and a gimmick creature — that being the second duck.
One of Game-Maker’s more confusing and least exploited features is its monster attack animations. Even the name is confusing. In this case a monster is any non-player sprite: a weapon, an NPC, a moving platform, or an actual adversary. Normally monsters can move at a set speed toward the character, away from the character, randomly, or along a set path. If the user defines a path, then along each leg of the path the monster can move at a different speed. Simple so far.
Each monster can also have a secondary behavior, that triggers in proximity to the character sprite; those behaviors can be relative to or independent of the sprite. When used well, this second move can greatly flesh out a monster’s behavior. It can make monsters responsive to the player’s actions, or ensure that beneficial monsters remain by the character’s side — almost like an extension to the character.
The problem is that this secondary movement is so hazy to define and hard to exploit. It is never clear how close the character must be to trigger the behavior, it is a matter of trial and error to establish the behavior in relation to a character, and it is not guaranteed that the behavior will always work as intended.
I lucked out with A-J’s Quest; my first game out, I gave the character a sidekick monster — and it worked pretty well. After that, I shied from the attack movements. They were frustrating, and I was intimidated. For my last demo game, then, I chose to demystify the feature. This game would be all about the monster attack movements — how to employ them in a game, and how to turn them into a deliberate game mechanic for the player’s benefit.
The player’s only attack or defense against the encroaching paper boats is his far more aggressive companion duck, Zeke. In theory the player should be able to circle and whip around to snap Zeke at the boats and destroy them. If the player isn’t careful, then Zeke may also eat the fish and bread slices before the player can get to them.
None of that really works. All that happens is that Zeke slowly follows Clyde, and then rapidly spins around on the spot. The player can defeat the boats by staying very still and allowing them to approach from the side. Most of the time, Zeke will destroy them before they can touch the player. Whether the mechanism that I imagined is feasible within Game-Maker, I don’t know. I just know that I couldn’t do it at the time, in the time that I had.
Regardless, I sent the game off. I understand that they received it; for whatever reason, it never made it into the CD. I think they paid me for it, though. Thus my first contract job ended on an awkward note. What else is new!
Some months later, the CD-ROM had yet to arrive. I knew the concept of lead time, but this was my first published work. Four months is an eternity. I began to obsess.
One night I dreamed, rather prosaically, that the package had arrived. I opened the package, and marveled at the CD inside. It had a cyan logo, in a curvy sans serif typeface, warped around the upper semicircle of the disc.
I woke from the dream and wandered downstairs to the front porch. There was a package for me. I opened it, and it was the new version of Game-Maker. The disc was exactly as in my dream, down to the new typeface, except that the lettering was orange instead of cyan.
I have a poor memory for color. If I actively know something, I’ll remember it; for passing memories, I tend to remember colors as their exact opposites across a color wheel. I remember red banners as green, blue signs as yellow, and of course orange as cyan. So, that’s sort of interesting.
That was almost the last that I heard from RSD. There were a few phone calls and letters, but the lead programmer and CEO was busy with school and other projects; within a year they abandoned support for Game-Maker altogether. I still played with their engine, though — first in hope of various feature upgrades, then absently, without ambition.
For all my bad habits and lack of insight, I was a different designer after this commission. Being forced to apply myself creatively at once drained me and encouraged me to think more efficiently about design. This was also probably the first time that I thought about creating for someone else, rather than just my own benefit. I had to keep in mind both the publisher’s needs, stated or otherwise, and the needs of the end user who would be dissecting my games for their own education.
The commitment also ensured that I saw each project to its conclusion. They may not all have been perfect, but I finished six games in a fairly short time — and some of them were as ambitious as I had ever tackled. Without that responsibility, the games would have lingered. Maybe a couple of them would have wound up better for the added time. I’m sure that Peach would never have gotten beyond the first level, if that far.
Most of all, this commission gave me confidence. This was the first time that anyone paid me for a service, and it was for my creative work. More than that, I had a published volume that I could wave around. To an extent I felt that all of my years of screwing around with my NES and Genesis were justified. All of the people who had mocked my comic strips and shrugged at my early games were irrelevant; this work had brought me somewhere.
I was high on my heels. I felt I could do anything. I knew the software inside and out. I felt appreciated, and a part of something important. This was the perfect time for me to show off.
Next: the return of the insertion games.
