Final Battle II (c. 2002)

posted on 31 May 2024 by Broken Muse

When summer came, the infinite potential of the TI-85 went with it. It being a school-issue calculator meant our formulas, the only means of playing, were gone. This was devastating. We did write down, by hand, a lot of the formulas and how they were programmed. The hope was that we could buy another and put them back in. That was a far-off hope thanks to the cost of the device. So how then could we move forward? Well, we kept the same basic idea: video games without video games. This, in reality, led to two different versions of the next iteration of Final Battle. Developed in sequence, as one flopped and never made it to the table. But it of course made some massive contributions. The second lasted enough to run a very exciting campaign.

Final Battle 1.5, c. 2002

The first step was to find a new set of calculations to use. So we opted to find an option like where we started: video game math guides. This time, we found help from a guide written long ago: Jarulf’s Diablo/Hellfire Math Guide. A simpler set of calculations, we didn’t need to rely so much on a heavy-duty calculator. Plus we could easily pre-write several formulas based on our characters ahead of time. This means an average calculator would be able to do the work. This choice was influenced by my desire to fold in a game I was already interested in, Diablo. This version, we’ll call it 1.5. would be short-lived due to several issues, but there were a handful of things that we would hold onto.

A main issue was that Diablo’s formulas were dependent on the level of a character. Each class also had different formulas for similar things. Rogues calculated ranged damage differently than Warriors. Warriors calculated melee damage differently from Mages. Since we were coming from a game driven by having several classes at once, this was a problem. Any character with multiple classes would have several formulas for the same thing. This was inefficient in a game designed to allow characters to take many classes. Spells were very similar and lacked variety for making spells feel unique. Anything that wasn’t a spell had to be built from scratch and was hard to build with so few examples. This led to an Import Problem creeping in very early. We needed to move away from class-based formulas.

Our next inspiration was serendipitous. Further back, in 1998, we had a short opportunity to play a game that we never forgot. It was lodged in our brains, a happy memory of an amazing game—Castlevania: Symphony of the Night. While working on Final Battle’s sequel, we saw a used copy of Symphony in our one small games shop. We decided to buy it, as our sibling had recently procured a PlayStation for the household. This was a massive joy for us. We delved into the game, and immediately wanted to master it. We searched high and low (and missed about 3/4 of the game’s content for the first several playthroughs). We realized we were in over our heads when the progress counter reached over 100%. So we went looking and found a very detailed and complete guide to the game. What we did not expect is that this guide, by Zach Keene, would include a math section. A detailed breakdown of the game mechanics and formulas. We dropped everything and started porting over a sample character.

Symphony’s math was drastically different from Diablo’s. Since the game had no classes, all the formulas were based on the basic stats of the character. This was more in line with what we had in mind from Final Fantasy Tactics. The special attacks, spells, and weapons were quite varied. And their formulas, despite being simpler, meant we could modify them easily. Enough so, that Import Problems were rare. This led to the hunt for new players, and the start of the second campaign of Final Battle. This hunt turned out to be easier than we expected. We had some ideas from the earlier version but wanted to try something new. Our players picked a starting class they wanted, and we built up from there. We built the classes for the test game and before we knew it, we were playing Final Battle II.

Final Battle II, c. 2002

And so—a Dwarven Mobile Driver, a Psychic Vampire, a Zombie Samurai, and a Mystical Elf Dark Magician—set out. Tasked by the King of Hyrule, they were to sneak into the borders of the Gerudo territory. While their leader was away, they would investigate claims of an amassing army. This meant exploring uncharted areas and facing dangerous obstacles.

The game ran well despite some bumps in the formulas. We were able to simplify combat by pre-filling some formulas to a point. The first hurdle was that we needed to randomize the results, but a basic calculator couldn’t do that. You may be asking why we didn’t go with the obvious solution. When in doubt, math rocks were the king of randomization at the gaming table. I’ll bring this up again later, but we did do this to a degree. All random notations were adjusted to the nearest multiple of 6. We would roll that many six-sided dice and voila, chaos. We accidentally developed a dice pool mechanic long before we knew what a dice pool was. We loved it. The thrill of tossing a handful of dice was a fun upgrade from the days of calculator mashing.

At the end of the campaign, came the time for level-ups and expanding on options available to players. This led to a lot of between-campaign homework for us. During this time, some players expressed impatience and disinterest. Some moved on to other things. Exit interviews gave us a large amount of data, as did the playtest. We had taken plenty of notes and comments on things that did and did not work. We won’t get into the details of what formulas did or didn’t work as intended. We will instead highlight some mechanics that we thought were particularly interesting.

Soul

The party decided Zora’s Domain would be the fastest way to get to Lake Hylia, using the shortcut there. What the party did not take into account was that it was not a magical teleportation. It would involve them holding their breath for the entire trip. A trip primarily designed for the amphibious people. This led to not one, but two drownings. This was fine, as the characters involved still had Soul.

Soul was inspired by the concept of extra lives in video games. A character has a limited number of times they can face death and come back unscathed. Whenever a means of resurrection is used on a character, it costs Soul. This cost represents the spiritual strain involved in the resurrection process. While some methods may cost more Soul, some may cost none. Once a character is out of Soul, their death is permanent. They move on to the afterlife. What that means, well that may be a completely separate adventure for them to embark on.

