Conviene haber comprendido Patrones de diseño con criterio.
CONTENIDO ORIGINAL
Avanza en orden. Cada lección está redactada para Palta es Cool, utiliza ejemplos propios y termina con una actividad cuya respuesta puedes desplegar.
ANTES DE EMPEZAR
Ubícate antes de avanzar
Al terminar deberías poder relacionar Evidencia y diagnóstico con Depurador y pruebas y resolver un caso nuevo.
Reserva entre 75 y 120 minutos o divide el laboratorio en dos sesiones.
04 / PREPARA EL LABORATORIO
Instala Unity Hub, una versión LTS compatible y un IDE con integración para C#. Conserva un proyecto de laboratorio separado.
Abrir la guía de herramientas →Diagnóstico rápido: ¿cómo se relacionan Evidencia y diagnóstico y Depurador y pruebas? ＋
No necesitas acertar todavía. Escribe una hipótesis de dos líneas y compárala con tu respuesta al finalizar; si puedes corregirla y justificar el cambio, hubo aprendizaje.
Aprende el tema paso a paso
Diagnosticarás con evidencia y añadirás pruebas y mediciones para impedir que el mismo problema vuelva o que una optimización empeore el juego.
Al terminar podrás
- Reproducir, reducir y formular una hipótesis precede a corregir
- Consola, Inspector, Gizmos y breakpoint responden preguntas distintas
- Test Framework y Profiler convierten intuiciones en evidencia
01
Investigar
Reproducir, reducir y formular una hipótesis precede a corregir
Un buen diagnóstico registra pasos, frecuencia, escena y resultado esperado. Después aísla el sistema, propone una causa refutable y observa evidencia. Cambiar varias cosas a la vez destruye la relación entre causa y efecto.
Corrige primero el primer error relevante.
Conserva un caso mínimo repetible.
Verifica la solución con el caso original y sus fronteras.
¿Por qué reiniciar Unity no es una explicación aunque temporalmente oculte el fallo?
Mostrar respuesta ＋
Porque no identifica la causa ni evita que vuelva. Puede borrar un síntoma o estado, pero no demuestra qué condición estaba rota.
02
Observar el estado
Consola, Inspector, Gizmos y breakpoint responden preguntas distintas
La Consola y el stack trace localizan mensajes; Inspector muestra estado serializado; Debug.Log y DrawLine agregan contexto; Gizmos visualiza geometría; Handles permite editarla; el depurador detiene la ejecución y sigue variables y llamadas. Null checks, Assert y excepciones expresan fallos diferentes.
Incluye el objeto como contexto del log.
Usa Assert para invariantes de desarrollo.
El código de Handles pertenece al Editor, no al build.
¿Cuándo es mejor un breakpoint que agregar diez logs?
Mostrar respuesta ＋
Cuando necesitas observar el estado completo y el recorrido exacto en un momento concreto sin generar ruido por cada frame.
03
Proteger y medir
Test Framework y Profiler convierten intuiciones en evidencia
Los tests de Edit Mode sirven para lógica independiente de frames; los de Play Mode para integración con el ciclo de Unity. El Profiler muestra tiempo de CPU, memoria, renderizado y asignaciones. Primero se mide una escena representativa; después se cambia una variable y se vuelve a medir.
Una prueba conserva el comportamiento corregido.
No optimices con el Editor abierto sin interpretar su sobrecarga.
Mide en la plataforma objetivo cuando el rendimiento importa.
¿Una tasa alta de frames demuestra que no existen problemas de rendimiento?
Mostrar respuesta ＋
No. Puede ocultar picos, pausas de recolección, consumo de memoria o fallos en otro dispositivo. Debes revisar distribución temporal, recursos y plataforma objetivo.
Tu recorrido en tres ideas
- Reproducir, reducir y formular una hipótesis precede a corregir
- Consola, Inspector, Gizmos y breakpoint responden preguntas distintas
- Test Framework y Profiler convierten intuiciones en evidencia
Investiga un fallo que ocurre una de cada diez veces
Integra reproducción, hipótesis, Console, Inspector, visualización, debugger, pruebas y Profiler.
CASO
Al recoger una llave y cambiar de escena, ocasionalmente la puerta no recibe el evento y queda cerrada.
Procedimiento
- Registra una secuencia mínima y añade identidad y tiempo a la evidencia.
- Formula hipótesis sobre orden, suscripción y destrucción; refútalas una a una.
- Corrige la causa, agrega una prueba o arnés repetible y ejecuta cien ciclos.
Evidencia mínima
- Bitácora de hipótesis y resultados.
- Primera divergencia observada en el flujo.
- Cien repeticiones y prueba de regresión exitosas.
Mostrar razonamiento modelo ＋
El diagnóstico observa si la puerta existía y estaba suscrita cuando el evento ocurrió. La solución puede cambiar el propietario del estado o la secuencia, no solo añadir una espera arbitraria.
Para ir más lejos¿Qué evidencia distinguiría pérdida de evento de carga incompleta de escena?
CIERRE DE LA SECCIÓN
Comprueba que puedes usarlo
Antes de continuar, revisa estos tropiezos frecuentes y resuelve un caso sin copiar los ejemplos.
Modificar código antes de poder reproducir el fallo o añadir logs sin hipótesis.
Optimizar desde intuición sin una escena, plataforma y medición comparables.
Ahora hazlo sin guía
Investiga un fallo intermitente, conserva una bitácora de hipótesis y evidencia, añade una prueba de regresión y mide la corrección.
Mostrar pauta de corrección ＋
Una respuesta sólida:
- Los pasos reproducen y reducen el problema.
- Cada herramienta responde una pregunta concreta sobre estado o flujo.
- La prueba falla antes, pasa después y la medición usa la misma carga.