Category Archives: Another Star 2

Posts and dev log entries for the sequel project to Another Star.

Another Star 2 Dev Log #22: The Shape of Music

As mentioned in previous dev logs, Another Star 2 uses a real-time software synthesizer to generate its music and sound effects as you play. This required me to program a special tool called FM Pipe Organ that I use to set up the sound of the “instruments” and actually compose each track. It’s a little buggy in places and lacks a lot of helpful tools that most composing interfaces provide, but it’s good enough that I’ve already put together quite a bit of music, some of which I’ve shared in past dev logs. Granted, there’s still a long way to go, but the music is already shaping up pretty well in my opinion.

In the early stages of developing the synthesizer, I’d get lots of audio pops and other artifacts. It’s hard—and, in some cases, rather impossible—to tell what’s going on just by listening. Thankfully, sound is a wave, so it’s fairly easy to represent as a winding line that maps the waveform over time. To debug the synthesizer early on I would record the output using whatever sound editing software I had on hand at the time, and then go peek back at what the waves looked like. I often continued to do this whenever I made a new instrument setting and was trying to get a specific shape for the waveform. Even back then, I realized how helpful it would be to have this capability inside FM Pipe Organ instead of having to rely on an outside tool.

FM Pipe Organ oscilloscope visualization

The hills are alive.

This past week I hastily added a handy little oscilloscope visualization to FM Pipe Organ. Not only does it show the final left and right audio output that’s sent to the system, it also displays the individual output of each of the eight channels. The visualizations for the individual channels do their best to show the actual timber of each sound by left-aligning the waveforms based on when they pass the zero-boundary while going upward. They further stabilize the waveform rendering by checking multiple passes through the boundary and choosing one based on how close it is to the one before it. This is really helpful for complex waveforms that pass the boundary multiple times in a single repetition and otherwise end up snapping back and forth a lot in the rendering. Sometimes this works and sometimes it doesn’t, but usually you can see the waveform pretty clearly. It gives a really good indication of what the channel is doing and why it sounds the way it does.

Below you can watch and listen to FM Pipe Organ in action, playing a song I specifically wrote to show off what it can do. It’s meant to be used in some of the early hidden areas you can explore, but we’ll see how it ends up used in the final game. It may even end up sounding quite different in the end. Pardon any frame skips or audio pops in the video; they aren’t normally present when I’m not trying to use capture software.

If you watch carefully, you’ll notice that the bottom two channels, channels seven and eight, never do anything. That’s because Another Star 2 only uses six of the eight channels in an attempt (possibly in vain) to avoid sounding too much like a later 16-bit console game. I haven’t fully decided what the limitations for the game’s soundtrack are going to be, but that one in particular is pretty firmly set at this point.

One day, I’ll publicly release FM Pipe Organ for sure, so that everyone who is interested can play around with it. However, I don’t see that happening until after the game itself is released. Like a magician, I don’t want to give away all my secrets in the middle of the show!

Another Star 2 Dev Log #21: Adventures With Friends

Another Star 2 footage

Sally forth!

Adventuring is always more fun with friends. Even the darkest dungeons aren’t so dreary when you have comrades by your side. As noted before, there are nine planned party members for Another Star 2. I’ve completed the map sprites for three of them thus far, allowing me to test a proper party. They all need plenty of tweaks their sprites still need, but it’s a start.

Party composition will be a fairly big deal in Another Star 2. In the first Another Star, the hero Tachi had two companions, giving you a set party of three characters that were with you for pretty much the entire game. However, I really wanted to build on the party mechanics and give the player options to balance the strengths and weaknesses of each party member by teaming them up in different ways. Instead of being forced to stick with glass cannon Tachi, what if you could have occasionally switched him out in favor of a faster and sturdier character that wasn’t quite as strong, and lacked Tachi’s strength buff spell?

I want players to have reasons to experiment and change their lineup regularly. First off, like with most games, each character has their own stats. Some specialize in strength, some in defense or speed, and so on. Second, each character has their own unique skills, a new addition for Another Star 2, giving each character their own flavor and gameplay style. Most RPGs are content with these two properties for characters, but Another Star 2 goes a bit further. As mentioned in an earlier dev blog, each character has their own elemental strengths and weaknesses. You may be able to compensate for these a bit later in the game, but you can’t get rid of them altogether. If you’re headed into an ice cave, you may have to swap your favorite character out for awhile because they’re weak against ice and can’t defend against the hits they’re receiving from the ice-themed enemies. Forth, a character’s guard meter only goes down a small amount at the end of a battle. If it’s starting to fill up, you may want to swap the character out for a bit. Every character’s guard meter goes back down a bit after a battle, even if they aren’t in the active party. Finally, you may not always have access to all nine party members at all times. Each character has their own things to deal with in the wide, wide world, and so they may be unavailable from time to time. You may even be able to send them off on their own mini-quests for a set amount of in-game time, to return with loot and items if they’re successful.

Here’s a preview video that I recorded of in-game footage, showing the current state of the project and letting you listen to the game’s real-time FM synth at work. Give it a view and then I’ll discuss some of what you’ll see.

First off… the glitches. I kept wanting to put this recording off until I fixed everything perfectly, but then the game would be finished and four years would have passed without a single dev log update! The biggest issues to notice are that the animation for the two follower members likes to glitch out because they’re changing speed and direction so often. Sometimes they have trouble figuring out which direction to face and end up walking backwards (this happens most often in the overworld). Don’t worry. These issues will be fixed before release, and I promise they’ll look great as they follow you around the world. The frame rate also tends to skip at points, and there’s some video and audio artifacts, but these are mostly recording issues because my computer isn’t the best. Ignore all of these for the moment, and I’ll get on to the more interesting stuff.

First off, encounters. If you played the first game, you know how the system works. As you walk around, prompts show up above the main character’s head indicating an encounter. A yellow “!” means that you can fight or ignore the battle, while a red “!!” means that you have to accept the battle right away or else you’ll be ambushed. But right off the bat, in the video you’ll see a red “!!!” followed by a yellow “!!” and then a yellow “!”. What’s the difference? Difficulty! Battles that force you to think about how to beat your opponent are great, but if every battle is such a mental workout it gets tedious and boring, and sometimes just downright stressful. It’s nice to spice things up by having some simpler battles that you can basically just button-mash through. Some games do this by mixing difficult bosses with cakewalk normal battles, but that can make the easy normal battles bland and forgettable. Another Star 2 does its best to strike a balance by having a wider range of standard battles. Those encounters with a single “!” are easy, those with “!!” harder, and those with “!!!” the hardest. These happen independently of whether a battle is forced or not, thus the icon changes. When you first enter a new area, maybe you’ll only accept the easiest battles to make sure you can handle them before venturing further and risking the chance of a more difficult forced battle.

