Demo Feedback Updates

Based on preliminary feedback from the demo, a few changes have been made to the game:

Fixed Bugs

• The "Shell" status effect (imparted by Shell, AoE Shell, Good Touch, and Good Breath) crashed the game due to a missing effect file

• The party and First Villain were not removed from the top of Einstein's Tower after the First Villain was defeated, meaning you could walk to the roof and battle him a second time

• Princess would appear in Dawnstar Palace in the throne room after you finished speaking to her father and left the castle

• Hats and Robes incorrectly claimed that they raised M.ATK, when in fact they only raised M.DEF

• The "AoE" variants of debuff spells (AoE Blind, AoE Silence, etc) were not properly applying any debuff. These skills now work

• The "Slow" debuff was not triggering the proper message when an enemy lost a turn

New Interactions

• Every well in the game can now be entered

• New dialogue was added to a few NPCs following key plot advancement

• Added three new tutorials:

  • If you attempt to leave a party member without talking to them, a message will inform you that party members are optional

  • When Princess joins the party, a small tutorial dialogue teaches you about the two-weapon skill system

  • When OCG joins the party, a small tutorial dialogue informs you that she is auto-battle only

• Descriptions were added to all skills and spells. These were about 40% written by me and 60% written by ChatGPT (full disclosure required as my game now contains content produced by Generative AI, which was not true before)

Updated the damage formula

The previous damage formula for most attacks was:

Multiplier * (ATK - DEF)

Distributing the "Multiplier" you can rewrite this as:

Multiplier * ATK - Multiplier * DEF

Looking at this in two parts, we have:

• Your starting damage: computed by multiplying your ATK by the skill's modifier

• Mitigation: we subtract some amount, computed by multiplying the enemy DEF by the same modifier

This simple formula had two undesirable effects.

First, it means that building defense rapidly caused damage to fall to 0, since the value of defense gets multiplied based on the strength of the skill. So long as your defense met or exceeded the enemy attack, you were invincible. On the other end of the stick, it severely limited my ability to add defense to enemies to avoid the same effect - giving enemies even a little defense risked the player dealing zero damage to them.

Second, it caused buffs to be unexpectedly strong against enemies who had defense. Imagine a hypothetical battle where you have 40 ATK and the enemy has 36 DEF. Using a skill with a 5x multiplier you would deal 20 damage. If Princess cast ATK UP on you, this would triple your ATK stat to 120. Now the same skill deals 420 damage! A buff intended to give a 3x multiplier just gave you a 21x multiplier, all because the enemy had defense.

The new formula is:

Multiplier * ATK * (ATK / (ATK + DEF))

Now let's break this into two parts. We have:

• Your starting damage: computed by multiplying your ATK by the skill's modifier, same as before

• Mitigation: we multiply by some fraction to reduce the damage, computed as the ratio of your ATK to the enemy DEF

Now if the enemy has equal DEF to your ATK, this ratio is 1:1 and you deal half damage. If the enemy has half as much DEF as you do ATK, the ratio is 2:1 and you deal 2/3 damage. Conversely if the enemy has twice as much DEF as you do ATK, the ratio is 1:2 and you deal 1/3 damage.

This new formula solves both of our earlier issues.

For starters, no matter how much defense the enemy has, you will always deal some damage. This means I can safely add defense to enemies as a way to make them harder without increasing their total HP, and as a way to make enemies strong against either physical or magical attacks. It also means that there's reason for the player to continue stacking defense after they have exceeded the enemy's ATK value, because at no point is the player taking 0 damage from enemies.

Next, it has solved the issue of buffs being overpowered when enemies have defense. Let's return to the hypothetical battle of 40 ATK versus 36 DEF using a skill with a 5x multiplier. Before getting buffed you will deal 105.26 damage. After getting buffed you will deal 461.54 damage. This is only a 4.38x increase, not a 21x increase! Much more reasonable.

Note that skills with "special" damage calculations were not impacted:

• Gravity always does 25% of the enemy's current HP, with no mitigation

• "Cancer" skills (white magic attack skills) have lower multipliers, but bypass magic defense

• Poison deals 5% of the enemy's max HP, with no mitigation

• Armor Pierce bypasses physical defense

Updated Experience Curve

The built-in RPG Maker experience curve has four variables you can tune:

The formula for the total experience to reach a certain level is then computed as:

Math.round(
(base * Math.pow(level - 1, 0.9 + acc_a / 250) * level * (level + 1)) /
(6 + Math.pow(level, 2) / 50 / acc_b) +
(level - 1) * extra
)

This can be written more simply as:

numerator = (base * A * B * C)
denominator = (6 + D)

total_exp_for_level = (numerator / denominator) + "some extra"

