Joshua Barretto, one of Veloren’s core developers, wrote up the choices his team made that run against the grain — the open-source multiplayer voxel RPG started in 2018 and is still going. Most of the post is about what those decisions cost, which is what makes it worth reading.

  • ECS from day one. Started before ECS was common outside demoware, so the team invented internal concepts to make it work. Payoff: 50% core utilisation on a 48-thread server with 500+ players and tens of thousands of interacting entities — without sharding or shrinking gameplay scope.
  • ECS inverts the default. In a class hierarchy, polymorphism is opt-in; with an ECS it is the default and taxonomy is what you opt into. Consequences included players getting an ItemDrop component for their carried items and being able to pick each other up, and mount cycles producing towers of entities riding each other.
  • Players and NPCs obey identical rules. NPCs use the same physics, the same Controller component (a virtual gamepad fed by keyboard for players and a decision tree for NPCs), the same movement code, and the same skill tree. If the agent code ignores momentum at a cliff edge, the NPC falls off.
  • Voxels are stored as “chonks”. Not big arrays, not RLE, not octrees — an index table marking NxNxN groups homogeneous or heterogeneous, split into vertical sub-chunks. Trades compression against cache coherence, keeps random access fast.
  • The world is pre-generated. Full map at low resolution on startup, details filled in near the player. That is what makes long rivers always flow downhill possible; local constraint solving cannot express it. It also gives free level-of-detail for distant terrain.
  • Generation is ontological, not teleological. Rather than judging outputs by whether they look right, Veloren models physical inputs and simulates them — hydraulic erosion for terrain and rivers, a traversal-cost model for paths.
  • RTSim never stops. Leaving a player’s view does not despawn an NPC; it gets a low-resolution dual that keeps running its decision tree. Quests, faction dynamics and parts of the economy live there, tracking tens of thousands of NPCs at once.
  • No invisible walls, one world space. Pulling a boss out of its dungeon into a town is allowed, which forces systems to be designed defensively. No loading screens means cave networks a kilometre deep must not leak surface lighting — global effects like lightning keep finding ways through shadow maps and screen-space reflections.

The best paragraph in the post is the aside on what procedural generation actually is: not random content, but constraints that produce self-consistency. Good generators need almost no randomness, because randomness is what the player brings — the generator’s job is to coerce it into a system with consequences. If you find a river you should be able to follow it to the source; if you kill a monster, the nearest town should notice.

The recurring theme is that constraints make better systems than features do. “No invisible walls” and “one world space” are rules, not mechanics, and both of them forced the team to build defensively rather than patch around exceptions later.