Ejercicios y práctica · Programación Multimedia y Dispositivos Móviles · DAM

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Monolito de lógica: Intentar implementar toda la lógica del juego en un único script o función. Causa: Falta de modularidad y comprensión de la arquitectura de componentes. Corrección: Dividir la lógica en scripts pequeños y específicos, asignándolos a los GameObjects/Nodes correspondientes.
• Escalado incorrecto de objetos: Utilizar valores de escala arbitrarios que no se corresponden con las unidades del motor o la resolución del juego. Causa: Desconocimiento de las unidades de medida del motor o falta de planificación del diseño. Corrección: Establecer una escala coherente desde el principio (e.g., 1 unidad = 1 metro o 1 unidad = 16 píxeles) y utilizar herramientas de diseño para previsualizar el tamaño real.
• Carga de escena bloqueante: usar un método de carga síncrona para una escena pesada, congelando la aplicación. Causa: desconocer o no configurar la carga asíncrona que ofrece el motor o la extensión instalada. Corrección: emplear los métodos asíncronos disponibles (por ejemplo LoadSceneAsync o el equivalente de la extensión) y mostrar una pantalla de carga mientras se completa.
• Confundir funcionalidad nativa con extensión: dar por hecho que toda gestión de escenas requiere instalar un paquete externo, cuando el motor ya ofrece funciones básicas. Causa: no distinguir qué aporta el motor por defecto y qué añade la extensión. Corrección: revisar la documentación del motor antes de instalar un paquete, instalando solo lo que amplía una necesidad real (streaming remoto, carga aditiva avanzada, transiciones específicas).
• Texturas no optimizadas: aplicar texturas de alta resolución a todos los objetos sin considerar su tamaño en pantalla. Causa: falta de criterio de optimización de recursos gráficos. Corrección: ajustar resolución según distancia/tamaño, generar mipmaps y aplicar compresión.
• Sonido desequilibrado: Volúmenes de SFX o música que abruman al jugador o son inaudibles. Causa: Falta de mezcla de audio y pruebas de sonido. Corrección: Utilizar un Audio Mixer para controlar los grupos de audio y realizar pruebas de sonido en diferentes entornos.
• Rendimiento deficiente en móvil: El juego funciona lento o consume mucha batería en dispositivos móviles. Causa: Falta de optimización de recursos gráficos y código. Corrección: Reducir la complejidad de los modelos, usar texturas comprimidas, optimizar el código y perfilar el juego en dispositivos reales para identificar y corregir cuellos de botella.
• Pruebas insuficientes: Lanzar un juego sin haber realizado pruebas exhaustivas, lo que lleva a bugs y una mala experiencia de usuario. Causa: Presión por el tiempo o subestimación de la importancia de las pruebas. Corrección: Establecer un plan de pruebas riguroso, automatizar pruebas cuando sea posible y realizar pruebas de juego (playtesting) con usuarios externos.
• Documentación ausente o desactualizada: No documentar el proyecto o dejar la documentación obsoleta. Causa: Percepción de que la documentación es una tarea secundaria. Corrección: Integrar la documentación como parte del ciclo de vida del desarrollo, utilizando herramientas colaborativas y asignando responsabilidades de actualización.
• Confundir la representación lógica con la espacial: Causa: usar coordenadas de pantalla para decidir colisiones o reglas del juego, en vez de un modelo de datos abstracto. Corrección: mantener el estado del juego (salud, posición lógica, inventario) separado de las coordenadas de renderizado; las colisiones deben calcularse sobre hitboxes lógicas, no sobre píxeles dibujados.
• Ignorar el papel del bucle de juego: Causa: no entender que el juego es un ciclo constante de entrada-actualización-render. Corrección: representar mentalmente el bucle como el director de orquesta que llama a cada subsistema (entrada, física, IA, render) en el orden correcto en cada fotograma.
• Tratar el listado de subsistemas como una exigencia normativa cerrada: Causa: pensar que el BOE define exactamente esos 10 bloques. Corrección: recordar que el CE pide identificar elementos de la arquitectura, y que la clasificación en subsistemas es una herramienta didáctica y profesional habitual, no un listado literal del currículo.
• Subestimar la importancia del sistema de scripting: Causa: Pensar que la lógica del juego se puede codificar directamente en el motor sin una capa de abstracción. Corrección: Entender que el scripting permite una iteración rápida y una separación limpia entre la lógica del juego y el código base del motor, facilitando el mantenimiento y la colaboración.
• No utilizar las herramientas del entorno de desarrollo: Causa: Intentar hacer todo por código o desconocer las funcionalidades del editor. Corrección: Familiarizarse con el editor de escenas, el inspector y el explorador de proyectos para aprovechar la productividad que ofrecen las herramientas visuales del motor.
• Elegir el motor incorrecto para el proyecto: Causa: Basar la elección en la popularidad o el conocimiento previo sin analizar los requisitos específicos del juego. Corrección: Realizar un análisis de requisitos detallado (tipo de juego, plataforma, estilo gráfico, tamaño del equipo, presupuesto) y comparar las características de los motores relevantes.
• Ignorar la optimización del renderizado: Causa: Asumir que el motor se encargará de todo el rendimiento gráfico automáticamente. Corrección: Entender los cuellos de botella comunes (demasiados polígonos, draw calls, texturas grandes) y aplicar técnicas de optimización desde las primeras etapas del desarrollo.
• Confundir contenedor y códec: La causa es no entender que el contenedor es el 'envoltorio' y el códec el 'método de compresión'. La corrección es visualizar el archivo multimedia como una caja (contenedor) que guarda diferentes tipos de contenido (video, audio) comprimidos de formas específicas (códecs).
• Ignorar permisos de acceso: La causa es olvidar que el acceso a la cámara o micrófono requiere permisos explícitos del usuario. La corrección es implementar la solicitud de permisos en tiempo de ejecución al inicio de la funcionalidad de captura.