Postmortem 2 - Combat



Battle System

This was the very first spark that gave life to RATD. It all happened way back before last year's Harold Jam concluded. I'm a pretty good buddy of Mooglerampage, and the two of us have more or less created an unspoken testing pact with each other, so naturally I got to play his literally award winning entry, Harold Between Worlds, a couple weeks before the voting period began proper. HBW is a quality entry with a quality battle system all in its own right, but there was a specific game mechanic that got my head completely spinning with ideas.

HBW uses the Brave Turn system, where you can "hold" your turns for later use. It's a great system on its own and well utilized in this jam, but specifically HBW managed to do something with it that the Bravely series never did (to my knowledge). By taking the light path, you're given Summons of your party members, and if you hold your turns enough to the point where you can use all three summons at the same time, the game activates an even stronger super-summon that gives you an incredible boost in power.

And so immediately I hit Moogs' DMs to tell him how this mechanic made me want to make a full game with this battle system.


So, if you've played RATD (what are you doing here if you haven't?) you may have noticed that what I just described isn't really what ended up in the final game. That's because a different idea came to mind for me in between then and now, which I was enamoured enough with to throw it into the mix. A lot of anime attacks (and by extension, attacks I name for my own projects) have a sort of two-word naming convention. They have a prefix, a sort of descriptor of what makes the attack unique and cool, and a verb, the thing that the attack actually is. It feels extremely satisfying screaming "RUSHING FINISH", doesn't it?

So with that idea in mind, partially as a joke but partially as a resource for people, I made a "cool attack name generator" which was merely a chart with a list of prefixes and suffixes for you to mix and match into attack names. And then shortly after sharing this little chart, I realized "I can totally fit that into that battle system I wanted to make".

And so I got theorycrafting to make a battle system where you take two words and turn them into cool skills. Pretty soon I had generated a whole chart of flashy names to mix and match alongside their effects and even rough damage outputs. While making this, I had come to notice an interesting dilemma:

It's really hard to make unique skill effects.

I never had this problem with Axial because Axial is a very gimmicky game filled with EBS and Cooldowns and granular code-riddled gimmick attacks. A lot of RPG skills fall into two categories though: varying strength with proportionate costs, or additional effects. Sometimes a mix of both.

The problem with this system is that I couldn't make additional effects, because those all had to be tied to the Prefixes. Furthermore, I wanted to avoid cooldowns, and I'm horrible at managing MP costs, so I had to really make an important distinction between skills. Luckily, around the point I was losing sleep over this, a certain game popped into my library.

What. A. Masterpiece.

I will try to keep this relevant but I love Live-A-Live so much, please play it. Anyway, specifically, Live-A-Live's combat is grid-based, and there are no MP costs. So, how are skills balanced? RANGE! Every skill in Live-A-Live has a different hitbox and hits different enemies, so the skills you choose are very dependent on how you can line things up with your enemies. It was honestly extremely cool seeing how an ultra powerful mega-nuke attack could be balanced by only hitting a target 3 squares away diagonally from you, and it felt great to set up.

So, tying this back to RATD, I decided that I should go with range for my system too. Strong skills would have small hitboxes, and wide hitboxes could be weaker skills that hit more enemies and things like that. I immediately thought about server darling Trailblazer, a game that uses AOE circles as a major game mechanic, and so I was quick to hit up Jeff to ask him how he pulled off those hitbox shenanigans.


With the stage set, I knew that I was going to be making this in MZ, so I got to work trying to get familiar with the engine in hopes of improving my speed before the jam started. That's when I got hit by a pretty tricky revelation:

In this article about which plugins would be ported to MZ, I noticed that among those listed were a few of my personal favourites, but more importantly, a few that were essential to my plans for the battle system: Selection Control, and Area of Effect (two plugins that Jeff specifically cited as essential for his battle system). 

So, great, that was no longer an option. I needed to get creative.

But ironically, my creative solution ended up leading to simplicity: I'd bring in MP, but take some notes from how MP worked in my pervious projects, Re:Punch and Obsidian. So, I ended up creating a "tier" system where skills would cost up to 3 MP out of a pool of 4, with 1 additional MP cost available to be added by powerful Prefixes. Every turn you'd gain back 1 MP, but there was no "free" skill which meant the only way to get back more than you spend is by passing a turn.