(You may notice I’m skipping all the forced encounters, by the way. That’s because the game is in debug mode–and also because the ambush doesn’t properly trigger yet.)

There’s also another type of encounter icon that the game will introduce that aren’t demonstrated because they haven’t been implemented yet, and those are mini-boss encounters. In the first game, mini-bosses were set encounters in fixed locations visible on the map. Another Star 2 will probably still have those in spades, but very rarely you will get a special encounter icon for a mini-boss. You are forced to accept these in order to avoid an ambush, and will be pitted against incredibly rare and difficult foes to further break up the monotony.

Now, pay special attention to the battle footage. If you watch careful, you’ll notice the rat enemies don’t use the same attack animation every time. Every time an enemy or party member attacks, the game will randomly determine if they managed a weak, moderate, or strong attack. You can tell what level of attack they get by how many strikes they make in the attack. One strike represents a weak attack, while three strikes represents a strong one. Strong attacks do higher damage (although this hasn’t been properly implemented yet). You’ll only see the attack levels with enemies right now, because none of the party members have their proper attack frames yet. Critical hits, of course, are a different beast and have their own unique attack animation, but they haven’t been implemented yet either.

Now, one last thing before I go, and this one is a biggie. Another Star used an “omni-battle” system where every attack hits every possible opponent. With Another Star 2 I intended to build on and refine the system by introducing the guard system and letting you choose your party composition, among other major changes. However, I’m seriously considering ditching it altogether and letting you select a command and individual target for each party member, just like a traditional RPG. Another Star is shaping up to have a more ambitious scope than its predecessor, even if it’s not planned to be that much longer in playtime, and I fear the old battle system will feel out-of-place and grow stale as the game goes on. Perhaps I can save all my ideas for the “omni-battle system 2.0” and use them in another, smaller RPG some other time in the future.

I do hesitate to commit to the change yet, though, for a few reasons. The biggest one is that I want to keep that connection to the first game. The omni-battle system was one of Another Star’s staple minimalist design choices. If you can only hit one target at a time, will Another Star 2’s battle system feel too generic, even with all the ideas I am still bringing over from the first game? I also worry that it will slow the game down too much. Battles (usually) played out so quickly in Another Star that they were an in-and-out affair and never ground the game’s progress to a halt. I don’t want Another Star 2’s battles to be something slow and tedious that you would automatically cut out of Let’s Plays and such without a second thought.

What are your thoughts about the battle system, and the project’s current state? I look forward to hearing your input!

Another Star 2 Dev Log #20: Setbacks

They say that the road to success is paved with failure, but it’s also paved with lots of sudden and unexpected detours. You may have noticed that I haven’t posted any dev logs in some time. There’s a reason for that, and it’s not because I’ve given up on the project.

In July of last year I got a new job, and am now working full time. Alas, it’s not in my field, which is really frustrating at times, but it is keeping my bills paid and that’s what’s important right now. Sadly, this means I simply can’t dedicate twenty-to-forty hours a week on this project anymore. Any progress is made in my free time now, and there was even a long period where I didn’t try making progress at all. I’ve been meaning to post about this for months now, but I kept putting it off until I had something new to show at the same time. I shouldn’t have done that, I suppose. I’ll try to get back to making updates semi-regularly again. Sorry about that!

That also brings me to another subject that needs to be discussed here: cutting content. As creators, we usually hate parting with the perfect vision we see in our minds. But we can’t do everything. Whenever you create something, be it video games or books or movies or something else, you eventually have to part with some of your ideas, even the ones you love the most. Some things have to be cut because they would take too long, others because they don’t work as well as was planned, and still others because they’re just not feasible.

Another Star 2: Fate of the Catalyst design document

The original design document for Another Star 2, complete with its original working title.

When I first began work on this game, I wrote out an enormous document. It detailed the game’s mechanics, its world and characters, and most importantly it included a very detailed outline of the game’s story from beginning to end. The document is a little over a hundred pages long (and single-spaced, at that). I knew from the beginning that I would probably have to trim quite a bit of fat to actually finish the game in a reasonable amount of time, and that was before I got caught up in pretend system limitations before rebooting the code from near-scratch! However, now that I have so much less time to do things, I’m probably going to have to cut even more than I had initially hoped. A lot more.

The question is, what are those cuts going to be? The game, as currently envisioned, contains nine playable characters, ten major dungeons, about twice that number of mini-dungeons, and like the original Another Star it includes countless little side areas to seek out that would consist of just a screen or two. So where do I point my knife? Should I reduce the number of playable characters to cut down on the number of highest-quality sprites I need to pixel out? Or do I just simplify their sprites, or even reduce the number of animations for them? Should I cut out entire dungeons whole cloth, or should I make them smaller, or leave them as intended and reduce the number of mini-dungeon side quests instead? If I streamline the game too much, will that detract from exploration because there’s nothing to find? Or do I just accept that maybe this is going to be a ten year project instead of one that one lasts only another year or two? These are all questions I need to consider very carefully right now.

I also wonder if I should carry on with my “vertical slice” demo that I mentioned before, or simply begin the actual game. I’ve honestly never really done a vertical slice. For better or worse, I usually just start at the beginning and go from there, accepting that I’ll have to come back and polish the early game content later. (Either way, I’d release some sort of demo as early as possible, just not a proper “vertical slice”.)

But regardless of what I cut, I think the harshest truth I must face is this: the game won’t be perfect. No game ever will, of course, but this one even less so. I have a habit of obsessing over little details, wanting to polish every pixel to its finest. I can’t do that anymore. I think I’m going to have to accept that some battle animations won’t be perfectly fluid, that some lines of dialog will be lackluster, that some map layouts won’t be as engaging as others. And then I will have to move on to the next piece of content that needs to be worked on.

Oh! And before I go, I mentioned I was holding out to show my progress. Well, here you go!

