     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Pixels Past's SCSIcide What Went Wrong1. The game concept was initially difficult for people to understand.
To a non-technical crowd, the concept behind SCSIcide is not exactly the most exciting and appealing one. One comment I received from a fellow gamer when I explained SCSIcide to him was "You need to inspire people to play the game. By itself, being a hard drive head is not very inspiring. Being a hard drive head is not as exciting as being a cowboy or a weird gobbling creature. The world that the drive head inhabits is too sterile and lifeless." Not wanting to reinvent the wheel and fall into an overused game mechanic, I kept the SCSIcide concept as-is. Being original can have its merits, though sometimes it can be risky. One advantage of keeping the game simple is that it forces players to use their imagination. Primitive graphics allows this to be done, as opposed to pseudo-realistic, graphic-intense games that put a fixed scenario into the player's mind. For SCSIcide, this simplicity ended up being a good thing. Those that didn't want to appreciate or understand the hard drive theme could easily think up another scenario to immerse themselves in. For example, one gamer's three-year-old daughter thought of the concept as "Move your basket to gather the colored Easter Eggs before time runs out." His eight-year-old son thought along the lines of "Fly a helicopter and lift the disabled cars from the lanes of a fast-moving freeway before traffic stalls." What I have realized is that many classic gamers are focused on game play more than anything else, possibly given the lack of high-resolution graphics in games they played during their youth. So even though it was initially difficult to get some people to adopt the concept of SCSIcide, the game play was appealing enough to make it a successful game. 2. Dealing with the challenges of Atari 2600 programming. The challenges of programming for the Atari 2600 are definitely one of the reasons it has become such a popular system for homebrew gamers (see sidebar). Its beauty is also its bane, however, as simple changes in routines or a typo of a single opcode can render the game unusable and set you up for hours of debugging. The requirement to keep the code space below 4K and use only 128 bytes of RAM throws many of the typical structured programming techniques right out the window. In many cases, re-using code in-line instead of calling external functions will save precious cycles, since the time associated with saving state is avoided. I had a number of problems throughout the development cycle that were fairly quickly fixed, such as timing problems with sprite generation (drawing, positioning, and moving the individual data bits) and hexadecimal score generation (a section of the score drawing function was over a page boundary which threw off the delicate timing of the routine). My hardest challenge was correctly implementing paddle control. Since SCSIcide was the first homebrew game to use the paddle, there was no previous work to reference. One byte of RAM was used to store the current numerical value of the paddle (which corresponds to the vertical position of the drive head on the playfield). At the beginning of each frame (in the vertical blank), the capacitor inside the paddle controller is discharged and, a few cycles later, set to recharge. During every scanline draw, the value of the capacitor is read. Depending on how long the capacitor in the paddle takes to charge (based on a simple RC time constant) determines the vertical position of the drive head on the screen. For example, the less resistance in the potentiometer of the paddle will cause the capacitor to charge more quickly, and place the drive head towards the top of the screen. If the paddle was moved in the other direction, increasing the resistance of the potentiometer, the capacitor will take a longer time to charge, and the drive head will be placed lower down the screen. Programming efficient and non-fluttering paddle control took the longest amount of development time and required a great deal of experimentation with the Atari 2600 system. 3. Color compatibility issues. Because SCSIcide is a fast-paced, intense game, quickly identifying the proper color bit to read is extremely important. Knowing right from the beginning of development that colors were an integral part of the game, I picked a visually simple color scheme and 10 unique and non-similar colors. I ended up with a brown background and data bits with bright colors throughout the spectrum. Sometimes the data bit colors appear very similar to each other, making it difficult to know which bit to read next. This is crucial in the later stages of the game where one false move could cause a hard drive crash, ending your game. It turns out that there are major variations in how televisions display color, so two colors that I had picked to be easily distinguishable might be displayed as similar colors. This was a design flaw in SCSIcide that was not uncovered until the final testing stages. It is really only important that the colors of the 10 data bits are easily distinguishable, not what colors actually are. Besides the television variations, SCSIcide was designed for NTSC (the North American television standard, also known as "Never The Same Color"), not for overseas standards such as PAL or SECAM. This is a potential problem because both PAL and SECAM display colors differently than NTSC. During SCSIcide development, there was some play-testing overseas and it was decided that the game will play fine on PAL sets, even though the colors were slightly off (but they were still distinguishable from one another). The proper solution would have been to create a suitable PAL color scheme and have the NTSC or PAL mode user-selectable. This was decided against due to lack of time but would definitely be implemented in any future game. SCSIcide was not tested on any SECAM systems. The color generation on SECAM Atari consoles is quite odd and the colors might all be converted to shades of grey. That would not make for a fun and exciting game of SCSIcide. Considering the huge range of overseas gamers, globalization is a necessity. 4) Not enough time to add more features. As much as I tried to plan enough in advance to complete the game, build the cartridges, and package the final product, I did not have enough time to add all the features into SCSIcide that I would have liked. The most neglected issue, though the game is still fully playable, is the screen flicker in between levels. This flicker is caused by the length of time required to calculate the colors and positions of the upcoming level's data bits using multiple calls to a pseudo-random number generator function. The routine is called immediately before the next level starts. Execution time of the routine takes too long and causes too many scanlines to be written to the TV screen by the Atari. This in turn causes a flicker until the Atari can resynchronize with the TV. The flicker initially happened every time a data bit was read, but I modified the code to have it happen only at the beginning of each level, making game play much nicer and suitable for release. Dealing with timing issues is one of the challenges of programming for the Atari 2600 (see sidebar). SCSIcide is also hard, if not impossible, for color-blind individuals to play, because the game requires the player to read colored bits in the correct order. If the player cannot differentiate colors, the game is essentially useless. I wanted to have the next required bit blink or be identifiable in a way other than color, but the idea came too late in the implementation cycle to make it work before the release date. 5. More demand than supply.
Fifty cartridges were manufactured by hand for the initial release of the game. I didn't know what type of response I'd receive at the 2001 Classic Gaming Expo. There was a slight buzz about the game being released, but the classic gaming community is very small (but growing) compared to the mainstream gaming community, so I decided to play it safe and do a small run. SCSIcide was to be released on Sunday, August 12, 2001 at 10:15am. An announcement was made at the show about 30 minutes prior to allow people to form a line to purchase a copy. I decided in advance to sell my game for only $20 complete. This price was much lower than the $30 or $40 that classic homebrew games are commonly being sold for. By 10:30am, all the SCSIcide cartridges were gone! I was amazed and slightly embarrassed, as there were at least 50 more people at the show who wanted to buy a copy of the game. However, people signed up on a waiting list to reserve a future copy of the game. Looking back, I should have taken a bigger risk up front and made more cartridges, considering that I had already spent the time and effort to design the game, though with my self-imposed $500 budget, this might not have been possible. As The Hard Drive Turns Many of the same challenges exist when programming for a classic game console as they do for newer game environments. In just nine months of part-time work, SCSIcide was brought to life. With over 200 copies sold since its release in August 2001, it is one of the highest selling homebrew videogames ever for the Atari 2600 system. SCSIcide was selected for the All Game Guide's "Best of 2001" and voted as runner-up for the MyAtari 2002 Awards "Best Game Release of the Year." It was a wonderful experience to create a physical cartridge-based game from a simple, non-tangible idea and release it for the public to enjoy. Watching gamers play SCSIcide is a thrill and I can only hope that my next game will be just as well received. My high score is 174E10. Can you beat it?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|