Los modos controlan el dispositivo

205. Identidad de la lección

Módulo

1.4 — Controles y entrada

Lección

Los modos controlan el dispositivo

Tipo académico

Sistemas

Tipo de esquema

Texto

Orden

1

Tiempo estimado

20–30 minutos

Esta lección establece un sistema para asignar a modos explícitos la responsabilidad de interpretar las entradas del ratón y del teclado. El título usa «controlan» como una abreviatura: un modo no controla físicamente el dispositivo, sino que se encarga de interpretar determinadas entradas mientras está activo.

206. Objetivo de aprendizaje

Al terminar esta lección, podrás enumerar dos modos de entrada y especificar cómo relaciona cada uno determinadas entradas del ratón y del teclado con acciones de juego y resultados observables.

207. Por qué importa

Una misma entrada física puede tener significados distintos según la situación del juego. Mover el ratón puede girar la vista durante la exploración, seleccionar una opción durante una conversación o no producir ninguna respuesta del juego mientras está abierta una pantalla de pausa. Si estas correspondencias quedan implícitas, una función nueva puede hacer que un gestor inactivo responda cuando no debe.

Una tabla de modos ofrece un contrato visible para ti y para tu colaborador de programación con IA. Separa lo que hace físicamente el jugador, el significado que le asigna el modo activo y el resultado que puede observar después.

208. Conocimientos previos

Debes poder describir una acción del jugador con lenguaje cotidiano e identificar las entradas del ratón y del teclado que utiliza actualmente tu juego. La lección anterior, 1.ai-partner L3 — Valida qué ha cambiado, estableció la práctica de comprobar el comportamiento mediante evidencias observables.

209. Supuesto y alcance de la lección

Para este ejercicio, supón que solo hay un modo de juego o de interfaz activo a la vez. La tabla incluye únicamente las entradas delegadas a ese modo activo.

Un proyecto también puede reservar controles para otro responsable explícito, como un control global definido de forma deliberada. Los controles del navegador, del sistema operativo, de la plataforma y de accesibilidad quedan fuera de esta tabla y no deben bloquearse por accidente. Esta lección no desarrolla arquitecturas de entrada por capas, sistemas de reasignación ni la implementación de API de plataforma.

210. Concepto central

Un modo de entrada es un límite explícito para interpretar determinadas entradas físicas en una situación concreta del juego.

Distingue estos tres términos:

1. Entrada o evento físico: lo que ocurre en el dispositivo, como pulsar E, mover el ratón o hacer clic en un botón.
2. Acción de juego específica del modo: el significado que el modo activo asigna a esa entrada, como iniciar conversación, avanzar línea o seleccionar respuesta.
3. Resultado observable: el cambio que puede percibir el jugador, como la aparición de un panel de diálogo, la presentación de la línea siguiente o la ausencia de cambios en el juego.

El modo activo solo se encarga de interpretar las entradas que tiene asignadas. Si ni el modo activo ni otro responsable reservado de forma explícita gestionan una entrada, el resultado previsto puede ser que el juego no responda.

Una tabla útil muestra los tres niveles:

La tabla es un contrato de diseño antes de convertirse en un detalle de programación. Evita que gestores activos e inactivos asignen en silencio significados incompatibles a una misma entrada física.

211. Modelo mental

Usa esta prueba de interpretación:

ENTRADA → INTERPRETACIÓN → RESULTADO → OTRA VEZ

1. ENTRADA: Anota la entrada física, como una pulsación o un movimiento del ratón.
2. INTERPRETACIÓN: Identifica el modo activo y la acción de juego que tiene asignada esa entrada, si existe.
3. RESULTADO: Anota el único resultado observable permitido por esa correspondencia.
4. OTRA VEZ: Repite la prueba en el mismo modo y después de cambiar de modo.

Para cada entrada seleccionada, pregunta:

1. ¿Qué entrada física se ha producido?
2. ¿Qué modo de juego o de interfaz está activo?
3. ¿Qué acción de juego asigna ese modo a la entrada?
4. ¿Qué resultado observable debe producirse?
5. Si el modo activo no la gestiona, ¿hay otro responsable reservado de forma explícita?

Si ni el modo activo ni un responsable reservado gestionan la entrada, puede ser correcto que el juego no responda. Se trata de un límite deliberado, no de una indicación de que deban bloquearse todas las entradas de plataforma no gestionadas.

212. Ejemplo concreto

Imagina un juego con los modos Exploración y Conversación. En Exploración, pulsar E puede corresponder a la acción de juego iniciar conversación cuando el jugador está cerca de un personaje. Al comenzar el diálogo, se activa Conversación. Ahora, pulsar E corresponde a avanzar línea y produce otro resultado visible.

