Another Star 2 Dev Log #21: Adventures With Friends

Another Star 2 footage

Sally forth!

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

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

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

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

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

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

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

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

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

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

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

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

2 thoughts on “Another Star 2 Dev Log #21: Adventures With Friends

  1. If you ask me, the way the characters follow you looks a bit unnatural when going diagonal. But I guess that’s just work in progress.

    Also, why the main character’s sprite in battle so far “down”?

    As for making party composition matter – it definitely needs to be implemented well. Often games don’t make it very clear THAT it matters by letting players win battles with a wrong setup too often early in the game. This often results in players feeling that the game in unbalanced and you will get complaints like “Game is too hard” and “There was a huge difficulty spike when I reached that dungeon”, because their favorite party was good for some places and bad for others.
    One game I know that solved this really well was Ys Seven. Here, monsters are often almost immune to damage, unless you use the right character and the game makes it quite visible by having very direct and visible feedback (damage display, sound that place, flinching of target) and you switch around character by single button press. It also has a very simple damage triangle rule, where you can usually tell which character to use just by looking at the enemy (e.g. archer against flying enemies).

    As for the omni-target system, going by the reviews I saw on your game, I think it wasn’t so well-received. Most people simply want the added strategy by having to select a target. Of course this only makes sense if you create good encounter sets. Select a targeting only makes sense if selecting a target matter. A simple example would be to combine an enemy takes deals high damage but dies in one hit, with an enemy that deals low damage, but needs three hits to die. In this sample, it is much better to target the enemy that deals high damage first. So the player will feel rewarded if he figures that out and loses less resources. If you just put 3 units of the same enemy type in an encounter set, then selecting a target is just a boring unnecessary step. An omni-target system isn’t bad by default, but I felt it didn’t necessary work out too well for Another Star. I could imagine it being good for a game that has the heroes fight automatically and you take more the role of “God” and add effects to the battle field that significantly render the outcome. Like say, you have a fire enemy that deals a lot of damage and a water enemy that deals less damage, then in an omni-target system the good strategy would be to add a field effect like “Attacks become water element”.

    Anyway I’m personally open for either as long as it feels like strategy matters.

  2. If you ask me, the way the characters follow you looks a bit unnatural when going diagonal. But I guess that’s just work in progress.

    It’s not just you; it’s a visual glitch. The characters switch between running and walking depending on how close they are to the player. However, when they hit the “sweet spot” they are supposed to follow at, they end up switching between the walking and running animations each frame, causing them to look weird. This will be fixed eventually.

    Also, why the main character’s sprite in battle so far “down”?

    When the game was sticking to pretend system limitations more closely, the bottom row of tiles wasn’t used in battle to save some room for more graphics in the character table. Now that I’m playing a little more loosely with the limitations, I decided to add the extra 8 pixels at the bottom of each character’s battle sprite. The main character’s sprite data is one of the ones that hasn’t been updated yet, so the sprite is placed 8 pixels too low.

    These are both things I really wanted to fix before showing any footage of the game, but I decided in the end that it was better to show something in-progress than wait until it was perfect and not post anything for months on end.

Leave a Reply

Your email address will not be published. Required fields are marked *