Saltar a contenido

Módulos de gameplay y contratos

Cuando un proyecto crece organizado únicamente en carpetas como Managers, Models, Systems y Helpers, localizar una mecánica puede requerir recorrer archivos por todas partes. Una alternativa es organizar por capacidades de gameplay.

game/
  simulation/        # reloj, scheduler, autoridad
  features/
    combat/          # reglas, acciones, efectos
    inventory/       # objetos, contenedores, propiedad
    quests/          # objetivos y progreso
    characters/      # atributos y necesidades
  presentation/      # UI, animación, audio, cámara
  infrastructure/    # guardado, transporte, assets

Estos límites no necesitan ensamblados ni servicios de red separados. Un monolito modular es razonable, y normalmente más simple de depurar.

Qué publica una feature

Su responsabilidad, los datos de los que es dueña, operaciones aceptadas, consultas, eventos útiles y pruebas. Otros módulos no deberían modificar sus colecciones internas directamente.

Una acción de ataque puede producir un resultado de daño que una misión observa. Combat no debería conocer el código de cada misión. Pero si Combat necesita comprobar un atributo, una consulta o contrato explícito puede ser más claro que convertir toda lectura en evento.

Dependencias y tiempo

Los eventos no arreglan todas las dependencias; también pueden ocultar relaciones y producir comportamientos difíciles de reproducir. Documentá cuáles son inmediatos, cuáles se encolan y en qué fase de simulación se resuelven.

Equipos y agentes de código

Definí una ficha de cada módulo con propietario del estado, interfaz pública, restricciones de dependencias, fases del tick y pruebas. Eso permite asignar tareas en paralelo sin que todos modifiquen el mismo archivo central.

Seguir: Agregar una mecánica sin acoplar todo el juego, Estado del mundo, definiciones e identidad, Intenciones, acciones y eventos, Cómo escribir, revisar y mantener capítulos.

Mencionado desde