Another Star 2 gameplay

Enemies are fully animated, and each has a neat little entrance animation at the beginning of the battle.

I promise I won’t wait so long for the next update! I’m planning to continue working on the battle sprites and animations so that I can get the battles mechanics into place. Look forward to it!

Another Star 2 Dev Log #19: Taking Inventory

It’s been a week and a half now since my last dev log entry where I noted that I was working towards a little playable build of the game for public release. I wanted to finish it by the end of the month. I haven’t made as much progress as I was hoping for, so it looks like I won’t have anything ready quite so soon. I just need to learn how to make games faster, I suppose.

But at least progress is being made, even if it’s not as quick as I was hoping. In the past week I’ve worked on getting the game’s item system up and running. The scripting commands needed for items to be usable haven’t been added yet, but almost everything else is done. This includes the inventory system, which is what I’m going to talk about today.

Another Star 2 screenshot

Here’s the main inventory screen.

It’s hard to imagine an RPG without some sort of inventory system. Not that it can’t be done—it certainly can. But it’s such a fundamental simulation of how we store and use our tools and possessions in real life that it’s not just a cornerstone of RPGs, but of countless other genres as well. Items are usually very important in RPGs. You are an adventurer! Here is your sword! Here is your shield! Another Star 2, of course, is no exception.

Inventories in games tend to be broken down into two camps: infinite inventories that can hold everything, and limited inventories that only allow you to carry so many items (often based on weight, or count, or a combination thereof). Personally, I kind of like inventory management, so long as it’s not too tedious, which is the main reason why Another Star had a limited inventory.

For a limited inventory to work well, the player needs to have access to information about the usefulness of items, and they need to be able to understand how much room they have. Both of these allow the player to make informed decisions about what items to keep and what items to toss or sell. Older games tended to fail at the former. Many came with fold-out charts in the box along with the manual. If you didn’t have the chart, there was rarely an in-game way to find how powerful a given weapon or piece of armor is. Thankfully, improved display resolutions and better interface designs have pretty much nipped that problem in the bud.

Informing the player about the space left in their inventory still tends to be a problem, though. Bethesda games like Skyrim and Fallout are an example of this. Those games’ inventories are limited based on weight, but when it’s time to clear out your inventory it’s often a struggle to figure out where all the weight is. Is it a few heavy items, or many light items that are the problem? This is an area where Another Star failed, I think. In Another Star you had 50 item slots. Players usually didn’t realize this, though, because other than an untitled counter up in the corner of the inventory screen the game never really tells you up-front. Most players discover the item limit when they go to open a chest or buy something and the game suddenly tells them that they’re already full.

There are a few ways I want to approach this differently in Another Star 2. First off, you’ll notice that the inventory isn’t an old-style list of text, it’s icon-based. The graphics aren’t just to be pretty. They add some valuable information that text alone has trouble conveying. There are visible slots for items to be in, so it’s easy for the player to realize at a glance “oh, I only have this much room” without being explicitly told. Second, the inventory is going to be smaller at first. Maybe a dozen or so item slots at the beginning of the game. This means that the first time the player opens up the inventory, they’ll see that there are less slots on screen than there is room for, meaning they don’t have to scroll down before they realize the item slots don’t go on forever. It also lets them “practice” managing a small inventory early in the game that’s easy to track while they’re still figuring out how different sorts of items are useful. Don’t worry about the small starting inventory too much. Unlike the first Another Star, as this game goes on you’ll be able to earn more inventory slots.

One more thing I’d like to do is to better encourage the player to use their items instead of hording them just for boss battles. The first Another Star had lots of battle-minded items like nets and bait that were useful in certain situations. However, other than the throwing stars and bows, even I usually just sell them when I go back and play the game. I want items you find to look and sound like they’d be fun to use when you come across them so that you’ll want to try them out right away. I also want to make items like this more reliable. Why shouldn’t the net always immobilize or slow down low-level non-intelligent enemies instead of only working half the time? If it’s reliable instead of a gamble, people will want to make use of them because now they’re a dependable tactic in battle. Plus, if it isn’t as useful on bosses, players are likely to be less stingy with them.

Another Star 2 screenshot

This option sorts your entire inventory by type, name, or how long you’ve had each item.

The one thing I haven’t quite figured out yet is “key” items. These were a problem in Another Star. They took up room in your inventory, but the game would never deny you one when you were out of inventory room. What sometimes happened is that a player would end up with 51 items or more in their inventory because they’d just gotten some key items. They’d go sell a single item when told to free up room to buy something, then get confused when they still couldn’t buy the thing since their inventory was now at 50—still no room.

In my original notes for the game I planned to not have key items count towards the item total at all, but this might also be confusing, suddenly adding extra slots when you go over the limit just to have them disappear when you sell off items to make room. Most games tend to solve this by moving key items to their own special inventory, but I’m not sure this is a good idea for Another Star 2. In the first game, key items weren’t just MacGuffins that have no purpose. They were often items that you could equip, such as the very useful “Father’s Pendant” accessory acquired early in the game. If they’re all in their own little “key item” inventory, the player is less likely to remember them or even realize they can be used. I may make some sort of “overflow” inventory where key items get banished to when you acquire one but have no room for it.

I suppose I should also mention to two icons at the end of the inventory screen. The first is just a simple sort option, as pointed out in the caption above. Another Star 1 also had this. Selecting it multiple times in a row has the game sort your inventory by a few different criteria. I assume most people will use this if their inventory starts to get too cluttered instead of doing it all manually by hand, especially as the inventory size grows.

The second icon is more interesting to me, though. In my original mock-up image of the inventory I added a recycling symbol to the trash bin to make it more obvious that when you “drop” an item, you aren’t just throwing it away. As in the first game you get a little loot for it, although it’s just a pittance so that it’s still more worthwhile to hold on to it until you can sell it, if possible.

When I began working on the inventory this week, I went back to that mock-up in order to figure out where to put everything on the screen. When I did, I couldn’t remember at first why I made it a recycle bin icon and not an actual trash icon. It reminded me so much of the “recycle bin” in modern operating systems that I decided to just roll with it.

Another Star 2 screenshot

Thanks for the gamedev pointers, Windows 95!

