Menu

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.

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!

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!

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.

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!

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!

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.

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.

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.

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.

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.

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.

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.

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

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

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.

I’ve talked a lot about Another Star 2’s production and its gameplay mechanics, but so far I haven’t said very much about its story. Since RPGs as a genre are so narrative-driven, I suppose that’s a little strange. Today I’ll finally introduce the game’s setting. Small parts of what I’m going to share here I’ve touched on before elsewhere, but this is the first time I’ve really discussed the game’s story in any detail. Hopefully it sounds like something fun you’ll all want to experience and play through just as much as I want to create and share it.

Obvious disclaimer: story and details subject to change as the game’s production carries on towards release.

The events of Another Star took place on the planet Mathma, a world full of warring clans that struggled against one another in ever-shifting alliances, eager to increase their own power and glory no matter the cost. The story of Another Star 2, however, takes place on a brand new world called Byo. Byo is a world of magic, swords, and fantasy, but also a world of technology and gunpowder, a planet populated with civilizations at all sorts of levels of development. Numerous species coexist on Byo, though humans are the most populous by far.

Like most habitable planets, Byo is a world teeming with monsters. Those traveling are advised to take the normal precautions, to have their sword or firearm at the ready, and to stick close to the roads if they don’t want to run into too much trouble. But unlike Mathma, Byo is really quite peaceful. There is a stable balance of power between factions and, while armed struggle is not unknown, it has been generation since Byo has seen open warfare.

Here is Byo, the world you will explore and become a part of.

Byo may seem like a very Earth-like planet, but do not be fooled. It is no mere rock. Beneath its thin surface is a planet-sized mechanism of unknown purpose and provenance. Whatever advanced beings created this world are long gone, but a legion of synthetic custodians, widely assumed to be some manner of robots, now look after it deep below the surface. Whether these custodians were also created by the beings that created the planet itself, no one can say for sure. They rarely venture above ground, and even more rarely do they speak. Their only purpose, it seems, is to keep the planet’s core running.

The planet has two moons, Exo and Origin. Exo is the smaller of the two, a mundane oblong sphere that it likely a captured asteroid. Origin is the more exceptional of the two, just as mysterious as Byo itself. Origin is covered in thick clouds and absolutely nothing is known of its surface, if indeed there is one. Probe and manned craft alike dissolve almost instantly upon contact with the moon’s cloud cover. However, it seems that something must be active beneath the clouds. Occasionally, material drifts up from below, gathering in the moon’s rings. This material includes organic compounds, suggesting the possibility of life. The rings periodically eject their contents, leaving bits to tumble down to Byo. What doesn’t burn up in Byo’s atmosphere always seems to land in the same place, piling up in a toxic heap overgrown with enormous fungus. Perhaps Origin’s strange behavior is fundamentally tied to Byo’s operation somehow?

You should find stuff like this all about the game’s overworld.

Countless alien structures litter the landscape of Byo, exterior parts of the complex mechanisms below. They are a common sight, though their exact purpose can only be guessed at. What are they for? What do they do? Are they still functional?

Well, whatever this used to be, it’s a shop now.

For the most part, the people of Byo just don’t really care. All they know is that they’re a free source of electricity. You can easily plug into the planet’s power conduits where they come up to feed these structures, so it’s common for people to build up around these structures. The planet’s robot custodians still tend to these alien structures, maintaining them just enough to keep them from becoming completely overgrown. If they’re bothered by others siphoning off the planet’s power, they’ve yet to say or do anything about.

The people of Byo tend to build on top of those who came before—literally.

Byo’s modern history stretches back many thousands of years, with many different space-faring civilizations arriving to find this strange world, colonizing it and tweaking it to suit their needs, but never fully claiming it for their own. Thus it’s no surprise that it contains more recent ruins that clearly do not originate from the planet’s original creators. Sometimes younger, fledgling peoples take up residence in the fallen cities of more advanced civilizations that arrived before them, while other times very advanced civilizations may find a home by modernizing a more primitive ruin.

But Byo’s specific state as a lush planet of blue and green can be traced back to roughly ten thousand years ago. In that time, when few other civilizations had arrived, an extremely powerful human faction known as the Novar landed here and undertook its most extensive terraformation. The planet’s alien shell was covered in oceans, grass, mountains, and forests. They built a great many vast cities, full of skyscrapers built of glass and steel that reached up to the heavens. But, for some unknown reason, they suddenly left Byo, leaving only a tiny fraction of their kind behind. These remnants would become the ancestors of the humans now living on Byo.

The world of Another Star 2 is certainly one of many mysteries. However, these mysteries are about to unravel very quickly, and at a most inopportune time. Despite its long history of peace, in truth Byo is very much a powder keg just waiting for the right spark to set it off. Tensions on the surface of the planet are starting to pile up very quickly. Rifts between factions are starting to widen, and old wounds that never quite healed are in danger of being reopened. Moreover, a power most foul is growing desperate, as a certain event elsewhere in the galaxy has led to unexpected consequences.

In the midst of this looming tragedy about to unfold, a young woman in search of adventure begins to take her first steps into the wide world…

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.

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.

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

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:

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

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.

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…

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.

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.

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.

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!

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.

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.

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.

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.

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.

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!