Monthly Archives: January 2021

Another Star 2 Dev Log #28: Toying With the Enemy

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.

Another Star 2 Dev Log #27: The Full Arsenal

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)

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.