Menu

“I think the next big hurdle to tackle is scripting,” I wrote in my last dev log. Well, that was the plan, anyway. But shortly after writing that I decided to make a quick addition to the game’s room code. With just a little work, the game could automatically switch door tiles between “open” and “closed” variations as the player approached. It worked quite well and right away, despite being such a minor thing, really made the tiny world inside the game feel all that more grounded.

I’d imagine in real life, she’d just leave a bunch of open doors behind her with all the lights turned on.

This is done programmatically, by the way. No scripting is involved, which makes it really easy to throw doors into a room. The game simply caches all the door tiles after loading up a room and then the entities moving around the map ping their location as they move. But as I tested it out, I couldn’t help but realize how empty it felt because everything was so quiet. The doors needed a satisfying audio cue as they changed state. To do that, I’d need to implement a proper sound engine, the only major core engine task left other than scripting.

Being a child of the 1980s, I really love FM synthesis. Especially the early, somewhat cheap sounding little FM synth chips that Yamaha liked to develop. The first Another Star played prerecorded music composed in FL Studio using samples from (and a VST that emulated) a Yamaha YM2413, a chip used in the Japanese version of the Sega Master System. Most game soundtracks flock to the more traditional chip tunes of the NES or Commodore 64, so working with early FM synth sounds instead was a real treat for me. For those who never played Another Star, here’s an unused track from the original game to give an idea of how it sounded:

As I’ve noted in past dev logs, I’ve always planned for Another Star 2 to have a similar soundtrack that emulates early FM synth chiptunes. But I wanted it to sound more unique instead of being almost entirely limited to the preset instrument selection of the YM2413. Instead of just choosing a different emulated chip VST to record, I decided to go a step further and actually write a software FM synthesizer of my own to run in-game in real-time. Not the brightest solution, perhaps, but I’ve written a few before as experiments and I really had my heart set on doing this. To justify going through all the trouble of making it work, I decided I would create ways for the game to dynamically react to what’s happening on-screen. While far from impossible, that’s a lot harder to do with your usual pre-recorded tracks.

It took a month and a half of work—time I really probably should have spent elsewhere—but I finally accomplished it. Most of my time was spent writing the tool to actually get the music into the game. I thought about writing a simple General MIDI file importer, but even then I would need a custom tool to be able to do things like place event triggers and create song variations by enabling or disabling individual tracks.

Up to four operator FM is supported in the editor, but in-game only operators one and two are enabled. This is partially for optimization on older systems, and also to stick closer to the simpler, “cheaper” sound of the earlier FM chips used before the 16-bit era.

Most of my tools are written in C# with WinForms because it’s really quick to get things up and running, and afterwards I rarely need to rewrite any code in C++ for the game other than the routines for importing files, which usually doesn’t take very long. But a software synthesizer is a much different beast, and I didn’t feel like writing it or the playback code twice, once in each language. So I ended up writing the composing tool in straight C++, something I don’t normally care to do. As you can see, I wasted a lot more time trying to make it look pretty than I should have.

Because I wasn’t using WinForms, I even had to write custom interfaces for normally trivial things like picking where to save a file.

The playback format is similar to MOD music in that it’s pattern based, although each pattern is a variable-sized list of single-byte commands for a single monophonic channel instead of a table having something for all the channels together. Notes and other commands are inserted in the piano roll for each pattern, and then patterns can be assigned to tracks down below the piano roll.

The little board at the top is displaying volume in this screenshot, but it can also be used for editing stereo panning, assigning instruments, and more.

Finally, the variation editor is used to decide which tracks will be used on which channel. Internally all the tracks advance together and there can be any number of them, but only the assigned tracks send their notes to a channel to play. Originally, there were going to be only four channels of FM synthesis, and then there would be two other channels limited to just noise generation and low-fidelity PCM samples that could be used primarily for percussion. But this would require actually programming special channels for noise generation and low-fidelity PCM samples instead of, you know, just telling the computer to make six FM channels instead of four. The FM channels can already switch from sine waves to noise generation anyway.

In the end I think I won’t limit any channel to any ability the others don’t have and just continue to use all six FM channels as proper FM channels. I really need to get back to making a game instead of messing around with this anyway. (The editor actually supports eight channels, but that’s an awful lot for a simple 8-bit system, so the game only uses six.)

