1267. Identidad de la lección
Esta lección convierte el límite del wrapper estudiado en la lección anterior en un flujo de verificación. Compararás los supuestos del navegador, el escritorio de desarrollo y el escritorio empaquetado, en lugar de tratar el empaquetado como una copia final del desarrollo.
1268. Objetivo de aprendizaje
Al finalizar esta lección, podrás elaborar una matriz que registre diferencias acotadas de runtime, resultados esperados y observados para cada entorno, decisiones de responsabilidad, el estado de la verificación y una primera prueba debidamente priorizada.
1269. Por qué importa
Un juego puede funcionar correctamente en el navegador o en el escritorio de desarrollo y fallar después del empaquetado porque pueden cambiar las rutas, los eventos del ciclo de vida, el almacenamiento, los permisos o la visibilidad de los diagnósticos. Estas diferencias no son automáticamente defectos de la simulación y no deben abordarse repartiendo conjeturas de plataforma por las reglas del juego.
Una matriz hace visible cada supuesto. También distingue una hipótesis de un resultado verificado, delimita el análisis que puede realizar la IA y registra evidencia independiente para cada entorno. Una afirmación compartida como “funciona en todos los entornos” no basta si no se ha observado y documentado el resultado de cada uno.
1270. Conocimientos previos
Debes haber completado 3.11 L1 — El wrapper es un límite de entorno. Debes poder distinguir las responsabilidades del juego de las del wrapper y la configuración de empaquetado. También necesitas conocer, de forma básica, los procedimientos disponibles para iniciar el proyecto en el navegador, ejecutarlo como aplicación de escritorio durante el desarrollo y abrir una versión empaquetada o una previsualización equivalente.
1271. Concepto central
Una diferencia de entorno solo resulta útil cuando se expresa como un supuesto comprobable.
No escribas:
“Las builds empaquetadas pueden ser diferentes.”
Formula una hipótesis acotada:
“El runtime empaquetado puede resolver los assets de arranque desde una base distinta a la del navegador y el escritorio de desarrollo. Prueba el arranque en cada entorno y registra los resultados por separado.”
La matriz conecta cinco elementos:
- Entorno — dónde se ejecuta el juego.
- Supuesto — qué espera el juego, el wrapper o la configuración de empaquetado.
- Responsable — qué capa debe contener el comportamiento o la corrección si el supuesto falla.
- Prueba de verificación (probe) — la acción o inspección que comprueba el supuesto.
- Evidencia — el resultado observable que confirma, rechaza o deja sin resolver el supuesto.
Este modelo de cinco partes sigue siendo la base del flujo. La matriz lo amplía al exigir un resultado esperado y otro observado para cada uno de los tres entornos. También registra si la afirmación es una hipótesis o un hecho verificado, su estado actual y una conclusión comparativa.
1272. Modelo mental
Usa el modelo Entorno → Supuesto → Responsable → Prueba → Evidencia.
| Campo | Pregunta | Ejemplo |
|---|---|---|
| Entorno | ¿Dónde se realiza la prueba? | Navegador, escritorio de desarrollo o escritorio empaquetado |
| Supuesto | ¿Qué debe seguir siendo cierto o qué diferencia se sospecha? | Los assets necesarios para el arranque se resuelven correctamente |
| Responsable | ¿Qué capa es responsable de la regla o la corrección? | Juego o aplicación, límite del wrapper o configuración de empaquetado |
| Prueba | ¿Qué acción repetible lo comprueba? | Iniciar el entorno y entrar en la escena inicial |
| Evidencia | ¿Qué resultado observable lo confirma o rechaza? | La escena muestra todos los assets necesarios o aparece un fallo concreto |
“Revisar el empaquetado” no es una prueba porque no indica qué hacer ni qué observar. “Funciona con normalidad” tampoco es evidencia, ya que otra persona no podría saber qué se inspeccionó.
Compara los tres entornos de ejecución requeridos:
| Runtime del navegador | Runtime de escritorio de desarrollo | Runtime de escritorio empaquetado |
|---|---|---|
| Se ejecuta en una pestaña o ventana del navegador; se aplican sus reglas de origen, permisos, foco y almacenamiento | Se ejecuta como proceso de escritorio mediante las herramientas de desarrollo; pueden aplicarse rutas locales, diagnósticos de desarrollo y el comportamiento de la ventana de desarrollo | Se ejecuta desde el artefacto de escritorio de destino; se aplican las rutas empaquetadas, los archivos incluidos, el ciclo de vida de la ventana y los permisos de destino |
| Deben observarse directamente los diagnósticos y resultados de permisos del navegador | Los diagnósticos suelen estar disponibles mediante las herramientas de desarrollo | Los diagnósticos pueden requerir logs del wrapper u otra vía de inspección |
| La navegación, los cambios de visibilidad y el cierre de la pestaña pueden diferir de los eventos de escritorio | Los reinicios suelen ser explícitos durante el desarrollo | Cerrar, volver a abrir, suspender o sufrir un fallo puede activar rutas distintas del ciclo de vida |
Este cuadro es un marco de comparación, no una afirmación de que todos los proyectos o wrappers se comporten igual. Verifica el comportamiento real del proyecto y del wrapper en los tres entornos.
1273. Formato de la matriz
Utiliza una fila por cada supuesto acotado. No combines los tres entornos en una única celda de evidencia.
| Área y supuesto | Responsable | Prueba | Navegador: esperado | Navegador: observado | Escritorio de desarrollo: esperado | Escritorio de desarrollo: observado | Escritorio empaquetado: esperado | Escritorio empaquetado: observado | Estado del conocimiento | Estado del resultado | Conclusión comparativa |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Los assets de arranque necesarios se resuelven | El límite de carga de la aplicación; la configuración de empaquetado controla la inclusión en el artefacto | Entrar en la escena inicial e inspeccionar el resultado visible y los diagnósticos disponibles | Aparecen el fondo, la fuente y los valores de configuración | Registra lo ocurrido o “no probado” | Aparece el mismo contenido necesario | Registra lo ocurrido o “no probado” | El mismo contenido aparece desde el artefacto empaquetado | Registra lo ocurrido o “no probado” | Hipótesis hasta completar las pruebas | No probado, verificado, fallido o inconcluso | Indica la diferencia real, su responsable y si queda alguna acción abierta |
Si un supuesto no se aplica a un entorno, escribe no aplica y explica el motivo. No dejes vacíos los campos de resultados esperados u observados. Una fila solo está completa cuando su conclusión indica:
- qué diferencia se observó, o que no se observó ninguna;
- qué capa es responsable de la regla o corrección correspondiente;
- si el elemento está verificado, fallido, inconcluso o aún sin probar.
1274. Ejemplo concreto
Supón que la primera pantalla necesita una imagen de fondo, una fuente y un archivo de configuración local.
Una nota débil diría:
“Funciona en desarrollo, pero las rutas podrían romperse al empaquetar.”
Esa nota omite el navegador, no separa expectativas de observaciones y tampoco identifica a un responsable.
Una fila útil registra los tres entornos:
| Área y supuesto | Responsable | Prueba | Navegador: esperado / observado | Escritorio de desarrollo: esperado / observado | Escritorio empaquetado: esperado / observado | Estado del conocimiento y del resultado | Conclusión comparativa |
|---|---|---|---|---|---|---|---|
| Los assets de arranque se resuelven en todos los runtimes necesarios | El juego o aplicación solicita los assets; la configuración de empaquetado controla su inclusión; el wrapper solo es responsable del límite de runtime pertinente | Iniciar cada runtime, entrar en la escena inicial, inspeccionar el resultado visible y capturar los diagnósticos disponibles | Esperado: aparecen el fondo, la fuente y los valores de configuración. Observado: registra el resultado del navegador. | Esperado: aparece el mismo contenido necesario. Observado: registra el resultado del escritorio de desarrollo. | Esperado: aparece el mismo contenido desde el artefacto empaquetado. Observado: registra el resultado del escritorio empaquetado. | Hipótesis hasta ejecutar las tres pruebas; después, verificado, fallido o inconcluso | Indica si los tres resultados coincidieron. Si uno fue distinto, nombra la diferencia, el responsable y si la acción está abierta o resuelta. |
Este ejemplo comprueba el resultado en los tres entornos. No afirma que el wrapper deba decidir el aspecto del juego. Distingue la regla de presentación del juego de las condiciones del wrapper o el empaquetado que pueden afectar a la disponibilidad de assets.
Una fila sobre el ciclo de vida utiliza la misma estructura. Por ejemplo, compara el cierre o cambio de visibilidad en el navegador, el cierre y reapertura de la ventana de desarrollo y el cierre y reapertura de la ventana empaquetada. Si el cierre de una pestaña no permite realizar la misma observación, marca el campo como no aplicable o inconcluso y explica la limitación, en vez de fingir que todos los eventos son idénticos.
1275. Flujo de trabajo con IA
Usa la IA como apoyo para auditar supuestos, no como sustituta de la evidencia obtenida durante la ejecución.
- Proporciona los tres entornos, el límite del wrapper definido en la lección anterior y únicamente los procedimientos de arranque o empaquetado que conozcas.
- Pide como máximo cinco diferencias acotadas que puedan afectar al juego.
- Exige un responsable, una prueba repetible y evidencia esperada para cada entorno.
- Exige que las afirmaciones específicas del proyecto que aún no estén comprobadas aparezcan como hipótesis.
- Rechaza filas vagas, APIs inventadas, historial del proyecto no documentado y propuestas que trasladen reglas del juego al wrapper sin justificación.
- Ejecuta las pruebas y registra por separado el resultado observado en cada entorno.
- Redacta una conclusión comparativa que identifique la diferencia real, su responsable y su estado.
Un prompt útil sería:
“Compara los supuestos de runtime del navegador, el escritorio de desarrollo y el escritorio empaquetado para este juego. Propón hasta cinco filas acotadas. Para cada una, incluye el supuesto, el responsable, una prueba de verificación y el resultado esperado en cada entorno. Marca como hipótesis las afirmaciones específicas del proyecto. No inventes APIs del wrapper, comportamiento de empaquetado, historial del proyecto ni resultados observados.”
La IA puede ayudarte a formular preguntas y estructurar la matriz. Solo la observación directa puede establecer un resultado específico del proyecto.
1276. Errores comunes
El primer error es tratar el runtime empaquetado como un detalle de distribución que solo se comprueba al final. Esto produce advertencias generales y correcciones tardías en la capa equivocada.
El segundo es escribir una secuencia como “navegador → escritorio de desarrollo → escritorio empaquetado” en una sola celda y añadir una única evidencia compartida. Esa estructura puede ocultar el fallo independiente de un entorno. Registra por separado los resultados esperados y observados de cada entorno.
El tercer error es confundir una hipótesis con evidencia. “El runtime empaquetado usa otra base de assets” sigue siendo una hipótesis hasta que una prueba produzca evidencia. Escribe no probado en vez de presentar el supuesto como un hecho.
El cuarto es asignar todas las diferencias al wrapper. Las reglas del juego siguen perteneciendo al juego o a la aplicación. El wrapper es responsable del comportamiento de su límite, mientras que la configuración de empaquetado controla el ensamblado y la inclusión de archivos en el artefacto.
1277. Práctica guiada
Prepara una matriz de cuatro filas con el formato requerido. Debe cubrir:
- Assets de arranque o entrada de la aplicación.
- Un archivo local o una dependencia de configuración.
- Diagnósticos y visibilidad de errores.
- Ventana, pestaña, cierre, reapertura, visibilidad u otro límite del ciclo de vida.
Para cada fila:
- Formula un supuesto acotado.
- Asigna un responsable: juego o aplicación, límite del wrapper o configuración de empaquetado. Usa varios responsables solo si separas con claridad sus funciones.
- Define una prueba repetible.
- Registra un resultado esperado para el navegador, el escritorio de desarrollo y el escritorio empaquetado.
- Registra un resultado observado para cada entorno o indica explícitamente no probado, no aplica o inconcluso, junto con el motivo.
- Marca la afirmación como hipótesis o hecho verificado.
- Asigna el estado del resultado: no probado, verificado, fallido o inconcluso.
- Redacta una conclusión comparativa que nombre la diferencia real, su responsable y si queda alguna acción abierta.
Después elige la fila de mayor riesgo y justifica por qué su prueba debe ejecutarse primero. La prioridad puede deberse a que impida el arranque, oculte fallos, corrompa una decisión de sesión o dificulte un diagnóstico fiable. No priorices una fila solo porque parezca más específica de una plataforma.
Entrega la matriz mediante la evaluación práctica asociada a esta lección. El cuestionario es una comprobación complementaria de conocimientos; no sustituye la matriz.
1278. Validación y evidencia
La matriz es válida cuando incluye:
- cuatro o más filas acotadas que cubran las cuatro áreas requeridas;
- campos para navegador, escritorio de desarrollo y escritorio empaquetado en cada fila;
- resultados esperados y observados separados para cada entorno;
- una explicación explícita para cada entrada no aplicable o inconclusa;
- un supuesto, un responsable, una prueba repetible, un estado del conocimiento y un estado del resultado en cada fila;
- una conclusión comparativa que nombre la diferencia observada o indique que no se observó ninguna, además del responsable y del estado abierto o resuelto;
- una distinción clara entre hipótesis y hechos verificados;
- una justificación de la prueba que debe ejecutarse primero.
Una lista de riesgos, funciones del wrapper o tareas de implementación no constituye una matriz de entornos. El artefacto debe permitir una sesión de verificación repetible y mostrar si un entorno falla de forma independiente.
1279. Puntos clave
- El navegador, el escritorio de desarrollo y el escritorio empaquetado son tres entornos de ejecución distintos que requieren una comparación explícita.
- El modelo de cinco partes es Entorno → Supuesto → Responsable → Prueba → Evidencia.
- Los resultados esperados y observados deben registrarse por separado para cada entorno.
- Cada conclusión debe identificar la diferencia real, su responsable y su estado actual.
- Las diferencias de plataforma deben mantenerse acotadas en el wrapper o en la configuración de empaquetado cuando no pertenecen a las reglas del juego.
- La IA puede organizar hipótesis, pero las pruebas directas proporcionan la evidencia específica del proyecto.
1280. Próxima lección
Continúa con 3.12 — Integración con Steam. La próxima lección utilizará esta matriz y sus decisiones de responsabilidad para distinguir los límites del juego, el wrapper, el cliente de la tienda y el empaquetado. Esta lección no presupone ni enseña detalles de implementación del cliente de la tienda.
1281. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué estructura permite comparar de forma repetible los tres entornos?
Mostrar respuesta y explicación
Respuesta: Resultados esperados y observados separados para el navegador, el escritorio de desarrollo y el escritorio empaquetado, además de una conclusión comparativa
Por qué: Los campos separados de resultados esperados y observados muestran si un entorno falló de forma independiente. La conclusión identifica después la diferencia real, su responsable y su estado.
¿Qué debe aportar la IA al flujo de trabajo de la matriz de entornos?
Mostrar respuesta y explicación
Respuesta: Hipótesis acotadas, posibles responsables y pruebas de verificación, con las afirmaciones no comprobadas claramente identificadas
Por qué: La IA puede estructurar preguntas y proponer hipótesis acotadas. No puede establecer evidencia específica del proyecto sin observación directa durante la ejecución.
Una prueba de cierre y reapertura muestra que una sesión se reanuda de forma inesperada. ¿Qué análisis de responsabilidad es el más adecuado?
Mostrar respuesta y explicación
Respuesta: El juego es responsable de la regla de sesión; el wrapper puede informar de eventos del ciclo de vida o facilitar acceso al almacenamiento.
Por qué: El juego define su regla de sesión. El wrapper puede exponer mecanismos de ciclo de vida o almacenamiento, pero no debe sustituir esa regla de forma implícita.
¿Qué afirmación es un resultado observado y no un supuesto ni una prueba?
Mostrar respuesta y explicación
Respuesta: En el runtime de escritorio empaquetado, la escena inicial mostró el fondo y la fuente necesarios, y los diagnósticos disponibles no registraron fallos de assets requeridos.
Por qué: Un resultado observado indica qué ocurrió en un entorno concreto después de ejecutar la prueba. Las demás opciones son una hipótesis, una acción y una afirmación sobre responsabilidad.