My first game for Atari ultimately became what is now known as Yars’ Revenge – and the story of how it started is a good way of illustrating some fundamental design principles.
Originally, Yars’ Revenge was assigned as a coin-op conversion of a Cinematronics arcade game called Star Castle – a 1980 shooter that involved shooting an enemy cannon protected by three rotating, circular shields. With its sharp vector graphics and fast-moving enemies, however, Star Castle wasn’t exactly the ideal fit for the Atari 2600’s chunky sprites and meagre CPU. Clearly, a simple port of the arcade game wouldn’t be possible, so I had to think carefully about how I could adapt some of its core mechanics.
“The key to design is knowing what you’re trying to do”
With Star Castle, my design goals were:
1. To make a splash: I want my debut to be a contribution, establishing my reputation as a game maker.
2. To create a sensory experience: I want it to be distinctive – an eye- and ear-catching extravaganza that cannot be ignored.
3. To break new ground: I don’t want to iterate on existing material, I want to create something fresh and innovative.
Was I asking a lot? Sure, but why aim low? This is what I’ll strive for and the results will fall where they may. Now, let’s look at Star Castle as a candidate and see how it fares with these three goals.
1. Splash? Star Castle is a decent game with some interesting mechanics. Vector graphics are easy on powerful coin-op hardware, but miserable to recreate on the 2600. I could see the particulars of this game would be a nightmare. It was clear to me from the outset: this game would suck on the 2600. Would it be a contribution? More likely a charity case.
2. Sensory experience? Star Castle’s on-screen motion is interesting, but the focal point is always the centre of the screen. Black and white vector graphics are not known for stunning visuals. In fact, all the colour in the game comes from a plastic overlay. Not the eye candy I’m looking for. The sounds feel a bit limited and somewhat monotonic. Star Castle is kinetic but not dynamic. I want to do better.
3. New ground? Let’s face it, when you’re doing a knock-off, innovation is not the thrust of the work. It didn’t take me long to realise that coin-op conversions are the opposite of what I wanted to do.
My primary implementation goal was to create an action game I would enjoy playing, and Star Castle wasn’t going to do it. Therefore, my first task was changing my assignment, creating room for me to do something different. As a veteran of a few days, I went to my manager Dennis and told him straight up that this game would suck on the 2600.
However, I felt I could take some of the basic mechanics and tweak them into something that would play much better on our console. Fortunately, Dennis was receptive to the idea and said, “Go for it!” (this would never have happened two years later in the Age of Marketing, but that’s another column entirely).
So, if not a direct translation, what would I do? Well, as we covered in my last column, talent borrows, genius steals. Where does Star Castle shine? The basic mechanic of having to break through obstacles to expose the target is nice, and the fact the target fires back with a major weapon is also good. Constant danger creating the need for constant motion is an essential action game criterion in my eyes.
On the other hand, line drawing is nightmarish on the 2600, and the central visual focus gets tiring. How shall I change it? I’ll push the target to one side of the screen to create room for play, and change the shield from lines to bricks which are easier to display.
I’ll add a high-power player weapon and put it on the opposite side for visual balance. And maybe put something shiny in the middle. It was amusing to me that Star Castle was made by Cinematronics because I approached this development like movie-making. Being a huge movie buff, my design thinking for games is cinematic. I think of screen composition and how game action drives eye movement.
If I can keep your attention continually moving up, down, right, left, this will increase the intensity of the experience. With the drone forcing the player into vertical motion, and the player’s weapon moving left-to-right and the target’s weapon moving right-to-left, a compelling dynamic could be achieved. Next, I’ll animate both graphics and colour, resulting in a sensually intense visual ballet! At least, that’s the hope.
I also use movie economics. Sound is cheaper than visuals, especially when the sound effects are cheap. I don’t want the sounds to be just about action, I want sound to dictate mood. Most games use sound simply as feedback for action, but I want to create a soundscape that incites mood and increases tension. I’ll start with a background theme (fifties sci-fi lab electrodes and a faint buzzing), then build a layered hierarchical sound schema on top of that to accent game events and to foreshadow danger. You have only two sound channels on the 2600; I want to keep them both busy all the time.
I wasn’t sure exactly what my game was going to be, but it wasn’t going to be Star Castle. I knew I’d have to figure out a title and setting at some point, but there was plenty of time for that. One thing was absolutely clear to me from the beginning: I needed this game to be great!
This was the mindset from which I began, and it was to evolve substantially. Next time, I’ll share with you how this unfolded, as my plans and reality collided in the development system.