DOTS · ECS · Jobs · Burst
Performance measured in entities, not excuses
When your game needs thousands of units, bullets, or agents simulated at 60 fps — on phones — object-oriented Unity hits a wall. I build data-oriented gameplay with Unity DOTS: ECS architecture, jobified systems, and Burst-compiled hot paths, applied surgically where your game actually needs them.
What you get
- A profiling audit first — we find the real bottlenecks before rewriting anything
- ECS architecture for the systems that need it: units, projectiles, crowds, simulation
- Jobified, Burst-compiled hot paths that use every core the device has
- A hybrid approach — DOTS where it pays, GameObjects where it doesn't
- Frame-time budgets validated on your actual target hardware
- Documentation so your team can maintain and extend the data-oriented code
Proof, not promises
Backed by 12 years of making Unity games run on hardware players actually own — performance discipline learned shipping to mid-range Android long before DOTS made it fashionable.
Common questions
Do we need to rewrite our whole game in DOTS?
Almost never — and be suspicious of anyone who says yes. The winning pattern is hybrid: convert the measured hot paths (simulation, spawning, movement) to ECS and keep the rest as familiar GameObjects. You get the performance without a year-long rewrite.
Is DOTS production-ready?
Entities 1.x is production-ready for the right use cases, with real trade-offs in tooling and learning curve. Part of my job is telling you honestly whether your game needs DOTS, plain Jobs + Burst, or just better-written MonoBehaviours.
Tell me about your project
A short message is enough — what you're building, the platform, and roughly when you need it. I read every message and usually reply within a day.