     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Pixels Past's SCSIcide
SCSIcide (pronounced 'skuzzy-side') was my first design attempt for the Atari 2600 console. I wanted to create a game that was simple yet addicting, and would incorporate enough features to make the development of the game a challenge and learning process. From concept to completion, the project was essentially a one-person show. The original Atari 2600 game developers were tasked with all aspects of the process, including concept, graphics, sound, design, and implementation; twenty years later, the creation of SCSIcide was no different. How does one decide to create a game for a 20+ year-old console? I became actively involved with the Atari 2600 development community in 1997. My hope was to use SCSIcide, my first programming attempt for the Atari 2600 and my first publicly released game, as a stepping-stone into design for other systems, notably the Game Boy Advance -- which also offers interesting design constraints. By day, I have my own product development and engineering firm and spend most of my time thinking of ideas, creating prototypes, and licensing them to interested parties. By night, I do the same thing (after a few rounds of SCSIcide).
Essentially, SCSIcide is a psychotic, instinctive reflex game and was the first paddle-based homebrew game for the Atari 2600. Like the original Pong, SCSIcide was designed to be easy to understand yet difficult to master. Something that, if this were an arcade game, kids would be lining up and pumping quarters into the cabinet as quickly as they could. The original idea was based on a rotating circular disk, mimicking a real hard drive. However, I knew programming the 2600 was rather difficult due to the limited memory environment and tricky timing requirements (see sidebar), so I settled on an easier horizontally based, single-screen game. The game has slight similarities to Kaboom!, a simple but devilishly fast-paced game that made me nervous every time I played it. I wanted to create a game that would replicate this nervousness. Not only was there the challenge of creating a game that people would play, I also needed to design game packaging and build physical cartridges. From laying out a new circuit board for the old Atari 2600 cartridge cases, to drawing cartridge labels, to printing manuals, to building the cartridges, to testing, it was a successful journey. But, it wasn't without its problems. What Went Right1. Expecting changes in the game plan. As with any engineering or development project, it's important to have an idea of your final goal before you start. With SCSIcide, the game concept essentially stayed the same from its inception (control a hard drive head and read bits of data). After deciding on a single-screen horizontal view, I set to work on developing the core game kernel, drawing of objects to the screen, and game play intelligence. I was prepared for design changes to the game plan as implementation progressed. Because the game plan wasn't completely set in stone, I had an opportunity to implement features I had not originally intended, many of which came up as the result of programming problems and bugs. My design document was a single paragraph: "The player will control the hard drive head (i.e. can move it left or right between tracks using the paddle). The hard drive platter will spin clockwise (starting slowly). One sector in each cluster (column) will be illuminated. The player needs to move the head back and forth and hit the button when the lighted sector is under the head (essentially "reading" the sector). After the player "reads" 8 sectors, the platter will increase in rotation speed (i.e. the next level) and another combination of sectors will be illuminated. Speed will increase for every 8 sectors the player can read. Each sector needs to be read in sequential order (i.e. one column after the next). The player will lose (or the game will be over) if he misses an illuminated sector. Scoring will be based on the number of sectors the player successfully read." I originally envisioned the game to have a memorization component like Milton Bradley's popular "Simon" game, possibly reading the bits in the proper color order and then having to re-write them back to the disk (a la defragmenting). As I started to program the core game, I decided to axe that part in order to keep game play simple. This decision left me with extra RAM and ROM to use for other features of my game. Instead of using the standard decimal scoring system that most games use (I had originally planned on just a 2-digit decimal score), I decided to implement a 6-digit hexadecimal scoring routine to add to the whole "hard drive" theme of SCSIcide. The first "byte" of the score became the level number, and the last 2 "bytes" of the score was the actual score. Towards the end of the game implementation, I had some unused memory space, and decided to create a title screen for a more "complete" gaming experience. 2. Solid development environment.
This might sound like a no-brainer, but having a development environment that has been fully tested and all components are known to work can save you lots of hair-pulling when a bug mysteriously appears in your Atari 2600 game. Each piece of my development system, such as my Windows PC, the Atari 2600 Jr., the television, and the Supercharger (to load a game through the PC sound card directly to the real 2600 hardware) was individually tested. So were all of the software components: the text editor, Atari 2600 emulator, and 6502 cross assembler. After each component was known to be functional, I combined them to form my development suite. Additionally, as the components were brought together to form the environment, they, too, were tested. For example, making sure the Supercharger works with this particular 2600 Jr. by trying to load known-good games and making sure the 2600 Jr. properly displayed graphics on this particular TV. By the time the entire environment was set up, I could be sure that if a bug or problem arose, the components themselves worked fine so I could remove some unknowns from the debugging process. Doing this helped me "Keep It Simple, Stupid" and let me focus on potential areas in the code that could have caused the problem. 3. Play testing. So I had a concept for a game and was on the way to making it a reality, but in order to make it good, I needed people to check it out and throw some opinions and criticism at me. Most game studios can do this in-house, by showing off code or game snippets to fellow developers or maybe beta testing a version of the game during lunch. Since SCSIcide was a one-person project, I needed a way to get some other gamer's perspectives. The entire development process of SCSIcide, from inception to completion, was provided on my website, including source code and compiled binaries of various incarnations of the game. By sharing my beta versions with the world (or at least those people who actually cared), I could receive much-needed comments about the game design, allowing me to tailor components as I went. I was also active on the Stella Development mailing list, which consists of a number of stellar Atari 2600 homebrew game designers and gamers eager to provide their expertise (see sidebar). Some brilliant suggestions came from my play-testing colleagues. For one, some of the numbers and letters were hard to read with the font I drew by hand. I thought the font was fine, because I had been staring at it for a few days, but when I shared this version of SCSIcide, I received enough feedback about it to change the font to something a little simpler. Another suggestion was to have a "Latency Buffer" that the player needed to keep full by reading bits of data. The Latency Buffer decreases when the desired data bit is missed or if an incorrect data bit is read. When the buffer is empty, the hard drive crashes and your game is over. The buffer adds a sense of urgency to the game, especially at the higher levels when the data bits are moving fast. Little tweaks such as these led to a more exciting game to play than was originally intended.
Everybody has his or her own Great Idea™ about how any game should play. When receiving suggestions, I made sure to avoid feature creep by staying true to the original concept. I did not try to implement every suggestion offered, especially those that would affect my simplistic game model. Some great suggestions, which were unimplemented in this version of SCSIcide, were to include bad sectors (which would cause a hard drive crash if the read head simply touches the bad sector), vary the lengths of the data bits (requiring the player to keep the button down for a varying length of time to read the entire bit), and vary the data bit graphics. Any way you look at it, play testing and sharing your game during the development process is an absolute necessity. I would say there is no way to have a successful and popular game without getting the opinions of insiders, such as co-workers, and outsiders, such as the general game playing public. 4. Prepared in advance for cartridge manufacturing.
About halfway through programming SCSIcide, I knew that I needed to have a plan for building the cartridges. My goal was to release 50 cartridges, complete with color game manual and packaging, at the 2001 Classic Gaming Expo in Las Vegas, NV. I had made a public announcement on the expo site and on various classic gaming mailing lists and websites. I wanted to generate some buzz. There was no going back. The date was March 2001. I had exactly five months to complete the game, design a circuit board, receive the prototype, test it, receive a production order, burn EPROMs, solder chips onto the boards, put the assembled boards into cartridges, and clean and label the cartridges. The first thing I did was to create a custom circuit board for use in the standard Atari 2600 cases. I didn't want to have to modify the existing circuitry in the old cartridges, which takes a lot of time and careful soldering. The 2600 boards I made for SCSIcide support 2K and 4K EPROMs. All necessary components are easily obtainable at most electronics stores. This made the manufacturing process much easier and trouble-free. Once I had the circuit boards designed and manufactured, it was simply a matter of soldering the components onto the custom boards, preparing the cartridges (stripping the labels off old common Atari 2600 games, such as Combat, Pac Man, Missile Command, Asteroids, all cheaply available on eBay), removing the old guts of the cartridge, putting the new populated circuit boards in, testing, putting the cartridge together, testing again, and finally putting on the new label. Piece of cake! The 50 cartridges were successfully built by CGE and were extremely well received.
I allocated a $500 budget to develop and build SCSIcide. With such a meager sum, I needed to have an efficient and cost-effective production process. The design and production of the cartridge PCBs and purchase of the EPROMs and logic ate up most of my available funds. By planning in advance, I knew I could save a lot of money by avoiding rush fees and expensive overnight shipping charges. The
packaging and presentation of SCSIcide was kept to a minimum:
low-cost and simple, but effective. I wanted the game to stand out
in a way that no other homebrew game in the past had. I wanted the
packaging and appearance to be special but not so flashy as to take
away from the simple experience of the game. I didn't consider using
a cardboard box because of the manufacturing costs associated with
high-quality boxes and offset printing. I have seen other homebrew
and low-budget game vendors use a cheap inkjet printer and flimsy
cardboard packaging. This was not an option for me. I decided to
package the game and manual in an anti-static bag, like a hard drive
commonly is. This was a cheap way to provide a "box" for
the game. It was funny and catchy, since it helped keep the "hard
drive" theme of the game, and the price was right - just under
$0.15 a piece!
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
What
Went Right?
Features
|
|
|