El wrapper es un límite de entorno

1251. Identidad de la lección

Módulo

3.11 — Wrappers de escritorio

Lección

El wrapper es un límite de entorno

Tipo académico

Sistemas

Tipo de esquema

texto

Orden

1

Tiempo estimado

30–40 minutos, incluida la práctica

Esta lección establece un límite entre la simulación del juego, la integración con el escritorio y el empaquetado. Tendremos en cuenta tres contextos —navegador, ejecución de escritorio durante el desarrollo y aplicación de escritorio empaquetada—, pero sin elaborar todavía una comparación exhaustiva. El objetivo es colocar cada responsabilidad donde pueda probarse y modificarse sin cambiar el juego por accidente, y describir el contrato que conecta las capas.

1252. Objetivo de aprendizaje

Al terminar esta lección, podrás clasificar un comportamiento como responsabilidad del juego, del wrapper o entorno, o del empaquetado, y justificar la decisión con un pequeño contrato de límite que indique la capa responsable, la entrada, la salida o evento y el límite del fallo.

1253. Por qué importa

Un mismo juego puede ejecutarse en el navegador, como proceso de escritorio iniciado desde herramientas de desarrollo y como aplicación de escritorio empaquetada. Esos entornos pueden ofrecer condiciones distintas de ventana, input, almacenamiento, ciclo de vida y artefactos. Si esas diferencias se filtran en las reglas de simulación, un cambio de entorno puede alterar el gameplay o dificultar las pruebas aisladas.

Definir un límite también mejora el trabajo asistido por IA. En lugar de pedir un «arreglo de escritorio» impreciso, puedes solicitar un cambio dentro de una responsabilidad concreta y exigir evidencia de que la propuesta no traslada una regla del juego al wrapper o al empaquetado.

1254. Conocimientos previos

Debes poder definir un gate de clean build y describir las variaciones de target, configuración, entorno y entradas que debe cubrir una build. La lección anterior, 3.10 L2 — Define a clean-build gate, proporciona el vocabulario de build que utilizaremos aquí. También debes distinguir entre una regla del juego y el entorno desde el que se presenta o activa esa regla.

1255. Concepto central

Un wrapper de escritorio es un límite de entorno, no un segundo motor de juego.

• La simulación del juego es responsable de las reglas, las transiciones de estado, la progresión y los resultados propios del juego.
• El wrapper o la integración con el entorno traduce servicios de ventana, capacidades de input, almacenamiento y ciclo de vida en interfaces y eventos que el juego pueda utilizar.
• El empaquetado ensambla y configura el artefacto específico del target, incluidos sus archivos y metadatos requeridos.

Un comportamiento puede atravesar varias capas sin que todas sean sus propietarias. Por ejemplo, «guardar la partida actual» puede comenzar como una intención del juego. El juego define qué datos forman un guardado válido, mientras que un servicio del entorno proporciona un mecanismo de persistencia disponible. El empaquetado puede tener que incluir archivos de runtime, pero no decide las reglas de guardado.

Las diferencias entre entornos pueden cambiar la forma de cumplir un contrato sin cambiar quién es responsable de la regla. Un navegador puede imponer restricciones de permisos o ciclo de vida. Una ejecución de escritorio durante el desarrollo puede depender de herramientas y rutas de desarrollo. Una aplicación empaquetada debe utilizar los servicios y archivos disponibles en su artefacto objetivo. La matriz completa de los tres entornos y su flujo de verificación se desarrollan en 3.11 L2 — Comparar entornos de runtime.

1256. Modelo mental: el contrato de límite

Para cada comportamiento seleccionado, registra cinco elementos obligatorios:

1. Responsable: la capa con autoridad para decidir el comportamiento.
2. Entrada del límite: la solicitud, el estado o la señal que entra en esa capa.
3. Salida o evento del límite: el resultado que vuelve a cruzar el límite.
4. Límite del fallo: la capa que debe informar o contener el fallo.
5. Justificación de la responsabilidad: por qué la capa alternativa más cercana no debe tomar la decisión.

