Game Engines vs Bases de Datos: lo que Typhon une

El problema que nadie quiere admitir en servidores de juegos

Los servidores de juegos modernos viven atrapados en una contradicción incómoda. Por un lado, necesitan el rendimiento bruto de un motor de videojuego: decenas de miles de entidades actualizadas en cada tick a 60 frames por segundo. Por otro, necesitan lo que ofrecen las bases de datos: transacciones que no corrompan el estado, consultas selectivas y durabilidad que sobreviva a un crash.

El resultado habitual es un apaño: un framework Entity-Component-System (ECS) para la velocidad, con serialización manual hacia Redis o PostgreSQL para la persistencia. O una base de datos para la seguridad, con un mismatch de impedancia cada vez que se toca el estado del juego. Ninguna opción es elegante y ambas generan deuda técnica.

Typhon, un proyecto open-source escrito en .NET / C# por el desarrollador Nockawa, plantea que esta dicotomía no tiene por qué existir. Y para entender por qué, primero hay que entender lo que los motores de videojuegos saben sobre los datos que las bases de datos olvidaron.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

ECS y bases de datos relacionales: dos mundos que llegaron al mismo lugar

La arquitectura ECS evolucionó en los motores de videojuegos. Las bases de datos relacionales evolucionaron en el software empresarial. Nunca hablaron entre sí. Pero si observas lo que construyeron cada uno, la similitud estructural es asombrosa:

Archetype (ECS) ↔ Table (DB): almacenamiento homogéneo con esquema fijo.
Component (ECS) ↔ Column (DB): datos tipados, iterables en bloque.
Entity (ECS) ↔ Row (DB): identidad con composición dinámica.
System (ECS) ↔ Query (DB): procesar todos los registros que coinciden con una firma.
Frame Budget 16ms (ECS) ↔ Latency SLA (DB): deadlines de tiempo real.

Dos campos separados por décadas y fronteras industriales convergieron en soluciones estructuralmente idénticas porque estaban resolviendo el mismo problema fundamental: gestionar datos estructurados bajo restricciones de rendimiento. Esta convergencia es exactamente la que hace posible una síntesis como Typhon.

Lo que los motores de videojuegos enseñan sobre datos

Localidad de caché por defecto

En un almacenamiento de filas tradicional, leer todas las posiciones de los jugadores implica cargar filas enteras: nombres, inventarios, puntos de vida, todo. La mayoría de esos bytes son desperdicio. En ECS, los componentes se almacenan por tipo: todas las posiciones contiguas, todos los valores de salud contiguos. Leer 10.000 posiciones es un escaneo lineal de memoria donde cada byte es útil.

Esto importa más de lo que la mayoría de los desarrolladores cree. Un hit de caché L1 cuesta aproximadamente 1 nanosegundo. Un fallo en DRAM cuesta entre 60 y 70 ns, una penalización de hasta 65x. Cuando el layout de tu base de datos fuerza fallos de caché constantes, ninguna optimización algorítmica puede salvarte.

Zero-copy como comportamiento por defecto

En una base de datos tradicional, leer un registro implica deserializarlo desde una página de almacenamiento hacia un objeto en memoria del lenguaje. En ECS, un componente ya está en memoria en su layout final: simplemente devuelves un puntero. Typhon preserva esto: los componentes son structs unmanaged blittables leídos directamente desde páginas de memoria fijadas. Sin serialización, sin allocations en el heap administrado, sin involucrar al garbage collector.

La entidad como identidad pura

En ECS, una entidad es solo un ID, un número de 64 bits sin estructura inherente. Toda la información vive externamente en tablas de componentes. Esto es lo opuesto del pensamiento ORM, donde el objeto es la entidad. Typhon hereda esto: EntityId es un value type ligero; todo el estado vive en almacenamiento de componentes tipados. Esta separación es lo que hace posible el versionado por componente, los modos de almacenamiento independientes y los índices por tipo de componente.

Lo que las bases de datos tradicionales aportan al modelo

Transacciones ACID con MVCC por componente

Los motores de juego típicamente no tienen aislamiento. En un servidor de juego con sesiones de jugadores concurrentes, dos sistemas modificando la misma entidad al mismo tiempo es una condición de carrera que no puedes controlar con orden de ejecución.

Las bases de datos resolvieron esto hace décadas con MVCC (Multiversion Concurrency Control): aislamiento por snapshot donde los lectores nunca bloquean a los escritores, con detección de conflictos en el momento del commit. Typhon adopta esto con un twist importante: las bases de datos tradicionales versionan filas enteras. Typhon versiona cada componente de forma independiente. El PositionComponent y el InventoryComponent de una entidad mantienen sus propias cadenas de revisión: un buffer circular de entradas de 12 bytes, cada una marcada con un número de secuencia de transacción de 48 bits.

Esto significa que una transacción que lee la posición de un jugador ve un punto congelado en el tiempo consistente a través de todos los tipos de componentes, sin bloquear ninguno. Actualizar la posición de un jugador no crea una nueva versión de su inventario. Menos datos copiados, menos basura para recolectar.

Acceso selectivo con índices

Los sistemas ECS iteran todo lo que coincide con una firma de componente en cada tick. Eso funciona brillantemente para simulaciones de partículas. Pero los servidores de juego a menudo no necesitan procesar todas las entidades:

Battle royale (relevancia por cliente): 50.000 actores totales, se procesan 500–2.000 por tick (1–4% del total).
MMO área de interés: 100.000 entidades, se procesan 200–1.000 (0,2–1%).
Física (solo cuerpos activos): subconjunto del 5–20%.