The "some extra" here is a very small amount (the maximum value for the "extra" parameter is 50, and the maximum level is 99, meaning this can't exceed 4900), so we can mostly ignore it when considering late game curves.

So let's look at these A, B, C, and D values more closely:

• A = (level - 1) ^ (0.9 to 1.1) -- the exact value between 0.9 or 1.1 is chosen based on "Acceleration A"

• B = level

• C = level + 1

For very high levels (after level 50 or so) the difference between "level - 1", "level", and "level + 1" is negligible. So we can simplify by pretending these are all just "level":

• A = level ^ (0.9 to 1.1)

• B = level

• C = level

Since "0.9 to 1.1" is "about 1", we can simplify once more by saying that A is "approximately equal to level ^ 1"

This means the entire numerator simplifies to:

numerator = base * level * level * level = base * level^3

Just like we ignored "some extra" because it was a very tiny value as numbers got large, we can similarly ignore the "6" in the denominator. So the denominator is essentially:

denominator = level^2 / (some stuff)

Where this "some stuff" is based on the Acceleration B value

Some simple algebra shows us that we can simplify:

total_exp_for_level = (base * level^3) / (level^2 / (some stuff))
= (base * (some stuff)) * (level^3 / level^2)
= (constant) * (level)

That's a lot of math to say: as your level increases, the experience curve becomes linear. In fact, if Acceleration A is less than 25, the experience to go from level 98 to 99 is less than the experience to go from level 97 to 98! When Acceleration A is equal to 25 we're dealing with a linear function, and when Acceleration A is greater than 25 it's a function that grows only slightly faster than linear.

So what does this mean for game design?

A common expectation is that as you progress in the story, enemies will get harder and will give more experience. But if the experience curve is linear, then increasing the experience from enemies will lead to accelerated leveling! While it may take an hour of grinding in the early regions to get from level 10 to 11, it only takes 2 minutes of grinding in the last dungeon to get from level 98 to 99. Levels come so fast that they stop meaning anything.

Given that stats grow linearly with your level and skills acquisition is (by default) based on level, this means that you will experience very little growth in power for most of the game then fly through all of your skill and stat gains right before the game is over. This is hardly as engaging as growing gradually as the story progresses.

After researching how large JRPGs handled experience curves (Final Fantasy, Dragon Quest, Breath of Fire, Golden Sun,...) I opted for a three-part model:

• During early levels (1 - 30 or so) I wanted the experience curve to be roughly linear. This way if you choose to grind, time spent grinding is directly rewarded proportional to time spent, but if you choose to fly through the story any "missed" experience is rapidly earned from late-game enemies.

• During mid levels (30 - 60 or so) I wanted the experience curve to be roughly quadratic. This puts pressure on players to stop grinding and start progressing, as their gains become farther spaced apart and continued time in low-level battles becomes inefficient.

• During late levels (60 - 90 or so) I wanted the experience curve to be roughly cubic. This way giving huge experience rewards for end-game enemies will rapidly catch up under-leveled players without throwing over-level players accidentally to level 99 (reaching max level should be a conscious choice, not the result of bad experience curves).

So to start, I drafted the following formula for "experience to next level" (rather than "total experience to this level"):

exp_to_next_level = A + B * L + C * L^2 + D * L^3

This gives us:

• A constant ("base") experience to next level, "A"

• A linear component

• A quadratic component

• A cubic component

I then tuned A, B, C, and D such that I hit my level goals:

• At level 15 (halfway between 1 and 30), L = 15, L^2 = 225, L^3 = 3,375

  • In order to keep this portion of the game linear, I needed C x L^2 and D x L^3 to both be less than 15

• At level 45 (halfway between 30 and 60), L = 45, L^2 = 2,025, L^3 = 91,125

  • In order to keep this portion of the game quadratic, I needed C x L^2 to be greater than 45, but I needed D x L^3 to be less than C x L^2 (and ideally less than 45)

• At level 75 (halfway between 60 and 90), L = 75, L^2 = 5,625, L^3 = 421,875

  • In order to keep this portion of the game cubic, I needed D x L^3 to be greater than C x L^2 which needed to be greater than 75

Note that the value of "A" isn't actually all that important, and only impacts the lowest of levels.

Some example values of B, C, and D which accomplish all goals above are:

• B = 1

• C = 1 / 30

• D = 1 / 2000

Once I had the formula for experience to next level, I applied general summation formulas to compute the total experience to a given level:

total_exp_to_level_N = sum(1 to N, exp_to_next_level_N)
= sum(A + B*L + C*L^2 + D*L^3)
= sum(A) + sum(B*L) + sum(C*L^2) + sum(D*L^3)
= sum(A) + B*sum(L) + C*sum(L^2) + D*sum(L^3)

sum(L) = N * (N + 1) / 2
sum(L^2) = N * (N + 1) * (2 * N + 1) / 6
sum(L^3) = (N * (N + 1) / 2)^2 = sum(L)^2

I wrote a plugin for this new formula, being sure to incorporate the "basis", "extra", "acc_a", and "acc_b" values so that I could tune the experience curve for each character in the UI.

Here's a table showing the difference in required experience for different levels before and after the change:

Other

Following the multiple game crashes as a result of assets being missing from the final build, I opted to build my own "unused asset remover" tool.

Over the past few weeks I've been gradually working on this program which intelligently scans your entire game database as well as plugin code to find asset references. It's very similar in nature to RPG Maker Resource Manager by Starlit, with a few key differences:

• My tool runs about 200x faster (this is not an exaggeration, this was measured performance) through a combination of:

  • Never processing any data file or plugin more than once (Starlit's tool will process each file once per asset)

  • Using the Aho-Corasick algorithm for substring detection instead of grep, which has higher performance for finding multiple possible substrings

  • Multi-threading

• My tool can rename assets and will update all references found

• My tool can detect duplicate assets (same file hash) and merge these duplicates

• My tool will warn if a reference is found to an asset that doesn't exist (this actually caught a missing asset in chapter 9 of my game)

• My tool provides a preview of assets (supports both image and audio at this time)

• My tool has a much lower false positive rate through a combination of:

  • JSON parsing data files

  • Lexers for JavaScript files to extract string literals (ignores comments, variables names, etc)

This tool will be made available on itch.io for $9.99 once I've done a little bit more cleanup to the UI and fixed a few minor bugs.

I also plan on releasing this tool free on Steam for anyone who buys the full Trope Tales game when it's released!

The latest version of the demo utilized my tool to remove unused assets rather than RPG Maker's built-in "Remove Unused Assets" feature. This resolved the crash with the "Shell" effect, as well as prior crashes from missing front-view battle sprites which I have been manually copying over to the final release.