La evidencia observable respalda el contrato. Puede ser una transición de estado, un resultado tipado de capacidad, un evento de ciclo de vida o una comprobación del contenido de un artefacto. La evidencia muestra que el límite funcionó como se describió; no transfiere la responsabilidad del comportamiento.

Plantilla vertical copiable

Usa esta plantilla para cada comportamiento seleccionado. Las etiquetas se presentan en vertical para que el contrato siga siendo legible en pantallas estrechas y con tecnologías de asistencia.

Comportamiento:

Capa responsable — juego, wrapper/entorno o empaquetado:

Entrada del límite:

Salida o evento del límite:

Límite del fallo:

Evidencia observable:

Por qué la capa alternativa más cercana no es responsable:

1257. Ejemplos de clasificación

El ejemplo de pointer lock muestra una responsabilidad dividida con claridad. El entorno controla si la solicitud de capacidad tiene éxito, y la política del navegador puede exigir un gesto de usuario válido o rechazarla. El juego sigue siendo responsable de las reglas de interacción que determinan qué estado presentar después del éxito o la denegación.

1258. Ejemplo concreto

Considera un juego pequeño con un estado de título y otro de partida activa. El jugador activa la acción asignada a START_RUN.

1. En el navegador, la página carga el runtime, y el navegador proporciona las condiciones de pestaña, foco, input y almacenamiento.
2. En una ejecución de escritorio durante el desarrollo, las herramientas de desarrollo inician el proceso; después, el runtime inicializa la ventana de desarrollo y los servicios del entorno.
3. En una ejecución de escritorio empaquetada, el ejecutable empaquetado o el launcher de la plataforma inicia el proceso; después, el wrapper o runtime inicializa la ventana objetivo y los servicios del entorno.
4. En todos los entornos, un adaptador traduce el input disponible a START_RUN.
5. El juego valida su estado actual y decide si debe pasar de TITLE a RUNNING.
6. Si se rechaza una solicitud de pointer lock, el adaptador del entorno informa del resultado. El juego decide qué estado de interacción presentar, pero no sustituye la decisión de permisos del entorno.
7. Si se produce una señal de ciclo de vida, el wrapper traduce la señal disponible. El juego decide qué significa para la partida activa según sus propias reglas.
8. El empaquetado garantiza que el target empaquetado contenga los archivos y la configuración requeridos; no decide si la partida puede comenzar o reanudarse.

Los entornos proporcionan servicios y señales diferentes, pero el juego conserva la autoridad sobre las mismas reglas del juego.

1259. Flujo de trabajo nativo de IA

Usa la IA como revisora de clasificaciones, no como autoridad que asigna responsabilidades sin evidencia.

1. Escribe cada comportamiento en lenguaje cotidiano.
2. Pregunta a la IA qué capa debería ser responsable: juego, wrapper/entorno o empaquetado.
3. Exige que la respuesta indique la entrada, la salida o evento, el límite del fallo y la evidencia observable.
4. Pide la mejor clasificación alternativa y una explicación de por qué resulta menos adecuada.
5. Contrasta la respuesta con las reglas de tu sistema y las restricciones conocidas del entorno.
6. Registra tu decisión final antes de pedir consejos de implementación.

Un prompt útil sería:

Clasifica cada comportamiento como responsabilidad del juego, del wrapper o entorno, o del empaquetado. Para cada comportamiento, indica la entrada del límite, la salida o evento, el límite del fallo, la evidencia observable y por qué la capa alternativa más cercana no debería ser responsable. Señala variaciones relevantes del navegador o del escritorio, pero no construyas una matriz de entornos completa ni propongas código de implementación.

Rechaza las respuestas que solo nombren una tecnología. «Se implementa con una API de escritorio» no demuestra quién es responsable. La respuesta debe identificar qué capa tiene autoridad para decidir y qué cruza su límite.