Notice that by this point I stopped caring about fixing visual bugs in the editor.

Now, here’s that same track from before, recreated using the new software synthesizer and playing back in the editor:

And, since the game and the editor use the same synthesis and playback code, it only took literally an afternoon to get the audio into the game itself. It’s still rough around the edges, but here’s some actual footage I recorded this morning:

Notice how the music switches between variations when going from one room to the next. You’ll probably also notice that sound effects cut out parts of the music so they can play. This was common back in the day, and makes me feel nostalgic, but I may break down and add a couple of channels that are reserved just for playing sound effects.

So, with the rudimentary basics of the battle system implemented, I decided it was time to go back and reimplement the overhead map portion of the game in the new engine. It actually didn’t take too long to get everything back up and running since a lot of the code could just be copy-pasted verbatim, although I still had to sit down occasionally and work out exactly how some things should work now. This finally brought me back to where I was before chunking the old “pseudo emulator” engine.

I decided my next task was to actually link maps together so that you can get around. While I’m sure you could make an RPG that takes place in a single room, it’d take some real skill to give it enough gameplay to make it interesting for hours on end. Since the earliest dungeon crawlers of the 1970s played on university mainframes, role playing video games have done their best to drop you into a world—sometimes small, and sometimes vast—that you are meant to explore.

Don’t mind me. I’m just exploring.

It seems like a really simple little thing, but the mere act of moving from one screen to another is a huge moment for me. All of a sudden, individual maps have context and purpose. I remember getting the same feeling when working on the original Another Star. When I made it so that you could move between sections suddenly it felt like I was playing a real game. In any case, this means I can finally start building up actual content and start piecing the game together.

You may also notice that the protagonist has a running animation now. Speeding along at two pixels per frame while watching a normal walk cycle always looked strange to me, so I decided to throw in a simple run whenever the player characters speed up. I think it gives it more of a Chrono Trigger feel than I really wanted, but it just feels like it controls so much better, even though literally nothing else changed other than the animation. It also gives the character a little more personality when they can zip along like that, especially if I give each party member their own running style. I’m currently undecided if I should implement a classic “run button” when using the digital d-pad.

I think the next big hurdle to tackle is scripting. Right now, moving between rooms (maps) is a simple system of “warps” and “labels”. In the room editor, you can drag out a rectangular label in one room and a rectangular warp area in another, then tell it the name of the room and label to take the player and the game will handle it all on its own. For most uses, this is perfectly fine, but there also needs to be a way to handle more complex transitions. Not to mention a way to actual add the NPCs and objects for the player to interact with. Scripting can be big and complex, but having done this once before, I don’t think it will take me very long to get the basics up and running.

A disclaimer before I begin, it must be noted beforehand that I’m talking about a game in active production that is still early in its development cycle. Some of things I’m going to talk about today have already been implemented. Other things are half-finished, while others still are merely planned. It should go without saying, but be aware that lots can change between now and the final game as things are implemented, tested, refined, and, in some cases, dropped altogether.

The first Another Star had a pretty typical battle system for an RPG modeled after the 8-bit era. Battles were fought in rounds. You’d pick a command, the game would randomly decide on a turn order based on each combatants’s agility, and then the battle would play out for you to watch. Fairly standard stuff. There were five commands in battle: Fight, Defend, Magic, Item, and Flee. They all did pretty much exactly what you’d expect they’d do in an RPG, with the exception that there is no targeting—everyone always attacked everyone else—and the defend command not only lowered damage taken but also restored a little bit of HP.

Another Star 2 builds on the first game’s battle system, so little has changed when it comes to the commands available. That said, however, the way you use many of the commands is liable to change.

The biggest single addition to the battle system comes in the form of “guard points“. Each character will have a few guard points; probably just two or three at first, but they’ll gain a few more as they gain EXP and level up. But even maxed out, each character will still only have a precious few—maybe 10 to 16 at most, and that’s only for certain characters. These guard points form the character’s “guard meter”. Certain actions in battle will begin to fill the meter, while others (more slowly) will allow the meter to lower back down until it empties out again.

