Changing a single value is easy. The cost lies in the surrounding process: open the code, locate the number, edit it, rebuild, and enter the game to verify the result. Testing twenty values in one evening makes that process itself a significant drain on attention. I built a tuning console to remove code editing from the loop.
Separating data from code: balance.json
Each value keeps a default in code, but the game reads a balance.json file at startup. That file contains only override values. The console is a visual editor for the JSON: adjust a control in the browser, write the result to the file, and launch the game to apply it. The logic remains unchanged while the values stay directly tunable.
Five groups of controls—enemy strength, skill phases, feel parameters, stat curves, and damage formulas—are collected on one page. Testing twenty values now means making twenty adjustments without touching the code.
The additional benefit of data-driven tuning
Separating values has another benefit: it forces me to define which properties should be tunable. When boss durability, stance-break windows, and enchantment slopes must all become named controls, the boundaries of each system become clearer. Magic numbers scattered through the code are often evidence that the design itself has not yet been stated precisely.
Assertions: preventing value changes from breaking logic
Tunable data also introduces risk. Changing one number can quietly break a relationship elsewhere, especially in an AI-assisted workflow.
I use assertions to contain that risk. In one case, the entire level scale was increased by a factor of five while enemy strength was supposed to remain unchanged. I added an assertion requiring enemy strength at equivalent progression points to match the previous version exactly. If any related constant changes in isolation, the assertion fails. Values may change, but the relationship between them is locked. That assertion later caught a coefficient that had been missed during the conversion.
Summary: tools should serve judgment
The tuning console and its assertions serve the same purpose: spending time on whether a value is correct, rather than on the mechanics of changing it.
In solo development, the scarce resources are not lines of code but judgment and patience. Mechanical work that can be replaced by tools should be delegated to tools, preserving attention for the human task that remains: entering the game and deciding whether a value actually works.