While incomplete, this part of the world is where your adventure begins. The lookout tower is where you take your first steps in the game.

From your starting point, you can begin to fan out into the wider world, but as you continue along the road, you’ll immediately stumble upon a little pond that flickers into being with the sound of a chime. This is the game’s first “hidden” area, purposefully placed in plain sight so that you can hardly miss it.

I’ve talked about these before in past dev logs: places that aren’t visible on the overworld until you get closer to them. This pond quickly teaches the player to expect them, and it’s only the first of many you will stumble upon.

Now, those of you who have played Another Star will know that there were only 2 or 3 NPC types that I reused all throughout the entire game. Yeah, this game is not that game. I want the world of this game to really come to life. You know how in most RPGs, you can easily spot the important characters by whether they have face sprites for dialog? I wanted to change player’s expectations of that right off the bat.

Every NPC is supposed to be an adventure in their own right. They have personalities and, in my opinion, are just plain fun to watch. Notice how the map sprite even blinks in unison with their face sprite! A small detail, but I’m proud of it. The flip side to this is that there are going to be so many different NPCs that I have to remind myself to move on, even if they aren’t perfect. A number of them will likely get tweaks and slight redesigns as I go on, but I’m forcing myself to finish each NPC and then move on. There’s just me. I can’t spend all day making every encounter perfect.

Most areas have their own little story or history. Some even have a narrative that plays out. Often they’ll loosely connect to the game’s central plot in some way, but even they are likely to be be self-contained. This particular area, you learn, is a fishing hole that is a local favorite. The characters here even make it clear that you’re supposed to explore in order to find more cool stuff like this.

Of course, just like the first game, the main thing you’re looking for in places like this is loot! This game even includes a nifty feature lacking in the first game, where if you don’t have enough room for an item the character will leave the chest open just a crack instead of closing it back up all the way so that you’ll know you’ve already searched it.

Not every NPC is completely unique. I don’t have that much time! But even repeated NPCs are made a little less noticeable by the fact that various NPC designs include a number of variations. These scouts of the Pioneer Alliance come in multiple flavors. You should keep an eye out for them, by the way. They have helpful advice about adventuring and can clue you in to the game’s mechanics.

This one makes it clear that, like the first game, sub areas have more difficult enemies than the overworld. In fact, in this game, the enemies in areas like this are much tougher. When you first encounter this area at level one you are likely going to have to play smart or outright ignore some battles in order to survive to reach the goodie chest at the end.

Even then, though, the game further uses this area to showcase a few anti-frustration mechanics that encourage you to press your luck instead of discouraging you from exploring. But that’s best left for another entry.

You really never know what you’ll find in this game.

Generic encounters make up the bulk of play time in most RPGs, and Another Star 2 is certainly no exception. These battles can be dull padding if the developer is not careful. The original Another Star addressed this by speeding them up with its omni-battle system. Most of the strategy in battle was deciding which elemental attacks to use so that you could take out the biggest or most annoying threats first. Still, it’s easy for battles to feel samey with enemies becoming no more than the same thing but with different graphics. Another Star was by no means innocent of this.

Another Star 2 takes a slightly different route than its predecessor. Battles are still meant to be fast paced and not drag on past their welcome, but without the omni-battle system each character manually choose their target and a so lot of the first game’s design decisions are no longer applicable. And even as quickly as the battles play out, they just aren’t as fast. To make up for this I want to make sure that each enemy feels unique and gives players reasons to think about how they will approach them.

Take the humble Toad, for example. This is a very early game enemy, though one players will likely struggle with for their first few levels of progress because of the Toad’s relative power compared to the player’s initial strength.

Now, like all real-life amphibians, you can see that Toads have heavily armored skin on their backs. (Of course it’s true. Why would I make such a thing up?) This is a good demonstration of one of the game’s design philosophies: you should be able to gather clues about an enemy just by looking at their design. Sure, there are enemies that will purposefully defy your expectations to keep you on your toes, but observing new enemies is usually your first step to determining how best to confront them.

