Data-Driven Tower Defence with Balancing Tools and Playtest Telemetry

The problem: games are tuned, not just coded

Most student games hard-code numbers: tower damage in one script, enemy health in another, wave sizes in a third. Balancing then means a programmer editing code, rebuilding and guessing. Real studios separate data from code, give designers tools to change numbers safely, and use evidence from playtests to decide what to change. That workflow is exactly what gameplay and tools programmer roles ask for, and almost no portfolio shows it.

Tower defence is the ideal genre to practise on. It is three data-driven systems (waves, towers and the economy) interacting, and the whole quality of the game lives in the balance between them.

What already exists and the gap

• GameAnalytics is a free analytics SDK for Unity, Godot and other engines. Its own case study on Tower Defense Simulator describes using win and loss ratios per map to keep modes balanced.
• Machinations is a browser tool for modelling game economies as resource flows and simulating them before implementation. Studios such as Wooga have written about using it.
• Unity Analytics and similar engine services collect events and show funnels.

These are production services aimed at live games with thousands of players, or abstract models that sit outside the engine. None of them gives a student a small, inspectable pipeline from data asset to editor tool to playtest log to changed numbers. The gap for your project is the whole loop, built by you, small enough to explain line by line.

What you build

A complete tower defence game with two maps and at least ten waves, where every number lives in a data asset (ScriptableObjects in Unity, Resources in Godot, Data Assets in Unreal).

Three kinds of users:

• Player: places towers, upgrades them, survives waves.
• Designer: opens the editor tool, sees each wave's total health and required damage per second, edits values and sees warnings immediately.
• Analyst: reads the telemetry, finds where players fail and proposes data changes.

The main flow is: build the core game, build the tool, playtest, analyse, change data (not code), playtest again, and compare.

The technically interesting part

Two pieces are worth showing your supervisor.

First, the balance validator. For each wave, compute total enemy health, arrival rate and the gold a player can have by then. For the towers the player can afford, compute the best case damage per second along the path length. If a wave needs more damage than any affordable build can deliver, the tool flags it as impossible. This is a small model of the game written as code, and it is the same idea behind the simulation-driven balancing that live-service studios describe at GDC.

Second, telemetry done properly. Keep the event schema tiny and versioned (session id, map, wave, towers built, gold, cause of loss), ask for consent first, and never collect names or device identifiers. Store events locally or post them to a small endpoint, then aggregate with Python. The analysis should answer one question clearly: at which wave do players lose, and why?

How to evaluate it

• Balance change evidence: round one of at least 15 sessions, a list of data changes made, round two with new players, and a chart showing where losses moved.
• Tool usefulness: time a non-programmer changing a wave's difficulty with the tool versus editing values by hand; report both times.
• Validator accuracy: deliberately create five impossible and five possible waves; the tool should classify all ten correctly.
• Performance: frame time at the busiest wave with and without pooling, from profiler captures.

Suggested plan

1. Weeks 1 to 2: paper design, data model for towers, enemies and waves, one greybox map.
2. Weeks 3 to 6: core loop (pathing, targeting, projectiles, economy) reading only from data.
3. Weeks 7 to 8: editor tool and validator, telemetry with consent screen.
4. Weeks 9 to 10: first playtest round and analysis.
5. Weeks 11 to 12: data changes, second map, pooling and profiling.
6. Weeks 13 to 15: second playtest round, comparison, report and demo build.

Path to a product

The game itself can go on itch.io, but the more reusable output is the tooling. A tidy wave editor and balance validator can be sold as an engine asset on the Unity Asset Store or shared as an open source Godot addon, which also builds your reputation. For the team, a finished game with evidence of data-led balancing is a strong portfolio piece for gameplay and tools roles at studios in Pakistan and abroad.

Scope warning

Do not build multiplayer, a campaign with story, or a monetisation system. Two maps and ten waves with good tools beat six maps with none. Keep art to free assets and spend the time on the loop from data to evidence.

Learn what you need on Sefism

• Game Programming Patterns : the Type Object and Object Pool chapters describe exactly this data model and pooling.
• Red Blob Games : the clearest explanation of A* and flow fields for tower defence pathing.
• Unity Manual and Scripting API : ScriptableObjects and editor scripting for the balance tool.
• Godot Engine Documentation : Resources and editor plugins if you choose Godot.
• Data analytics roadmap : the analysis skills for turning playtest events into findings.
• DSA cheat sheet : graphs, priority queues and search for the pathing code.

Get help with this idea

This idea works best when the data model is fixed early and the telemetry is running before week eight. Tauseef can help you size the game, pick an engine your team can finish in, and shape the playtest analysis so examiners see evidence rather than opinions. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session