Category Archives: Another Star 2

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

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

“BEE-DA-LEE-DA-LEEP!”

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!

Another Star 2 Dev Log #11: Getting Around

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.

Another Star 2 in-game footage of room transitions

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.

Another Star 2 Dev Log #10: The Battle Menu

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:

Another Star 2 battle command icon

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.

Another Star 2 battle command icon

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.

Another Star 2 battle command icon

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.

Another Star 2 battle command icon

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.

Another Star 2 battle command icon

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.

Another Star 2 battle command icon

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.

Another Star 2 Dev Log #9: The Battle Interface

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.

Another Star version 1 battle screenshot.

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.

Another Star version 3 battle screenshot.

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.

Phantasy Star screenshot.

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.

Another Star 2 mockup.

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:

Another Star 2 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:

Another Star 2 battle system screenshot.

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.

Another Star 2 battle menu mockup.

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?

Another Star 2 battle system footage.

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.