Here’s the basic gist of it: you do not want the guard meter to fill up. Collectively, your active party’s guard meters make up the “guard pool”. If the guard pool is completely filled—that is, if the guard meter for every party member is filled—and the enemy manages to land a hit, then a “guard break” happens. The round immediately ends, and new one will start with the enemy free to wail on you with heavily increased damage while your party stands there in a daze unable to resist. In other words, it’s designed to be an easy way to get yourself killed if you’re not careful with your actions in battle. Character’s guard meters are not emptied after victory either, so plan accordingly.

Another Star 2 has six battle commands, in the form of icons. (Speaking of which, it turns out there was a Famicom RPG with an icon-based interface…) Here are the commands in Another Star 2, and here’s what they do:

FIGHT

This is your basic “attack” command. As with the original game, every party member will attack every enemy. There is no traditional targeting system. And again as with the original game, the fight command is a bit of a gamble. There’s a chance the attacker will miss a defender completely, dealing no damage at all. Or they might land a critical hit and deal loads of extra damage. The damage range is also likely to be very wide, more variable than the first game. If you absolutely must kill an enemy this turn, then “fight” might not be the way to go.

There’s also another interesting difference between Another Star and Another Star 2’s fight command. Characters with high agility have a chance to attack twice in the same round. The chance of it happening depends greatly on their order in the turn queue. And if you’re really lucky, and the character is really fast, they might even get a third attack in… (To make up for the lack of hits, characters with higher strength will likely have a better chance of getting good “rolls” which lead to better, higher-damage attacks. You’ll be able to tell how good an attack is by the character’s attack animation.)

The attack command is also important for another reason: it’s the primary way to get your guard meter to go back down. When the character attacks during a round (but probably only the first time, if they’re lucky and get multiple attacks) their guard meter will go down by half a point.

DEFEND

Defending will significantly lower any damage that characters take during the round. And, like the first game, when the character’s turn comes around in battle they’ll regenerate a decent chunk of their HP. The system was easy to cheese in the first game if you were patient and leveled up enough that you could restore more HP than the damage you took from enemies. But, as you might have already guessed, Another Star 2’s guard system is designed specifically to prevent that particular exploit. In addition to restoring HP, the character’s guard meter will go up by one point. Or, if the character’s meter is already full, that point will either be split between the other two characters, or given to the only character left with any room in their meter. This can make characters with smaller guard meters a liability if you’re not careful.

Defending is also not something to take for granted. In Another Star 2, each character has their own innate elemental affinities, which means they have their own elemental weaknesses and strengths. Those who played the first game should already know what this means: if a character is hit by an elemental weakness, it won’t matter if they’re defending. They’ll still take the same amount of damage as if they weren’t—which means extra damage, since it’s a weakness after all.

Getting hit by a weakness also causes the character’s guard meter to go up by one point, whether or not they’re defending.

MAGIC

Magic is going to work a little differently than the first game, but it’s still the same idea. There are no “magic points” in Another Star 2. Spells are cast by sacrificing your hit points. Since magic cost HP, there aren’t really any traditional healing spells (which is why the defend command is so useful in both games).

When casting magic, only the caster gets to act in battle; the other party members do not get to do anything that round. However, magic attacks ignore enemy’s armor rating, meaning they can often do just as much damage as all three characters together if the caster is good, and they can do a lot more if they exploit an enemy’s elemental weakness. Magic attacks will also tend to do more “stable” damage in Another Star 2, with very little variance from round to round. There’s also plenty of buffs and debuffs and support magic, too. Veterans of the first game will be glad to learn that hit point costs for magic are planned to be fixed-cost in Another Star 2 instead of percentage-based, and you’ll likely have access to earlier forms of spells instead of just the most recent upgrade. Useful, since the cost will still go up with each new spell evolution.

It’s also worthy to note that spells are not planned to be tied to characters in Another Star 2. Each character will get a fixed number of spell slots (with access to a few more as they level up), and you will be able to equip spells like you would weapons or armor. Some characters will get more slots than others, making them more useful for magic. But remember that characters have innate elemental affinities now. They can use spells of any element, but they likely won’t be able to do as much damage with spells that they’re weak to the element of.

SKILL

This is a new command for this game that wasn’t in the original. Skills are innate to a character, similar to how magic was in the first game. You can’t just unequip a skill and give in to someone else. Each character has at least one skill, but may gain more as they level up. There will likely be ways to use skills from characters who aren’t in the active party, at the cost of guard points. As with magic, only the skill-user will go during the round.