1260. Errores comunes

Error 1: El lugar donde se origina el evento determina la responsabilidad

Un comportamiento activado por un evento de ventana, navegador o sistema operativo no pertenece automáticamente a la capa del entorno. El wrapper puede informar de un cierre o un cambio de visibilidad, mientras que el juego conserva la regla que determina qué ocurre con una partida activa.

Error 2: Todas las capas participantes son responsables de la decisión

Una operación de persistencia puede implicar el estado del juego, un servicio de almacenamiento del entorno y archivos empaquetados. Participar no equivale a tener autoridad compartida. Asigna un único responsable a cada decisión y describe las demás capas como proveedoras, traductoras o consumidoras.

Error 3: Una ejecución de desarrollo demuestra que el target empaquetado funciona

Una ejecución de escritorio correcta durante el desarrollo no demuestra por sí sola que el artefacto empaquetado contenga todos los archivos de runtime requeridos ni que use los servicios previstos para el target. Esa comparación y sus pasos de verificación pertenecen a la matriz de entornos de la siguiente lección.

1261. Práctica guiada

Sigue este flujo en el orden indicado.

Paso 1: Clasifica los seis comportamientos

Para cada comportamiento, escribe juego, wrapper/entorno o empaquetado, más una razón de una sola frase:

1. El juego calcula si un ataque impacta.
2. La aplicación solicita pointer lock para una interacción compatible.
3. El wrapper o adaptador del entorno selecciona una ubicación o servicio disponible para la persistencia.
4. La aplicación empaquetada contiene su icono y los archivos de runtime requeridos.
5. El juego decide si una sesión interrumpida puede reanudarse.
6. El wrapper o runtime reenvía al juego un evento de foco o visibilidad.

En el caso de pointer lock, anota brevemente que una solicitud del navegador puede exigir un gesto de usuario válido y puede ser rechazada. Para el foco o la visibilidad, anota que una pestaña o página del navegador puede producir señales de ciclo de vida distintas de las de una ventana o proceso de escritorio. No conviertas estas notas en una matriz completa de los tres entornos.

Paso 2: Selecciona tres comportamientos representativos

Elige exactamente tres de los seis comportamientos clasificados:

• uno cuyo responsable sea el juego;
• uno cuyo responsable sea el wrapper o entorno; y
• uno cuyo responsable sea el empaquetado.

Paso 3: Completa tres contratos de límite

Usa la plantilla vertical para completar un contrato por cada comportamiento seleccionado. Cada contrato debe incluir el responsable, la entrada, la salida o evento, el límite del fallo, la evidencia observable y la justificación frente a la capa alternativa más cercana.

Mantén el trabajo en el nivel de responsabilidades e interfaces. No elijas un framework, escribas código, construyas una matriz de entornos completa ni definas una secuencia de pruebas para varios entornos. Esas actividades de comparación y verificación están reservadas para 3.11 L2 — Comparar entornos de runtime.

1262. Validación y evidencia

1263. Comprobación de conocimientos

1264. Ideas clave

• El juego es responsable de las reglas de simulación y las transiciones de estado.
• El wrapper o adaptador traduce capacidades, servicios y señales de ciclo de vida del entorno.
• El empaquetado ensambla el artefacto específico del target y no decide reglas de gameplay.
• Un comportamiento puede cruzar una capa sin transferirle su responsabilidad.
• Un contrato de límite identifica el responsable, la entrada, la salida o evento y el límite del fallo.
• La matriz completa de navegador, escritorio de desarrollo y escritorio empaquetado, con sus pasos de verificación, corresponde a la siguiente lección.

1265. Siguiente lección

Continúa con 3.11 L2 — Comparar entornos de runtime, donde estas clasificaciones se convertirán en una matriz completa de entornos con pasos de verificación explícitos.

1266. Comprobación