I also want to make sure that’s there’s not necessarily just one strategy to defeat an enemy. Again, the Toad is an excellent example. As I noted, Toads have natural armor. An obvious approach is to switch to a piercing weapon. As in the first game, piercing weapons ignore armor and deal damage directly to a target’s natural defense. Toads are squishy beneath all that armor, so you can easily deal a lot of damage.

However, that’s far from the only strategy. See, there’s a trick to these Toads in that you can use what would normally be an advantage to their disadvantage. If you think about it, you may note that many amphibians survive the cold winters by burying themselves in loose, wet soil and hibernating. Thus, as you might suspect, Toads are immune to ice damage. But this is a two-edged sword. Have you figured it out?

If you hit a Toad with an ice attack, you won’t do any damage, but you will put them into a deep sleep. While they’re in this state, they won’t wake up, even if you attack them! You can use this to your advantage by putting them into hibernation and then laying the smack down, or just ignore them and focus on any other enemies while the Toad is no longer a threat.

There’s certainly not an endless array of strategies. Another Star 2 is by no means a game steeped in emergent gameplay, and I can assure you that the developer has not thought of everything. But if you experiment with your abilities and think about how an enemy behaves and reacts, you’ll likely to be rewarded. Items, skills, and magic can take you a long way in battle if you put some thought into how best to use them. The work I put into the game’s scripting engine is really paying off in that regard.

The standard go-to action for any RPG is the humble “attack” command. Sometimes it has other names, like “fight” or “strike”, but the meaning is the same: beat the crap out of your enemies with whatever happens to be in your hand. It’s the bread and butter of 99% of RPGs, western and eastern alike. Like the majority of games in its genre, Another Star 2 toys with the mechanics of the “attack” command, but it doesn’t fundamentally change it. Instead, it goes the tried-and-tested route of augmenting your standard attacks with supporting commands.

Here, at last, is the item interface in battle. Selecting “item” icon from the character command menu brings up a palette that contains any items in the party’s inventory that can be used in combat. I went back and forth on the design for this during the game’s development. At one point I was going to just have the game switch to the normal inventory screen but ended up deciding against it so that there’s not an abrupt change of interface. As in the first game, only items that can be used in battle will show up, so you don’t have to spend a bunch of time sorting through other junk to find what’s useful.

There are some limitations when it comes to items that you’ll have to be mindful of when you’re deciding what orders to assign to your characters. For one, two separate characters cannot use the same item in a given round. That may be a good reason to buy a second healing item just in case, even though each one has multiple uses before they’re consumed.

In the first game, using an item meant your party always went first. This was to counteract the fact that the “party leader” was the one who used the item, and so long as he wasn’t KOed the party leader was always Tachi, who was the slowest by far of your three party members. The fact that items guaranteed first move advantage added a layer of strategy to that game, and it also encouraged them to chance pressing their luck just one more round before healing, knowing that as long as the characters survived they would always be able to use Healing Dust to restore their HP before the enemy could act again. Even though party members now act on their own, I may end up reusing this idea so that using an item gives a character a significant boost to their order in battle. Just be warned that in this game, some enemies also have an inventory of items that they can use!

Items in Another Star had a wide range of effects, and that is equally true of the items in this game. They’re more than just a few healing items to get you by. Many items have unique effects and can prove especially useful against enemies. Because of this, it wasn’t really possible just to have a simple “heal this much” property for items, so the past week or so I spent implementing the scripting needed to let my imagination really run wild. I also wanted to make sure that I could easily add graphic effects for that extra level of polish using a very simple particle system. Here’s what the uncompiled code looks like for a healing item, for example:

