Flujo de recursos para juegos con IA
Updated 2026-09-05
Define el recurso que necesita tu juego, conserva su origen y permisos, e inspecciona el resultado importado a escala de gameplay antes de incluirlo en un lanzamiento.
Escribe un contrato de recursos antes de generar arte
Define la función del recurso en el juego: sprite del jugador, obstáculo, mosaico de fondo, botón, señal de sonido o material promocional. Especifica las dimensiones, la transparencia, la disposición de los fotogramas, el punto de vista, las restricciones de paleta y la escala a la que se inspeccionará. Trátalos como datos de producción en lugar de esperar que una imagen atractiva encaje después.
Para una hoja de sprites, define el número de fotogramas, las dimensiones de las celdas, el origen y los estados de animación esperados. Para un recurso de interfaz, identifica el texto y el estado de interacción que lo rodean. Usa un placeholder propio hasta estabilizar el contrato, para que la iteración artística no oculte si el gameplay funciona.
Selecciona una fuente con una base de permisos revisable
Entre las fuentes posibles están el trabajo original encargado, los recursos creados por ti, un paquete con licencia o material generado bajo condiciones de servicio revisadas. Compáralos por permisos, capacidad de edición, coherencia y esfuerzo de revisión, no por una afirmación sin respaldo de que una fuente sea siempre más barata.
Conserva el enlace de la fuente original y la licencia o acuerdo aplicable junto al registro del recurso. Registra los requisitos de atribución y redistribución. El material generado también necesita revisar sus entradas y su salida; el acceso al modelo no demuestra autorización para personajes, marcas u otro material protegido que se haya copiado. Eleva los derechos dudosos antes de distribuir, en lugar de convertir la incertidumbre en un estado aprobado.
| Ruta de la fuente | Evidencia que conservar | Revisión técnica |
|---|---|---|
| Trabajo original | Registro del autor y la propiedad | Ajustes de exportación y fuente editable |
| Paquete con licencia | Licencia, fuente y obligaciones de atribución | Compatibilidad de escala e importación |
| Material generado | Identidad de la herramienta, derechos de entrada y revisión de condiciones | Coherencia, limpieza y utilidad de los fotogramas |
Mantén atribuibles la programación y la producción de imágenes
Astra puede ser el objeto de un experimento de programación mientras una herramienta de imagen independiente produce el arte. Registra esos papeles por separado. Una instrucción de texto que pida un sprite no demuestra qué servicio generó los píxeles y una sesión de código correcta no proporciona una factura del servicio de imágenes.
Para cada salida generada, conserva la identidad real de la herramienta de imagen, el registro de la solicitud cuando esté disponible, los ajustes de generación, la salida seleccionada y las ediciones manuales. Incluye los intentos fallidos o descartados en el registro de uso. Sigue el trabajo de imagen por separado de la programación de texto aunque un mismo agente coordine ambos, para que el caso pueda explicar dónde se emplearon realmente el coste y el esfuerzo humano.
Usa un manifiesto con incógnitas honestas
Usa el registro ilustrativo de abajo para una canalización de recursos y mantén los campos desconocidos como null hasta revisarlos. La aprobación requiere una fuente real, una decisión sobre permisos, la identidad del archivo y una revisión técnica. Mantén estable el identificador del recurso al sustituir una salida, para que el archivo nuevo herede el contexto sin heredar una aprobación que no se ha ganado.
Vincula el material original y la salida final importada mediante el mismo identificador de recurso. Cuando una persona elimine un fondo, repare un fotograma de animación o cambie el contraste, registra la transformación. Así son posibles la sustitución posterior, la revisión de atribución y la depuración sin depender del recuerdo de una sesión de chat.
{
"asset_id": "player_idle",
"source_url": null,
"permission_record": null,
"creator_or_tool": null,
"source_hash": null,
"final_file_hash": null,
"transformations": [],
"image_cost_record": null,
"review_status": "pending",
"import_result": null
}Inspecciona la importación del motor, no solo el archivo fuente
La documentación de importación de imágenes de Godot describe opciones de compresión y mipmaps que afectan a las texturas importadas. Selecciona los ajustes según las condiciones reales de visualización del recurso; el pixel art, los fondos escalados y las texturas 3D no comparten un preset universal. Conserva los ajustes usados para la salida aceptada.
Inspecciona los bordes transparentes, los fondos no deseados, el espaciado de fotogramas y la escala visual dentro del juego. Compara la representación de colisión con el objeto visible. Un PNG técnicamente válido todavía puede ser inutilizable si los fotogramas desplazan la posición aparente del personaje o el sprite desaparece contra el nivel. Rechaza estos problemas antes de propagar el recurso por muchas escenas.
Revisa la animación, el sonido y la interfaz en contexto
Reproduce repetidamente la acción pertinente e inspecciona las transiciones entre estados de animación. Comprueba si la temporización visual coincide con las colisiones y el feedback. Una hoja de contacto fotograma a fotograma puede ayudar a inspeccionar, pero no sustituye observar la animación en ejecución y la entrada del jugador que la activa.
Para el audio, revisa por separado la coherencia del nivel, el bucle, la sincronización y los registros de permisos. Para el arte de interfaz, verifica el foco, los estados desactivados y el contraste del texto en las resoluciones previstas. Registra los fallos por recurso y comportamiento para que el agente reciba feedback accionable en lugar de una petición general de mejorar el aspecto del juego.
Comprueba el artefacto exportado y el inventario de declaraciones
Verifica que los recursos aceptados estén presentes en la compilación exportada y se comporten como se revisó. Conserva una captura o grabación del artefacto real cuando hagas una afirmación de implementación. No sustituyas la evidencia de gameplay por una imagen conceptual o una maqueta generada.
Mantén un inventario de distribución que distinga el arte, el sonido, la narrativa, la localización y la salida en tiempo de ejecución. Usa la guía de preparación para Steam y el Content Survey actual para decidir qué debe describirse del juego real. Un registro interno de recursos completado ayuda a esa revisión, pero no establece por sí mismo la aprobación de la plataforma ni resuelve una cuestión de derechos incierta.
Presupuesta los recursos aceptados, incluido el retrabajo
Mide la producción de recursos frente a resultados aceptados dentro del juego, no simplemente según el número de archivos generados. Conserva en el registro las generaciones rechazadas, la limpieza manual, las correcciones de importación y las nuevas comprobaciones de la compilación objetivo. Usa las categorías y fechas reales de facturación del proveedor en lugar de insertar un precio en la guía.
Cuando generaciones repetidas fallen el mismo requisito técnico, revisa el contrato del recurso o usa un placeholder original mientras resuelves el gameplay. Más prompts no compensan una disposición de fotogramas indefinida. Estos procedimientos y campos del manifiesto son ilustrativos; evalúa los archivos reales y las condiciones aplicables antes de tratar un recurso como aceptado o estimar el siguiente lote de producción.
Preguntas frecuentes
¿El uso de programación de Astra incluye todos los costes de arte del juego?
No. Atribuye por separado los servicios de imagen y audio, incluso cuando un agente los invoque durante la misma tarea. Usa los registros reales de solicitudes y facturación.
¿Puedo usar cualquier imagen que parezca adecuada?
Revisa su base de permisos y su encaje técnico. La apariencia por sí sola no establece ni derechos de distribución ni un comportamiento utilizable de animación e importación.
¿Un PNG transparente es un sprite terminado?
Todavía necesita comprobaciones de escala, origen, fotogramas, bordes, ajuste de colisiones y visibilidad dentro del juego previsto.
¿Qué pertenece a un manifiesto de recursos?
El origen, el registro de permisos, la identidad del creador o de la herramienta, los hashes, las transformaciones, el estado de revisión y la evidencia de importación. La información ausente debe seguir marcada explícitamente como desconocida.
¿Cuándo debe marcarse un recurso como aceptado?
Después de resolver su registro de permisos, comprobar que el archivo importado coincide con el brief técnico y verificar el comportamiento pertinente en la compilación objetivo.