1189. Identidad de la lección
1190. Objetivo de aprendizaje
Al terminar esta lección, podrás identificar los riesgos de una dependencia de assets y definir evidencias o controles para su nombre, formato, responsabilidad de producción, ownership del recurso en runtime, carga y validación.
1191. Por qué importa
Un asset no es simplemente un archivo dentro de una carpeta del proyecto. Una textura, un sonido, una fuente, un modelo o un archivo de datos pasa a formar parte del sistema de producción cuando el código o el contenido dependen de él. La dependencia puede fallar antes del runtime porque su nombre es ambiguo, su formato no sirve o nadie tiene claro quién la mantiene. También puede fallar durante la carga, la sustitución o la limpieza, o producir un resultado incorrecto que una prueba superficial no detecta. Tratar los assets como entradas gestionadas te permite orientar el código generado por IA y comprobar si el juego está utilizando entradas confiables.
1192. Conocimientos previos
Debes poder describir un fallo de lifecycle acotado del Módulo 3.8, incluyendo estado inicial, resultado esperado, resultado real y un resultado repetible. Los errores en el momento de carga, la sustitución, la descarga o la limpieza también pueden documentarse con esa evidencia de lifecycle. Además, debes distinguir un fallo en una entrada de un fallo en la regla que procesa esa entrada.
1193. Vocabulario de trabajo
- Checkout limpio: una copia nueva del proyecto obtenida de su fuente bajo control de versiones, sin depender de archivos locales no registrados ni de estado generado anteriormente.
- Fuente de referencia autorizada: la fuente designada cuya versión debe utilizarse cuando existen copias distintas; sirve como referencia para las decisiones de mantenimiento y sustitución.
- Requisito de importación: un ajuste o una transformación que el motor o el pipeline de contenido debe aplicar para convertir el archivo fuente en un recurso utilizable por el juego.
- Runtime: el periodo durante el cual se está ejecutando el juego o la aplicación.
- Ownership del recurso en runtime: responsabilidad dentro del motor o sistema de carga sobre la retención de un recurso cargado, la decisión de cuándo puede sustituirse o descargarse y la verificación de su limpieza. No se refiere a la propiedad legal del archivo.
1194. Concepto central
Una dependencia de asset tiene un contrato de producción. El contrato responde cinco preguntas principales:
- Nombre: ¿Qué identificador o ruta exacta solicita el consumidor?
- Formato: ¿El sistema objetivo puede leer el archivo e interpretarlo como se espera, incluidos sus requisitos de importación?
- Ownership: ¿Quién o qué responde por el asset fuente y quién o qué gestiona el recurso cargado durante el runtime?
- Carga: ¿Cuándo y mediante qué mecanismo obtiene, retiene, sustituye y libera el juego ese recurso?
- Validación: ¿Qué evidencia demuestra que el resultado cargado existe, es compatible, sirve para su uso y se limpia como se espera?
Si falta una respuesta, la dependencia está especificada solo parcialmente. El código puede parecer correcto mientras el juego sigue siendo frágil.
El ownership tiene dos dimensiones diferentes:
- Responsabilidad de producción o procedencia: la persona, equipo, sistema o fuente de referencia autorizada responsable de proporcionar, aprobar y mantener el archivo del asset.
- Ownership del recurso en runtime: el componente del motor, sistema de carga, escena, caché u otro mecanismo de runtime responsable de retener el recurso cargado y decidir cuándo puede sustituirse, descargarse o liberarse.
Las responsabilidades concretas de runtime dependen del motor y del sistema de carga. Si el sistema las gestiona automáticamente, el contrato debe indicar gestionado por el sistema y nombrar la comprobación observable que permitirá verificar la sustitución, descarga o limpieza. No des por segura la gestión del lifecycle solo porque no aparezca una llamada manual de liberación.
Conviene separar estas afirmaciones:
- Presencia: el archivo existe en algún lugar.
- Disponibilidad: el juego puede localizarlo y cargarlo mediante la ruta prevista.
- Corrección: el asset cargado tiene el formato, dimensiones, contenido y comportamiento requeridos.
- Seguridad del lifecycle: el recurso se conserva mientras hace falta y puede sustituirse, descargarse o limpiarse de acuerdo con el lifecycle previsto.
No son la misma afirmación y cada una necesita evidencia diferente.
1195. Modelo mental
Usa la cadena de dependencia del asset:
| Pregunta sobre la dependencia | Riesgo de fallo | Evidencia o control |
|---|---|---|
| ¿Cómo se llama? | Ruta incorrecta, diferencia de mayúsculas, duplicado o reemplazo ambiguo | Nombre y ruta canónicos |
| ¿Qué formato tiene? | Codificación no compatible, dimensiones incorrectas, canal ausente o importación inadecuada | Requisitos de formato e importación |
| ¿Quién mantiene la fuente? | No hay responsable o no existe una fuente autorizada clara | Responsable de producción o fuente de referencia autorizada |
| ¿Quién gestiona el recurso cargado? | El recurso se libera demasiado pronto, se conserva demasiado tiempo, se sustituye de forma insegura o su limpieza queda sin verificar | Owner de runtime, o lifecycle gestionado por el sistema con una comprobación de verificación |
| ¿Cómo se carga? | Referencia ausente, momento incorrecto o desajuste con el lifecycle | Mecanismo y punto del lifecycle |
| ¿Cómo se valida? | El contenido roto o incorrecto llega al jugador, o persisten recursos obsoletos | Comprobaciones reproducibles y resultados esperados |
No conviertas estas preguntas en una sola afirmación: “el asset está ahí”. Un archivo puede superar la comprobación de presencia y fallar en disponibilidad, corrección o seguridad del lifecycle.
1196. Ejemplo concreto
Imagina que un menú muestra un icono de advertencia. La implementación depende de una imagen llamada warning-icon.
- El contrato de nombre puede exigir
ui/warning-icon.png, respetando las mayúsculas exactas del entorno objetivo. - El contrato de formato puede exigir un PNG con transparencia, un tamaño conocido en píxeles y ajustes de importación definidos.
- El contrato de responsabilidad de producción puede identificar la carpeta de assets de la interfaz como fuente de referencia autorizada y nombrar quién aprueba las sustituciones, en vez de depender de un archivo copiado en una carpeta temporal.
- El contrato de ownership del recurso en runtime puede indicar que la caché de recursos del menú retiene el icono mientras el menú está activo y que el sistema de carga se ocupa de liberarlo o sustituirlo. Si el motor gestiona este proceso automáticamente, el contrato lo registra y especifica cómo se comprobará la limpieza o sustitución.
- El contrato de carga puede exigir que la imagen esté disponible antes de mostrar el menú.
- El contrato de validación puede exigir abrir el menú en una ejecución limpia, confirmar que el icono aparece con transparencia y con el tamaño esperado, sustituirlo o cerrar el menú según corresponda y comprobar el resultado esperado del lifecycle.
Que falte el archivo es solo un posible fallo. Una diferencia de mayúsculas en la ruta, un fondo opaco, una carga posterior al renderizado del menú o la conservación de un recurso antiguo después de sustituirlo pueden producir otros fallos aunque la ruta parezca razonable.
1197. Error común
El error más común es tomar una búsqueda exitosa del archivo como prueba de que la dependencia funciona. La búsqueda solo demuestra que se encontró algo en una ubicación. No demuestra que el formato sea compatible, que se haya usado la fuente correcta, que la carga ocurra en el punto adecuado del lifecycle, que el recurso permanezca disponible durante el tiempo necesario ni que el juego presente el resultado esperado.
Otro error es atribuir la responsabilidad de producción al “proyecto” o a “la IA”. Una herramienta puede generar un archivo o sugerir una ruta, pero la responsabilidad sigue perteneciendo al proceso de producción. Alguien debe definir el contrato esperado y verificar el resultado.
También es un error asumir que la responsabilidad de producción identifica automáticamente al owner de runtime. La persona que mantiene una imagen no tiene por qué ser el sistema que retiene su recurso cargado. Registra ambas responsabilidades o indica expresamente que el lifecycle de runtime está gestionado por el sistema y ha sido verificado.
1198. Práctica guiada
Revisa esta descripción de dependencia:
La pantalla de pausa usa
pause.png. Está guardada en una carpeta de assets, se carga cuando se abre la pantalla de pausa y se comprueba confirmando que el archivo existe.
- Identifica un riesgo en cada área del contrato: nombre, formato, responsabilidad de producción, ownership del recurso en runtime, carga y validación.
- Elige el riesgo más alto para un juego que debe funcionar desde un checkout limpio. Explica por qué tiene mayor impacto que los demás.
- Reescribe la descripción como afirmaciones breves de contrato. Cada afirmación debe indicar un requisito o una evidencia observable.
- Registra el owner de runtime responsable de retener, sustituir, descargar o liberar el recurso. Si el lifecycle está gestionado por el sistema, escríbelo expresamente y define cómo lo comprobarías.
- Señala qué afirmaciones siguen sin estar verificadas si no tienes acceso al proyecto, a la configuración del motor o al archivo real. No conviertas la descripción en evidencia por simple suposición.
Una respuesta sólida puede priorizar una fuente autorizada poco clara, un formato no especificado o un lifecycle de runtime sin verificar, en lugar de asumir que la comprobación de existencia cubre esos aspectos. La decisión importante es ordenar los riesgos y justificar el primero, no limitarse a enumerar defectos.
1199. Validación / evidencia
Tu evidencia es una revisión de dependencia que incluya:
- un requisito explícito de nombre;
- un requisito de formato o importación;
- un responsable de producción o una fuente de referencia autorizada;
- un owner del recurso en runtime, o una indicación explícita de que lo gestiona el sistema junto con una comprobación del lifecycle;
- un punto o mecanismo de carga;
- un procedimiento de validación con resultado esperado;
- al menos dos riesgos de dependencia identificados; y
- una clasificación de riesgos con la justificación del riesgo principal y un control o una comprobación observable correspondiente.
La revisión solo está completa cuando distingue lo que se sabe de lo que todavía debe verificarse. Si otro desarrollador puede usarla para comprobar la dependencia sin adivinar qué significan “funciona” u “ownership”, has demostrado la capacidad.
1200. Puntos clave
- Un asset se convierte en dependencia de producción cuando otra parte del juego depende de él.
- Presencia, disponibilidad, corrección y seguridad del lifecycle son afirmaciones distintas.
- Nombre, formato, ownership, carga y validación forman el contrato de la dependencia.
- La responsabilidad de producción identifica quién mantiene el asset o cuál es su fuente autorizada; el ownership del recurso en runtime identifica quién o qué lo retiene, sustituye, descarga o libera.
- El ownership de runtime gestionado por el sistema también debe registrarse y verificarse.
- Encontrar un archivo no demuestra que el juego pueda usar y limpiar correctamente el asset previsto.
- Una buena gestión de assets hace visibles los riesgos y asigna evidencia observable a cada uno.
1201. Evaluación práctica
Completa Revisión de riesgos y controles de una dependencia de asset. Analizarás un escenario acotado, identificarás y ordenarás riesgos de dependencia y redactarás un control o una comprobación observable para el riesgo principal. Los criterios del proyecto forman la rúbrica de evaluación.
1202. Próxima lección
Continúa con 3.9 L2 — Auditar un conjunto de assets.
1203. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué afirmación distingue mejor la presencia de un asset de su corrección?
Mostrar respuesta y explicación
Respuesta: La presencia significa que el archivo existe; la corrección significa que cumple los requisitos de su uso previsto.
Por qué: Un archivo puede existir y aun así tener un formato incompatible, dimensiones incorrectas o contenido equivocado. Por eso la presencia ofrece menos evidencia que la corrección.
¿Qué afirmación distingue correctamente la responsabilidad de producción del ownership del recurso en runtime?
Mostrar respuesta y explicación
Respuesta: La responsabilidad de producción se refiere a la fuente y el mantenimiento del asset; el ownership de runtime se refiere a retener, sustituir, descargar o liberar el recurso cargado.
Por qué: La persona o fuente responsable de un asset no es lo mismo que el mecanismo de runtime que controla el lifecycle del recurso cargado.
¿Por qué es insuficiente comprobar que existe el archivo como única validación de un asset?
Mostrar respuesta y explicación
Respuesta: Porque la existencia no demuestra que el juego pueda cargar, interpretar, presentar, retener o limpiar correctamente el asset previsto.
Por qué: La existencia solo establece la presencia. Se necesita evidencia separada para la disponibilidad, la corrección y la seguridad del lifecycle.
¿Qué debe registrar un contrato de asset cuando el motor gestiona automáticamente el lifecycle de un recurso cargado?
Mostrar respuesta y explicación
Respuesta: Que el ownership del lifecycle está gestionado por el sistema, junto con una comprobación observable de sustitución, descarga o limpieza.
Por qué: La gestión automática sigue siendo una decisión de lifecycle. El contrato debe indicar que la realiza el sistema y explicar cómo se verificará el comportamiento esperado.