function @Wafer1
	get $User from user
	get $Target from target	

	narp 0, "$B:Actor$ nibbles on a vanilla wafer."
	batanim $User "Use" and resume
	await $User "USE"

	sfx "_Heal1"
	rng? 10 to 15
	restore $Target hp by result
	
	epalette green lime
	psys "effects.sprite"
	emit "SmallSparkle" at (-10, -20) for 30
		pvel (0, -4)
	emit `` at (10, -20) for 30 after 5
		pvel (0, -4)
	emit `` at (0, -20) for 30 after 10
		pvel (0, -4)
			
	finish

Much of the scripting and code is easily carried over and reused for spells. (And originally, spells were just going to be another kind of item from the engine’s perspective.)

The spells in this game are planned to be more diverse than those of the first, with a wider range of spells than just your basic elemental attacks and generic buffs/debuffs. How they’re planned to work and interact with enemy scripting is likely to be the subject of the next dev log I write.

So there you have it, the item system in motion. Items and spells are a huge part of the game’s battle system, and it’s really cool to see them up and running. Now pretty much all the player’s options are on the table in the game’s current version. Whether it was wise to work on these features now like I have instead of churning out a few environments to explore is yet to be seen, but at least I’m making forward progress for a change.

A whole lot has changed in the world since my last dev log entry. I wanted this to be the year that I finally got this project back on track, but it seems life has other plans. My day job is in retail. When the world hunkered down to brace for the initial impact of Covid-19, I was not stuck at home in a lockdown with lots of spare time to advance my own personal projects. Instead I was working overtime, doing my best to unload trucks and push food to empty grocery shelves. And that daily responsibility only continued to eat into my free time as I moved up through two promotions and the extra work load of the American twin holidays of Thanksgiving and Christmas.

Still, I’ve managed to eke out a little progress these past months that I wanted to share today.

Around the time of my last dev entry, I took some time away from this project to dabble in some NES homebrew development. Though I grew up with the system in the 80s and early 90s, I’m not wild about the system’s graphical limitations. But here in the United States it’s the most widespread 8-bit video game console, and thus the easiest to produce content for if you want people to be able to run it on actual hardware. I decided that if I really wanted to develop for an 8-bit console with strict hardware limitations, I should make something original for a real one instead of shackling Another Star 2 to an imaginary one. Here’s a couple mockups I did of various ideas I had.

Eventually I began to toy with the NES’s 6502 to see what came of it. It can be hard to wrap your head around programming in assembly on a CPU that is limited to single byte values and only has three general purpose registers, but after a lot of effort I actually managed to get something up and running, even if it never grew into anything. In the process, I learned something important.

It is often observed that the shortest distance between two points is a straight line. With the NES and its 6502 I had so little space, memory, and power to work with that I had to force myself to simplify how things worked in order to get a result. Other times I had to realize that, even if a solution to a problem was awkward, if it already worked just fine I needed to leave it alone and move on because a more “streamlined” version would not only take more time to write, it would often require more space and precious CPU cycles.

There’s a lot of odd choices I made early on in Another Star’s 2 development. Many of them derive from the game’s stricter adherence to the original fake limitations of the game. However, I’ve had to tell myself to leave those decisions alone. They’ve already been implemented. They already work. It’s time to move on to the next thing. I can do it different in another game.

An excellent example of this is a feature that I’d been putting off for a long time. Whenever you change a character’s weapon in Another Star 2, I wanted the sprite to match. This works by giving each weapon its own unique set of sprites. The characters then have “attachment points” each frame to anchor the weapons to. But though the sprite data already contained a way to store the information for these attachment points, I’d never gotten around to implementing them in the sprite editor I made. For weeks, I went back and forth on how best to implement a way to drag and drop pieces, and thought in-depth about what interface buttons I would need to determine whether I wanted to select sprite pieces or attachment points, and so on.

But that’s too much work! No, I forced my way through and just assigned selection to a hot key and made placing and renaming attachment points a function of the editor’s existing right-click menu. Boom. Probably less than half a day of work and I had weapons up and running.