La entrada física no ha cambiado, pero el modo activo la relaciona con una acción de juego y un resultado diferentes. Del mismo modo, mover el ratón puede corresponder a girar la vista en Exploración, mientras que una acción del puntero sobre una respuesta visible puede corresponder a seleccionar respuesta en Conversación.

Esta separación evita usar la palabra «acción» de forma ambigua para referirse a la pulsación, a la orden interpretada y al cambio resultante en el juego.

213. Flujo de trabajo con IA

Usa la IA como asistente de especificación e implementación, no como autoridad sobre el diseño de los controles.

1. Escribe dos modos y sus correspondencias de entradas físicas antes de pedir código.
2. Para cada correspondencia, indica la entrada física, la acción de juego específica del modo y el resultado observable.
3. Pide a la IA que señale correspondencias duplicadas o incompatibles, incluidos los gestores inactivos que aún podrían procesar la entrada.
4. Decide qué conflictos son intencionales, están reservados para otro responsable explícito, son accidentales o siguen sin resolverse.
5. Pide a la IA que convierta la tabla aprobada en una breve lista de comprobación sin añadir modos, entradas, acciones ni resultados.
6. Realiza tú la prueba ENTRADA → INTERPRETACIÓN → RESULTADO → OTRA VEZ en ambos modos y compara el comportamiento observado con la tabla.

Un prompt útil es: «Esta es mi tabla de modos de entrada. Separa en cada fila la entrada física, la acción de juego del modo activo y el resultado observable. Señala correspondencias incompatibles, gestores inactivos que puedan responder y decisiones de ausencia de respuesta que falten. No añadas controles que no aparezcan en la tabla».

214. Error común

Un error frecuente es comprobar el modo en un solo gestor de entrada y dejar que otros gestores sigan respondiendo. El problema es la aplicación incoherente del contrato de diseño, no la representación elegida por sí sola. Un booleano puede representar correctamente dos estados excluyentes si todos los gestores pertinentes aplican la misma regla; resulta inseguro cuando las comprobaciones están incompletas o no significan lo mismo.

Otro error es suponer que toda entrada física debe producir un resultado en el juego. Una entrada puede carecer deliberadamente de correspondencia en el modo activo, siempre que la decisión sea explícita y no interfiera con controles reservados de la plataforma o de accesibilidad.

215. Práctica guiada

Crea una tabla de entrada con dos modos para una situación de juego pequeña. Usa Exploración y Conversación, o sustitúyelos por dos modos de tu propio diseño.

Para cada modo, anota:

• una entrada física del ratón o del puntero;
• la acción de juego específica del modo que tiene asignada;
• su resultado observable;
• una entrada física del teclado, su acción de juego y su resultado;
• una entrada que el modo no interpreta;
• si esa entrada no gestionada tiene otro responsable reservado o no produce respuesta en el juego.

Después toma una decisión deliberada sobre una entrada física que pueda tener significados distintos. Por ejemplo, decide si pulsar Escape cierra la conversación, abre la pausa mediante un responsable reservado de forma explícita o no produce respuesta en ese modo. Registra la decisión en vez de dejarla implícita.

Recorre la tabla dos veces:

• una mientras el primer modo está activo;
• otra después de cambiar al segundo modo.

En cada recorrido, sigue una entrada del puntero y una del teclado mediante ENTRADA → INTERPRETACIÓN → RESULTADO → OTRA VEZ. No escribas únicamente «gestionada». Indica la acción de juego y el resultado observable, o anota que ni el modo activo ni otro responsable reservado gestionan la entrada.

Por último, pregunta: ¿Dispone cada acción esencial de la interfaz de una alternativa adecuada que no dependa del puntero, y deja este modo intactos los controles de la plataforma y de accesibilidad?

216. Validación y evidencias

217. Ideas clave

• Una entrada física, una acción de juego específica del modo y un resultado observable son elementos distintos.
• Para este ejercicio, solo hay un modo de juego o de interfaz activo a la vez, y este interpreta únicamente las entradas que tiene asignadas.
• Otro responsable definido de forma explícita puede gestionar un control fuera de la tabla del modo activo.
• Si ni el modo activo ni un responsable reservado gestionan una entrada, la ausencia de respuesta del juego puede ser intencional.
• Un comportamiento fiable depende de aplicar el contrato del modo de forma coherente en todos los gestores pertinentes, no de una representación concreta del estado.
• Una tabla de modos puede orientar tanto la implementación humana como la asistencia de la IA.

218. Próxima lección

Continúa con 1.4 L2 — Reproduce antes de corregir. El siguiente paso consiste en convertir esta tabla de modos en una reproducción basada en el comportamiento observado: anotar qué hace realmente cada modo con cada entrada relevante, sin atribuir una causa antes de haber reproducido el comportamiento.

219. Comprobación