ITEM

Items are meant to be especially useful in Another Star 2. Other than defending, healing items are the primary way for you to restore HP. There’s also magic scrolls to cast spells you don’t have equipped, and without using up HP. And there’s going to be lots of situational battle items and fun little things to play around with, just like in the original Another Star. Certainly there will be rare or expensive items to do something about your guard pool getting dangerously close to filling up…

The best part is, just like in the first game, agility is not factored into turn order when using an item. The party leader will use the item right away as soon as the round starts. So go ahead, take a chance and let your HP get really low before burning a consumable to bring it back up! As long as you survive the round, you’ll be able to heal up right away come the next.

FLEE

Sometimes things go wrong. Like, very wrong. In that case, there’s little to do but run away and live to fight another day.

As with the first game, you can’t run away on the first turn. You’ll also lose a good chunk of your loot when you do choose to run.

But one planned change from the first game is that fleeing doesn’t happen right away. The enemy gets one last free turn to smack you around before you go. Thankfully, however, you’re guaranteed escape. For this last beating anyone left standing will retain at least one hit point, and you won’t get your guard broken even if you take a hit with a filled guard pool.

Early RPGs, whether released on consoles or the personal computers of the day, had very simple interfaces. This was common across all genres, of course. RAM was severely limited, especially on consoles, so there was only so much room to store data and graphics. But this was harder on some genres, like RPGs and strategy games, than it was on others. Sometimes important information had to be remembered because there just wasn’t enough room to keep it on screen. Other times, the games left out important information altogether and you had to keep the manual and a bunch of fold-out charts on hand if you wanted any chance at making sense of it all.

These early RPGs are perhaps most famous for their simple text menu, usually consisting of the classic Fight/Spell/Run/Item combo. The original Another Star followed this tradition practically to the letter.

Command?

This screenshot is from the game’s original release. Notice how much focus is put on the interface elements themselves. The party is squished in up at the top, enemies are barely a blip on the screen, and most of the screen space is dedicated to menus and numbers. A little over a year after the game first came out, I did a new version for the game’s release on Steam. This new version included brand new graphics for all the enemies.

The Version 3 Steam release.

The enemies are bigger and more distinct here, it’s true, but many of the same issues remain. Now, it’s not necessarily a bad setup. You can only make text so small on an 8-bit system without getting into serious VRAM issues, and this interface packs in a lot of information that most RPGs didn’t even bother with, like details about the enemies’ current HP and health bars for the player’s party members to help them better visualize how their party is holding up.

But for Another Star 2, as you’ve seen from past mockups, I really want more focus put on the graphics themselves. I want the enemies to be big and detailed. I want the backgrounds to really give a sense of the game’s setting. I want the party members to be recognizable and relatable—I want them to face the player when they’re receiving their orders instead of always standing with their backs to the camera, so that the player knows what they look like and can actually get attached to them. This is really asking a lot of an “8-bit game”, but it’s not entirely without precedent.

Contrary to what some think, Another Star wasn’t named after this game.

Phantasy Star was a late Sega Master System game. Notice how bright and colorful the background is, and how it takes up the full screen. The enemies were even animated when they attacked, although they could only ever manage to fit a single enemy on the screen at a time. This game really pushed what the console was capable of.

However, by giving more priority to the graphics, I’m left with less room to assign to the interface. I used mockups to try and solve this problem by seeing what I could move around or reorganize. I wrote about the process in more detail here before I even began actual work on the game, but to summarize, I began by simply recreating the interface to the first game.

No room for the characters’ names, see?

This would work, in theory, but it’s awfully cramped. The bottom 8 pixels of the characters would be covered by the menu whenever it comes up, though that’s not too big a loss. But on a real television, the trooper’s head would be hidden under the overscan, and there’s meant to be even bigger enemies still. The interface had to be made smaller. After several iterations, I came up with this mockup:

Still quite tight, but much more breathing room.

