Veloren sostiene 500 jugadores con ECS y una estructura de vóxeles propia

Uno de los desarrolladores principales de Veloren ha publicado un repaso de las decisiones de diseño menos convencionales del proyecto, un juego de vóxeles open source escrito en Rust que arrancó en 2018. La más gorda: todo el motor se apoya en un ECS (Entity Component System) en vez de una jerarquía de clases al uso.

Según el autor, el resultado se nota en la escalabilidad. Veloren llega al 50% de utilización de núcleos en un servidor de 48 hilos con más de 500 jugadores conectados y decenas de miles de entidades interactuando a la vez. La mayoría de MMO solo alcanzan cifras así recortando el alcance del gameplay o repartiendo jugadores en shards.

Polimorfismo por defecto

En 2018 el patrón era raro fuera de demos y el equipo tuvo que inventarse conceptos propios. Con un ECS, el polimorfismo viene de serie y la taxonomía de entidades hay que optarla explícitamente, algo que ha dejado bugs curiosos. En un momento dado los jugadores heredaban un componente ItemDrop por el inventario que llevaban, de modo que podían 'recoger' a otros jugadores y expulsarlos del servidor al hacerlo. Con las monturas, la detección de ciclos y el paso de control estaban mal, y se podían apilar entidades montadas unas sobre otras o crear ciclos de montura mientras el motor de físicas peleaba contra restricciones contradictorias.

NPC y jugadores comparten código

En todo lo posible, un personaje jugador y un NPC son lo mismo. Ambos interactúan igual con la física: un NPC no puede teletransportarse ni falsear sus propiedades, y si su código de agente no tiene en cuenta el momento y la fricción al borde de un acantilado, se cae. Todas las órdenes de movimiento pasan por el componente Controller, una especie de gamepad virtual que en el caso del jugador alimentan teclado, ratón y mando, y en el del NPC el árbol de decisión. El controlador de movimiento, el árbol de habilidades y el sistema de experiencia son idénticos; en versiones anteriores hasta sonaban efectos de sonido cuando un NPC cercano subía de nivel.

'Chonks' y mundo pregenerado

Para guardar el terreno, los juegos de vóxeles suelen tirar de arrays 3D grandes, de RLE o de octrees, y cada opción tiene un problema serio: los arrays son rápidos pero comprimen poco, RLE solo comprime bien con bloques homogéneos y su acceso aleatorio es malo, y los octrees destrozan las cachés de CPU modernas. Veloren usa una estructura propia, los 'chonks': una tabla índice de un solo nivel donde grupos de NxNxN bloques se marcan como homogéneos o heterogéneos, y cada chonk se parte además en sub-chunks verticales de tamaño fijo. El equilibrio entre coherencia de caché y compresión sale bien parado, con buen acceso aleatorio.

El mundo tampoco se genera sobre la marcha como en Minecraft. Veloren lo pregenera entero al arrancar a baja resolución y rellena el detalle cuando el jugador se acerca, con interpolación y técnicas de ruido. Eso habilita cosas que la resolución local de restricciones no permite, como ríos largos que siempre fluyen cuesta abajo, y deja tiempo para simular el mundo antes de la partida. El código de esa simulación del mundo está en el repositorio.

La idea que subyace es la misma en los tres frentes: elegir estructuras y componentes que aguanten interacciones entre entidades a gran escala. Quien trabaje con ECS fuera de los videojuegos, o necesite almacenar volúmenes grandes de datos con acceso aleatorio, tiene aquí un caso real con números detrás. El autor cierra con una advertencia sobre la generación procedural que va más allá del motor: no consiste en contenido aleatorio, sino en definir restricciones entre elementos y mantener la autoconsistencia.