Probar la simulación y medir antes de optimizar¶
Cuando un juego crece, la arquitectura empieza a depender de evidencias: ¿qué sistema consume CPU?, ¿qué parte es frágil?, ¿podemos recuperar una partida?, ¿una mecánica nueva rompe otras?
Pruebas por alcance¶
| Tipo | Qué comprueba |
|---|---|
| Regla aislada | Invariantes, límites y condiciones |
| Feature | Acciones y estado propio de un módulo |
| Simulación headless | Muchas entidades y ticks sin interfaz |
| Persistencia | Snapshot, restauración y migración |
| Topologías | Misma mecánica en local, host y dedicado |
| Replay | Divergencias y orden causal |
| Rendimiento | Presupuesto y tendencia de tiempos |
Un prototipo de validación arquitectónica¶
Podés construir un pequeño mundo de prueba con NPC, salud, inventario, comercio, combate y una misión que observa derrotas. Necesitás guardar y restaurar el estado y ejecutar la simulación sin renderer.
Ese prototipo debe obligarte a agregar una mecánica, modificar una definición YAML y cambiar una política de IA sin editar toda la solución. No busca ser un videojuego completo: busca detectar acoplamientos.
Qué medir¶
- Simulación: tiempo por tick promedio y p95; tiempo por sistema; ticks atrasados.
- Red: mensajes rechazados, ancho de banda, discrepancias y reconciliaciones.
- Persistencia: duración de guardar/cargar, tamaño, integridad y fallos de migración.
- Contenido: errores de referencias y tiempo de validación.
- Mantenimiento: archivos y módulos tocados para una mecánica; dependencias circulares.
- Mundos grandes: cantidad de entidades por nivel de detalle y presupuesto para NPC alejados.
Optimización basada en datos¶
Si un sistema tarda demasiado, identificá si el coste viene de memoria, iteración, IO, sincronización o algoritmos. Antes de migrarlo a ECS o paralelizarlo, tomá mediciones reproducibles; después repetilas bajo condiciones comparables.
Criterios de aprobación¶
La simulación ejecuta headless; una acción no depende de UI; una partida antigua migra; la misma regla funciona en las topologías objetivo; un replay muestra el primer punto de divergencia; y ninguna optimización se incorpora sin comparación antes/después.
Relacionado: Elegir un game loop, Núcleo de simulación y scheduler, Módulos de gameplay y contratos, Tres topologías: local, host-and-play y servidor dedicado, Guardado, versionado y replay.
Mencionado desde¶
- Arquitectura de videojuegos
- Composición, entidades y ECS
- Elegir un game loop
- Guardado, versionado y replay
- Hoja de ruta de la documentación
- Núcleo de simulación y scheduler
- Principios de una arquitectura evolutiva
- Receta: incorporar hambre a los personajes
- Tres topologías: local, host-and-play y servidor dedicado
- ¿Por dónde empiezo?