Post-Mortem

So I thought it's finally time to do a post-mortem on this! I think the game is pretty much finished at this point; I have a few more ideas I might add later, but everything I initially planned is in the game.

I'll be up-front about this: The entire reason I made the engine for this game is because I can't draw. I've tried other game-making programs, but even "accessible" ones like RPG Maker and Game Maker are extremely visual. Sure, they provide default graphics you can plug in, but everyone hates them and they make your game look like boring, generic garbage. You still have to think in visual terms, and you have to make unique sprites, facial expressions, animations etc. if you want your story to have any artistic subtletly or depth whatsoever. That doesn't exactly play to my strengths. Can you imagine the scenes in Cartoon Battle if I had to do them in RPG Maker? It's not just the dialogue that made those scenes so enjoyable, it was the facial expressions, mannerisms, and behaviors of the characters that offered subtle storytelling through little tics and details. I love that stuff, and consider it vital for any good story, but I wouldn't have been able to do any of it in RPG Maker.

So if a picture is worth a thousand words, I'll just have to write ten thousand. Fortunately, a cerebral, turn-based game doesn't need visuals to make the gameplay work, so I made one in a fully text-based medium.

I think I succeeded. I unfortunately haven't gotten much feedback on the writing, but people seem to enjoy the gameplay despite the lack of multimedia. It was sometimes a little tricky coming up with unique descriptions for every single ability, but it was also a fun exercise to personalize the details that we so often skip over in RPGs. I love games like UnderTale that use every aspect of their presentation to tell us about the world and characters, and I hope I was similarly able to express character details through attacks and fighting styles.

So, as for the game itself.

First Principles

This was my first real game, as is probably obvious. I did not even try to filter myself; I crammed every idea I could think of into the game, and if it didn't work I hammered the engine until it did. This was pretty reckless, but I think it was a good idea for a game designed to stress-test a game-making engine. I don't want people to think they have to stick to the basic RPG formula; if they want to do really inventive stuff, I want to make sure that's possible! You want counterattacks? Here you go! You want different types of counterattacks that behave in very specific ways, like Blind Archer's Earshot from Bonfire? There it is! You want to do something crazy complex like Mia's Brand ability from Prayer of the Faithless? I got you! Getting them to work and integrating them cleanly with the rest of the engine was a trial, but in succeeding I showed how versatile the engine can really be, and I hope I inspired other designers to consider similar ideas.

When I laid out the core principles of the game, I did so by going through the many RPGs I've played over the years and identifying what I did and didn't like from them. I wanted to make the kind of game that I would enjoy playing. My major takeaways were:

No randomization.

I despise random chance mechanics in video games, and they are especially prolific in RPGs. How much damage does your attack do? Oh, anywhere from 1 point to 12. Oh, but didn't we tell you? Sometimes you miss and your attack does nothing at all. Want to use one of your incredibly limited spell slots? Oh whoops, you flubbed your Spellcraft or Concentration check, you just lost a limited resource for nothing. Oh, but don't worry, it'll all balance out when you get a critical hit! Or don't.

I hate this. When you have so little idea of what your action will accomplish, tactical planning is nearly impossible. I can understand the argument of adding elements the player can't control to avoid creating a solved game, but stuff like the possibility of completely wasting an attack takes it way too far.

In Cartoon Battle, attacks always hit and always do the same amount of damage; the only random factors are who the enemy hits and what ability they use, and even those can be influenced by some player actions. I think this is a much more reasonable way to avoid a solved game: the player can't predict what challenges they'll have to deal with, but they are always in complete control of their own actions. This turns the game into more of a puzzle than a slot machine: if you figure out the tactically optimal response to an attack, you are consistently rewarded for your insight instead of potentially punished through no fault of your own. I prefer this style of play.

Energy, not MP.

