From 64 FPS to 144 FPS: Tower Defense Game Optimization
Aztoon Lab
From 64 FPS to 144 FPS in 21 Days: A Tower Defense Transformation
The Crisis Nobody Saw Coming
"We can't scale this anymore."
That's what the client told me on our first call. Not "won't scale" — can't. The game ran at 64 FPS on desktop during early waves. Playable. Shippable, even.
But wave 7? 64 FPS dropped to barely playable. Wave 10 would be a slideshow. Mobile port? Forget it. 15 FPS on mid-range devices.
New tower type? Two weeks of development, and somehow performance got worse after each feature.
The team wasn't stuck because of lack of ideas. They were stuck because the architecture was fighting them. Every line of code they added made the foundation shakier.
The Hidden Cost:
This wasn't a "performance problem." This was a business blocker disguised as technical debt.
Mobile launch: Delayed indefinitely. Potential market: 2 billion users. Current access: zero.
Feature velocity: 2 weeks per tower. Competitors shipping in days.
Development cost: Every feature took longer than the last. Engineering hours burning money.
Team morale: "Why does everything break when we add something new?"
The game was playable today. But scaling it — adding content, supporting new platforms, competing in a live market — was financially impossible with the current architecture.
They needed transformation, not just optimization.
This is the story of how I delivered it in 21 days.
The Diagnosis: 11,900 Problems Per Second
I started where I always start: Unity Profiler.
What I found:
11,900 Update() calls every second
CPU time: 15.6ms per frame (63.9 FPS ceiling)
Every Enemy, Tower, Projectile, StatusEffect running individual Update() methods
No separation of concerns. Monolithic architecture.
LINQ queries in hot paths (500 operations/second)
Physics.OverlapSphere called 500 times per second
The pattern:
500 enemies × Update() = 3,000 calls/sec
600 towers × Update() = 3,600 calls/sec
1,200 projectiles × Update() = 7,200 calls/sec
1,800 effects × Update() = 10,800 calls/sec
Total: 11,900 function calls per frame.
Classic monolithic Unity pattern. Easy to prototype but Impossible to scale.
The Business Translation:
Each new enemy variant: +500 Update() calls → FPS drops.
Each new tower type: +600 Update() calls → FPS drops.
Each new status effect: +1,800 Update() calls → FPS dies.
This architecture wasn't just slow. It was economically unsustainable. Adding content made the product worse.
The Solution: Incremental Transformation
I've seen teams try "big bang rewrites." They fail. You can't rewrite a production game while shipping features.
My approach: phased refactoring with measurable wins every week.
Each phase: implement new system → migrate entities → validate performance → move forward.
No rewrites. No production breaks. Just measurable progress.
Week 1: Movement System — Stop the Bleeding
The Problem:
500 enemies × Update() = 3,000 movement calculations per second. Each enemy running its own Update() method with individual transform updates.
The Solution:
Created MovementSystem — one system processing all moving entities in a single batch pass. Instead of 500 scattered Update() methods, one system method called 60 times per second.
How Batch Processing Works:
Replace individual entity updates with centralized system that iterates through all entities once per frame. Eliminates function call overhead, improves cache locality, enables compiler optimizations.
Results:
Update() calls: 3,000/sec → 60/sec (-98%)
CPU time: 15.6ms → 12.1ms (-22%)
FPS: 63.9 → 82.5 (+29%)
Business Impact:
Mobile testing jumped from 15 FPS to 28 FPS. Still not shippable, but progress visible in one week. Client reaction: "We can actually see this working."
Week 2: Attack & Effect Systems — Unlock Velocity
The Problem:
Tower targeting system running LINQ queries every frame, per tower:
OrderBy().FirstOrDefault() = memory allocations + sorting overhead
600 towers × 50 calls/second = 30,000 LINQ operations/second
Physics.OverlapSphere called 500 times/second for target scanning
The Solution:
LINQ Elimination: Replaced with manual iteration (25× faster, zero allocations)
Coroutine Scanning: Moved target acquisition to coroutines — 5 scans/sec instead of 50/sec
Batch Processing: Created AttackSystem and EffectSystem following same pattern
Results:
Update() calls: 12,100/sec → 50/sec total (-99.5%)
LINQ operations: 500/sec → 0 (-100%)
Physics queries: 500/sec → 50/sec (-90%)
FPS: 82.5 → 115.6 (+40% cumulative)
Business Impact:
New tower types now implement IAttacker interface — no Update() method needed.
Development time: 2 weeks → 2 days. That's 5× faster feature velocity. Same team. Same tools. Just better architecture.
Week 3: GPU Optimization — Future-Proof Performance
CPU bottleneck solved. But still not hitting 144 FPS target.
The Problem:
Frame Debugger revealed GPU bottleneck:
9,125 shadow-casting objects (including 3,000 decorative grid nodes!)
7,277 draw calls
SRP Batcher disabled (materials incompatible)
The Solution:
Shadow Optimization: Disabled shadows on decorative objects. Only gameplay entities cast shadows.
SRP Batcher: Refactored materials for compatibility. Grid nodes batched from 400 draws to 6.
Static Batching: Combined non-moving meshes.
Critical Learning: Stats Window doesn't show SRP Batcher savings — use Frame Debugger for accurate measurement.
Results:
Shadow casters: 9,125 → 83 (-99%)
Batches: 7,277 → 1,917 (-74%)
SetPass calls: 800 → 200 (-75%)
FPS: 115.6 → 144.1 (+25%, VSync capped)
Business Impact:
144 FPS = esports-ready performance. Stable, competitive, tournament-viable. Mobile: Now running 55-60 FPS on mid-range devices. Launch unblocked.
The Results: ROI in 8 Weeks
Investment:
3 weeks optimization work
Zero production downtime
No production regressions
ROI Delivered:
Mobile launch: 6-month delay eliminated, 2B user market unlocked
Dev velocity: 5× faster features (2 weeks → 2 days per tower)
Platform expansion: Desktop 144 FPS (esports-ready), mobile 55-60 FPS (shippable)
Technical debt: 6+ months maintenance avoided
Break-even: 8 weeks through development savings alone
The Math:
3 weeks investment paid for itself in 8 weeks through faster feature development. Mobile revenue and platform expansion were pure upside.
What Made This Possible
Incremental Approach: Each week delivered measurable value. Client saw progress weekly, not after 3 months.
Business-Focused Metrics: Translated technical wins into business outcomes:
+29% FPS → "Mobile testing viable"
LINQ elimination → "New towers: 2 days not 2 weeks"
144 FPS → "Tournament ready"
Documentation-Driven: Created 136 pages of handover documentation. Client can maintain and extend without vendor lock-in.
Zero Production Risk: Incremental migration with old code as fallback. Each system validated before moving forward.
Lessons for Your Project
Bad architecture isn't about FPS today. It's about cost tomorrow.
Your game might run "fine" right now. But ask:
Can you add features without performance degrading?
Can you port to mobile without a rewrite?
Can new developers be productive in 2 weeks instead of 3 months?
Is your architecture enabling growth or fighting it?
If development is getting slower with each feature, you have architectural debt. The cost isn't the optimization sprint. The cost is every month you delay while competitors ship faster, platforms stay blocked, and development costs compound.
Optimization isn't a cost. It's an investment with measurable ROI. This project: 3 weeks work, 8 weeks break-even, years of faster development unlocked.
Ready to Transform Your Project?
I specialize in taking struggling Unity projects and turning them into scalable, performant, developer-friendly codebases.
What you get:
Phased approach with weekly measurable wins
Business-focused metrics (not just FPS)
Complete documentation (no black box) Zero production risk (incremental migration)
Interested in similar results?
📂 Read the full technical breakdown: Here on GitHub
📚 Explore 136 pages of documentation: Here on GitBook
💬 Let's discuss your project: Get in touch
Performance problems are business problems. Let's solve both.
Like this project
Posted Jan 8, 2026
Optimized Unity game from 64 to 144 FPS in 21 days, enabling mobile launch.