By shrinking the window-based interface elements down sixteen pixels and moving the HP bars up to the enemies themselves, not only does everything feel less cramped but parts of the interface now feel a little more connected to what they’re meant to represent. Still, there was the problem of the menu itself. Another Star had five battle commands, not four. One of them had to be pushed off the end, indicated by the down arrow letting the playing know there’s more they can do. But that seemed sub-optimal. That arrow is pretty small. Would the player always realize at a glance that there were more options? Forgetting “flee” might not be a big deal 99% of the time, but Another Star 2 is set to have at least one new battle command, so what else might get lost in the shuffle? It seemed there must be a better way.

I put this all on the back burner for a long time, but now I’m working on getting the battle system up and running, so it finally came time to confront the issue head-on. My first attempt, pictured here in-game:

Finally, an actual screenshot.

The cursor hadn’t been implemented yet, but it was going to point to the selected option, making it more obvious that it was an option. And since you could only see one of the options at a time, the layered windows should have communicated pretty well that there was more you could do. But it seemed so clunky, especially since I really need to keep the 8 pixel tile above each letter of text reserved for languages that need diacritics (you’ll see this often in Japanese RPGs on the NES; it’s how they implemented the dakuten for their kana characters). I thought about adding a little animated icon for the current selection to liven it up a little, but I was already out of VRAM tiles for the scene.

Then came the engine reboot I talked about in the last dev log entry, at which point the tile limit became more of a suggestion than a hard-and-fast rule enforced by limitations of the engine itself. So I decided to do a mock up of what it might look like if I went all-in with icons.

I did make sure to leave text so that you don’t have to guess what the highlighted icon means.

I hated it almost immediately. It didn’t feel very 8-bitish to me at all. On the NES and Master System, text was used for everything it possibly could be. The letters were already taking up precious space in VRAM. Why waste them? Extensive iconography was rare even into the 16-bit console era and beyond. Mainstream Final Fantasy wouldn’t even get a visible HP bar until the PlayStation 2 came around!

But the mock-up got a pretty good response when I previewed it on Twitter, and after sleeping on it, it did kind of grow on me. I decided to try implementing it in the game just to see how it’d look for real. The custom As2Tool application I wrote to help make the game has an animation tool that standardizes all animated graphics in the game, cutting down on the amount of graphics-related stuff I have to hard code in the engine. The tool is very simple and somewhat primitive, but it ended up being fairly flexible and allows a single frame of animation to have multiple elements, so… well, suddenly it was very easy and fast to make things look however I wanted them to. Maybe I got a little carried away, even?

It’s alive!

Apologies for the poor quality of the GIF, but this is actual footage from the game. Granted the characters are stuck on arbitrary loops right now for testing, but look at how alive the whole thing feels! Another Star 2 is supposed to carry on the torch of Another Star’s fast-paced battle system. It’s supposed to feel snappy and energetic! Look at how the screen flicks down to focus on the party when it’s time to give orders. Look at how the clash of swords sends sparks flying. It’s meant to keep you pumped and eager for battle! It actually turned out better than I’d imagined it.

It doesn’t look like an NES or Master System game interface at all, but having tasted from this particular chalice, I’m not sure I can go back to the old ways…

In the next dev blog I plan to dig a little deeper into the inner workings of the battle system itself. There’s a lot I’m not ready to reveal yet because it’s so early and so much can change between now and release, but there’s some interesting changes planned in comparison to how things worked in the first game.

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:

Another Star 2 is a Virtual Boy game now. Surprise!

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:

I disabled the CRT screen filter for both these to make it clearer what’s going on.

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.

A lot of As2Tool is just repurposed ROM Architect code.

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?

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.

This is the thing that inspired me to work on this game.

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

I made the grass much more lush and less scratchy.

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).

It’s quite limiting. Maybe too limiting?…

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.

An overview of possible palettes for the character’s design. Which is your favorite? What would you change?

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

Trying out the first four possible palettes in pixel art.

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…

His hair is probably moving a little too much.

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.

He’s a big character, so fitting him in 34 tiles is not easy.

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”.

Can I refer a design from a three year old indie game that hardly anybody played as “nostalgic”?

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.

Weapons have not quite been implemented yet, and our sole party member is taking up all three slots.

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.

Option 1.

Option 2.

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.

First off, a huge THANK YOU to everyone who has commented on the project thus far. I’m happy that you’re enjoying watching the game’s progress, and I hope that you’re looking forward to when it’s released, even though that’s still so far off.