Or in the terms I used in the engine's design doc, renewable resources, not limited resources. MP as a concept has often felt really awkward to me in RPGs; either the game affords you so few shots it effectively turns magic into a gimmick, or it gives you so many there is effectively no limit on your magic. (Final Fantasy X, anyone?) That's not tactically interesting. The point of limited resources is to engage with long-term strategic planning, but modern computer RPGs have pretty much completely given up on that concept. I've always enjoyed renewable resource systems more, such as those in Alter A.I.L.A. Genesis or Wine & Roses. When you have to actively generate the resources for your skills, you gain a greater appreciation for and understanding of them. The tradeoff between multiple resources, of time and HP for Energy, adds much more tactical depth. Furthermore, the renewable nature of the mechanic makes its failure states more interesting. If you run out of MP, you just can't use cool abilities anymore, which is boring; if you run out of Energy, you've put yourself at risk but you can still bounce back with clever maneuvering. Since Cartoon Battle was purely tactical, with no long-term resource management, I figured this was a good fit.

Everyone has special skills.

Fighters are boring, okay? I understand that being able to take and deal big hits is an important contribution and all, but doing nothing but hitting "Attack" every round is still boring. Even in the more traditional editions of Dungeons & Dragons, fighters did actually have other abilities that forced you to make tactical trade-offs, such as Power Attack. So, none of that -- everyone gets special abilities, not just spellcasters.

No speed stat or turn order.

I have never, ever seen a good way to balance these. I genuinely do not think it is possible to properly balance a variable action economy in any RPG with qualitative abilities. More actions are always better than fewer actions, no matter how you try to balance for it. As for a constant action economy, and just using speed to determine turn order... I've never really seen the point of that. Speed becomes an either/or stat; you will always go after this character until you pass them, and then you will always go before that character no matter how many more points you stack on top. This tends to make Speed a really bad stat, since unlike other stats there is not a 1:1 ratio of investment to payoff. So I'm just not going to wade into this mess; you can control your characters in any order and enemies act all at once, done, simple, easy.

No magic stats.

I've always been a little dubious of making duplicate versions of stats that only apply in special circumstances. It whiffs of padding to me. There are other ways to accomplish the qualitative result of "You can do a lot of damage, but only sometimes" and "Some characters react differently to different types of attacks". I much prefer to keep things streamlined, especially for a simple proof-of-concept game like this, so I collapsed everything into one Attack and one Defense stat.

Characters and Abilities

After estabilishing these guiding principles, I filled in most of the remaining details by copying ideas from Bonfire, as it was one of the most enjoyable RPGs I've ever played. (Unfortunately, I've discovered it seems to no longer be available on MoaCube's website. The developers claim to be working on a new and improved version, but there have been no updates for years.) I took its character roster, player abilities, and the idea of the "Special" stat. (With one crucial change: I made Special defend against debuffs rather than Defense, to ensure it still mattered to characters with no debuff abilities. Bonfire did have a bit of a problem with making it too easy for Knight and Blind Archer to ignore Special upgrades and just turn into overpowered killing machines.)

There are now 7 different puppets you can play with, but initially I only conceived of the basic three, to keep things simple. This influenced the design of the initial three in certain ways, because I thought I had to cram all my ideas into them. If I had the specialist classes in mind from the beginning, I might have streamlined the base classes a little more, maybe remove some of Mage's buff/debuff abilities, maybe give Fighter fewer defensive options... but I think it still turned out alright.

I didn't really care about consistency here; I didn't track how many abilities everyone had to ensure everyone had the same number. I believe everyone did end up with about the same number anyway, but that was happy coincidence.

I knew that I wanted to make the characters not just the archetypical Dungeons & Dragons party, but to each revolve around one of my three stats: Attack, Defense, and Special. So Fighter had to have tanking and protection abilities, Mage had to have powerful attacks, and Rogue would have disabling debuff abilities, plus cool items to make use of their Special. (It amused me that under this setup, Rogue is actually the "wizard" in game-mechanical terms: their regular attacks are poor, but they can expend limited resources for very powerful one-off abilities.)

It's interesting to look back through my original design document. For the most part, it's very consistent with the final product.