Same with per-frame event triggers. I wanted to know which frame of animation during an attack is where it “connects”, hitting the opponent. It wasn’t going to take long to program the editor to save the trigger name as a string to an existing string library in the sprite file and then cache the trigger names before each battle to check against—

No, no, no. That was going to take too long. Instead I went with an old idea I had and used the 32-bit integer value intended to store the index of the trigger name as the trigger itself in the form of a four character ASCII string. “HIT ” becomes a four byte sequence that I can check as the hexadecimal value $00544948. It’s just as efficent since it’s still just comparing an integer to an integer, and I cut out the need to cache anything. I think it took me longer just now to explain how it works than to actually implement it.

It’s easy to get caught up in trying to do things “the right way”. There are obviously times where that’s important. But other times, you need to focus on just getting the thing done and moving on. I’d like to make other games one day, after all.

Did you ever have to make up your mind? Pick up on one thing and leave the other behind? Did you ever have to finally decide? Well, that’s how the song goes, anyway.

It can be a difficult thing, though, choosing one path out of many. This indecisiveness can also delay or even kill a project. In my experience, one of the biggest sources of eternal “feature creep” is the failure to draw a line in the sand. “This much and no further.” It’s so hard because doing so means closing out so many more possibilities! So many great things that could have been will now never be!

Here’s a big case in point. This is the palette that I used for Another Star:

Each color is an 8-bit RRRGGGBB value, scaled to NTSC tolerances (so white is less than 100% and black is more than 0%). These sixteen colors went a long way, but they didn’t happen overnight. Even with just sixteen colors to decide upon, and a mere 256 possible values to select from, I went back and forth a lot during the game’s development. I didn’t add the mid-gray color until the game was nearly complete!

However, changing the palette for that game wasn’t a big deal. All the game’s graphics fit into a single image—just 128×128 pixels in the game’s initial release, raised to 512×512 with the new graphics used in the Steam release. Replaced a color? No big deal! I could just edit around it in a few minutes or so.

This game is different, though. The main player character’s sprite sheet alone is about half as big as the first game’s entire graphics set. And that’s just her area map graphics! It doesn’t count her in-battle graphics. And NPCs thus far currently have 128×256 pixel sprite sheets. Notice the plural. “Sheets”. Each one has their own, so changing a single color means I have to edit multiple files, a task that only gets more difficult as time goes on.

A minor change isn’t a big deal, mind you. If I tweak a color in the palette, the colors are stored in a special palette file and that change is applied at runtime by the game’s graphics engine. The sprite sheets themselves don’t contain the colors when they’re saved for use in the game. But if I decide to remove the purple and make a green? Yeah, that’s a big deal. I have to go back to all the characters that used that purple and decide what to replace it with, which may not even be the same for every instance it appears. It means I have to rethink everything up to that point!

Now, this game is a little different from the first. The imaginary VGS console’s graphics are largely based on the Sega Master System, and like the Master System this game actually has access to two palettes, not just one. While the first game stuck with a single sixteen color palette for everything, one of the palettes in this game changes quite regularly based on the room or battle arena and such. However, since there’s only one palette for characters, outside of the special case of their in-battle graphics everyone has to share the same sixteen colors in the second palette (and for sprites, one of those sixteen is always transparent). As much as I hated it, the time came to make up my mind. I had to choose the sixteen color palette (really fifteen, remember) for all the characters in the game to share. I expected it would only take a few days, but I ended up agonizing over it for a good two weeks.

Here is the palette for Another Star 2:

Even now I’m not 100% happy with it, but here it is. This is what I’m using going forward. There will likely be a few tweaks here and there, but only that. Tweaks. No more rehauls. I’ll never be completely happy with it anyway, especially since the limited RRRGGGBB master palette lacks the exact colors I often want to use. But it’s nice and bright and I think the colors really pop, even if they’re a slight bit more saturated than I would like.