Anyway, computer Role Playing games have changed a lot over the years, and to this day there still tends to be a rather large chasm between what defines “western” and “eastern” style RPGs. But despite all their differences—whether it be battle systems, character mechanics, or art styles—there’s always been one thing that virtually every RPG ever made has in common:

Text. Lots of text. Loads and loads of it.

For early RPGs, both on consoles and home computers, this was a bit of a problem. Today we can fit entire movies on our phones without a second thought, but just a few decades ago space was so limited that just finding the room for dialog was a major development hurdle in and of itself. The original Another Star emulated this by keeping character interactions short and to the point, often with intentionally stilted lines to recreate the feel of the era, even though the storyline as a whole contained an obscene amount of text compared to an actual 8-bit console game. Another Star’s text files combined together add up to over 400 kilobytes, which is larger than most NES carts. Even with some decent compression, there’s no way a game from that era would have as much text as Another Star.

Another Star 2 will likely have even more text than its predecessor. But I’d actually like to lean away from the original game’s dialog style and have the characters speak a little more naturally. However, I still want to keep the pace up, so don’t expect a visual novel. Persona this is not.

Like an actual 8-bit game, both Another Star and Another Star 2’s fonts require part of the character table. Here’s what Another Star 2’s font currently looks like, as seen in a debug overlay.

The quick brown fox…

Notice that the font alone takes up almost half of the character table for the background, leaving fewer characters for actual map tiles. This was a very real problem that console games often ran in to. It’s part of the reason many games that only needed a little text would just make do with capital letters and not include any lower case ones. This is the solution that the original Another Star used to stick to its own 256 tile limit. 8-bit console RPGs of the era, which were usually made in Japan, couldn’t settle for this though, as they needed more than the English Latin alphabet’s mere 26 characters in order to manage a single set of kana.

Because Another Star 2 is allowed to change between tile sets at will, I don’t forsee this being too big of a problem. As seen in the mockups I’ve done, the area maps are more detailed than the original game, but they aren’t meant to look quite as advanced as, say, the late SNES games that most “classic style” pixel art game prefer to emulate, such as Seiken Densetsu 3, Final Fantasy 6, or Terranigma. If it does become a problem, I suppose I can always steal a “cheat” from some of the later NES games: they had a special chip on the cartridge that would let the game switch between character sets between scanlines. Some lines would display the map graphics, while others could display the text and interface. Granted, this was possible because the NES has no VRAM and thus all the graphics memory was on the carts themselves, but I’m sure I could cook up some excuse if I absolutely have to. (Or just admit that I would be cheating and live with it.)

You’ll notice in all the mockups I’ve done that character graphics tend to be quite prominent, most notably in the form of character portraits for dialog instead of the speaker’s name. I want players to be attached to the characters of this game, and it’s hard to make that attachment in such a visual medium as video games when all you have to go on is a name on a screen and an itty-bitty mash of pixels. Originally I intended the portraits to be static, but I wanted the characters to be very expressive in-game. Here’s what they look like right now in-game.

Notice that the portrait has its own unique palette. This is done by switching palettes mid-scanline.

Having a flapping mouth and blinking eyes was very rare for the time, but a handful of games did use them. Still, note that not only does the mouth flap, but the entire jaw moves. It’s really fairly detailed for a little 32×48 pixel graphic. The room needed to store all the portrait graphics, their layouts, and their animation data is a bit much on its own, not to mention the fact the graphics have to be streamed to VRAM each frame in addition to everything that’s still going on with the map graphics. Not impossible, perhaps, but it borders on the implausible.

However, when deciding on whether to go this route or not, I had to remind myself of the first rule of Another Star 2: “Another Star 2 is not actually an 8-bit game.” I believe having animated portraits makes the game more engaging, and as long as they’re not over-animated I don’t see them clashing with the art style, so I erred on the side of inauthenticity for the sake of making a good game.

Anyway, as a bonus, here’s what the portrait look like when viewed in the current iteration of the screen shader.

In-game, the jagged, uneven lines flicker like on a real display.

It’s meant to look like the console is coming in through a cheap RF adapter, but better settings will be available in the final game. I plan for a high-quality option that emulates a computer CRT instead of a television. There will also probably be a few different screen shapes to let you customize how much of the picture is chopped off by overscan, and how round the display is.