When you drop an item into the inventory’s recycle bin, you get your bit of loot, but the item isn’t actually disposed of yet. The most recent five items remain in the bin. If you change your mind, or pressed the button by mistake in a hurry, you can open up the recycle bin and select the item to get it back so long as you still have the loot from it, and have room in your inventory.

Now, it is possible in theory to abuse this mechanic to get five extra slots in your inventory. However, it’s not as simple as you might think. Nothing in the recycle bin is safe; not once you leave the status menu and go back to exploring. If you die in battle, the entire contents of the bin is gone forever even if you choose to retry the battle. They’ll also be gone if you ever reload a save. They aren’t even guaranteed to be there while just walking around as maybe they’ll start to randomly disappear from the bin after just a few seconds.

Another Star 2 captured footage

Here’s the inventory in action.

Well, that pretty much sums up the inventory and my thoughts on it. What are your preferences when it comes to the way games handle items? What are some of your examples of both good and bad inventory designs in games you’ve played?

I think my next goal now is to get the character status and equipment screens up and running. Hopefully those go more quickly.

Another Star 2 Dev Log #18: The Path Forward

Lately, I’ve been working on a new tileset. This will be used for many of the ruins dotted across the world of Byo, built by all sorts of past civilizations that have come and gone.

Another Star 2 screenshot

My tilesets usually begin as mockups, like this one. I can display images in the engine to test them.

Ruins can be kind of tricky to get right with low resolution tile-based graphics, because if they look too nice and uniform then they just look like slightly run-down castles instead of crumbling ruins being slowly reclaimed by vegetation. I’ve been looking at Star Ocean: Blue Sphere a lot lately for inspiration on this. It’s a Game Boy Color game that never left Japan, and it has some really nice looking ruins (well actually, it has some really nice looking everything). That game’s graphics show what you can accomplish even on a grid with limited colors.

Another Star 2 screenshot

I added roots and broken floors to make it feel more run down. Variety helps keep it from looking too clean.

Some of my biggest progress in the past week has been finally hooking rooms up to the battle system. Encounters now trigger, and you can accept them as in the first game to begin a battle. After the battle, you get experience and loot, and are returned to the room to continue exploring. So far every battle is exactly the same because enemy parties haven’t been properly implemented, and your HP isn’t tracked between battles because the characters aren’t actually in your party, but it’s starting to feel like a real game at last. (I even find myself reflexively pressing the A button as soon as I hear the ambush alert sound, even though ambushes don’t begin on their own yet.)

Another Star 2 screenshot


I began Another Star 2 about a year and a half ago. While I haven’t been working on the game that whole time, a great chunk of that year and a half has been dedicated towards this one project. It can get a little frustrating when it takes so long for something to bear fruit. The first Another Star was playable within just hours, and could be played from beginning to end within a few months. (Completing it took much longer, though; about nine months all together.)

But with Another Star 2 I’m only now getting the map system and battle system to tie into each other. Granted, I spent a lot of time building a new engine for Another Star 2 in C++, while the majority of the first game’s basic code was put together long before I began work on it. Still, this is taking a lot longer than it should. Even ignoring the time I spent before rebooting the engine, I’ve poured a lot of work into this with very little to show for it.

It’s time to change all that.

Early on in Another Star’s development, I put up a very early version of the game for download, jokingly calling it a “leaked” version. It was unpolished and had lots of bugs and typos, but it was complete up through about the third or fourth dungeon. I wasn’t having very much luck with finding people who wanted to playtest the game for me at that point, so this was sort of my last-ditch effort to get feedback. I was hoping a few people would try it out, but to my surprise it really took off. (Granted, I assumed “now they’re interested and will buy it when it’s released” instead of continuing to post about the game and keep those people engaged, but that’s another topic for another day.)

I’d like to do some similar things with this game. The first phase of that will be a preview build of the game. This won’t be a full “leaked” release containing lots of unfinished dungeons. It will be more like a small demo in that, while incomplete, it will have some level of polish and be self-contained with an achievable end goal. I suppose this is akin to what many professional developers call a “vertical slice”. The idea here is that the demo will be centered around a single small dungeon. It will give players a chance to try out the game, get interested, and give feedback. It also allows me to figure out how to streamline content creation so that I can churn out the assets for the full game. It will also help me decide what constitutes a “small” dungeon, how big a “full” dungeon should be, and how many the final game needs. This preview build won’t be long. Maybe a half hour at most, and I think most of that will be just from getting used to a new game and trying things out.

Since I now have something to work towards, instead of aimlessly deciding what to work on next I can map out definite tasks that need to be completed. RPGs are really difficult to boil down to their essentials, because they need so many different components to work together before they are all that interesting. Thinking it over, I believe the following things need to be done in order to release this preview build. In no particular order:

  • The preview build needs a small, non-linear dungeon to explore. I have a rough layout planned, and am already playing with room layouts to figure out how build they should be. Because the player character can run, and because the characters are larger than the first game, rooms may need to be rather big in order to avoid feeling cramped.
  • The dungeon needs a couple of tilesets to build these rooms out of. (This part is mostly done; the outside tileset for the ruins is the only one I haven’t done any work on yet.)
  • There should be optional areas and secrets to find, encouraging the player to explore, and making the dungeon feel more like a real place instead of a simple obstacle course.
  • There needs to be a variety of enemies. The enemies have to be drawn and animated, and they have to formed into enemy parties (called “formations” in the As2Tool editor). The game also needs to decide on which formation to use from several possibilities per room.
  • There should be a challenging end boss for the dungeon. Of course, they have to be bigger and more impressive than normal enemies, because that’s what makes them a boss!
  • There needs to be a battle background or two for the ruins. Right now, the only backgrounds in the game are tests from early in the game’s development, and they don’t match the direction that the art style has been going. (Also, none of them are ruins.)
  • Battles need to be further fleshed out. Right now, all either side can do is attack. The foundation of the enemy AI also needs to be implemented.
  • There needs to be a full party to play with. That means three playable characters need to have a full set of animations for moving around, and for battle. Thus far, no playable characters have more than a handful of frames. Ridley, the game’s main character, will be one of the party members in the preview build. I haven’t decided yet who the other two will be. Ideally, they should bring a good balance to the team, because the player’s customization options for them are going to be super-limited compared to the finished game.
  • There needs to be a few different pieces of music, though they don’t have to be 100% finished. Most needed are: the dungeon’s theme, a battle theme, and a victory theme. These three all exist in varying states, but I don’t think the dungeon theme or battle theme are ready even for the preview build.
  • Items and equipment need to be implemented. It won’t be much fun to explore if there isn’t anything to find as a reward.
  • The playable character’s battle sprites need attachment points for their weapon sprites. The basic code for attaching sprites to each other has existed in the code for some time now, but there’s currently no way to place these attachment points in As2Tool’s sprite editor.
  • The status menu needs to be up and running. Everything in the status menu needn’t be functional, but the basic ability to check your party’s current health and inventory are a must. The actual status page showing each character’s detailed stats is likely to be a placeholder for now, though.
  • I need to continue working on the scripting engine so that I can not only add interactive objects to a room, but also play out said interactions through dialog and cut scenes.
  • Said cut scenes need to be written. There should be a few as the player progresses, letting the preview build’s little side story play out. This will give players a chance to get a feel for the game’s storytelling style.
  • There needs to be some sort of title screen to greet the player when starting the game.
  • There also needs to be a loading screen at startup. Right now, the game window remains invisible until its initial resources are in place, which takes a few seconds and may confuse players.
  • There needs to be a game over screen, and a way for the player to carry on without having to start all over from the beginning.

