Skip to content
Crowd Control
← Devlog

A core that never knows the game

· 2 min read
netngine architecture

The one design decision everything else in NetNgine hangs off is this: the engine core never knows the rules of the game running on top of it. It sounds obvious written down. In practice it’s the thing that’s easiest to quietly break, and the thing that keeps the whole project maintainable when you don’t.

Small, fixed contracts

The engine is split into modules, each with a minimal public contract that stays stable as everything behind it changes:

  • an ECS core for the world and its entities,
  • a transport layer over UDP,
  • snapshot sync — generating and applying the deltas that keep clients in agreement,
  • interest management, so a client only hears about what’s near it,
  • persistence, for the state that has to outlive a session,
  • and sharding, for splitting a world across processes.

A game is added by implementing a game module against those contracts. The core never grows a special case for it. If I catch myself wanting to reach from the engine into game rules, that’s the signal something is wrong with the boundary, not the game.

Boring demos on purpose

Each demo exists to stress one part of the engine, not to be fun. A ping-pong movement demo exercises the core sync loop — prediction, reconciliation, interpolation. A shooter demo pushes grid-based interest management and lag-compensated hit detection. A two-zone world runs the same engine across two processes and hands a player from one to the other. There’s an inventory demo whose only job is to prove persistence with a real database.

They’re deliberately unglamorous. But because each one is small and pointed, when something regresses I know exactly which contract I broke.

Keeping it honest under load

The last piece is a headless load test: a few hundred simulated clients — up to five hundred — connecting to a running server, so I can watch tick timing, bandwidth and ping hold up (or not) under sustained pressure, with the numbers going to Prometheus and a Grafana dashboard. A networking project can’t demonstrate competence with a slow, hand-wavy claim; it has to show the graph.

None of this is trying to beat commercial networking middleware. It’s a bounded, honestly-built base that I understand end to end — which, for now, is exactly the point.