Sometime early in the development of the original Another Star, I happened to think to myself, “I wonder how this would look on an actual tube television set.” So I decided to learn about how GPU shaders work and see how hard it would be to slap a good scanline filter on the game’s output. It was just a spur-of-the-moment thing that I didn’t think would go anywhere, but I was so impressed by the initial results that I ended up seeking out a high-quality CRT filter created for video game emulation and incorporated it into the game.

Another Star in all its glory.

A lot of other games began implementing CRT filters around the time Another Star first came out in 2014, and many more have done so since, so it’s not quite as unique a feature as I’d hoped. But it did give the game the warm, nostalgic feeling of old-style console pixel art. Simulating old displays has come a long way from the time when developers would simply render every other row of pixels and call it a scanline effect. Today’s filters capture the actual look of actual displays by simulating the scanline’s brightness, making up for the dark areas between lines and preventing the picture from looking too dark or washed-out. The higher resolution of modern screens also help out.

Of course, it goes without saying that Another Star 2 will follow its predecessor’s footsteps and do its best to emulate playing the game on an old tube set early Saturday morning in your underwear before your parents get up. And, like Another Star, it’ll be fully optional for those whose system’s can’t handle it, and those who simply don’t want it. (You kids get off my lawn, now!)

It’s always interesting that the first thing people usually compliment me on when they first see Another Star is the screen shader. Which is always a little embarrassing because the screen shader is one of the few things that I didn’t make in the game. It’s a GPL licensed shader written in part by a trio of coders: cgwg, Themaister, and DOLLS. Yes, I rewrote small chunks to fit it into my own engine, and to tweak some of the effects, but it’s not really my work. This time around, I wanted to roll my own.

It’s a work-in-progress, so I hope it will look even better in the future.

So, here it is, the first iteration of Another Star 2’s brand new screen filter. You’ll notice that it does away with the traditional horizontal scanlines more commonly seen on old computer and arcade displays and instead works to emulate the staggered, big-holed shadow masks of consumer television sets. This is more true to the game’s status as a “home console game”. It’s more noticeable when you zoom in for a closer look.

“Don’t sit so close to the screen!”

Currently, the shader doesn’t emulate the separate red, green, and blue rectangles that you’d see on a real tube-style television set. My early tests trying to accomplish this programmatically didn’t produce satisfactory results, so it’ll probably take a texture reference to pull off. But to be honest, I’m not even sure it’s completely needed. Zoomed out to the normal viewing distance, you wouldn’t see those anyway. I may decide it’s more processing power to no end and just not implement it.

You’ll also notice that it currently lacks the rounding of the television screen, which makes the vertical lines really noticeable and a bit distracting when resized for most of these screenshots. It looks much better in-game, though, and I think the slight rounding should mostly eliminate the artifacts at lower resolutions. Instead of calculating the screen’s shape in the shader like Another Star’s filter, I’ll probably take a page from J. Kyle Pittman and spread the game’s display across a 3d shape. This should result in much more efficient output than doing it in the shader anyway. I’d really like for the shader to be useable on lower-end laptops, something that’s mostly impossible with Another Star’s computation hog of a shader.

Sometimes all you had to play your Nintendo on was a cheap old monochrome TV nobody else wanted anymore.

Another Star 2 is also implementing something that I could never quite get to work in the original Another Star, and that’s NTSC artifacts. When it came to color, NTSC was a horrible, horrible display standard that plagued us until the advent of HDTV. Running it through a low-quality connection like an RF cable made it look even worse by causing the colors to carelessly bleed into each other (even more than usual). It should be a real nostalgia trip for those of us old enough to recall it. Remember trying to fiddle with the television’s tint knob so that the colors looked right?

Not pictured: figuring out whether the TV had to be on channel 3 or channel 4.

Thankfully, you’ll have some input into the output quality of the shader, so if you want to play with the screen shader enabled but want to minimize the NTSC artifacts and blurring, you’ll be able to do it from the game’s options menu.

And, of course, Another Star 2 is not actually an old game, so I don’t plan to rely on the screen effects as a crutch. They’re there to compliment the game’s style, not to stand in for or take the place of real gameplay. I have a lot of ideas on how to continue to innovate on the old RPG mechanics I first toyed with in Another Star. Hopefully you’ll agree when you get the chance to play through the game yourself.

