234. Identidad de la lección
Esta lección utiliza el caso aprobado pointer-lock-dialogue. Su alcance es limitado: documenta un conflicto entre un contexto de control de vuelo que utiliza el bloqueo del puntero y unas opciones de diálogo pensadas para seleccionarse con el cursor. No documenta una traza exacta de eventos, una causa de implementación ni una solución demostrada.
235. Objetivo de aprendizaje
Al finalizar esta lección, podrás identificar los dos modos de interacción que compiten en el caso aprobado, separar la observación aportada por el caso de las hipótesis de implementación y proponer una prueba de una sola variable que ayude a distinguir entre posibles explicaciones.
236. Por qué importa
Un mismo dispositivo apuntador puede servir a distintos sistemas en momentos diferentes. Un modo de control de vuelo puede utilizar el movimiento del puntero como entrada de juego, mientras que un modo de diálogo puede necesitar el cursor para señalar opciones visibles. Cuando esos requisitos se solapan, identificar los modos y probar la transición entre ellos es más preciso que suponer que se perdió un evento o que una API concreta seguía activa.
Esta disciplina también permite entregar a un asistente de programación con IA un informe acotado: qué establece el caso, qué sigue sin saberse y qué conviene probar a continuación.
237. Conocimientos previos
Ya deberías poder:
- distinguir un resultado observado de una causa supuesta;
- reproducir un problema de controles antes de proponer una corrección;
- utilizar ACTUAR → RESPONDER → CAMBIAR → REPETIR para comparar dos condiciones.
La lección anterior, Reproduce antes de corregir, proporciona esa disciplina de evidencia.
238. Límite terminológico
Utiliza bloqueo del puntero al hablar de este caso documentado.
Pointer Lock y la captura de puntero de la API Pointer Events son mecanismos distintos del navegador. Esta lección no trata ambos términos como equivalentes ni afirma que la captura de puntero interviniera en el caso.
La expresión control del dispositivo es solo un modelo de razonamiento utilizado en esta lección. Sirve para preguntar qué sistema debería controlar el dispositivo apuntador en un modo determinado. No designa un estado literal de una API del navegador.
239. Registro acotado del caso
Estas son todas las evidencias aportadas para esta lección:
| Campo del registro | Afirmación aprobada del caso |
|---|---|
| Configuración | Un contexto de control de vuelo utiliza el bloqueo del puntero y un diálogo presenta opciones pensadas para seleccionarse con el cursor. |
| Acción del jugador | El jugador intenta seleccionar una opción de diálogo mientras se solapan los requisitos de ambos modos de interacción. |
| Resultado observado | El caso aprobado registra un conflicto entre el bloqueo del puntero y la interacción con las opciones seleccionables del diálogo. |
El resultado anterior es un hecho aportado por el caso. No se proporciona ningún artefacto ni traza de eventos que permita deducir un síntoma más concreto. Por tanto, esta lección no afirma que se descartara un clic, que un evento concreto no llegara a la interfaz, que el bloqueo del puntero siguiera activo en un fotograma determinado ni que un parche conocido resolviera el conflicto.
240. Concepto central
Dos modos pueden exigir usos incompatibles del mismo dispositivo apuntador.
En este caso, los modos que compiten son:
- Modo de control de vuelo: utiliza el bloqueo del puntero como parte del control del juego.
- Modo de selección de diálogo: necesita el cursor para señalar opciones de diálogo visibles.
El problema debe describirse como una incompatibilidad entre modos de interacción o como la falta de disponibilidad del señalamiento mediante cursor cuando se necesita. Esta descripción acotada no presupone que se hayan perdido eventos de la interfaz.
La pregunta diagnóstica es:
¿Qué sistema debería controlar el dispositivo apuntador en este momento y qué parte de esa afirmación está respaldada por el registro del caso?
241. Modelo de evidencia
Clasifica cada afirmación como Observación, Hipótesis o Evidencia de prueba.
| Afirmación | Clasificación | Motivo |
|---|---|---|
| El caso combina un control de vuelo con bloqueo del puntero y opciones de diálogo seleccionables con el cursor. | Observación | Forma parte de la configuración aprobada. |
| El jugador intenta seleccionar una opción mientras se solapan los requisitos de ambos modos. | Observación | Forma parte de la acción aprobada. |
| Los dos modos de interacción entran en conflicto. | Observación | Es el resultado observado que aporta el caso. |
| El bloqueo del puntero seguía activo en un fotograma concreto. | Hipótesis | El registro no incluye una traza de ese estado. |
| Se perdió un evento de la interfaz. | Hipótesis | El registro no contiene evidencias sobre eventos. |
| Cambiar una condición del modo altera el resultado del mismo intento de selección. | Evidencia de prueba, si se registra | Procede de una comparación controlada, no del hecho aportado por el caso. |
Una observación expresa lo que aporta el registro aprobado. Una hipótesis propone una explicación que todavía necesita evidencia. La evidencia de prueba solo aparece después de realizar y registrar una comparación controlada.
242. Ciclo de diagnóstico
Aplica el ciclo de la lección sin dar por sentada una causa:
- ACTUAR: repite el mismo intento de seleccionar una opción de diálogo.
- RESPONDER: registra el resultado visible sin deducir una ruta de eventos ni un estado de API.
- CAMBIAR: modifica una sola condición relevante del modo.
- REPETIR: realiza de nuevo el mismo intento de selección y compara el resultado visible.
Debes indicar con precisión qué condición has cambiado. Si modificas a la vez varias reglas de entrada, elementos de interfaz y asignaciones, la comparación no permitirá saber qué cambio fue relevante.
243. Clasificación resuelta
Considera estas tres afirmaciones:
- «El caso sitúa el control de vuelo con bloqueo del puntero y las opciones de diálogo seleccionables con el cursor en el mismo límite de interacción».
- «El bloqueo del puntero seguía activo cuando el jugador intentó realizar la selección».
- «Repite el intento de selección después de cambiar únicamente si el diálogo se trata como el modo activo de interacción con el dispositivo apuntador».
Clasifícalas así:
- La afirmación 1 es una observación aportada por el caso.
- La afirmación 2 es una hipótesis, porque el caso no proporciona un registro de estado fotograma a fotograma.
- La afirmación 3 es un plan de prueba, porque modifica una sola condición y repite la misma acción.
Si el segundo intento produce una diferencia registrada, esa comparación se convierte en evidencia de prueba. Puede respaldar o debilitar la hipótesis, pero no demuestra por sí sola una causa completa de implementación ni una solución definitiva.
244. Práctica guiada
Completa la tabla utilizando únicamente el registro acotado del caso.
| Indicación | Tu respuesta | Clasificación requerida |
|---|---|---|
| ¿Qué dos modos de interacción compiten? | Nombra el modo de vuelo con bloqueo del puntero y el modo de selección de diálogo mediante cursor. | Observación |
| ¿Qué intenta hacer el jugador? | Describe la acción de selección sin añadir una traza de eventos. | Observación |
| ¿Qué condición exacta de implementación causa el conflicto? | Escribe «el registro aportado no lo establece» y, si resulta útil, añade una posible explicación. | Desconocido más hipótesis etiquetada |
| ¿Qué única condición cambiarías? | Indica una sola condición del modo. | Plan de prueba |
| ¿Qué compararías? | Registra el resultado visible del mismo intento antes y después del cambio. | Evidencia de prueba tras ejecutarla |
Ahora elige la primera prueba que mejor permita distinguir entre explicaciones:
- A: Cambiar varias asignaciones, sustituir la interfaz del diálogo y modificar la transición de modo al mismo tiempo.
- B: Mantener sin cambios la acción del jugador y el diálogo, modificar únicamente qué modo de interacción controla el dispositivo apuntador y repetir el intento de selección.
- C: Repetir el intento original sin cambiar ni registrar ninguna condición.
Elige B. Examina el límite identificado por el caso y mantiene constantes la acción y la interfaz. Sigue siendo una propuesta de prueba, no un parche verificado.
Redacta una justificación de dos frases:
- una observación copiada o parafraseada fielmente a partir del registro del caso;
- una hipótesis etiquetada de forma explícita que la prueba pueda respaldar o debilitar.
245. Errores comunes
Tratar el bloqueo y la captura del puntero como sinónimos
Son mecanismos distintos. El caso documentado se refiere al bloqueo del puntero. No lo renombres como captura de puntero.
Tratar el control del dispositivo como un estado literal de una API
Es un modelo de diagnóstico para hablar de qué sistema debería controlar el dispositivo apuntador. Si más adelante se dispone de evidencias, habrá que verificar por separado el estado real de las API.
Inventar un síntoma que no consta en el caso
El registro aportado establece un conflicto, pero no especifica que se perdiera un evento ni qué sistema lo recibió. Durante una reproducción, anota únicamente el resultado visible.
Presentar un cambio plausible como solución demostrada
Una comparación de una sola variable puede aportar evidencia a favor o en contra de una hipótesis. No demuestra una solución completa sin validación adicional.
246. Validación
Tu trabajo es suficiente cuando incluye:
- el modo de control de vuelo que utiliza el bloqueo del puntero;
- el modo de selección de diálogo que necesita el cursor;
- la configuración, la acción del jugador y el conflicto observado que aporta el caso;
- una distinción clara entre bloqueo del puntero y captura de puntero;
- una explicación de implementación etiquetada como hipótesis;
- una prueba que modifique una sola condición del modo;
- el resultado visible que se comparará antes y después del cambio.
No afirmes que el bloqueo del puntero seguía activo en un fotograma concreto, que se perdió un evento de la interfaz o que un parche determinado resolvió el caso, salvo que otras evidencias lo demuestren.
247. Ideas clave
- El caso documentado se refiere al bloqueo del puntero, no a la captura de puntero.
- El control del dispositivo es un modelo de razonamiento, no un estado literal de una API.
- El hecho aportado por el caso establece un conflicto entre dos modos incompatibles de interacción con el puntero.
- La condición exacta de implementación y la solución siguen sin establecerse.
- Una prueba útil cambia una sola condición del modo y repite la misma acción del jugador.
248. Siguiente lección
Continúa con 1.5 — Cámara.
Conserva la tabla de evidencias y elige en ella un momento de control observado. En la próxima lección, utiliza ese momento para escribir una frase de intención acotada que indique qué debe ver el jugador, sin añadir una explicación de implementación no verificada.
249. CONTRABANDO
- Clasificación: Diálogo con bloqueo del puntero
- Uso en esta lección: Caso aprobado que establece un conflicto entre el control de vuelo con bloqueo del puntero y las opciones de diálogo seleccionables con el cursor.
- Límite: El caso no establece una traza exacta del síntoma, una causa de implementación, fechas, métricas, historia adicional del proyecto ni una solución demostrada.
250. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
Un modo de control de vuelo utiliza el bloqueo del puntero. Después aparece un diálogo con opciones pensadas para seleccionarse con el cursor. ¿Qué diagnóstico se mantiene dentro de la evidencia aportada?
Mostrar respuesta y explicación
Respuesta: Los modos de control de vuelo y selección de diálogo tienen requisitos incompatibles para el puntero en ese límite de interacción.
Por qué: El caso establece requisitos de interacción incompatibles. No demuestra el uso de la captura de puntero, una ruta concreta de eventos ni asignaciones idénticas.
¿Qué afirmaciones deben seguir tratándose como hipótesis mientras no se registren evidencias adicionales? Selecciona todas las respuestas correctas.
Mostrar respuesta y explicación
Respuesta: El bloqueo del puntero seguía activo en el momento exacto del intento de selección.; Un evento concreto de la interfaz no llegó al diálogo.; Cambiar qué modo controla el dispositivo apuntador corregirá por completo la implementación.
Por qué: El caso aporta el solapamiento entre ambos modos. El momento exacto del estado de la API, la entrega de eventos y la eficacia de un cambio propuesto requieren evidencias adicionales.
Quieres comprobar si el modo de interacción activo explica el conflicto. ¿Qué procedimiento produce la evidencia más útil para distinguir entre explicaciones?
Mostrar respuesta y explicación
Respuesta: Mantener sin cambios la acción y el diálogo, modificar únicamente qué modo controla el dispositivo apuntador, repetir el intento de selección y registrar el resultado visible.
Por qué: Mantener constantes la acción y la interfaz mientras se cambia una sola condición del modo permite realizar una comparación controlada. El resultado puede respaldar o debilitar la hipótesis sin presentarla como causa o solución demostrada.