Another Star 2 screenshot

Pictured: every single battle in the game right now. Every. Single. One.

In the interest of getting this preview build out the door, there are other tasks that are needed for the final game that, maybe, just maybe, aren’t that important yet. Some of these include:

  • Magic. It may not be implemented in the preview build. Items and magic both use scripting to function, so they’re quite similar, but magic needs additional visual functions whereas most items can get by with a basic “use item” animation from the character and some text.
  • Likewise, The characters almost certainly will not have their skills implemented, even if I implement magic in time for the preview build.
  • PC games tend to have pretty large and complex option menus. A lot of this has to do with the wide variety of hardware you need to accommodate. I may put off programming this for now.
  • Difficulty levels will absolutely be in the final game. However, you might not be able to select your difficulty level in this preview build because that would require having a working options menu.
  • It would be nice to have a town in the demo so that you can buy supplies. Maybe the preview build even starts in the town and then you leave for the dungeon using an option in the town menu? However, while the town itself would be very easy to script, I’d have to set the game up to handle said script, so I’ll likely put that off. You might get a merchant somewhere at the beginning of the dungeon instead.
  • Another Star 2 has a new system planned for its leveling-up mechanic. It takes more work than just telling the player what stats got raised, though. For this preview build I may just give the character some more HP and call it a day. Your other stats are not quite as important in Another Star 2 as they were in Another Star; for a single dungeon, just improving your characters with stronger equipment found along the way should be enough to feel like you’re making progress.
  • The game’s overworld is already functional as past dev logs have shown, but there’s not really a reason to use it for this preview build. And while the mini-dungeon used here will almost certainly be in the game, I haven’t even decided its position in the world anyway.
  • You may or may not be able to save your game.

The goal here is to have this preview build out sooner rather than later. My aim is to have it up and running by the end of the month, but more likely it’ll be well into August. A lot of this also depends on how much time I have to devote to the project. Depending on how real life plays out, Another Star 2 may have to set on the backburner for a bit. In any case, I’ll continue to post on my progress and give insights into Another Star 2’s mechanics and development as I do my best to press forward.

Another Star 2 Dev Log #16: “Welcome To Our Town!”

The original Another Star’s limitations and theme of minimalism led to a lot of interesting decisions that defined it as a game. Some results were positive, such as the unique battle system. Others not so much so, like the strict tile limit for the graphics in a 20 hour RPG.

Another Star screenshot

A common sight in the first game.

Villages and towns in the first Another Star were one of the more curious outcomes. They were completely menu-driven. You would walk into a location, get a description of the place, and then select where you wanted to go. Hunting down NPCs for flavor text was replaced with the “news” option in the menu that allowed you to get a bit of backstory, some indication of where to go and what to do, and even some gameplay tips and pointers. The menu-driven towns were a direct result of the tile limit; I couldn’t afford to use up tiles to create a bunch of NPC graphics or furniture. However, it also fit pretty snugly with the game’s theme of minimalism. Locations had been reduced to their most essential base elements, streamlining the entire experience. It was a solution even used by some other games at the time. (I’m reminded of my father playing Sid Meier’s Pirates! on the Commodore 64 when I was a kid.)

Player reactions to the towns in Another Star are possibly among the most divisive issues I come across in the game’s feedback. There are people who absolutely love the classic RPG town experience, and they live to seek out each and every NPC to hear what they have to say, no matter how mundane. For them, Another Star’s town menus were a major let-down. Others quite enjoyed the reduced “drive-thru” town experience. It was easy in Another Star to jump into a town, sell off your loot, rest, buy a couple slots worth of healing dust, and then jump right back out again, all without disrupting the game’s larger flow.

But the menu-driven towns also had a wider, most curious side effect. Because I didn’t have to make any maps for them, it was very easy for me to add a complete town to the game. Very, very easy. As a result, Another Star has maybe a hundred individual towns, cities, and villages spread across its world. The starting area alone has a good twelve menu-driven locations you can visit (only two of which are hidden). Furthermore, because of the lack of maps or visible NPCs, each location could be as big or as small as it needed to be. Instead of a vast, sprawling metropolis of a dozen people aimlessly shambling back and forth down a single street, I could just say there were tens of thousands of people and be done with it. Because we never see them directly, from the game’s own descriptions the world of Another Star can be assumed to have a semi-realistic population count for its size and technology level. This affected the game and its story more than I think people realize.

However, there were things lost in the trade-off. All these towns were reduced to flavor text. You could tell a location’s size by the relative number of huts it had on the overworld, but that was really all you actually saw of it. Every place was varied and unique, but you could only read about them and imagine what they must look like. In such a visual medium as video games, that’s kind of disappointing.

It’s now getting close to the time for me to begin properly implementing villages and towns in the sequel, so I had to start really thinking about how I wanted them to work. Like with so many other aspects of the game, I decided that a simple mockup would be the best way to plan this.

Another Star 2 location mockup

Tile limit? What tile limit?