And once again, I discovered this system was similar to another game I love: Endcycle Vs.

This game works very differently from RATD of course, being a real time grid battler, but the deck building mechanic was specifically helpful: each of your skills are infused with a sort of modifier. These modifiers can do things like changing elements, reversing a skill's effect, adding status effects, just about anything. So, I was able to take some notes, see how the game balanced these elements, and even appropriate and translate a couple that fit well into my own ecosystem. By the time I'd started taking notes from Endcycle, the system just about built itself, and I just needed to handle the technical stuff.

And it wasn't too hard actually!

I'll be talking more in depth about VisuStella in a later section, but ultimately they were the reason I was able to pull this system off. I needed to make a ton of skills, close to 300 just for this one jam, so I found a way of modulating it by creating a single unique action sequence for each Suffix, and a single unique animation for each Prefix. Every combination would merely be the combination of the AS with the animation. On top of that, thanks to Visustella's Skill Containers, I was able to construct a seamless system where opening the Prefix tab would list every available Suffix combination.

From there, the system sorta created itself, and it became a matter of copying all of the skills I had come up with in my spreadsheet and grafting them into the new system. Adding all of the skills into the game took around 5 hours, but it was completely worth it. Had I more time, I'd have thought of a better and less manual approach, but for a jam game, this did the trick.


Then my next problem revealed itself!

The thing about a good battle system is that you need to have stakes and present a challenge; otherwise, players won't explore your game's depth and simply mash the most effective strategy. So the game needed to be somewhat difficult. I wasn't looking to make the next Soulslike, but I felt that players needed to be challenged to explore the mechanics.

So, here's the thing about Jams. Your audience is very finnicky. People are very quick to drop a jam game and move on, and that typically means that a game over can be  an extremely easy stopping point. That's sorta antithetical to my philosophy, right? How do I prevent the player from dropping the game if I want them to have to try in order to beat it?

Re:Punch dodged (har) this problem by having two layers of goals. Beating the game was quite easy, I can think of very few players that didn't see it through to its conclusion. Those players really didn't have to try. But, there's a secondary goal, which was beating the game without taking damage, and that allowed players interested in the systems to learn and master them without generating friction for those who don't.


RATD doesn't have anything like that.

So, I needed to instead find a way to make Game Overs simply not suck. At first, the game actually did have a Soulslike approach to enemies, where you had rest stops and enemies would respawn when you rested (meaning you have to get through all encounters on a single heal). I admit, keeping this feature would have made the game more fun. But dying and losing progress would have sucked, so I had to ditch it. In the end, I went for the most frictionless approach possible: when you die, you simply get back up again, full health, right where you were. You lose progress in the battle before you, but that's it.

It's a concession, but we have to concede certain design philosophies that would improve longer games for the sake of the jam environment. I've always been a believer in "Too Easy is better than Too Hard", and in game jams, "too hard" literally just means losing progress when you die. So, at least for RATD, I had to ditch that element of game overs.


So. Did I succeed in this goal?

Yes! ...ish. The gameplay was resoundingly well received, and people really resonated with the word-combining aspect. Nate described a few battles as "puzzle-like" which is, in my opinion, exactly what you want out of a jam game's combat.

But the system did have flaws too, largely in balancing. Because I ditched the rest system, damage only mattered during specific fights, and so the game became much more trivial when HP became a weaker resource. Players were able to beat them game while only buying a handful of skills, spamming the Rushing Prefix which in hindsight may have been a little too strong. That said, even though most encounters could be defeated with relative swiftness, players still needed to discover those solutions, so I think it was at least somewhat of a success. Overall, I'm really happy with how the gameplay came out here.




Files

Rage Against The Dying.zip 226 MB
Mar 12, 2023

Get Rage Against The Dying

Comments

Log in with itch.io to leave a comment.

“In this article about which plugins would be ported to MZ…”

I think you meant “would NOT” because otherwise this is a rather confusing sentence.