It’s strange how I started with the first game’s palette and toyed with it over time. At one point, I actually trashed the palette and went at it anew from scratch, only to end up coming back around to pretty much the exact same colors.

It’s not far from the basic choices of the first game, however I added a hint of blue to the grays to give them a nice cool quality and eventually ended up merging the light gray with the light blue and added an extra mid-tone gray. Most of the colors ended up getting a touch of blue, which does end up somewhat extreme since, with only two bits for blue, there’s only four levels for the blues to be. I toyed with the idea of sacrificing that extra gray or the bright purple for either a richer red (the red I have now is practically a pink) or for a light yellow-green for the greens and yellow to ramp up in to.

There are a lot of browns and grays in the palette, true, but I wanted to be able to represent a wider array of skin tones than we normally see. The midtone gray is likewise used to represent an ebony-skinned character. Earlier versions of the palette lacked a good tone for him and his color ramps clashed pretty badly as you might be able to see in some of the long past videos I posted. I could have just made his skin brown, but I’d rather he get his proper character design in his sprite form.

What’s interesting though is that as I finally nailed down the color palette with one hand I was gleefully opening up a can of worms with the other. On a whim, I decided to add two new “features” to the game engine. One is a minor change, the other is a major change.

The minor change is that characters now have a subpixel resolution to their position. That is, their actual position within a room can be “between” two pixels. This is not something foreign to 8-bit consoles. In Super Mario Bros. on the Famicom and NES Mario has a 1/16 subpixel position in order to tighten his handling and smooth out his acceleration and deceleration. However, it’s a super odd choice for an “8-bit” RPG like this, which is strange enough being a non-action RPG with movement not limited to a grid. Most games of the era didn’t bother, or else they used tricks like alternating each frame which axis got an extra pixel of movement when moving diagonally. I originally was doing the latter, but I ended having to implement different solutions to different areas where it was needed (diagonal movement vs. slower movement on the overworld, for example) and there was an ever-expanding bundle of extra code to deal with edge cases.

Going to subpixel movement made the handling feel pretty slick, especially when you’re using the thumb stick instead of a d-pad. I was unsure at first, but it actually simplified the flow of the code in the end so it’s likely here to stay. Characters have a whopping 120 subpixel resolution, which as the lowest common multiple of 2, 3, 4, 5, 6, and 8 gives a lot of granularity. (Adding 7 to the mix raises the multiple to a whopping 840, which does not fit into a byte.)

The other change seemed more innocent at first, but ended up being far more dramatic…

I decided to try giving the characters eight-directional facings just to see how it played. Only a very small handful of 8-bit (or even 16-bit games, for that matter) bothered doing this. The number of NES games that did it can probably be counted on two hands, if that many! Earthbound is the only RPG I’m aware of that used them in that era, and that’s an SNES game. It’s certainly stretching the aesthetic, and I’m not sure that I like the results. Not to mention it’s doubling the sprite graphics workload right out of the gate.

But I’ll be derned if it doesn’t look pretty in action.

This game has been in production off and on for some four years now with little to show for it. I have to stop adding things on a whim and decide what’s important. The scope of this game began big enough as it was, especially as a follow up to such a simple little RPG. I can’t allow it to continue growing and growing forever. As Derek Yu once pointed out, finishing things is a skill in and of itself, and one I’m admittedly not very good at. Eventually I have to draw that line in the sand. “This much and no further.”

Eventually…

My day job makes it difficult to set aside time to work on projects like this. I have to be careful to budget my time, or else I’ll end up getting a lot of work done for awhile but then quickly burn out. Still, over the past month or so I’ve managed to get about thirty minutes to an hour of progress a day. It doesn’t seem like much (and really, it isn’t) but it does add up after awhile, so long as I’m good about where I spend those precious minutes each day.

