Saltar a contenido

Empezar un juego sin diseñar un framework

Al principio, la prioridad es comprobar una hipótesis jugable. Debemos saber si el jugador puede realizar una acción interesante, observar sus consecuencias y repetir ese ciclo. La arquitectura es un medio para experimentar, no un objetivo separado.

Un gameplay loop —por ejemplo explorar, reunir recursos, fabricar una herramienta y acceder a otra región— no es lo mismo que el bucle técnico de actualización. El primero explica qué hace el jugador; el segundo, cuándo y cómo avanza el mundo.

La primera versión

  1. Describí el ciclo jugable con una situación concreta.
  2. Representá el estado estrictamente necesario.
  3. Implementá una intención y su consecuencia.
  4. Mostrá el resultado en pantalla.
  5. Repetí el experimento y verificá si produce la experiencia buscada.

Una implementación sencilla con objetos tradicionales y llamadas directas es válida. Desde temprano, conviene distinguir la tecla de ataque de la regla que calcula el daño: la interfaz pide, el simulador decide. Esto no obliga a construir un servidor, pero abre el camino a Autoridad: quién puede cambiar el mundo.

Qué conviene postergar

No implementes sistemas genéricos de abilities, soporte de mods, infraestructura distribuida ni ECS completo por si algún día los necesitás. Cuando las capacidades de una entidad empiezan a combinarse, la composición puede resolver ese problema. Cuando hay decenas de variantes de datos, incorporá Gameplay dirigido por datos y comportamientos declarativos. Cuando nuevas mecánicas requieren editar otros subsistemas, extraé módulos de gameplay.

El objetivo es conservar fronteras reemplazables, no anticipar cada posible función.


Mencionado desde