Principios de una arquitectura evolutiva¶
No buscamos que todos los videojuegos utilicen las mismas clases. Buscamos limitar dónde aparece la complejidad y documentar cuándo una decisión deja de convenir.
Principios de referencia¶
Una fuente de verdad por estado. Puede haber réplicas visuales, caches o snapshots, pero debemos saber cuál es el dato autoritativo y quién puede modificarlo.
Intención, resolución y presentación son conceptos diferentes. El jugador solicita atacar, las reglas validan y resuelven, el render representa el resultado. La separación es conceptual: puede vivir en un mismo proceso.
Composición cuando hay variación; ECS cuando sus beneficios son reales. Evitá subclases por cada objeto. Pero no introduzcas arquetipos, chunks y sistemas masivos para una docena de personajes sin necesidad.
Los módulos deben tener límites. Una feature puede colaborar con otras por contratos; no debería alterar su estado privado de forma arbitraria.
La optimización se respalda con medidas. Multithreading, streaming, LOD y caches cuestan memoria, complejidad y posibilidad de depuración. Medí primero.
Progresión posible¶
flowchart LR
A["Prototipo"] --> B["Composición"]
B --> C["Módulos"]
C --> D["Autoridad / simulación"]
D --> E["Persistencia y pruebas"]
E --> F["Escala medida"]No es una secuencia obligatoria. Un juego multijugador requiere autoridad desde el principio, y un RTS puede beneficiarse de un diseño orientado a datos temprano. Un puzzle offline quizá nunca necesite ECS ni replicación.
Una decisión técnica debe ser revisable¶
Anotá el problema actual, la solución mínima descartada, las alternativas, los riesgos y la señal concreta para reconsiderarla. Un pequeño ADR es más útil que una arquitectura «correcta» sin justificación.
Para aplicar estos principios: ¿Por dónde empiezo?, Núcleo de simulación y scheduler, Módulos de gameplay y contratos, Probar la simulación y medir antes de optimizar.