It’s been a long time since I’ve posted a status update on this project. Sorry about that. I’ve been meaning to for quite awhile now, but life has been fickle lately. I’d also been working on another, shorter project that just didn’t pan out, so Another Star 2 has been on the back burner for a little while. Still, there’s quite a bit to cover.

The most recent thing I’d been working on is the battle system. This being an RPG, getting it in working order would be a huge leap forward on the project. You may remember one of the very first mock-up images I ever did of the game.

Here’s the battle background from that image, recreated in the engine:

Each battle background (or “arena”, as the game refers to it internally) is only allotted 54 total 8×8 pixel characters to work with, and they have to be arranged into 32 tiles that are 2×2 characters each, although there is some mirroring allowed. These tiles are then fitted into the final layout. In addition, each arena has a unique 10 color palette to work with (the other six colors are reserved for other things, like the window graphics).

But a battle background is just eye candy for the most part. The two most important things in an RPG battle are the enemies, and the party members, so that’s what I dove into next. Because I’m still trying to stay try to tile limitations for the most part, I decided to begin with the largest party member first to make sure they would fit.

I’ll be using the initial red design for the character, at least for now.

The party member graphics are a bit weird. Instead of being “sprites”, they’re actually made up of background tiles. There are 90 total 8×8 pixel characters in the background character table reserved for the party, and there are three party members at any one given time. Thus each one gets 30 characters, which are all streamed (and each party member is updated on different frames to simulate the fact there wouldn’t be enough CPU power or bandwidth to update all 90 tiles in one frame). They also get an additional four characters each in the form of sprites that can overlay the background, the idea being that weapons would be unique sprites and can be changed out depending on a party member’s equipment. And since the party is located beneath the battle arena and enemies on screen, that means I can do a palette change between scanlines and give each character their own unique half-palette of eight colors.

You’ll notice that this is getting a bit complex. And I’m not sure that’s a good thing…

When awaiting orders at the beginning of each round, the party members face the player. This was important to me, so that you can see their faces often. In the original Another Star, each character tended to be really samey. In this game, I really want each personality to shine and stand out on their own, both in the way they look and act in the story, and in the way they play in the game. Having their backs to the player all the time in battle makes them harder to connect with, I think.

Each party member is updated every six frames. That’s only 10 frames per second, but does emulate the graphics-limited look of the era. On the other hand it’s also a bit sluggish for things like this attack here.

Enemies, on the other hand, work a lot differently, and are actually much simpler. Almost all the sprite character table is free for use by enemies, but the party members would already be hogging all the bandwidth of the console with their streaming which means the enemies need to have all their graphics loaded into memory at all times. Still, bigger enemies can use up more room, and smaller, simpler enemies can use less, so long as all the enemies together in a given battle don’t go over the limit.

I began with the most basic, iconic enemy from the first game: a “weedgora”.

The original Another Star was pretty typical of the 8-bit era. You usually had big, colorful enemy graphics, but they didn’t move or animate to save on cartridge space. Another Star 2, on the other hand, has vibrant enemies that animate and can scurry about. Mr. Weedgora here, for example, shuffles from side to side while he idles.

Like party members, enemies also get a unique half-palette, but there can only be two half-palettes at a time so some enemies in a battle will have to share them (all other colors are used by the background and interface). I’m also toying with the idea of enemies having palette swaps that are only cosmetic. For example, our weedgora friend here might have bright green foliage in the bountiful grasslands, but on the dry steppes of the world his leaves might be a more subdued yellow, even though his stats have not changed. This could also make palette sharing between enemies more fluid and easier to work with.

So here we are, with the initial framework of a battle system in place. However, one of the last things I worked on was something I got stuck at, and I even knew I would get stuck at for some time. And that’s how it would look when the player goes to issue their orders for the round. The characters and enemies are already taking up so much of the character tables that there’s really not any room left for any other iconography. Here were two alternate styles I toyed with, using just text.

There’s too many options to fit on the screen at one time, so I need some way to let the player know that there’s more they can do, but both of these seem more messy than anything else. As it is, I’m really straining the limits of the original “rules” that I came up with. It’s looking like something might have to give. Either I need to change how party members and enemies work on-screen, or I need to go back and reconsider the limitations I came up with. Trying to do both will likely result in a much weaker game.