Making Skyline: What’s not in a Game?

This game I’m building for the 40th anniversary of the Atari VCS … there are a few things it needs to “do.”

Back in 2007, I threw together a rather cute (IMHO) proof-of-concept adventure game called Skyline. As for game play … OK, well, it kinda … sucked. And it has been, thankfully, totally forgotten.

So let’s not do that again. The sucking part.

Now, I do want to show off the capabilities of the Atari — as well as keep the basic game portable enough to get it onto other systems. What “capabilities” are we looking at? The TIA (Television Interface Adapter) graphics are challenging, themselves, and using them effectively is obviously part of this. Like many games, I’ll “have to” use a certain amount of “flicker” for complex scenes, but I don’t want more than 30Hz flicker most of the time. I’d prefer not to have the Venetian Blinds effect, but I’m re-using the technique I’d used nine years ago, which combines a bit of flicker/jitter with the Venetian Blinds to hide it, and I’m OK with that. There should be an acceptable amount of music … I won’t demand “fully-scored,” but the music, when present, has to sound something like music should. There should be some sound effects.

Controller-wise, I’ll accept standard Atari joysticks with one button, but leave in support for Sega Master System or Genesis controllers, reading from two buttons when those are available. The console controls should work more-or-less as expected: Game Reset to start the game, Select can be used in-game for a menu feature, and the Color/B&W switch repurposed as a Pause control. (Except on SECAM Ataris, where there is no such switch.)

If someone actually happens to have a MemCard or AtariVox, let’s let them save games to it, sure.

If the program crashes through the BRK vector, it should display some kind of useful debugging info. At least, a sad face and a build identifier and probably a full core dump (the entire 128 bytes of RIOT RAM dumped to the screen).

For testing, I’ll want some cheat code vector or other, also.

It should run on NTSC, PAL, and SECAM systems, and the display should look as comparable as possible on each. That means not only using the platform palettes and timing standards, but also ensuring things like, the SECAM display won’t have things that turn “invisible” because of the limited (8-color) palette. (On NTSC, we’ll have 128 colors, and you can pretty easily read very light blue on very dark blue, but, on SECAM we don’t want to have that translate to blue-on-blue or something.)

So, what we don’t have and can’t use that we might wish for on a later system like, say, the Commodore 64, are:

  • We don’t have a lot of read-write storage. We’ll have to be thrifty about what we remember.
  • We don’t have a keyboard, nor a lot of input buttons.
  • We can’t put a lot of changing or moving objects on the screen at once, so we’ll have to be thrifty about that, as well.
  • Also, displaying text nicely is a pain, so we’ll need something for that.

What do you think? Add your comments →