Parte: 11 — Móvil, consolas y plataformas · Fuente: Guías de certificación de plataformas de consola (visión general pública) ⏱️ Duración estimada: 70 min · Nivel: Intermedio
Entender qué es la certificación de consola: el proceso por el que el fabricante comprueba que tu juego cumple una lista de requisitos técnicos y de comportamiento antes de permitir su publicación. Cada plataforma tiene su nombre y su lista: TRC (Technical Requirements Checklist) en PlayStation, TCR (Technical Certification Requirements) en Xbox y el equivalente de Nintendo (a menudo llamado "lotcheck"). Son documentos confidenciales bajo NDA, pero comparten un núcleo de requisitos comunes que sí podemos estudiar de forma general.
Como Godot llega a consola vía porteador, buena parte de la implementación de estos requisitos la resuelve el porteo; pero tú, como diseñador del juego, debes conocerlos para no crear situaciones que los incumplan. Al terminar sabrás elaborar una checklist de certificación con los requisitos comunes y auto-evaluar tu juego frente a ellos.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Qué es la certificación | Es el filtro final antes de publicar. |
| 2 | TRC / TCR / lotcheck | Cada plataforma nombra su lista distinta. |
| 3 | Suspensión y resume | El sistema puede dormir el juego en cualquier momento. |
| 4 | Gestión de controladores | Conectar/desconectar mando debe manejarse con gracia. |
| 5 | Mensajes del sistema | Invitaciones, batería, notificaciones interrumpen el juego. |
| 6 | Guardado y su integridad | Perder una partida guardada es causa de rechazo. |
| 7 | Fallos típicos | Conocerlos ahorra iteraciones de certificación. |
| 8 | Auto-evaluación | Detectar problemas antes de enviar a certificar. |
No hay SDK público que consultar (los documentos TRC/TCR están bajo NDA), así que trabajaremos con los requisitos comunes que son de dominio general. Prepara un documento o tabla para construir tu checklist. Ten a mano tu juego de Godot para auto-evaluarlo, aunque sea en PC: muchos requisitos (pausa al perder foco, manejo de desconexión de mando, guardado seguro) se pueden simular y probar en el editor antes de que exista un port.
En Godot, apóyate en las señales de entrada de mando (Input.joy_connection_changed) y en la notificación de foco de ventana (NOTIFICATION_APPLICATION_FOCUS_OUT) para reproducir localmente el comportamiento que la consola exigirá.
Construiremos una checklist de certificación y auto-evaluaremos el juego. Además, implementaremos dos comportamientos que casi todas las listas exigen: pausar al perder el foco y avisar al desconectar el mando.
[ ] Al perder el foco / suspender, el juego pausa y silencia el audio
[ ] Al reanudar, el juego recupera estado sin crash ni audio desincronizado
[ ] Al desconectar el mando activo, el juego pausa y muestra aviso
[ ] Al reconectar, se reanuda con el mando correcto
[ ] El guardado se escribe de forma segura (sin corromper si se apaga)
[ ] No hay cuelgues, memory leaks graves ni caídas de framerate persistentes
[ ] Textos legibles y terminología del sistema correcta
[ ] Manejo correcto de notificaciones/invitaciones del sistema
Certificacion que reaccione a los eventos del sistema:extends Node
# Gestiona pausa por pérdida de foco y por desconexión de mando.
signal juego_pausado(motivo: String)
func _ready() -> void:
# Nos avisa cuando un mando se conecta o desconecta.
Input.joy_connection_changed.connect(_on_joy_cambio)
func _notification(que: int) -> void:
# El SO nos quita el foco (suspensión, overlay del sistema).
if que == NOTIFICATION_APPLICATION_FOCUS_OUT:
_pausar("foco_perdido")
elif que == NOTIFICATION_APPLICATION_FOCUS_IN:
# Al recuperar el foco no reanudamos solos: lo hace el jugador.
pass
func _on_joy_cambio(_dispositivo: int, conectado: bool) -> void:
if not conectado and Input.get_connected_joypads().is_empty():
_pausar("mando_desconectado")
func _pausar(motivo: String) -> void:
get_tree().paused = true
juego_pausado.emit(motivo)
func _ready() -> void:
Certificacion.juego_pausado.connect(_mostrar_aviso)
func _mostrar_aviso(motivo: String) -> void:
match motivo:
"mando_desconectado":
$UI/Aviso.text = "Vuelve a conectar el mando para continuar."
"foco_perdido":
$UI/Aviso.text = "Juego en pausa."
$UI/Aviso.show()
Asegura que la UI de pausa siga funcionando: pon su nodo en Process Mode: Always para que reciba entrada aunque el árbol esté pausado.
Prueba en PC: desconecta el mando USB en pleno juego y confirma que pausa y muestra el aviso; reconéctalo y comprueba que puedes reanudar.
Para el guardado seguro, escribe primero en un archivo temporal y renómbralo al final, de modo que un apagado a mitad no corrompa el guardado real.
Rellena la checklist marcando qué cumple tu juego hoy y qué te falta. Ese listado es tu plan de trabajo antes de enviar a certificación.
Elabora una checklist de certificación de al menos 10 requisitos comunes y auto-evalúa tu juego frente a ella, marcando cumplidos y pendientes. Implementa en Godot, como mínimo, la pausa por desconexión de mando con aviso al jugador y la pausa por pérdida de foco, verificables en PC.
Criterio de aceptación: al desconectar el mando durante la partida, el juego pausa y muestra un aviso claro; al reconectarlo, el jugador puede reanudar; y la checklist entregada distingue con claridad los ítems cumplidos de los pendientes.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| El juego sigue corriendo con el mando desconectado | No escuchas joy_connection_changed. Pausa y avisa al perder el mando. |
| La UI de pausa no responde al pausar | Su Process Mode no es "Always". Cámbialo para que reciba entrada. |
| Crash al reanudar tras suspender | No recuperas bien audio/red al volver el foco. Reinicializa lo necesario. |
| Partida corrupta tras un apagón | Escribías directo sobre el guardado. Usa temporal + renombrado atómico. |
| Rechazo por terminología del sistema | Usaste nombres de botones/servicios incorrectos. Sigue la nomenclatura de la plataforma. |
❓ ¿TRC y TCR son lo mismo? Son análogos: TRC es de PlayStation y TCR de Xbox; Nintendo usa su propio proceso ("lotcheck"). Todos comparten un núcleo de requisitos comunes.
❓ ¿El porteador se encarga de toda la certificación? Ayuda mucho y resuelve gran parte de la integración, pero decisiones de diseño (cómo pausas, cómo guardas) son responsabilidad del juego.
❓ ¿Puedo ver la lista TRC/TCR completa? No públicamente: están bajo NDA. Sí puedes estudiar y prepararte con los requisitos comunes conocidos.
❓ ¿Por qué tanto énfasis en suspensión y mandos? Porque son situaciones cotidianas en consola (dormir la consola, quedarse sin batería el mando) y un fallo ahí provoca rechazo directo.
Clase 209 - Desarrollo para consolas: panorama y devkits