• My first note for Fighter says "No magical abilities, get creative with the many things mundane weapons can do". Very early on I considered giving Fighter more weapons, but decided three was enough. Two abilities of theirs that I cut were "Swing", an attack that hit all foes, and "Trickster", a stance that allowed them to counter-attack. (This was inspired by Assassin's "Riposte" ability from Bonfire.) I also vaguely considered giving them some sort of "Feint" attack, but couldn't figure out what it would actually do. (I think the idea was that it could bypass counterattack stances, but I didn't end up using those.) They also had an ability some alpha testers may recall: "Charge", which combined the functionality of both Assault and Bull Rush: a x1.5 attack that made them Off-Balance. More on why I changed this later.
• I originally wanted to give Mage more status ailment spells and to break their "Blessing" spell into single buffs, but I decided they had too many abilities already. Two of their abilities I cut were Thaumastasis (which I would later bring back with Witch) and "Energy Purge", which would reduce an enemy's Energy points; this was before I decided I didn't want to use Energy for enemies. I already had the idea for their supercharged spells this far back, and with the exception of Annulment they did not change at all from original conception.
• Rogue is the most different. My notes propose the idea of giving them magic items, but that never made it off the ground. Crossbow wasn't armor-piercing at this point; I changed that because Rogue's poor Attack just made it too crappy to ever be worth using otherwise. I cut three abilities from them: Hunter (which I later brought back with Archer), "Sucker Punch", which would inflict Dizzy (pointless when I decided I wouldn't make enemies affected by Dizzy)... and "Procure". The idea behind this one was that Rogue could spend Energy points to create an item out of thin air, adding it to party stock. I did implement it in the very first versions of the game, and the code is still in the engine if you check. I ultimately decided it was too hard to balance while also keeping items meaningfully powerful, so I went hard and made items completely limited.
• Status effects remained the same from original conception. I struggled with the name for the DEF debuff for a little before settling on "Pain".
• Items are also pretty much all the same. I struggled with coming up with a name for the Dizzy cure and considered a mass attack item that inflicted Dizzy, again before I decided I wouldn't use Dizzy on enemies. My working name for it was "Sonic Boom", which is different from the chaff grenade idea I settled on when I brought the item back for Anais.
• Aw, and I have a little rant about how much I hate random targeting. I ended up going with it after all, though.

Once I got this all working, I came up with the specialist classes because I knew I wanted my engine to have a party swapping mechanic, and so my example game might as well show it off. I came up with Bard first as sort of a trial run, and then made the other three.

Enemies

I actually came up with the enemies before the player characters. This is generally not how you should do it, but in this case it was the premise of the entire game, so.

What was important to me was that every battle had a unique feel to it. Every enemy demonstrated a different concept.

• Princess Bubblegum and associates (I will never get tired of referring to the Mertens brothers that way) are a "flunky boss". There is a power discrepancy between Bubblegum and the others; she is the main threat, but you have weaker minions nipping at your heels the whole time. In this case, the flunkies are the boss' strength, as she weaponizes them through powerful buffs. Once you take them down, she's not all that tough on her own.
• The Mystery Twins are a dual boss that turns red. The meaning of a "dual boss" is actually inverted here where the standard enemy size is 3; they are actually less of a handful than the other encounters. But the real Big Idea behind these guys is that they become stronger once you beat one of them, intensifying the battle for the final stretch. You get to pick your poison here; do you quickly take out the support caster but make the blaster more dangerous in the process, or do you try to blitz the heavy hitter and weather a more protracted fight against an empowered debilitator?
• The Watterson kids' gimmick is unpredictability. Gumball's actions have a wide spectrum of usefulness, everything from stunning himself to a powerful AoE nuke, and Darwin has no preference for who he protects. Anais inverts this by being very predictable, but she's also the one you're most likely to take out first. Their surrender behavior is also, I expect, rather surprising, and not something you would know going in.
• The Crystal Gems' gimmick is supposed to be that they're the hardest because they actually know how to fight, but I don't know how well I actually succeeded at that.
• Marceline is a puzzle boss.
• Bill is a gradual grinder -- little in the way of direct damage, but an absolute nuisance of status effects.
• Nicole is a rush boss. I originally considered giving her the counterattack stance, since that would fit with her martial artist aesthetic, but decided a defensive ability didn't fit the rest of her.
• Rose is a marathon boss and a sequential boss.
• The final boss is a mirror match and a wolf pack boss, even moreso than the tier 1 fights.

I'm very pleased with how well I was able to follow through with these varied concepts while still remaining true to the characters!

The Damage Formula

In addition to everything else I took from Bonfire, I also took its damage formula... with a few tweaks. I altered it from lumped weighting to specific weighting. If you don't know those terms off the top of your head, it's the difference between this:

DMG = (Attack - Defense) * [unique ability weight]

and this:

DMG = Attack * [weight] - Defense

Hoo boy did I end up regretting that decision.

My reasoning was this: This makes more intuitive sense with how we think of strong attacks in the real world. If you punch something harder, you can break through strong defenses. This also has the added benefit of making attacks that hit multiple times meaningfully different than strong single attacks: the Defense term remains constant in both cases, so multiple-hit attacks will see a greater dependence on Defense. I wanted to use this functionality for Rogue's attacks, so it seemed like a good idea.

I ran into problems almost immediately. Because you see, you can't use a formula that's literally just Attack minus Defense if you want to have Attack and Defense exist on the same scale, because if Attack and Defense are equal, the attack does no damage. The way Bonfire dealt with the problem was to add a constant, like so:

DMG = [20 + (Attack - Defense)] * [weight]

This is fine if you use lumped weighting. It gets weird when you use specific weighting.

To begin with, my game had much higher HP values, so I doubled the constant. However, I, perhaps foolishly, kept stat values relatively low in comparison ("manageable", I told myself). The average stat value was 30, and at this time, Rogue had an Attack of 20. So the average damage from their Knife attack was this:

DMG = [40 + 20 * W - 30] x 2

Notice how the constant is double that of the Attack stat. And since it was a multi-hit attack, to make it on par with a normal attack I'd have to give it a low weight, reducing the value of Attack even further! Even when I dropped the weight to incredibly low values (I think I went as low as 0.1 at one point), Knife was still beating out Sword thanks to that massive constant getting applied twice.

What I hadn't predicted, and what I now knew, was that multi-hit attacks experienced great dependence on the base constant, not just the difference between Attack and Defense as I intended. The large base constant I used skewed the results.

I kludged a fix for this by applying the weight term over the sum of the base and the Attack stat, like so:

DMG = (40 + ATK) * W - DEF

And this worked. By making the weight apply to the total base damage, I could control for the influence of the base constant, and effectively balance multi-hit attacks.

...But this led to its own problem: Disproportionately favoring high-weight attacks. Because now a high weight multiplies not just your Attack, but also the base constant. Now it's single-hit attacks that can be disproportionately skewed by the base.

This one I... never really fixed. You may notice that Mage and Archer's ultimate abilities can rack up some pretty ridiculous damage values. I overall decided this wasn't too bad of a glitch, since reducing the effect of Defense with strong attacks is the entire point of this weighting system in the first place; but I do worried it skewed things a little too much, especially after I boosted the base constant further. I think I could have patched it by only making weight apply to the base for multi-hit attacks, but that strikes me as an inelegant solution.

Ultimately, I wasn't even able to totally balance multi-hit attacks. On the itch.io page, you can see me complaining a while back that Archer's 10-point Shot is impossible to balance with the rest of the system because it multiplies any Defense difference by an absolutely unmanageable amount.

My takeaway advice for you is that if you choose to use multi-hit attacks in this style, don't use a base constant, use something like RPG Maker's a.atk * 2 - b.def or just bite the bullet and make all Defense stats lower than Attack. Also, don't ever make a multi-hit attack that hits 10 times. @_@

Balancing the Numbers

So at this point I had all the core parts of an RPG. I had my characters, I had their abilities, and I had my damage formula. Now I just had to fill in the numbers.

This is an important question in RPGs. What scale do you want to work with? Do you want even a 1-point difference to be meaningful, or do you want to dazzle the player with incomprehensible numbers? I generally prefer the former, so I leaned towards that in my design. Stats were double-digits, with relatively small variations between them. I picked 30 as a baseline rather arbitrarily; I think my reasoning was something along the lines of "I have 3 stats, and 10 is a nice multiple." It seemed obvious to give every character the same stat total (90) for ideal balance, and then adjust the distribution to create specialties. In the first version of the game, I only had Fighter, Rogue, and Mage, which each mapped perfectly onto one of the three stats: Defense for Fighter, Special for Rogue, and Attack for Mage. I decided that each of them would have one focus stat that was 10 points above baseline, one dump stat that was 10 points below baseline, and one regular stat that remained at baseline. There would be no redundancies; no two puppers could have the same focus stat or dump stat.

From there, the distribution was pretty easy. Fighter, the tank: 30 ATK / 40 DEF / 20 SPC. Mage, the glass cannon: 40 ATK / 20 DEF / 30 SPC. Rogue took a little more thought, but by process of elimination the only remaining layout was 20 ATK / 30 DEF / 40 SPC.

Enemies got the same stat totals, because the fights were 3-on-3. How did I decide on a total of 150 for the boss enemies? I'll be honest, it was entirely because I designed Nicole first and that was what worked for her. I knew exactly what I wanted her stat distribution to be: triple-digit Attack, average Defense, and poor Special; that translated to 100 / 30 / 20.

That looked pretty good. But how much HP? Like the stats, I wanted to give everyone the same amount, and I also wanted it to be an even number because I like things being neat. Why did I settle on something as high as 1000? Because I decided early on I would do something completely bonkers:

No healing.

I gotta be honest with you, I hate what healing has become in most modern RPGs. Because you can heal every turn (our old friend MP strikes again), designers assume you will, and therefore you must. I am so sick of battles where the healer can never do anything but spam the mass heal spell every turn because the enemy attacks are so powerful that the party is toast if they skip even once. That's not using the characters to their fullest tactical potential! It's not interesting!

So no healing. It's just another thing I gotta balance for and other thing I'd have to cram into ability lists that are I'm already worrying are too long.

I actually think this worked out really, really well. Cartoon Battle is so heavy on status ailments that you still have that sense of defensive team management without having to do it constantly. And for opponents that don't use a lot of status ailments, like Nicole, you're allowed to just go all-out on offense, which I think is more fun.

This also made it easier to balance enemies, which was something I was worried about. In most RPGs, there is an extreme health/damage asymmetry between players and enemies, since players can heal but enemies can't. By leveling that particular playing field, I can just give absolutely everyone the same HP and call it a day. This is, in fact, what I did originally: even the tier 1 opponents had HP totals of 3000. I would change this later.

Now, to Actually Do It

I started out as a total Twine newbie. I had dabbled in C++ and Java coding before, so I understood the basics of programming, but not any of the specifics of Twine.

I quickly settled on SugarCube as the best format to use, and gave myself a crash course in CSS to create a working user interface. (This was easily the hardest and most time-consuming part of the project.) I sketched what I wanted the user interface to look like, and was able to translate it to the page with mimimal issue.

When I first started, I didn't know anything about Tweego, so I tried to do everything in Twine itself. This proved a terrible mistake and I have no idea why anyone uses the default Twine interface. I couldn't search for anything effectively, my passages were scattered all over the place, and I kept freezing up the program by flipping between so many passages at once.

My original model used a separate passage for every single phase of battle. Clicking ACT took you to the action list passage, clicking an action took you to the targeting phase passage, then to the confirm phase passage, and then to the action phase passage. I used the include macro to maintain a consistent appearance throughout, but the player still had to wait for the passage transition between every click, which was terrible. I eventually got so fed up with this even in my own playtesting that I changed it to its current model of modifying components of a single passage.

Originally I didn't even use JavaScript. My "action database" was a massive switch statement embedded in the action phase passage. And a massive switch statement embedded in the action list passage. And a massive switch statement embedded in the preview passage. It was a very bad decision.

Once I implemented actions, puppets, and enemies as JavaScript classes, and after I switched compilers to Tweego, everything went a lot smoother and I was finally able to make a public release.

So I have one lesson to teach from this, it's don't use Twine's default interface for anything, ever. Write everything in your code editor and compile it with Tweego.

Status Effects

Hah. Hah. Hah.

My first attempt at this was bad. Really bad. I just kept adding blocks to the Jenga tower and cramming stopgaps into every problem without ever standing back and admitting, "Okay, this isn't working."

I started with some really complicated logic for applying status effects. Because it was necessary! What if a status effect was already applied, I don't want you to be able to stack them endlessly! But wait, some effects I did want to stack, so we need a handler for that. Now what if it's a debuff with a numerical component, how and when will that be calculated? What if we want to combine those? What if there's resistance or a protection effect, that bypasses all the normal rules to block the effect, but it shouldn't block buffs, and maybe it shouldn't block self-inflicted ailments either, and what if I do want to make it block buffs, what if what if what if...

This was not even the worst part. That is why it is still in the engine, even though it's a clunky widget that's not very adaptable if you want status effects to work any differently than in Cartoon Battle and probably would have been better off as a JavaScript function.

Oh no. See, once we finished all that and applied the effect, we had to tell it what to do. Originally, before I made effects into JavaScript objects, I think I actually made this part of the adder function as well. After the application check code, I had to manually stuff sub-functions into every single branch for every single effect, flipping flags and conveying stat changes, etc.

But wait! I said. How does the game know to undo those when we remove the effect?

I tried a bunch of different things that for reasons I can't remember didn't work. In my infinite wisdom, the "solution" I settled on was an "effect manager" function that ran over every single character's effects and applied the appropriate changes.

In every.

Single.

Passage.

Shockingly, this caused problems! So, so many problems. But I was somehow convinced that manually recalculating the stat changes from every buff and debuff on the field in every single passage was the only way this could possibly work. (I think it had something to do with the possibility of stat modifiers changing power between application and removal, thus causing a disjunct in the removal function... I turned stat mods into such an unnecessary nightmare for myself.)

It wasn't until I started designing equipment and giving them functions to apply and remove their effects only on, y'know, application and removal that I said Hey, wait a minute... and did the exact same thing for status effects.

So now all the code is in one nice JavaScript file and is only called when it needs to be, and the effect manager gets to be buried in a pit of shame forever.

The Problems

Once I had a working prototype, my beta testers gave me very consistent feedback: Battles took too long, battles were too hard, and the system badly needed hotkeys.

The first one was an easy fix: double the damage formula's base again. The ultimate success of this was... mixed. I think battles do now progress at a good pace, but it wrecked the stat balance I initially designed. Stats now provided miniscule adjustments relative to the base value, so minor stat changes were now irrelevant. The 10-point standard deviation that worked well with a base of 40 was now pretty meaningless. I had to double the standard deviation, putting the puppets at their current stat values: 50 focus / 30 mid / 10 dump. This still wasn't a perfect fix, because stats couldn't be debuffed below 0, putting an upper limit on the effectiveness of debuffs for characters with low stats. I could and probably should have bumped up the stat totals. Why didn't I? I'll be honest, it's simply because I didn't want to ruin Nicole's perfect stat layout. With higher stat averages, triple-digit Attack would no longer be so jaw-dropping.

So lesson one: High stat totals are easier to balance around. Bigger stat values make each individual point less significant, but that also means you have more of a buffer if things prove difficult to balance, or if you need to adjust another part of the system. If I had started with higher stat totals, increasing the damage constant wouldn't have caused as many cascade effects.

The second one was also an easy fix: decrease the HP of the tier 1 opponents. With no healing, placing them on even footing with the player actually made them very dangerous; if the player didn't know what they were doing (because, you know, this was their first fight), they could make mistakes it was hard or impossible to recover from. So I dropped enemy HP totals from 3000 to 2000. This actually worked out fantastically. I was initially worried that it wouldn't split nicely three ways, but the Mystery Twins were only had to split it two ways; Princess Bubblegum had an uneven distribution anyway; and bumping up the individual values to 700 was fine for the Crystal Gems, since it subtly allowed me to make them a little harder. That only left the Watterson kids, for whom HP totals of 666 were actually perfectly fitting.

So lesson two: Have a difficulty curve. I put the very first fights in the game on even footing with the player, thinking that was fair -- but it wasn't, because while the enemies knew the rules of battle, the player didn't! Give the player breathing room to recover from mistakes. That often means giving them more HP than the enemy, and this counts double in a system where they can't recover it.

Hotkeys were just another thing I had to learn. Once I understood how they worked, implementation was easy. Chapel's event macros were a big help.

Once I did all that, I got more detailed feedback: Items were too awesome, and had to be nerfed in some way. In my original conception, items cost no Energy to use, copying the model of Alter A.I.L.A. Genesis -- but in practice, this tended to mean Rogue and Fighter ended up overflowing with Energy as they pumped Stimulants into Mage. This was an easy fix: I just made items cost 2 Energy, the same as basic attacks, and halved that for Rogue and Witch to cement their role as item wizards.

But that still wasn't good enough. Items were still too powerful, and you just got too many of them. But I couldn't reduce the player's stock any further -- I already only gave the player 1 of each attack item! But I had just designed so many attack items that the total firepower added up to too much. To solve this problem, I designed the item shop. Yes, that was actually a very late addition! But I figured I ought to design one anyway, since shops are a staple of RPGs. I took a hard line on this, severely reducing the player's total stock and giving them no bomb items at all by default. Rogue could now be a supporter or a damager, but not both. I think the end result is pretty well-balanced.

I was also informed that no one saw any reason to ever use Charge, because making the tank so vulnerable always seemed like a terrible idea. So I split the functionality into two new abilities, Bull Rush and Assault. Now, if you're making Fighter Off-Balance, you're at least making the enemy Off-Balance at the same time; and Winded is a less debilitating effect than Knocked Down, so a less extreme price to pay for extra damage. (It also does a better job of advertising "This is an attack to use when you have Energy to burn", which was the idea behind Charge in the first place.)

Balancing the Bosses

Balancing the tier 2 enemies gave me some trouble. I didn't want to give them multiple attacks, yet I still had to not only balance the inherent inequality of a 3-on-1 fight but make them more challenging than the previous 3-on-3s.

Nicole was easy, because she was just a numbers game. I just kept pumping up the weights on her attacks until she stood a chance of winning the damage race.

Rose was trickier. Because the entire point of her was that the battle dragged out for a long time, damage-over-time effects, which I had already made very powerful, ended up trivializing her. If you used Perdition at the start of the fight (and why wouldn't you?), it added up to something like 500 extra damage by the end, which was huge. To balance this, I gave her tolerances to damage-over-time effects, and also implemented a rule that halved Perdition's damage against bosses. This was fair, I thought, since you only have to cast it once instead of thrice.

Bill proved the most difficult. Because his gimmick, status effects, was qualitative rather than quantitative, I couldn't just fudge the numbers like I could for Nicole and Rose. Originally, his sleep spell only inflicted sleep, and only hit one person. Because it didn't do damage, and because Witch could cure a single status ailment indefinitely, that was effectively a wasted turn -- and he was already only getting 1 turn to your 3. Not good. I actually did crack and gave him two actions per round for a little while, but then he became too hard, because his few damaging skills were balanced assuming 1 action per round. When he could stick Burning on everyone and put someone to sleep in the same round, it became impossible to keep up with him. In the end, my solution was actually quite simple: Just stack another status effect on top of his sleep spell. Now Witch couldn't completely negate him every turn, problem solved. I also gave him an ability that sleeps two characters at once, which is quite a bit harder to recover from.

Marceline, to my surprise, was actually smooth sailing. I had to implement a few new mechanics for her (respawning, immortal enemies, passage jump actions, and delayed attacks), but they all went off without a hitch.

Conclusion

I believe Cartoon Battle was a smashing success overall. It had a rough start, but once I figured out how to ditch the awful Twine interface and do everything in Notepad++, I pumped out content pretty fast and ended up with an RPG engine that has nearly every function you could want for building an RPG. I tried a lot of things and threw a lot of complicated moving parts together, and the end result actually works. I definitely could have balanced the numbers better, and I will probably be using different damage formulas and stat layouts in future games, but it isn't bad for a first try.

I think I'll take a bit of a break from game design now that I've achieved this milestone, but there are still refinements I can make to the engine. In particular, I think I will want to take a closer look at the leveling mechanics, since I didn't implement that here and thus haven't actually tested it. The current engine works well for this style of a few distinct set piece battles, but it remains to be seen how robust it is for a real RPG.

I think I will also need to -shudder- redesign the battle UI. The way I render the status boxes and the command boxes as completely separate elements breaks the display at party sizes larger than 3, which is a limitation I didn't intend. I'll try looking into ways to make multiple rows of characters possible.

I hope I conveyed my ideas on game design well, and I hope you enjoyed.

(And as always, don't be afraid to comment on the story scenes as well! I had so much fun writing them and I'd love to know if you had as much fun reading them.)