El audio observa los contratos del juego

905. Identidad de la lección

Módulo

2.14 — Audio

Lección

El audio observa los contratos del juego

Tipo académico

Concepto

Tipo de esquema

texto

Orden

1

Tiempo estimado

25–35 minutos

Esta lección establece un límite claro: los sistemas de juego deciden qué ocurrió, mientras que el audio observa esa decisión y presenta una respuesta adecuada. El módulo anterior es 2.13 — Persistencia.

906. Objetivo de aprendizaje

Después de esta lección, podrás relacionar eventos explícitos del juego con respuestas sonoras sin convertir la capa de audio en responsable del estado o las reglas del juego.

Este es un ejercicio de sistemas con un ejemplo hipotético o explícitamente etiquetado. No es historia de producción documentada de CONTRABAND salvo que se nombre un tema verificado.

907. Por qué importa

El audio resulta más fiable cuando reacciona a un contrato de juego estable, en lugar de intentar deducir el estado a partir de detalles de presentación. Así, una modificación de una regla no obliga a que cada respuesta sonora vuelva a implementar esa regla. También se crea un objetivo más claro para el trabajo generado por IA: el nombre del evento, sus datos y la respuesta del observador pueden revisarse por separado.

908. Conocimientos previos

Ya deberías poder distinguir una regla de juego de su presentación e identificar qué sistemas controlan el estado. El módulo anterior, 2.13 — Persistencia, es pertinente porque su lección Restaurar sistemas en un orden deliberado refuerza la responsabilidad de cada sistema, los contratos y la secuencia: un sistema debe recibir información válida antes de aplicarla o presentarla.

909. Concepto central

Los eventos de juego son contratos entre el sistema responsable de un hecho y los sistemas que responden a ese hecho.

Un evento debe comunicar un suceso significativo, como item_acquired, alarm_started o interaction_denied. El sistema de juego conserva la autoridad: valida la acción, modifica el estado y emite el evento únicamente cuando el suceso es real. Un observador de audio se suscribe al evento y elige un sonido, una variación o el silencio. No decide si se adquirió el objeto, no activa la alarma ni modifica el inventario.

Un contrato útil tiene tres partes:

1. Identidad del evento: un nombre estable que describa el suceso.
2. Datos relevantes: el contexto mínimo que necesitan los observadores, como la categoría del objeto o el nivel de alerta.
3. Respuesta del observador: una decisión de presentación tomada después de aceptar el hecho como verdadero.

El evento no es una orden para que el audio simule un resultado. Es una afirmación procedente de un sistema con autoridad: ese resultado ya ocurrió. El contenido de presentación sonora —la selección del sonido, su variación o el silencio— responde a ese hecho, pero no constituye la autoridad del juego.

910. Modelo mental

Usa el modelo autoridad–evento–observador:

La dirección es unidireccional:

acción del jugador → regla del sistema con autoridad → evento de juego → observador de audio → respuesta sonora

Si el observador de audio tiene que pedir al sistema de juego que decida si algo ocurrió, probablemente el límite está invertido. Si el evento incluye detalles internos que los observadores no necesitan, probablemente el contrato está demasiado acoplado. Una respuesta sonora puede comunicar un hecho del juego, pero no puede establecerlo.

911. Ejemplo concreto

Imagina un sistema de interacción que procesa un contenedor cerrado.

1. El sistema de interacción comprueba si el jugador cumple la condición de acceso.
2. Si se deniega el acceso, el sistema deja intacto el estado del contenedor.
3. Emite interaction_denied con un motivo breve, como locked.
4. El observador de audio relaciona interaction_denied: locked con un sonido breve y discreto de rechazo.
5. Otro observador, el de interfaz, puede mostrar un mensaje.

El observador de audio no debe desbloquear el contenedor porque un sonido se haya reproducido correctamente. Tampoco debe examinar una animación del botón para deducir que la interacción falló. Recibe el hecho del juego y lo presenta. El sonido de rechazo es contenido de presentación; la interacción denegada sigue siendo un resultado del que se responsabiliza el sistema de interacción.

Un segundo evento, container_opened, solo debe emitirse después de que el sistema con autoridad haya completado el cambio de estado. La respuesta sonora puede reproducir entonces un sonido de apertura, pero el sonido no demuestra que el contenedor esté abierto.

912. Extensión de cobertura: correspondencia de eventos en distintos contextos de juego

El mismo límite entre autoridad, evento y observador se aplica a varios contextos de juego. Primero identifica el resultado validado y después define la respuesta sonora:

Estos eventos solo deben emitirse después de que los sistemas responsables validen el resultado. El audio puede elegir u omitir una respuesta según los datos, pero no debe decidir si hubo daño, si se completó un objetivo, si una interacción tuvo éxito o si una llegada fue válida.

913. Error común

Un error frecuente es colocar decisiones de juego dentro de funciones de retorno de audio: por ejemplo, permitir que un controlador sonoro reduzca la munición, desbloquee un objeto o decida si una interacción tuvo éxito. De ese modo, un sistema de presentación adquiere autoridad por accidente. También aparecen dependencias ocultas: desactivar, retrasar o sustituir un sonido podría modificar el comportamiento del juego.

Otro error es emitir un evento para un intento y nombrarlo como si hubiera tenido éxito. open_button_pressed no equivale al contrato container_opened. El primero describe una entrada; el segundo describe un resultado de juego validado por el sistema con autoridad. La respuesta sonora debe distinguir qué tipo de hecho está observando.

914. Práctica guiada

Usa los siguientes candidatos de evento para un sistema de interacción sigilosa:

• button_pressed
• door_opened
• door_open_failed
• alarm_level_changed
• play_door_sound

Para cada candidato, toma tres decisiones:

1. ¿Es un hecho del juego validado por el sistema con autoridad, una señal de entrada o una orden de presentación?
2. ¿Debería consumirlo directamente un observador de audio?
3. Si es apropiado, ¿qué datos mínimos permitirían que el audio eligiera una respuesta?

Registra los candidatos apropiados en una tabla de autoridad–evento–observador. Añade una nota final que identifique las respuestas sonoras que podrían producirse al mismo tiempo o competir por la atención; utilizarás esos casos en la siguiente lección.

Después, elige un candidato y escribe un contrato breve con este formato:

Evento: door_open_failed
Autoridad: sistema de interacción
Datos: reason = locked
Respuesta de audio: señal breve de acceso denegado
Mutación del juego por audio: ninguna

Tu decisión principal consiste en determinar si el evento debe describir la entrada intentada o el resultado de juego validado. Prefiere el resultado cuando el audio deba comunicar lo que realmente ocurrió, y conserva los eventos de entrada solo cuando otro sistema tenga un motivo claro para observarlos.

915. Validación / evidencia

916. Ideas clave

• Los sistemas de juego controlan las reglas y los cambios de estado.
• Los eventos comunican hechos significativos mediante contratos explícitos.
• El audio debe observar los resultados del juego, no deducirlos ni autorizarlos.
• Los datos del evento deben aportar el contexto necesario para la presentación sin exponer detalles internos irrelevantes.

917. Siguiente lección

Siguiente: 2.14 L2 — Diseñar prioridades e interrupciones. Lleva a esa lección tu tabla completa de autoridad–evento–observador. Usa las respuestas que marcaste como simultáneas o en competencia para definir reglas de prioridad e interrupción sin transferir la autoridad del juego a la capa de audio.

918. Comprobación