Cuando procesas el 1–4% de tus entidades, escanear todo implica hacer entre 25 y 100 veces más trabajo del necesario. Las bases de datos resuelven esto con índices: B+Trees para búsquedas por valor, árboles espaciales para consultas de área de interés, estimación de selectividad para decidir cuándo escanear vs. cuándo buscar. Typhon incorpora estas capacidades al modelo de almacenamiento de componentes como ciudadanos de primera clase, no como parches añadidos.

Índice espacial integrado

Para los patrones de acceso espacial, la necesidad de acceso selectivo número uno en servidores de juego, Typhon integra un índice espacial de dos capas directamente en el almacenamiento de componentes:

Capa 1: Mapa hash disperso — mapea celdas de grilla gruesas a conteos de entidades. Rechazo O(1) de regiones vacías antes de tocar el árbol.
Capa 2: R-Tree respaldado por páginas — consultas AABB, radio, rayo, frustum y kNN. Misma arquitectura SOA que los B+Trees.

Ambas capas corren dentro del mismo modelo transaccional que todo lo demás. Sin hash espacial externo, sin destrucción de localidad de caché por perseguir punteros hacia una estructura de datos separada.

Durabilidad configurable por operación

Una base de datos para servidores de juego debe reconocer que no todos los datos tienen el mismo valor. Typhon permite elegir el modo de durabilidad por unidad de trabajo:

Modo Deferred: latencia de commit al estilo motor de juego, ideal para actualizaciones de posición que pueden re-simularse en caso de crash.
Modo Immediate: garantías al estilo base de datos con fsync inmediato, ideal para la transacción que concede un ítem raro que vale dinero real.

El mismo motor, la misma API. El servidor de juego decide por operación, no globalmente.

Modos de almacenamiento: no todos los datos son iguales

Un servidor de juego real no trata todos los datos de la misma manera. Las posiciones de los jugadores cambian 60 veces por segundo y pueden re-simularse tras un crash. Las mutaciones de inventario son raras pero nunca deben perderse. El estado runtime de la IA —objetivos actuales, puntuaciones de amenaza, puntos de ruta— se recalcula en cada tick y no tiene valor después de un reinicio.

Typhon ofrece tres modos de almacenamiento por tipo de componente:

Versioned: cadenas completas de revisión MVCC, persistencia WAL + checkpoint. Ideal para inventario, economía, progresión.
SingleVersion: solo estado actual, persistencia WAL + checkpoint con seguimiento via DirtyBitmap. Ideal para posiciones, salud, estado frecuentemente actualizado.
Transient: solo estado actual, sin persistencia. Almacenamiento puro en memoria para datos de IA que se recalculan en cada tick.

Views: el puente entre sistemas ECS y consultas de base de datos

En ECS, un "system" corre en cada tick procesando todas las entidades que coinciden. En una base de datos, una "materialized view" mantiene un conjunto de resultados en caché y lo refresca incrementalmente. Las Views de Typhon son ambas cosas a la vez.

Tras la creación inicial con ToView(), el método Refresh() drena un ring buffer lock-free de cambios enviados por el commit path. Solo las entidades cuyos campos indexados realmente cambiaron son re-evaluadas. Si 100.000 entidades coinciden con tu vista pero solo 12 cambiaron desde el último refresh, haces 12 evaluaciones, no 100.000. Este es el problema de "iterar todo" resuelto desde el lado de la base de datos: no re-escanear, rastrear deltas.

Por qué esto importa para founders tech y productos SaaS en tiempo real

La síntesis que propone Typhon no es solo relevante para estudios de videojuegos. Cualquier producto SaaS que maneje sesiones concurrentes con estado en tiempo real —plataformas de trading, simuladores, aplicaciones de colaboración en vivo, juegos en la nube— enfrenta exactamente el mismo trade-off: velocidad de motor de juego o seguridad de base de datos.

Los patrones de datos que Typhon formaliza (cache locality, zero-copy, MVCC por componente, índices espaciales integrados) son principios de ingeniería que cualquier equipo técnico puede adoptar al diseñar su capa de persistencia. Proyectos como Bevy (ECS en Rust), Unity DOTS y ScyllaDB (diseño columnar cache-aware) apuntan en la misma dirección: los próximos 10 años de infraestructura de datos de alto rendimiento estarán profundamente influenciados por los principios de diseño orientado a datos que los motores de videojuegos perfeccionaron durante décadas.

Para founders que construyen productos en tiempo real, entender estos patrones no es un ejercicio académico: es ventaja competitiva directa en latencia, costos de infraestructura y capacidad de escalar sin rediseñar la arquitectura desde cero.

Conclusión

Los motores de videojuego y las bases de datos relacionales llegaron de forma independiente a estructuras de datos casi idénticas porque estaban resolviendo el mismo problema bajo las mismas leyes de la física del hardware. Typhon es el primer intento serio de formalizar esa convergencia en un motor de base de datos embebido, persistente y con garantías ACID, diseñado desde cero para los patrones de acceso de servidores de juego en tiempo real.

Los principios que lo sustentan —localidad de caché, acceso zero-copy, MVCC por componente, durabilidad configurable, índices espaciales integrados— son lecciones que cualquier equipo técnico que construya sistemas de alta concurrencia debería tener presentes. Lo que los motores de videojuego saben sobre datos no es trivia de nicho: es ingeniería de sistemas en su forma más destilada.

Profundiza estos temas con nuestra comunidad de expertos en arquitectura de datos y startups tech

Unirse a la comunidad