Another Star 2, even if it doesn’t end up being a direct sequel to Another Star, will at the very least be a spiritual follow-up to that game. I want this game to continue the first game’s tradition of numerous and varied locations, set in a world that has a semi-realistic population count. Menu-driven towns are the best way I can think of to achieve that in a simple top-down 2d tile-based game. Bringing the town menus back achieves both that, and, by building on the original game’s menu system, allows the game to feel more like a proper, connected sequel. (Some games, especially modern RPGs starting from the PlayStation era, accomplish much the same thing by roping off your exploration to just a small section of a town or city, but that usually feels arbitrary to me and I didn’t want to go that route.)

The first thing that needed to change was that we needed to see where we were. Adding a big graphic hits that nail right on the head. Just by looking at the mockup screen, without reading anything, you can tell the player is in a small-ish rural village. The power poles indicate that, even though they seem somewhat primitive from the thatch roofing, they have some level of advanced technology; a mix of medieval and modern that you’ll likely see a lot of in this game. Ideally each location would have its own, unique graphic, but it will all come down to how much work it is to do hundreds of them in a reasonable amount of time.

Another thing I did was set the background to a nice blue color instead of pitch black. It makes the location feel more inviting, I think, although I’m not sure if every location would have the same color, or if maybe it changes from place to place.

Finally, you’ll notice that the player character is talking about what they’ve come across. In Another Star, locations were described in the third person by a disembodied narrator. Another Star 2 is meant to be a more visual, active game, so I wanted to reduce the use of a narrator in places where I could instead show something, or have the characters themselves directly express something. Ideally, when you arrive at a location, you’ll hear from one of the characters instead of reading about how “Tachi did this” or “Tachi saw that”.

Another Star 2 location mockup

What will Ridley do?

The menu itself hasn’t changed much, other than the fact the character now gives a short description of each location when you highlight it. Before you had to guess at the meaning of new or unique options. I have mixed feelings about how much real estate the menu is taking up in this mockup, but at least the player would have already seen the full graphic at this point. The “news” option returns, although I may spice it up a bit—more on that another time, though. The other options, “shop”, “tavern”, and “leave” should be likewise familiar.

However, there’s one unusual option among them that’s not a carryover from the first game: “town square”. Players of the first game may initially think this is the game’s version of the clan chief mechanic, but it’s not. If you were to select it, you’d get something like this:

Another Star 2 screenshot

Actual in-game screenshot.

A small area of the village you can run around. You can’t randomly barge into people’s homes and steal their stuff as they compliment your heroics, and it’s only a very small portion of the village, so in a lot of ways I suppose it’s very much like the alternate solution I discussed earlier. However, not every location has a town square. This is a unique feature to this particular village. Other locations may have their own unique locations.

They aren’t meant to replace the “news” option in the town menu. Instead they are primarily planned for story purposes. These would usually be places you have to go in order to progress either the main story or a side quest, so anything NPCs have to say in these places would likely be tied directly to the side quest instead of the more general advice and dialog of the news option. (Also, other reasons, but again, I don’t want to discuss that until I’m closer to implementing and playtesting it.) This isn’t really meant to be a “best of both worlds” solution, because I don’t think people missing classic RPG towns will be fully satisfied with this. However, it should add a little flavor and uniqueness to each location, and it gives a place for story scenes within a location to play out. (In the first game they were usually narrated, which tended to be sort of tacky.)

Another Star 2 screenshot

I can import images into the game to preview them. Helps see what works in mockups like this.

Perhaps every location will have a least one of these unique explorable areas? I don’t know yet. I’m still working to get my tools set up so that I can generate a lot of good content very quickly. How many of these areas get added depends entirely on how much trouble they are to get up and running.

Another Star Dev Log #15: Points of Interest

One of the most memorable features of Another Star was its secrets. You had to keep an eye open and scour the world in search of hidden areas and secret passages, searching every corner in the hopes of finding a good reward. The game took a lot of inspiration from the original NES/Famicom Legend of Zelda in this regard. Though that game was so simple, there was always an excitement in never knowing just what you might find.

Likewise, almost everyone who has played Another Star absolutely loved looking for secrets. It’s often mentioned in reviews, and it helped the game to forge its own identity.

But there was also a small minority of players that didn’t care for it. While there were usually obvious tells to guide players to a secret area—a lone group of trees on the overworld here that warps you to an area full of treasure, or a strange and narrow corridor there that seems to be a dead end but really leads you through the wall—some were not so obvious, especially when the rewards were very good. This meant that some players felt like they had to trek over every tile and bump into every solid object just to make sure they didn’t miss anything.

It’s impossible to please everybody, so it’s easy to ignore such criticism by deciding that this style of game is simply not for them. Indeed, sometimes you have to accept that you can’t make the perfect game for everyone to love equally. But, like all the responses to the game, I made sure to take note of it. Over time I continued to digest the complaint and, almost by accident, I think I stumbled on a sort of solution, at least in the case of the overworld.

Another Star game footage

Wait, what was that? Was this here before?…

In Another Star 2, locations on the overworld are sprites instead of being part of the tilemap. In the game’s code, they’re referred to as “pois”, short for “points of interest”. I mentioned them in my last dev log here. They spawn as they come into view of the screen, and then despawn once they’re a little ways out of view.

This was originally going to be a way to get around tile limitations, because having lots of unique locations would eat up a lot of source tiles even when they weren’t visible on-screen. But even after I loosened restrictions I went ahead and kept this implementation. As I was programming it into the game, I started to realize that, since the locations are sprites, they don’t always have to be there, even when they’re within the screen’s view. Hidden areas can wait until the player gets much closer, and then they can suddenly pop into existence. This allows for the thrill of discovery without having to physically comb over literally every single tile. And, once revealed, they can stay in their “discovered” state so that the player can find them again easily if they need to come back for some reason.

I’ve been using simple caves as the early test pieces for this concept, since there’s a lot of mountains in the player’s starting area, and caves are a quintessential RPG staple anyway. This meant I needed a cave tileset, of course, so I went about whipping one up.

Old cave tileset

An old cave tileset from a game idea that I never did anything with.

One thing that 8-bit games tended to rely on, especially with the super-limited palettes of the NES/Famicom and the later Game Boy Color, was to use separate color palettes for walls and floors. This made it easy to tell what you could walk through and what you couldn’t, and it became a distinctive artistic feature for those consoles. Originally the walls and floor of the caves were going to be the same color, like in the old tileset pictured, but it looked kind of boring. So I made the walls gray and the floors brown. Of course, each individual cave can have its own palette, so there will likely be lots of color variations as you explore the world.

