Intenciones, acciones y eventos¶
Un comando representa algo que un actor quiere que suceda. Un evento comunica algo que ya sucedió. Una consulta busca información sin modificar el mundo. No son categorías intercambiables.
flowchart LR
A["IA / Input"] --> C["Intentar atacar"]
C --> V["Validación"]
V --> S["Aplicar daño"]
S --> E["EntityDamaged"]
E --> Q["Quest / UI / Audio"]Command¶
Es útil cuando necesitamos separar entrada y reglas, reintentar acciones bajo control, registrar intenciones, enviarlas por red o probar una misma operación desde un bot. No hace falta crear una clase Command por cada botón si una llamada explícita resuelve bien el caso.
Un intento puede fallar. El resultado debería explicar por qué sin fabricar un evento exitoso.
Evento y Observer¶
Una consecuencia confirmada puede interesar a múltiples subsistemas. Una misión puede observar que murió una entidad; audio puede reproducir un sonido; UI puede actualizar un marcador. Las observaciones no deberían reinterpretarse como permiso para reescribir arbitrariamente el resultado.
Elegí conscientemente entre entrega inmediata y encolada. La cola introduce desacoplamiento temporal, pero obliga a definir orden, reentradas, capacidad y qué sucede al cambiar de escena o tick.
No convertir el bus en el sistema nervioso del mundo¶
Si un módulo necesita una respuesta inmediata de otro módulo conocido, un contrato directo suele ser más claro. Un bus global con cientos de eventos puede esconder causalidad e impedir depuración.
Acciones de varios sistemas¶
Consumir una poción requiere comprobar el objeto, aplicar salud y descontar inventario. Una transacción lógica o resolvedor de efectos puede coordinar estos pasos. Definí de antemano el tratamiento de fallos y duplicaciones; los eventos no garantizan atomicidad.
Relacionado: Autoridad: quién puede cambiar el mundo, Módulos de gameplay y contratos, Agregar una mecánica sin acoplar todo el juego, Guardado, versionado y replay.
Fuente: Game Programming Patterns — Command y Event Queue.