Another Star 2 Dev Log #26: Path of Least Resistance

A whole lot has changed in the world since my last dev log entry. I wanted this to be the year that I finally got this project back on track, but it seems life has other plans. My day job is in retail. When the world hunkered down to brace for the initial impact of Covid-19, I was not stuck at home in a lockdown with lots of spare time to advance my own personal projects. Instead I was working overtime, doing my best to unload trucks and push food to empty grocery shelves. And that daily responsibility only continued to eat into my free time as I moved up through two promotions and the extra work load of the American twin holidays of Thanksgiving and Christmas.

Still, I’ve managed to eke out a little progress these past months that I wanted to share today.

Around the time of my last dev entry, I took some time away from this project to dabble in some NES homebrew development. Though I grew up with the system in the 80s and early 90s, I’m not wild about the system’s graphical limitations. But here in the United States it’s the most widespread 8-bit video game console, and thus the easiest to produce content for if you want people to be able to run it on actual hardware. I decided that if I really wanted to develop for an 8-bit console with strict hardware limitations, I should make something original for a real one instead of shackling Another Star 2 to an imaginary one. Here’s a couple mockups I did of various ideas I had.

Eventually I began to toy with the NES’s 6502 to see what came of it. It can be hard to wrap your head around programming in assembly on a CPU that is limited to single byte values and only has three general purpose registers, but after a lot of effort I actually managed to get something up and running, even if it never grew into anything. In the process, I learned something important.

It is often observed that the shortest distance between two points is a straight line. With the NES and its 6502 I had so little space, memory, and power to work with that I had to force myself to simplify how things worked in order to get a result. Other times I had to realize that, even if a solution to a problem was awkward, if it already worked just fine I needed to leave it alone and move on because a more “streamlined” version would not only take more time to write, it would often require more space and precious CPU cycles.

There’s a lot of odd choices I made early on in Another Star’s 2 development. Many of them derive from the game’s stricter adherence to the original fake limitations of the game. However, I’ve had to tell myself to leave those decisions alone. They’ve already been implemented. They already work. It’s time to move on to the next thing. I can do it different in another game.

An excellent example of this is a feature that I’d been putting off for a long time. Whenever you change a character’s weapon in Another Star 2, I wanted the sprite to match. This works by giving each weapon its own unique set of sprites. The characters then have “attachment points” each frame to anchor the weapons to. But though the sprite data already contained a way to store the information for these attachment points, I’d never gotten around to implementing them in the sprite editor I made. For weeks, I went back and forth on how best to implement a way to drag and drop pieces, and thought in-depth about what interface buttons I would need to determine whether I wanted to select sprite pieces or attachment points, and so on.

But that’s too much work! No, I forced my way through and just assigned selection to a hot key and made placing and renaming attachment points a function of the editor’s existing right-click menu. Boom. Probably less than half a day of work and I had weapons up and running.

Same with per-frame event triggers. I wanted to know which frame of animation during an attack is where it “connects”, hitting the opponent. It wasn’t going to take long to program the editor to save the trigger name as a string to an existing string library in the sprite file and then cache the trigger names before each battle to check against—

No, no, no. That was going to take too long. Instead I went with an old idea I had and used the 32-bit integer value intended to store the index of the trigger name as the trigger itself in the form of a four character ASCII string. “HIT ” becomes a four byte sequence that I can check as the hexadecimal value $00544948. It’s just as efficent since it’s still just comparing an integer to an integer, and I cut out the need to cache anything. I think it took me longer just now to explain how it works than to actually implement it.

It’s easy to get caught up in trying to do things “the right way”. There are obviously times where that’s important. But other times, you need to focus on just getting the thing done and moving on. I’d like to make other games one day, after all.

Leave a Reply

Your email address will not be published. Required fields are marked *