I’ve been messing around with the battle system for a long time now, and that makes sense. The battle system tends to be what really engages people when they play an RPG, and it’s where they’re going to end up spending a lot of their time. But a video game is more than the sum of its parts. A good RPG needs more than just a battle system. It needs a story to frame the battles you’re fighting and give you a reason to fight them. To that end, I’ve switched gears for now and am plowing ahead on changing the game’s scripting engine from mere partially-programmed ideas to a reality.

Previously, I’d mentioned wanting to make a “vertical slice” to show the game off, but I’ve never really used that method before. Instead, I’ve fallen back to the same work flow I used on the first Another Star: starting at the beginning and working my way to the end. The first cut scene is scripted and plays, with characters moving to their cues and going through their dialog. After so long, it’s really amazing to watch play out, especially since the last game’s scenes were so simple. I’m working hard to make sure that the game’s custom scripting language makes it easy to generate and tweak the content very quickly so that I can make the absolute most of my time.

One of the things that I’ve done during this process is move the character portraits up out of the dialog boxes. This allows room for a few more letters to be visible in each line. As you can see, the portraits aren’t static. The mouths flap, and when they’re not talking they even blink in sync with their sprites!

I also made the portraits bigger. Much bigger. I was inspired by looking at Shining Force II which had these huge, vibrant character portraits. I wanted the characters in this game to be able to be likewise endearing, even though there wouldn’t really be quite enough room in the system’s VRAM for portraits this big without sacrificing some of the area graphics. I’m not 100% committed to it yet, and the first few portraits are in need of tweaks, but I kind of like how they look so far. My only worry about the size is that they’re going to obscure what’s going on beyond them. The characters on screen have various actions that play out with their dialog, and I don’t want their portraits to always be in the way.

I’ll share more from these early areas of the game as I make progress. In the next dev blog, I plan to write about the often overlooked process of nailing things down to avoid working on them forever.

Wow, it’s been a long time! I guess I should clear out some of these cobwebs before I continue on. In any case, rest assured that I haven’t given up work on this project, although my current day job and a freelance project are taking up most of my free time. It’s hard to make progress when you feel drained all the time.

Now, in a previous entry I mentioned that I was seriously considering ditching the “omni-battle” system from the original Another Star and replacing it with a more traditional battle system where you can issue individual orders for each character. As those of you who follow me on Twitter should already know, I ended up implementing this change. Part of me is sad to see the omni-battle system go, but I don’t think this is the game for it. Maybe I’ll get to reuse and perfect it one day in another, smaller game.

In any case, you now tell each party member individually what they should do for a given round. You can only target one enemy normally, more like most players will expect. You’ll also notice a percentage displayed along with the targeted enemy. This is the hit chance, and it changes depending on the difference between the agility gap between the attacker and defender.

Note that if a combatant’s target is eliminated before they get the chance to attack it themselves, they don’t automatically select a new target. However, they don’t lose their turn altogether. Instead you’ll get a notice that they are deciding on a new target, and their turn will get pushed back to the end of the queue for the round. This should encourage you to be more tactical with your targeting decisions, while not punishing you too harshly for not micromanaging every single turn.

Another neat addition to the battle interface is that numbers now bounce into view more naturally, although it means that there are going to be far more sprites on screen than there should be. As it was I was already bending the rules, but the little damage boxes I was using before were kind of distracting and didn’t read very well. Yet another sacrifice for the sake of improved gameplay.

You’ll also notice something else really cool, and that’s the little flames that surround the characters as their turn comes up. These are called spirit points and they work mostly like magic points in other RPGs. Gone is the hit point based magic casting of the first game. You spend spirit points to cast spells now. Spent spirit points appear as dimmed flames. Spirit points are difficult to recover, so you’ll want to manage them wisely, especially in the early portions of the game.

That covers most of the changes that have been implemented over the past year or so. Not very much progress, sadly, but hopefully it won’t be nearly as long until the next dev log.

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.

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.

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!

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!