Data work is not a default part of my process, instead the decision to use it comes from the system's requirements, whether that is the complexity of its calculations, the range of possible player inputs, or the need to competitively balance its outcomes. A debug display can make an otherwise opaque system readable in real time, and a structured tracking file can turn a session of playtesting into a provable set of averages and comparisons. The output is always the same: design decisions backed by evidence rather than assumption, and a clear way to communicate the depth of a system to anyone who needs to understand it.
Magic System (2023)
In the initial design of the 'Magic System', balancing was a core part of the module's outcomes and proved to be an excellent alignment with my skillset at the time. With the intent of ensuring that all of the different spell combinations felt equally viable, I captured important moments such as what spell was being used, damage dealt by the spell (to each target) and time since the player was last hit as well as an end of round data set covering the total time elapsed in the round, the number of enemies that were spawned and the number of enemies the player killed.
Through three rounds of gathering and analysing these datasets, I was able to tweak most of the components to feel equally helpful, requiring the player to consider their situation before casting. For example, in 1-to-1 combat, a basic fire bolt will do low initial damage and continue to do a small amount of damage every second for five seconds after, whereas a water bolt followed up by an electric bolt will deal massive damage, requiring the player to determine whether their current situation has time to let the enemy burn or if they need to cast two spells to handle the threat.
Ball Explostion Fire, round 1
Hits
Tracked actions
Ball Explostion Fire, round 2
Damage counts
Ball Explostion Fire, round 3
Damage counts
Tracked actions
Tracked actions
RED 3D (2025)
Since 'RED 3D's purpose was to encourage replayability, game feel and system reaction were key to initial development. This prompted the development of a fairly complex and expansive debug display. In the first weeks of development, it started as a simple position and movement display, but quickly grew to show player states like dodge velocity, attack cooldown, and invincibility timer. Eventually expanded to include the modular 'Magic System's debug display as well. It displayed spell components, speed of the spell, and a counter for targets the spell had hit.
​
This display was developed even further to also show the game's adaptive difficulty system with different equation factors, like the average room clear time, hit accuracy, and dodge effectiveness, as well as a line graph of the total difficulty score.
Debug receipt
Paper conceptulising
Skill debug output
Skill tracker
Debug output v1
Debug output v2
Debug output v3
Pepper's Quest (2025)
As 'Pepper's Quest' was a very physics-intensive game, it required a lot of debug outputs. This covered a range of forces such as; input force, velocity inertia, and slope multiplier; lots of counters like the jump and airborne grace periods; and a handful of check results such as whether the front or back raycasts detected ground below them - every single one was integral to understanding how the system responded to these changes.
​
For my own personal development during this module, I added a player action heatmap to help with level design and game flow optimisation. The heatmap detected when the player shot a seed, jumped, reset rotation, or quit. It read the position and rotation of the player as well as their current velocity and physics state. This combined with a function that read the file and displayed the actions as opaque nodes in the physical level, it ended up proving to be an excellent data source.
Debug output
Heatmap tracking
Heatmap output