And speaking of gameplay, I’ve got text boxes up and running!

“Hello everybody!”

Although the scripting systems aren’t in place yet, the game can detect when you interact with NPCs and opens this little dialog box for you. The actual scripting isn’t too far off now. I’ll probably discuss text and game localization next time, so stay tuned. (No pun intended.)

A Let’s Player by the name of MrGazillion has just completed a blind Let’s Play of Another Star! Here’s the first episode, and you should really give it a watch:

I’ve never actually seen someone really sit down and play through my games before, other than roping a few family members to try them when I was much younger, so this is a new experience for me. As a developer, it’s pretty amazing to be able to watch as a new player picks up the game and gives insight into how they approach it and what they’re thinking. It’s one thing when people explain their thoughts on a game afterwards, but it’s quite another to see it firsthand and figure out what game systems players are overlooking, not understanding, or just not enjoying. There’s more than a few things MrGazillion missed that are probably far more my fault than his.

Developing Another Star felt like fumbling around in the dark a lot of the time. A few people did try the game and give they’re thoughts, and for that I will be ever grateful, but with so little total feedback it was really hard to figure out what was working and what was not. In many ways, I think the game suffered from my lack of direction. Thankfully, I have a feeling that Another Star 2 will have no shortage of volunteers to test it out.

In the last dev log, I promised to show screenshots from the actual game engine instead of just mock-ups, and that’s exactly what I have in store for you today. Prepare to be amazed! Behold, the very first screenshot ever from Another Star 2:

I’d say it’s almost ready to ship.

Okay, so that’s not very impressive at all. But with some work, it eventually improved to this:

A test render of the 8×8 pixels characters used to build a tile set.

What you see above were the first steps towards getting the game’s graphics up and running by uncompressing the character graphics from the game’s data file and then sticking them in the nametable (tile map) to show up on the screen.

Another Star 2’s display works a lot like an emulator. Most of the work is actually done on the CPU. It renders out the display as a 280×262 pixel texture that contains the 256×224 display, plus the overscan that would be present in an actual signal sent to the television. The CPU is not particularly efficient at drawing things, which is why these days we have blazingly-fast parallel processor GPUs that can draw millions upon millions of polygons a second to enormous displays.

However, the visual effects I want to do in Another Star 2 harken back to older, tile-based display processors of the past. They worked quite differently than modern display processors, and because the game can change a lot of display parameters (including the palette and scrolling values) from row to row of pixels, it didn’t seem like it was worth the trouble to format and send a bunch of row information to the GPU every frame and then write a specialized shader to interpret it all. Moreso because it all needs to work on somewhat more limited OpenGL 2.1 hardware, to meet the game’s planned minimum specs. But since the game’s resolution is minuscule, the CPU can handle it fairly easily and relatively quickly anyway. Even in debug mode, on my system the game rarely reaches too far above using 30% of a dual core CPU, spread across two threads. In release mode, that number usually falls to less than 10%.

But enough technobabble, let’s put those characters together into tiles, and then build a map out of them! Yeah! This is going to be great!

Well, that didn’t work out as planned.

Like a lot of the game’s graphics, the game’s maps are all compressed. In my first attempts, things didn’t go so well, as you can see. But with a little more work, I managed to actually work out all the kinks.

Not shown: scrolling.

So, now we have working maps. That’s like half the battle right there. Just needed some NPCs to liven things up.

There wasn’t any collision detection at this point, so they could stand on the tables without worry.

In this screenshot, I’ve included the entire game window to show the little tables on each side of the main screen. They show me what graphics are loaded at any given time, so they’re helpful for debugging. I’ll probably leave a way to pull them up somehow in the final version of the game for those who are interesting in seeing what the game is doing behind the scenes.

At this point in the screenshot collection we’ve caught up to about where I am now, where I have a playable character that can move around the map at will. Unlike the first game, movement is not completely limited to the grid. Pretty unusual for an 8-bit era RPG that wasn’t action-oriented, true, but I think it still stays true enough to the genre, and it makes getting around a little easier because you can move diagonally like a real person.

My clones actively follow me around the map as I walk, like in Chrono Trigger or the Mana games.