Projects using C# in AktobeProjects using C# in AktobeIn the December 2025 - wrapped up this Unity Tower Defense overhaul! š
Started with legacy spaghetti code, tight coupling, and Update() hell. Over 6 phases, rebuilt with ECS-inspired systems, runtime fixes, pooling, GPU instancing, SRP Batcher & shadow optimization.
Results:
ā¢ +125% FPS (63.9 ā 144.1 VSync-locked)
ā¢ 99.5% fewer Update() calls
ā¢ 74% batch reduction (7,277 ā 1,917)
ā¢ 99% shadow casters cut (9,125 ā 83)
Outcome: Scalable codebase + ~136 pages of docs (architecture, metrics, handover guide). Locked at 144 FPS - rewarding! š
Aztoon Lab
Github (https://github.com/aztoon-lab/unity-optimization-case-TD.git) | LinkedIn (https://www.linkedin.com/in/aztoon-lab/?lipi=urn%3Ali%3Apage%3Ad_flagship3_detail_base%3B4dpKXccQTWKEVLrz1pfCcA%3D%3D) | GitBook Showcase (https://aztoon-lab.gitbook.io/) | Batch Processing: how I reduced CPU overhead by 99.5% in Unity
Working on tower defense optimization. Initial state: 64 FPS, game lags at wave 7.
Opened Profiler - found the problem: 11,900 Update() calls per second.
Every Enemy, Tower, Projectile, StatusEffect had its own Update() method.
The Problem: 500 enemies Ć Update() = 3,000 calls/sec 600 towers Ć Update() = 3,600 calls/sec
1,800 effects Ć Update() = 10,800 calls/sec Total: 11,900 calls/frame
The Solution: System-based architecture
Instead of 500 individual Update() ā one MovementSystem.Tick() processing all entities in a single pass.
Results:
Update() calls: 11,900/sec ā 50/sec (-99.5%)
CPU time: 15.6ms ā 6.9ms (-56%)
FPS: 63.9 ā 144.1 (+125%)
Key takeaway: Batch processing beats individual updates 20Ć in performance.
#Unity3D #SystemArchitecture 