Another Star screenshot

First step is getting the basic walls and floors to look okay.

I kind of wanted the transition between walls and floors to be more natural, more like a real-life cave than some artificial tunnel, but it would have required a lot more tiles, and I’m not sure how well it mixed with the game’s art style. (I want the tile grid to be obvious, but not too obvious, if that makes any sense.)

Another Star screenshot

With lots of debris and other little touches added for interest.

The brown of the floor is the “transparent background” color, which lets me do neat tricks like have tiles that appear “above” character sprites without using multiple layers like a 16-bit or modern game would. Master System games absolutely loved to do this all over the place. Granted, it means those “above character” tiles can’t have any little bumps or stones in the part that’s the floor, because anything not the background color will appear above the character sprite, ruining the effect.

Another Star close-up screenshot

“Look! This wall is in front of me! No, really!”

It also sort of breaks down wherever there’s a shadow meeting a bottom wall, because the color of the shadow isn’t the background color. Thus, it appears above the character sprite. This can be partially hidden by the fact each 8×8 pixel corner of the sprite can independently be set above or below, just as on the Master System, but I can’t make it go completely away unless I make the walls perfect rectangles. The effect was too much fun and too iconic to loose altogether, so you’ll have to just ignore where it breaks. Old games had to make a lot of these very same trade offs, so I don’t feel too bad.

Another Star close-up screenshot

“Pay no attention to that tile in front of the curtain!”

Speaking of which, caves in RPGs tend to be… well, boring. They’re usually filler, they’re usually very samey from game to game, and they’re almost always a repetitive grind. The original Another Star was certainly no exception in this. It’s a shame, too, because in real-life caves are pretty cool. They feel so foreign to us surface-dwellers; at the same time wondrous and imposing. I’d like to try and do better; to capture a little bit of that feeling.

One way is by making caves some of the more treacherous areas of the game to chance upon. Exploring them might be a bit of a gamble when you first stumble upon them. But I’m not quite ready to talk about the ways that the game balances area difficulty yet, so I’ll leave that for another day.

The other big factor is lighting. 8-bit games were very limited in this regard. They couldn’t use layering to hide parts of the screen behind semi-transparent circles like later consoles, emulating the area of a light’s effect, and real-time GPU-driven 3d per-pixel lighting is of course right on out. Pretty much everything has to be evenly applied to the entire screen because it’s all the same palette. But it doesn’t really have to be anything fancy in this case, I don’t think.

You see, you’ll have some caves that are brightly lit (never mind where the light comes from; that’s just how caves work in video games). These will probably not be too much more dangerous than any other area you might discover. But then you’ll have dimly lit caves that have a darker color palette. They’ll contain more difficult foes, but also more desirable treasures.

And then you’ll have this…

Another Star screenshot

I think I’ll just curl up into a ball right here.

Pitch black caves where the walls are only barely visible. Sure, you might be able to see those walls, but you can’t see what’s hiding on the floor! There’s liable to be spikes or instant-death pits scattered about that maybe you normally can’t walk into, but with no lighting they’re the same color as the floor. Battles could be compounded by having your party unable to see the enemy, lowering their hit rate. And maybe even the game won’t even show you the enemy you’re fighting. Or tell you what they are.

You’ll no doubt need to have some sort of torch or lantern to explore these darkest of caves, moving them up a notch from “dark” to “dim” so you can see what you’re doing. And maybe there will be some of these caves with really good loot that are worth the risk to try and venture into early, even without something to light the way? As a game designer, I can’t wait to explore the possibilities.

And I know what you’re probably thinking: I’ll have to make sure that said lighting isn’t too much of a hassle to stock up on and use. Lantern oil that only lasts a couple minutes before having to be restored isn’t much fun. Likely I’ll end up having your torch/lantern/whatever last until you return to the overworld. Could even have some cheap ability or early item that won’t run out and that only lights the screen for a moment, allowing you a glimpse your surroundings just long enough to make a little progress before stopping to use it again.

Another Star 2 Dev Log #14: A Scripting Language

Almost everything in the original Another Star was hard coded, other than the layout of the map itself. Every item, every enemy, and every scene was entered as lines of C# code. Even the layout of some of the tile graphics I manually typed in. For many things, this actually wasn’t too much of a bother. Typing up all the enemies and their stats could be a little annoying because the C-derived family of languages tends to be so verbose, but it’s not too different than creating a parsable data file.

Scene scripting, on the other hand, was an absolute nightmare of a chore. Another Star was a very simple game. Other than the player, characters couldn’t move and were limited to “teleporting” around to room if the story needed them to be somewhere, and they always faced down with no alternate sprites for the other cardinal directions. Most of the story was given using raw text and nothing else. And yet, despite how little really needed to be done, it was still such a pain every time I had to write a new scene to advance the plot.

Another Star source code

Code for an early scene in Another Star.

Writing a story in a programming language just feels unnatural to me. Remembering to slap a semicolon on the end of every line, no matter how short, or having to reach for the parenthesis and curly bracket keys all the time. It may seem silly, but it really does disrupt my thought flow. I suppose you could say it puts me in a “programming” state of mind for problem solving, instead of a creative one for coming up with interesting scenarios and enjoyable dialog.

Worst of all, if you look over the code you’ll probably notice another, even bigger issue: none of the actual dialog is in there! The localized dialog is another of the small handful of things that’s not compiled into the code. It’s all off in a plain text file so that it could be possible to translate the game into other languages. So whenever I wrote a scene in Another Star, I’d have to constantly go back and forth between the code file and the dialog text file. Countless numbers of times I’d mismatch a line, or forget to remove a cut line no longer there, or just leave an important line out by accident altogether. Some of these made it all the way into the original release without being caught.

Another Star localized text

Speaking of which, the all-caps dialog didn’t help with catching typos.

For Another Star 2, I wanted to avoid having to go through all that again.

Now, there’s a lot of scripting languages out there that I could have just downloaded a library for and dropped into my project, but the vast majority of them have the C-style syntax I was trying to get away from, or just throw weird characters all over the place, like LISP’s unsettling infatuation with parentheses. I wanted something that felt a little more like natural English and didn’t have me reaching all over the keyboard just to do simple things. And I honestly didn’t need the raw power of most of these languages anyway. 95% of what I need to do is just pop a dialog box up on the screen. A simple language without a lot of bells and whistles would be just fine.

