Making Skyline: Art that doesn’t suck

Skyline is targeting, primarily, the Atari 2600, but also other “old” systems. And that presents a sort of challenge to us: art that doesn’t suck.

Other folks have great write-ups at various levels of technical sophistication of the hardware of each system, but let’s start with this: the goal is to look, at least no worse than average, and at best, as good as possible, on each platform.

That means for n platforms, we’ll want to remaster the artwork for each, to take advantage of its strengths (or hide its weaknesses). Drawing a sprite that looks “all right” on the Atari’s 8-pixel-wide Player sprites, with one unique color at a time, versus the Commodore 64’s 12×21 sprites with 1 unique and 2 shared colors, versus the NES’s 8×8 sprites with 3 colors from one of a few shared palettes, these each have unique challenges.

But my goal is to have one game design, that plays on each platform. I don’t want the designer to have to worry about all those different art options. What to do?

Well, in the simplest case, we design for a “meta” system, and then compile down to all the specific architectures. The game’s design itself — maps, dialogue, scripts — is the same; how they appear (and, how the controls work, music sounds, &c) are determined by the platform it’s running on.

That model, in this case, is the “tiles and sprites” model. The background maps are immutable and broken down into a set of (very few) large world maps.

For Skyline, there will be four worlds, each with its own library of tiles. For each world, there are four possible levels — as in, roughly, altitudes: Below, Ground, Above, and Special. These levels can draw from the relatively rich library of tiles for that world, freely, and are imagined as very large, free-scrolling spaces. The designer has major latitude, at this point.

Now, that lets us use the very nice Tiled app to draw the maps. Cool. We can sketch out some high-quality proxy art, draw the maps, lay out the game in pretty nice detail, and pan around to see what it would look like in some ideal world.

In fact, I might even want to hook up Hath to it, to let you actually playtest (or play?) the game under Linux …

What then?

Well, we take that big, beautiful tile sheet, and we copy it for each video architecture; say, the Atari 2600’s TIA. We scale it down, set it up fro the right palette, and generally do our best to present the best possible interpretation of each tile.

That part is basically manual. So, for each platform, you can “tweak” the artwork. You’ll still want to keep in mind various platform-related quirks, but you can work in the nice, modern environment of Gimp to design it.

After those are “done” (to whatever degree), the build process takes over. We’re taking advantage of the fact that Gimp happens to host a beautiful Lisp environment called “Script-Fu,” which is actually the Guile language — the GNU version of Scheme. Using that Script-Fu, the Make process for each version of the game can “call” Gimp to export its native XCF files into useful, flat PNG files that are easier for the compiler tools to read.

The compiler tool has to know about the various platforms’ constraints, and it can issue warnings about possible-problems (eg: an exact color wasn’t available in the palette, so the nearest-matching color was used instead) or signal actual errors.

Those actual errors, of course (this is Common Lisp, after all) don’t stop things dead. Restarts are established around the compilation process, and you can choose how to cure the problem. For example, you might open the affected artwork in Gimp and edit it, then ask the tool to reconsider it and see if you’ve fixed the problem.

Those restarts aren’t (today) very sophisticated, but they do work. In future, better error conditions being signalled from within the compiler tool will enable more fine-grained restarts to be presented, and eliminate some of the work by the user. Currently, the user sees a boatload of possible restarts and has to manually evaluate which one(s) are actually useful in the current context.

Making Skyline: Making it fun

So, yesterday I wrote about the limitations on the Atari. While these are going to end up defining what kind of a game I can‘t make, it doesn’t point too far as to what I can make. So, let’s think about that, for a moment.

Skyline is going to be a tile-based, top-view, adventure game. We’re going to focus on a plot with characters that have some dimensions to them — a bit more “rounded” than, “It’s dangerous to go alone. Take this.” I’d like to include some interesting puzzles, and I don’t want to fall back on fighting — nor even “competition,” by itself.

Slaughtering endless waves of critters? Play Gauntlet for that, pershaps, or Space Invaders — there are certainly lots of options there. But the Atari doesn’t lend itself to something like Gauntlet or Galaga, where the critters are all moving independently — a lot of games, like Bezerk or Adventure have it stripped down, to have a very few enemies at a time, in order to work within the limits of the system. Many screen-by-screen or room-by-room games, like Sorceror, just limit it to one (or one cluster) enemy at a time, for that reason.

There’s certainly room for a good turn-based RPG; the action of Pokémon or Final Fantasy could surely work well on the Atari, and Skeleton shows some insight in that vein, but that’s not really something I like to play …

So, it came down to an adventure game, like Adventure or The Legend of Zelda, but with more dialog, more interaction with other characters, and perhaps some more zany items to learn how to use.

Really, that’s the thing that those two games, in particular, are about. Adventure, for example: there isn’t necessarily a “right way” to win that game. What there are, are strategies. I started playing Adventure more than 20 years ago and it’s still fun, because it’s about learning how to work within its rules, not mimicking some optimal behaviour or guessing the solution to some problems.

