Post-Mortem
I had the idea for a game using this system for quite a while, probably since I made Cartoon Battle. Initiative systems in RPGs have never really appealed to me -- they've always felt limiting at best and needlessly convoluted at worst. I've also never found an RPG that managed to balance the stat used to determine turn order; in fixed action economies the stat is useless since it has a binary effect unlike other stats that gain value with every point, and in systems like Final Fantasy's ATB where higher stats give you more turns it's grossly overpowered.
But this particular system felt different. It's much easier to balance a variable action economy around specific actions than entire characters, and provides more possibilities to boot. I rarely think about my characters' turn economies in ATB systems other than assuming higher speed is better, but in a system like this you have to think about every action.
Unfortunately, this system is very rare in the wild. My primary model was Exalted, a tabletop RPG that is infamously terribly balanced and therefore a poor model to mine for specifics. There are a few indie RPGs that use similar systems, but they're extremely thin on the ground, and often had slightly different implementations than what I was picturing. This made balancing the game a lot harder, because unlike with Cartoon Battle, I had almost no examples to draw from.
Initial Concepts
My initial design process was intentionally similar to what I did for Cartoon Battle. I hashed out the very basic mechanics first: wait time, recovery time, stats, resting. It took me some time to brainstorm exactly how all of these things would work. I knew I wanted the timing of offense and defense to be important, but went through a few ideas before I settled on the current model. Initially I thought that maybe characters took more damage if they were attacked while in the wait time period and/or doing so would always cancel their action, but decided that was adding too much complexity right off the bat, and removed that to balance the core mechanics first.
I quickly settled on the idea of giving actions fixed damage values rather than a complex formula as in Cartoon Battle, because it's much easier to balance DPS on a per-tick basis that way. This led to the simplification of attack and defense stats as well.
I debated whether to have a stamina mechanic at all or whether I should make time the only resource. The game Helen's Mysterious Castle does the latter, but I found that game rather repetitive and overly simplistic, so I decided an additional element of resource management was necessary. This quickly led to the resting mechanic as well.
Initially I was unsure how to handle the vulnerability mechanic. At first I thought I would only make characters vulnerable during resting, but that seemed hard to balance since it was an either-or thing. Fortunately, I remembered Prayer of the Faithless' brilliant idea of using stamina as defense and stole it. This also allowed me to quickly decide that resting should only recover stamina at the very end of the resting period, creating the "resting = vulnerability" mechanic I wanted entirely through an organic outrgrowth of an existing mechanic.
I was initially ambivalent on the idea of a speed stat, but I thought it was worth trying out since it was the only one of the "core four" I nixed for Cartoon Battle. Restricting it to temporary buffs allowed me to balance it more carefully.
Players
Since the system was completely different from Cartoon Battle's, I knew I needed new player characters. In retrospect it might have been clever to use the same characters and translate their movest to the new system, but eh, I like what I ended up with.
Mechanically, it was obvious that the archetypes to use were Slow, Fast, and Mixed rather than thinking in typical Fighter/Mage/Rogue terms. I came up with the idea of the classes being Mage, Mage, and Mage very quickly, since spells with long casting times were a perfect fit for this system, and there are so many different types of wizards in Dungeons & Dragons and other roleplaying media that it was no trouble to come up with archetypes. Getting to delve into all the nerdy little differences between each class and using that to explore different models of magic was a lot of fun. Just as I intentionally blurred the lines between wizard and cleric with Mage in Cartoon Battle, here I gave Sorceror elements of a druid by leaning into the animal theme implied by the buff spells of Dungeons & Dragons.
From there it seemed obvious to turn the whole framing story into a wizard tournament, and therefore to pick characters from media with high magic content. I noted that, alas, I took so long to make Cartoon Battle that by the time it released most of the shows I drew from were already old news, so I had to draw from new sources. I had originally planned for additional matches against the protagonists of The Owl House and Twelve Forever, as well as another fight with Princess Bubblegum, but designing just the She-Ra fight was so exhausting I decided to stop there.
I actually came up with the moveset for Warlock first, which in retrospect was an odd choice because they have the weirdest one. I mainly did this because I was really excited to do the Slash/Thrust/Cleave combo, because that was something bouncing around in my head ever since I came up with the idea for the system: It's a great setup for exploring different timing balances, with a bonus of demonstrating how even mundane techniques can have a lot of fun variations. This conflicted with the wizard tournament framing, so I threw in a line about Warlock bribing their way around the rules. (I suppose I could have had it be a magic sword or whatever, but that was funnier.)
Thrust proved the hardest skill to design, and went through several iterations. Initially, I just had it reduce Warlock's defense until their next turn (the logic being that a thrust causes you to overextend and expose yourself to other attacks), but I wanted a more complex give-and-take where Thrust was risky but paid off if the target was already vulnerable, since that's mostly how thrust attacks work in real swordfights. First I changed it so that it did more damage the less HP the target had, making it a finishing move, but that didn't make a whole lot of physical sense to me. Once I came up with the stamina-as-defense mechanic, allowing it to capitalize on stamina loss seemed much more fitting. (This also gives it synergy with the Bleeding mechanic from Slash, which was something I wanted.) So it's now an attack that's weak by itself, but becomes extremely powerful if you use it at the right moment.
In my mind, Warlock's patron is Todd Howard -- you know, the Bethesda guy? I saw the idea on an internet post and found it hilarious. This is why Warlock's powers mostly involve warping time and space; it's a riff on how buggy Bethesda games are. It also worked with making Blood Sacrifice (which of course you have to have on a warlock) a metaphor for the crippling overwork of the professional games industry.
The other puppets were much simpler to design. I initially had the idea for Sorceror to have three attacks of varying speed and power, much like Fighter's attacks in Cartoon Battle, but nixed it once I realized I had already done that with Warlock's sword techniques. So Sorceror is pure support.
With Wizard, I had a number of ideas I wanted to implement. The first is that I wanted to give them the standard Fire/Ice/Lightning jRPG spell set, but give them more meaningful differences than just a different tag. I've always disliked elemental attacks in RPGs for this reason; even though I have to scroll through so many spells, in reality they're fundamentally all just "do damage", making it feel like artificial inflation. If I have different skills, I want that to actually matter; there should be some reason to use Fire over Ice even if the enemy has no elemental affinity for either.
To really emphasize that, this game has no elemental affinities to begin with. Instead, the different "elemental" spells have different secondary effects. (If you played Experiment 02, you'll see that I prototyped this idea there with Link's different wands.) You may notice this makes them mechanically identical to Rogue's various status attacks in Cartoon Battle, which brings me to the other guiding principle I had for Wizard. In Cartoon Battle, Mage was supposed to be the DPS, but I really messed that up. They have only two damaging moves; their other seven are pure support moves that don't use their attack stat at all! Rogue, even though they were the one that was supposed to be pure support, ended up having a lot of moves that did the same things as Mage while also doing damage, which was dumb because they had the worst attack stat. I got them totally backwards! So now Wizard gets Rogue's moves with Mage's damage potential, as it should be. If you still want to go for pure damage they have Finger of Death, but otherwise they let you set up useful effects while doing damage at the same time, effectively combining multiple actions of Sorceror's. I hope this made them more fun to play with while still cementing their role as the damager.
Defensive actions were among the last ones I implemented. I initially thought that only Warlock would be the "tank", but had trouble giving them abilities that both made sense and felt mechanically different from Fighter's. I eventually decided I should break from that thinking and just give everyone their own defensive action. I think the final results fit well with everyone's characters, which is a nice bonus!
Content
My initial spitballed values were to use 6 ticks as the standard speed for an action, based on D&D's idea that a round is 6 seconds. As soon as I was able to run an actual battle, I became aware to a problem that should have been obvious: Giving a uniform speed for everyone's actions caused everyone to fall into a very rigid pattern, effectively identical to a regular turn-based system. I realized I needed to vary action times a lot more.
Initially I boosted stamina to 100 to make it easily readable as a percentile, but cut it down once I implemented the stamina-as-defense mechanic. First I cut it down to 20, but I decided that would make Bleeding too powerful, since even at minimum, losing 1 stamina per tick is a lot. On my second pass I doubled it to 40.
The standard for action base damage was set to twice stamina. As I've said before, subtractive defense can lead to some pretty crazy swings, so I wanted to keep that controlled: At most, stamina reduction will double your damage. I think that's reasonable.
The very first battle I designed this time was the tutorial! The biggest criticism I got for Cartoon Battle was the lack of a proper tutorial, so I wanted to make sure to fix that. The feedback I got from my initial testers was that the timeline was hard to follow; while I couldn't draw unique graphics, I was able to color ticks to correspond to specific characters, which helped a bit. Next, I started work on the first real battle, which I decided would be She-Ra and the Princesses of Power, since those characters had fairly straightforward abilities.
Then I hit a brick wall and procrastinated by playing other video games for a few months.
The issue I ran into was that of AI. I could design the raw ingredients for Adora -- a Slash/Thrust/Cleave set to mirror Warlock, plus a guard skill since she's a tanky knight and a superblast to give her a little spice; easy enough. But coming up with a brain that could actually use them in an engaging way proved a complete non-starter. Maybe it had just been too long since my last game, but attempting to sketch out even basic AI logic was dizzying to me. This timeline system was much, much more complex than my simple turn-based game: every action had to be planned with an eye to the future, you could potentially react based on what abilities characters were telegraphing, and there is the question of how far to push your luck before resting and restoring your stamina. (I eschewed energy points for enemies in Cartoon Battle precisely because I feared the AI complexity they would necessitate, but with the stamina-as-defense mechanic there was no way around it here.) There were far more variables to consider, and in order to meaningfully challenge a player, I figured the AI would have to take everything into account.
First I had to I come up with a logic for when to rest. I decided to set upper and lower thresholds for stamina, with characters never resting at the upper threshold and always resting at the lower, with in-between states having a gradient of probability. It's not a perfect system, but it roughly mirrors the logic used by players. You have to decide whether to rest often to keep your defense high, or press your luck and get off more attacks. (I also wanted to have HP factor into the decision -- because stamina is defense, your priorities may shift as your HP drops, perhaps making you rest more in order to preserve your HP, or to rest less in order to rush the opponent before you go down. Unfortunately, I couldn't come up with a way to neatly integrate it.)
I actually found this quite fun, because it allowed me to personalize the characters in mechanical ways, which is always my favorite part of designing these systems. Adora, as an experienced fighter, has the confidence to press her offense, and so has the lowest EN threshold of the trio; Bow and Glimmer, as sheltered children who have never seen real combat, are more nervous, so they rest more often. This is a really subtle detail that most players probably won't ever notice, but it pleases me deeply when I'm able to tune even the smallest variables to fit the character.
This gave me the confidence I needed to push ahead and finish all the characters' AI. Bow was the trickiest, since I had to design logic for launching an interruption ability in advance, which resulted in me making the "have enemies seen you use this action" mechanic to determine if he could predict whether his interruption would trigger in time.
Then I turned it over to my friends for beta testing, and they found a ton of bugs I had to fix. I did that, then found even more bugs, which I also had to fix. I eventually decided I was sick of fiddling with this game for so long that I just released it into the wild, come what may. I had to fix a few more bugs (and it turned out I forgot to implement rest logic, oops), but I didn't get any complaints after that, so it seems like it came out well!
Conclusion
While Cartoon Battle and the following experiments went quite smoothly, this one was like pulling teeth. Unlike in previous games, I was flying into largely uncharted territory, and was constantly second-guessing and redesigning aspects of the core system, which held up content generation for far longer than it should have. I left it languishing for weeks and then months, dreading further work on the thing.
Unlike in Cartoon Battle where I was able to easily come up with nine different gimmicks, here I could barely even push out one. I planned to add encounters for the cast of The Owl House and Twelve Forever, as well as Princess Bubblegum again, but I had no clear ideas for any of them. The only gimmicks I could think of were enemies with no tells and enemies with very high initiative (allowing them to get the drop on you), but none of those characters were good fits. And after how hard it was to adapt the comparatively simple SPOP cast, I was too exhausted to try more, and just decided to push the game out the door.
I think the main problem is that the design space here just isn't as well-explored, so I had no foundations like I did for my previous games. You can't do an interesting twist on something until you have a baseline. So, I'm not eager to try this system again until I've played more games that use it. But hey, that's why I'm releasing it! Try your own hand at it and contribute to the collective artistic space.
Get Another RPG: Experiment 03: It's About Time
Another RPG: Experiment 03: It's About Time
An experiment in tactical combat and time
Status | Released |
Author | Another RPG Enthusiast |
Genre | Role Playing |
Tags | Minimalist, Tactical, Twine |
Languages | English |
Accessibility | Interactive tutorial, One button |
More posts
- Version 1.01Jun 16, 2022
Leave a comment
Log in with itch.io to leave a comment.