It’s been a little over a year now since I started work on Another Star 2. While I haven’t been working on the game all during that time, it has been dreadfully slow going and I have very little to show for all the work I’ve poured in thus far. Part of the problem can be traced to my tendency to overthink things, but the largest hindrance has been the way the game was being developed. I really wanted a game that was true to the era, but in doing so I broke the project’s own prime directive: Another Star 2 is not actually an 8-bit game.
Granted, there was something enjoyable about the way I was originally going about it. Other than the actual game code, everything was packed together in a “ROM” file. You could even open it up in a ROM editor like YY-CHR to see the raw tile data. But I was trying a little too hard to make a ROM and not enough time making a game. Some graphics were be compressed while others weren’t, depending on whether they needed to be streamed or could be preloaded. The animation system for party members in battle was completely different from the one used for enemies, and both were nothing like the one used for character sprites in the field! Yes, this was how devs fit games on cartridges back in the day, but every time I wanted to add something new I was programming it from scratch simply to pretend I was making a game in the late 1980s.
After coming back to the project recently following a several month absence, I realized that I was holding myself back and decided to do what I should have done from the beginning: work on a game, not on a pretend pseudo-emulator. This meant chunking the entire original code base, and all the nice tools I’d made for the game thus far (although a good chunk of the code is being salvaged, so I’m not starting over entirely from scratch). After a few weeks of work, I’m roughly back to where I was before.
Still, I wanted the game to be able to play around with cool 8-bit era toys like palette swapping, which isn’t really a thing on modern hardware. Thankfully, modern hardware has something else that old systems didn’t have: programmable shaders.
Here is how the display device “sees” Another Star 2:
But the player never sees this. The game continually updates a look-up texture containing a number of unique sixteen color palettes. Each sprite tells the shader which palette it wants to use, and then the shader can check the level of red in the input image and know right away which palette entry to replace it with. It ends up looking more like this:
The old ROM Architect tool I was making has been shelved, but I still needed something for converting images to a palette format and then animating them, so now I have the more boringly named As2Tool.
In this new incarnation of the engine, there’s no way to track or enforce little things like tile limits or streaming bandwidth. But maybe that’s not such a bad thing. I can concentrate on making the characters look good and animate fluidly instead of forcing everything into a box. That doesn’t mean I plan to deviate entirely from my original plan. This is still meant to be an ode to the late 8-bit era, so multi-layer parallax scrolling, partial opacity, and super-fluid animation are still off-limits.
This new approach also opens up the possibility of throwing in a couple of TurboGrafx CD or Sega CD style full-screen animated-pixel-art cut scenes. Yeah, the TurboGrafx 16 is supposed to be my speed limit, but I won’t get pulled over if I just go five miles over the limit… right?