Another Star 2 scripting example

A test draft of an early scene in Another Star 2.

After a lot of thought and a couple weeks of work I managed to put together a simple command-driven scripting language with support for functions and if-then-else blocks for branching. It could still use some tweaking for sure, but already it feels a lot more like writing a novel than writing a game engine. Writing a test scene was a lot more fun than frustrating, even as I was working out some of the kinks in the language’s syntax.

And see how all the actual dialog can be easily included in the script itself. The script is compiled to bytecode with a custom compiler so that the game doesn’t have to parse it on-the-fly, and this compiler outputs two files: the script bytecode goes to one file, and all the localized text goes to a separate text file to support possible translations in the future. You’ll notice that each line of dialog is indexed, so that moving things around in the code won’t completely mess up existing translations just to do minor fixes. I’m not wild about having to number all the lines out like that, but it beats having to manually track them in another file.

I’ve been careful to document how the language works and what all the commands do so that everything is ironed out and I won’t forget little details like what each command’s compiled byte code means. But maybe I got a little carried away on that front…

Another Star 2 scripting documentation

I’ve paid for released products that aren’t this well documented…

The first successful test for running the script in the game was to lock the player’s controls for a couple seconds and then play a song, but that’s kind of hard to show in a picture, so instead I used it to place this little lookout tower on the overworld.

Another Star 2 screenshot

You can walk over it to enter, but it doesn’t take you to the right place yet.

That probably seems like a weird thing to use scripting for, instead of just slapping it there in the room editor, but I promise it will make more sense later.

Another Star 2 Dev Log #13: The Unfinished Overworld

Lately, I’ve been spending a lot of time working on the graphics for the game’s overworld. Yes, yes, I know I keep saying I’m going to do the scripting next, but I wanted something to test the scripting on. Besides, scripts by themselves don’t make for very interesting pictures that you can post online to get people excited.

Another Star 2 mockup

As you’ll recall, here is the original concept mockup for the overworld.

Like with everything else in Another Star 2, it was important to me that just looking at the overworld should make you really want to play the game. I wanted the graphics not only to be bright and inviting, I wanted them to have a consistent feel, with a standardized scale—even if that scale wasn’t remotely realistic. I wanted the overworld to look big, so I went the Chrono Trigger route and made the player character small. And I created huge, detailed mountains pretty early on, and tried to make everything else fit around them. They’re bigger mountains than would really be feasible in the amount of VRAM the pretend console system supposedly has, but they came out too good to throw away!

Another Star 2 screenshot

One of the first actual screenshots from the overworld.

But there was a lot I wanted to change from the mockup. I wasn’t happy with the trees, and I also wanted multiple types of forests. I thought it would be neat if broadleaf forests dominated the warmer areas near this world’s equator, while conifers begin to dominate as you get closer to the poles. By arranging the conifers in columns, I was able to add an entire forest type to the tileset while only needing three unique tiles. Getting the scale right took some trial and error. I like the original conifer forest tiles shown above, but they just didn’t fit in well with everything else. I also lightened the darkest green of the palette, to make it more obvious you can walk over the forest tiles. I really like the touch of blue it added.

Another Star 2 screenshot

I also started to tweak the roads so that they weren’t so blocky.

Another thing I didn’t like about the original mockup is the coastline. I made it pretty plain because I couldn’t get a beach that I liked, so I just sort of did a callback to the first game’s rounded coastlines. Coasts like that would have required less tiles, too. But since I already threw virtually all the game’s hard technical limits out, I didn’t really have to care, and so I experimented until I came up with some nice cliffs.

Another Star 2 screenshot

The coastline can get really jagged in the far north.

Rivers were another struggle. I didn’t want to just reuse the ocean. I wanted real rivers this time! I don’t have any screenshots of my early attempts, but the early rivers were all a full tile wide so that I wouldn’t need unique tiles for both snow and grass and whatever else there might be for the river to plow through. But it all came out so blocky that it just wasn’t working, especially with how organic everything else was starting to look. I finally gave in and made them more similar to the dirt roads. Suddenly, the ability to snake the rivers all over the place really began to sell it.

Another Star 2 screenshot

Like the first game, you can expect to see plenty of rivers.

I also created proper beaches for the variety. It took eight frames to make the surf look right, pretty high for an 8-bit title, but I think it’s worth stretching the norm in this case.

Another Star 2 gif

If you leave Ridley long enough, she’ll do a little dance.

The tileset still needs quite a bit of work. For example, the ocean water looks really nice in stills, but it’s just too busy in motion. Too much pixel noise with everything moving around, detracting from the animation of the coastline. That’ll have to be tweaked. I was also trying to avoid having to do inner diagonals on the beaches. For a game like this, I like the nostalgic feel when certain tiles don’t line up quite right and you can clearly see the grid in spots. But the beach surf just doesn’t look right with all those interruptions in the shoreline.

Yet overall, I am quite pleased with how the overworld is turning out.

Another Star 2 overworld tileset

Here’s the tileset thus far, without aspect ratio correction.

I am also starting to run out of tiles to work with. The way tilesets are stored currently allows for up to a whopping 65,535 individual tiles, but the current room format only allows the first 256 tiles to be properly placed in the grid. The lower 256 tiles shown above are used exclusively for animated frames. 256 tiles is more than enough tiles for what I really should need in a game of this style, but the wide variety I’m trying to achieve on the overworld does demand a lot of graphics. That said, I’m not too worried about it, since almost all the needed terrain types have been implemented. I can always tweak the format later as need be, I suppose.

You’ll notice that there are no cities or villages or caves or anything like that in the tileset. All locations will be purely sprite-based objects, which is where scripting starts to come in to play. I’ll have to start working on that soon, but in the meantime, here’s a video preview of walking about the unfinished overworld. Enjoy!

Another Star 2 Dev Log #12: FM Synthesis

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

Another Star 2 in-game footage of doors opening and closing.

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.

FM Pipe Organ editor screenshot

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.

FM Pipe Organ editor screenshot

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.

FM Pipe Organ editor screenshot

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

FM Pipe Organ editor screenshot

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.

And now I really do need to get to work on that scripting engine!