Soul was determined by the Constitution (CON) stat. It would increase if CON was raised permanently. Sny decrease would reduce spent Soul first. We would later remove this as we found it too punishing when a player with full Soul lost CON. Instead decreases wouldn’t affect Soul. An intrinsic aspect of Soul is that it is nearly impossible to replenish. Some rare or mysterious items or beings might be able to, but most of those are myths.

Job Cards

A big thing we learned from Diablo was the separation between a character and their classes. We used to build characters from their classes. Now we were shifting a lot onto the characters themselves. Since Symphony did not have any classes, we had to find a way to fold them in. We decided the Familiars, who could earn experience and grow on their own, were a great example. And so we made the Job Cards: a physical, tangible object a character drew their strength from.

A character could carry any number of Job Cards at a time, designating one as their current Job. While equipped, any experience earned also provided Job Points. As previously, any Abilities can be purchased from the card for use. Being a tangible object, this was narratively explained as a form of osmosis learning. If a character parted with a card they were using, they would lose their abilities associated with it. These would be regained if they reclaimed the card. This a way to allow a party to share cards, with each card only carried by a single character at a time. This does mean a party whose cards went missing could be limited in their options. And could prove as a fun challenge.

Gaining them could be narrative, or hand waved as mechanical. A narrative example is a moment where the party bonded with an NPC, gaining a Job Card from her. This was her having funneled her knowledge into a rare and mysterious blank card. An act that didn’t go unquestioned by the party. They wondered if they could get a blank card of their own. While they did not get one, we had intended to provide some later.

Leveling up and gaining benefits from experience was one way for a character to grow. Another was spending their Job Points to buy Abilities locked inside of a card. The Job Cards were like the classes we had before. We had four types of Abilities: Action, Support, Reaction, and Movement. There were some changes made to fit the new mechanics.

First, we divided Action Abilities into Special and Action Abilities. Special Abilities were what Action Abilities used to be: an assortment of connected abilities. Black Magic, Summoning, and Ninjutsu are types of Special Abilities. Abilities under these umbrellas were often unofficially referred to as Options. Action Abilities became simpler single actions a character could take. Steal, Jump and Charge were examples of Action Abilities. They did not have Options and were self-contained. This was to reduce redundancy in Options. In exchange, classes could freely have several Special and Action Abilities. Not unlike Support, Reaction, and Movement Abilities.

Equipment Durability

After prolonged use, equipment wearing down and needing repair made sense. We introduced durability as a reason for players to change their equipment. Especially when a prolonged adventure is had. In this case, equipment included weapons and armor, but not accessories like jewelry.

The equipment’s durability decreased under specific circumstances. After any combat equipment was used in, one point of durability was lost. S critical hit would reduce armor durability by 1/10th the damage dealt. Weapons would also lose one point of durability for dealing a critical hit. If a piece of equipment had a special ability that could be activated, doing so would cost one durability. This cost would be in addition to any limits the ability had.

Something that had no durability left was considered damaged. While it could still be used, it would no longer provide any benefits until repaired. If something triggered more durability loss, it would be broken. A broken item was far more difficult to repair than a damaged one.

Permissions

One big aspect that was born here is the concept of Permissions. This code of conduct helped both Game Master and Player tell stories together. With an infinity of possibilities in Final Battle, it helped narrow focus. While the most used example of it is in character growth, it can be applied to other situations. In its simplest form, Permission is a straightforward question: in the narrative, as it currently stands, does this make sense?

Players can look for opportunities to learn new skills or gain powerful equipment. This is normal as games progress. What if a player wants something not as readily available? That is where Permission comes into play. A player needing to replace their sword can do so if there is a town nearby with either a smith or an arms dealer. A player wanting induction to a sect of spellcasters, however, is not as simple. They would need a member of that sect available, and amenable. And they would need time to undergo training. The key to Permission is that it isn’t a yes or no question. There is always a reason involved. This means Permission is not immutable. You can seek out the needs to obtain Permission within the narrative of the game. This can be small or large, however it should be doable, even in theory. Is that theory going to pan out as players learn more about what it will take? That all depends. The smithy has broken his arm and would need someone to help him prepare the forge if he plans on working it. The spellcaster is willing to teach you, in exchange for a favor in hunting a relic. This allows characters to pursue stories of their own, alongside the plot set out before them.

Import Problem, Part 2

This is a recurring problem, as you may imagine. We created this complex and rather in-depth system. Moreso than the previous version if we are being honest. Some of the formulas had to be tested several times or edited mid-game sometimes. We also lacked an easy way to put together new classes. Importing materials became labor intensive. Combined with the ability for our players to gain just about anything, it meant a lot of work. It also meant a lot of prep time between sessions. Which led to larger gaps between them. As it stood, we had made a game only we could run.

Arguably, a released product would have all things pre-made, and so anyone could run it. But our biggest flaw we saw was the lack of an engine for building new things being added. We wanted a way to include new things on the fly, with minimal extra work. It was proving to be difficult to establish.

As before, we lost players, conducted exit interviews and we had another packet of notes. It was time to go to the drawing board. We wanted new inspiration, and we weren’t finding it easily. We had recently rediscovered this thing called Dungeons & Dragons. It couldn’t hurt to look into it, could it?