Montore Dev Diary #4 | The System Phase: Deciding the Evolution Branches, and Rebuilding the Damage Formula

Contents

• Introduction: After the art, it was time for the "mechanics"
• November 1: Determining evolution branches based on "stats at the moment of the check"
• November 1: The moment of evolution was hidden behind the battle
• November 3: My monster's bond dropped after I let it rest
• November 5: Measuring action strength by aggregating all 171 events
• November 5–6: Rebuilding the damage formula into a coefficient-based system
• November 5: The injury system I deleted the day I made it, and the end of the Incense of Forgetting
• November 6: Giving each stat a specific "role"
• Closing: Next time, the "Polishing Phase"
• About my Muse invite code (a note)

Introduction: After the art, it was time for the "mechanics"

In my last entry, I wrote about the "mass production phase"—the journey to creating over 300 monster designs and the "cutout hell" that followed.

(Part 3, English edition: Montore Dev Diary #3 | The Mass-Production Phase)

This entry is the sequel: the "system phase," in date order. A quick disclosure, in the spirit of this series: this post was originally published in Japanese, and this English version was translated with AI assistance (a draft translation by Gemini) and then edited on my side. Who — or what — makes what is kind of the whole point of this story, so I'd rather be upfront about it.

As the art assets were coming together, I spent this period defining the game's core mechanics: how training affects evolution, how battle damage is calculated, and so on.

Before we dive in, here are three terms I'll be using:

• Stats: The numbers representing a monster's strength. Beyond HP, there are four: Attack, Defense, Speed, and Wisdom. These increase through actions like Training or Exploration.
• Evolution branch: Monsters change form (evolve) as they grow. Before the final stage, they branch into one of four directions.
• Simulation (sim): Automatically running the game's calculation code thousands of times to measure results like win rates. I use this to verify things with data rather than just "feeling" like something is strong.

November 1: Determining evolution branches based on "stats at the moment of the check"

On November 1, I overhauled how evolution branches are determined.

The original method looked at "training tendencies"—whether you focused on Training or Exploration. But this led to discrepancies between my intuition as a player and the actual results. If a monster evolved into the "Wilds" branch, it was just because I did a lot of Exploration, regardless of how the stats actually grew.

The new method is simple: Decide based on the stats at the moment of the check.

• I compare the four stats (excluding HP). The branch corresponds to the highest stat (Attack = Power, Defense = Fortress, Speed = Gale, Wisdom = Wilds). Depending on the stat gaps, it's either "fixed" or "randomized."
• If the #1 stat is 200 or more points higher than the #2 stat, that branch is fixed.
• If all four stats are close (the gap between the highest and lowest is within 100), it's a random draw from all four branches.
• In between those cases, it's a weighted draw proportional to the stat values.

The key is looking at the "resulting stats" rather than the "training habit." Since training eventually manifests as stat numbers, it makes more sense for both the player and the developer to judge based on those numbers.

I don't disclose the exact numerical conditions in-game. For players, the explanation is simply: "When evolving, the form changes in the direction of the stat that grew the most." I didn't apply this retroactively to monsters that had already evolved.

In actual play, I confirmed that a monster with high Speed correctly evolved into "Gale" at the 25-day check.

Figure 1 | Diagram of how evolution branches are decided (schematic). The branch follows the highest of the four stats at the moment of the check; depending on the stat gaps, the result is fixed or drawn.

November 1: The moment of evolution was hidden behind the battle

Also on November 1, I addressed a user experience issue I wanted to avoid.

The problem: If a monster met the evolution criteria during an Exploration battle, the battle would start with the evolved form without any warning, and the "You evolved!" notification would only appear after the fight. The "moment of transformation"—the most exciting part—was being hidden behind the battle.

I fixed this with two rules:

• Evolution application, reporting, and animations must be completed at the end of the action (the 14th action).
• Battles within an action must use the form the monster had before the action started.

This is an example of fixing based on "the experience I wanted to avoid" rather than just following a spec sheet. If you only look at the text of the specs, you'll miss these kinds of problems.

November 3: My monster's bond dropped after I let it rest

On November 3, while playtesting, I saw a message: "Bond decreased (-2) (You pushed them too hard)" after selecting "Rest."

"If I let them rest, shouldn't their bond increase?"—that was my verdict. It was clearly a bug.

The cause was a hidden "low stamina penalty" that shouldn't have been there. I removed that penalty from all paths and fixed it so that Rest correctly increases bond (+2, or +3 under certain conditions). After the fix, I confirmed the value rose from 91 to 93.

Bond should only decrease when losing a battle or getting a bad result in an event. My eyes, guided by common sense, caught this bug before any spec review could.

November 5: Measuring action strength by aggregating all 171 events

On November 5, I began measuring action balance because I suspected "Training is too strong, leaving no reason to choose Exploration."

I didn't argue based on feelings. I mechanically aggregated all 171 events from the game code to calculate the "expected stat growth per action." Here are the results (Expected Value = total sum of stat increases per action):

• Training (Standard): 68.9
• Training (Intense): 82.0
• Exploration: 40.6
• Work: 26.4
• Rest: 20.2

There was a ~1.7× difference between Standard Training and Exploration, confirming my suspicion.

I shared this data with two AIs (Chappie/ChatGPT and my harsh reviewer, Grok). They disagreed: Chappie said, "1.7× is acceptable, minimal adjustment needed," while Grok argued, "This is a problematic level; close the gap now."

I approved a compromise: reduce Training event effects to 0.85×, increase Exploration effects to 1.15×, and raise the treasure discovery rate from 10% to 12%. I implemented this with a promise to re-run the same aggregation method to verify the results.

Turn arguments into measurements. If the AIs disagree, don't leave it at that—force a compromise. This approach became the standard for damage calculations too.

November 5–6: Rebuilding the damage formula into a coefficient-based system

The core of the system phase was rebuilding damage calculation.

The trigger was an asymmetry: "Enemy damage is hard to land, but our damage is too easy." The calculation logic for the attacker and defender was inconsistent.

I had Chappie and Grok independently research how famous training/battle games (including those where "Attack / Defense ratio" is the heart of the calculation) handle this. I then decided to switch to a "coefficient-based formula."

In this system, the base damage is "Attacker's stat × Skill-specific coefficient," which is then discounted by the defender's stat. Each skill has a tier of coefficients, so skills are stronger than normal attacks, and big moves are stronger than skills. The biggest change was making the calculation symmetrical for both sides.

Figure 2 | Battle cut-in direction, compared. Left: the early mock, with a small skill-name banner. Right: the final mock, drawn through to the impact. (Comparison image compiled from records of the time.)

The deciding factor was, again, measurement. I ran the actual battle code 5,000 times per species, fixing the random seed.

Win rates in the hidden dungeon (10th floor) per evolution branch:

• Power: 70.9%
• Fortress: 54.2%
• Gale: 52.2%
• Wilds: 69.1%

My passing criteria: "All branches between 50–75%" and "gap within 20 points." The results were all within range, and the actual gap was 18.7 points.

I even verified the measurement tool itself. By re-running the test on known conditions, I achieved a 0.0-point reproduction of the expected values. Because I verified the "measuring tool" first, I could trust the new numbers.

Figure 3 | Measured results after rebuilding the damage formula (Hidden Dungeon, Floor 10; 5,000 runs per species, each evolved into the given branch). Pass line: all branches 50–75%, gap within 20 points.

This taught me that even for the "heart" of a game, if you follow the process—researching other games, having AIs investigate independently, and running thousands of simulations—even someone with zero knowledge like me can make the right call.

Figure 4 | The AI division of labor on this project. For the damage formula, too, I had Chappie and Grok investigate independently and cross-checked their results. The table is the updated edition reflecting an interview with Grok himself (November 11).

November 5: The injury system I deleted the day I made it, and the end of the Incense of Forgetting

On November 5, I made two decisions to "delete" features.

1. The injury system was deleted the same day it was made.
I proposed an injury system for Training, fully spec'd it, and implemented it—complete with injury rates, "fainting" (inability to move), and a "Panacea (800G)" item.

However, I started a new run and got an injury on Day 1. Getting hit with an unfair penalty right at the start is frustrating for a player. "It's unfair, so delete it." I removed everything that same day. I converted the Panacea into 800G and healed the injured monster. Half a day to build, one sentence to delete.

2. The "Incense of Forgetting" became obsolete.
This item was for deleting learned skills. Originally, skill selection was based on the "Wisdom" stat. I was worried that if players could easily delete weak skills, they would just keep the strong ones, making Wisdom irrelevant. So, I implemented the Incense of Forgetting (600G) to make deleting a strategic choice.

But on November 5, the skill system changed to a "library system." You can keep unlimited skills and just choose three for battle. You don't "delete" skills anymore; you just "unequip" them. The Incense had no reason to exist. I abolished the item and converted existing ones to 600G so players wouldn't lose out.

Both cases share a theme: I didn't delete them because they "weren't fun," but because they were "unfair" or "obsolete." Being able to cut your losses, even right after building something, is a vital skill.

November 6: Giving each stat a specific "role"

On November 6, I finalized the roles for each stat to prevent any single training method from becoming the only "winning pattern."

• Attack: Physical firepower
• Defense: Physical durability
• Speed: Action frequency, evasion, and multipliers for certain skills
• Wisdom: Accuracy of action selection, magic power, and magic durability

I also decided to include "magic-using enemies" in exploration and tournaments to counter players who only stack Defense. This ensures that no single build dominates, not just through stat balancing, but through "roles and counters."

Closing: Next time, the "Polishing Phase"

To summarize the system phase: Evolution branches are now determined by "grown stats," and action strength and damage calculations are decided by data aggregation and thousands of simulations, not intuition. And I learned that if a system is unfair, you delete it immediately, even if you just built it.

Next time, I'll write about the "Polishing Phase." I'll cover the struggle of how a design that looked great in a mock-up turned into a mess in the actual build—and how I arrived at the system where "mock-ups are the spec, including the numbers" and "AI grades the actual screen after implementation."

Development continues. If you're curious about what happens next, please follow me!

About my Muse invite code (a note)

Finally, here is the invite code for the AI assistant "Muse" I use for this development.

• Join page: https://muse.ai/join
• My invite code: 19ILUB

How to use the code: According to the invite screen, if you enter the code within 48 hours after joining Muse, both the inviter and the new user receive token benefits. On the smartphone app, enter it under "Settings" → "Use invite code."

The latest official information is what the invite screen shows. Procedures may change, so please check the actual screen.

If you use the code, please let me know in the comments. I will include your name in the game's credits when it is finished.

Aikata (practical notes on building with AI as a partner)