Qué puede evaluarse
RA1: Aplica tecnologías de desarrollo para dispositivos móviles evaluando sus características y capacidades.
Limitaciones de hardware móvilGestión de recursos (CPU, RAM, batería)Conectividad y redes móvilesFragmentación de dispositivos y SOSeguridad en aplicaciones móvilesOptimización de rendimiento y UXDesarrollo nativo (Kotlin/Swift) frente a multiplataforma (Flutter, React Native, Ionic)SDK: librerías, APIs y herramientas de compilaciónIDE: Android Studio y XcodeDispositivo virtual (AVD) y simulador de iOS
RA2: Desarrolla aplicaciones para dispositivos móviles analizando y empleando las tecnologías y librerías específicas.
Activity LifecycleFragmentViewViewGroupLayout XMLEvent HandlingAlertDialogMenú de opcionesBluetooth LEWi-Fi Direct
RA3: Desarrolla programas que integran contenidos multimedia analizando y empleando las tecnologías y librerías específicas.
Entorno de Desarrollo Multimedia (SDK, API)Clases de Captura (MediaRecorder, CameraX, AVCaptureSession)Clases de Almacenamiento (FileOutputStream, FileManager)CódecContenedor MultimediaStream de DatosTranscodificaciónAVAssetExportSession (iOS)MediaCodec (Android)Procesamiento en Tiempo Real
RA4: Selecciona y prueba motores de juegos analizando la arquitectura de juegos 2D y 3D.
Arquitectura de juegoBucle de juego (Game Loop)Motor de juegoSistema de renderizado 2D/3DSistema de física y colisionesRepresentación lógica del estado del juegoRepresentación espacial y matrices de transformaciónBloques funcionales de un juegoMotor de renderizadoMotor de física
RA5: Desarrolla juegos 2D y 3D sencillos utilizando motores de juegos.
Motor de juegosGame loopGameObject/NodeComponentesScriptsSpritesMeshesFondos (backgrounds, skyboxes, tilemaps)Escena en un motor de videojuegosSceneManager nativo vs. extensión instalada
Trampas habituales antes del examen
- 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.