What makes it fun? Well, it has hard and fast rules, but things are all in motion, all the time, so it’s hard to keep track of where things are. The bat, the dragons, are each doing their own things, and in order to win, you have to keep an eye on them, but also learn the lay of the land, and more importantly, learn how to use the different items in the game to your advantage.

From Zelda, though, I’d steal an additional curve: “item-based leveling.” You see, in the original Legend of Zelda, you can just wander wherever you like, and that’s mostly a good thing, but you might wander into a “high level” area and get squashed quite quickly, and that can be disheartening until you discover where are the “safer” areas. In later games, though, they would sometimes “hide” some difficult areas in a way that required some item to get through. Really, they were just “keys,” but they let you into various areas once you had demonstrated your skill at the game.

And that’s what I was (long-windedly) trying to explain here, is the thing that I love about good ARPG’s like these, is that they aren’t testing your character’s stats and they can’t (always) be cheated by a walk-through. The real thing is that you’re being tested on your own ability to learn a skill.

I’m not pretending that “fishing for swords using magic magnets” or “stealing butterfly pendants from moblins with a hook-shot” are at all practical skills. Certainly there are better things to be learning, like integral calculus and how to make Jell-O parfaits. But within the game world, your ability to progress should be a test of your own skills at finding the things in the game, and applying what you’ve learned. Also, hopefully, there should be enough going on that you can’t just follow along with something you saw on YouTube, to skip puzzles.

So, there are some soft, framework-y ideas. How to implement them…?

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.

Making Skyline: Part I: 40 Years of Atari VCS

It’s 2016, so we’ve have almost 39 years since the Atari 2600 was released. Let’s write a game for it.

Let’s write a game for a machine with 128 bytes (~characters) of memory, marginally “crap” graphics, and a 1 MHz processor. We’ll write it mostly in 6502 assembly language, and design graphics, sound effects, music, and dialogue. In order to get it to anyone, we’ll have to build cartridges with the game’s ROM and some control circuitry, build cases for them, labels, a manual …

Oh, and of course the 6507 CPU in the Atari is also used in a bunch of other computers from the 1980’s: The 6502 in the VIC-20 and Apple ][, as well as the Atari 400, 800, 5200, and 7800; the 6510 in the Commodore 64, the 8502 in the Commodore 128, the 2A13 in the Nintendo Entertainment System, all are more of less the same processor. The big brother 65816 is in the Super NES and Apple //gs. Totally different memory arrangements, of course, and different video hardware, audio systems, even input devices. Let’s try to produce a single game that’ll be playable on several of these.

OK, well, maybe it’s just me. But, while we’re at it, let’s design this on a modern Linux system with top-of-the-line development tools.

Here’s what I’ve chosen for starters:

  • The main editor for the program code is, of course, Emacs.
  • The toolchain that will compile the art, music, maps, and so forth into assembler-friendly data files will be in Common Lisp — and I’m not going to be too shy about being SBCL-specific, Linux-specific, or even Fedora-specific if it makes any difference. This tool is basically just for me, but if someone wants to use it elsewhere, they might have to do a little hacking.
  • For the tool, I’ll use CLIM for the interface. Restarts will appear in the CLIM Debugger, the CLIM Listener and Climacs will be available at build time, and if there’s anything that makes sense as a general-purpose tool, I’ll build it in CLIM as well. Among other things, this means that interactive building tools can use rich text and embedded graphics for their output cheaply. Nonetheless, it must remain possible (in the “no errors” case) to run a headless build and capture a reasonable (text only) log file output from the process.
  • The size of the build tool is unimportant, but I’d like it to run on a sub-$300 notebook without choking.
  • For graphics, we’ll use Gimp XCF files, but we’ll hack on Gimp a little. A Gimp (Guile) plug-in for exporting as PNG, and some palettes for Gimp to make it easier to hit the various color palettes of our target machines.
  • Atari gets first dibbs, followed by Commodore 64, and then we’ll see what else I have time (or interest) to build.
  • Music will be imported from General MIDI files, but I haven’t set my heart on any particular editor. In fact, it’ll probably mostly be Public Domain or Creative Commons classical music.
  • For maps, Tiled wins. Yes, I made a donation to the author, too. Eventually, my own Hath will probably replace it, as this project will probably eventually merge with Hath altogether.
  • Ideally, let’s write a scripting system that supports a reasonable subset of Lisp and writes out native 6502 code.
  • The assembly source files should be 64TurboAssembler (64tass) compatible.
  • The game needs to be runnable in Stella, Vice, and the like.
  • Ideally, anybody with Gnu Make and SBCL installed should be able to do a one-step build — so, it ought to be able to bootstrap the whole toolchain with DNF in some rational way.

So, some arbitrary choices I made up front, based on things I like to use or think are nice to work with.

So, now what? Oh … we need a game.

Let’s talk about that next time