Presentación
Unity es un motor de juego y una plataforma de desarrollo en tiempo real creada por Unity Technologies.
Permite construir juegos 2D y 3D, aplicaciones interactivas, experiencias XR, simulaciones o visualizaciones, y luego desplegarlas en numerosas plataformas.
Su fortaleza histórica no proviene de un rendimiento espectacular único ni de una herramienta reservada a un solo oficio.
Proviene de un equilibrio entre una arquitectura relativamente directa, un lenguaje ampliamente difundido — C# — y un ecosistema capaz de adaptarse a proyectos muy diferentes.
Unity resulta especialmente potente cuando un mismo proyecto debe mantenerse modular, programable y portable entre varias plataformas.
Una escena se organiza en torno a GameObjects a los que se añaden Components.
Un personaje puede así reunir renderizado, colisión, física, animación y scripts sin convertirse en un bloque monolítico.
Los Prefabs prolongan esta lógica al transformar un objeto configurado en un modelo reutilizable cuyas instancias pueden conservar ciertas variaciones.
Esta arquitectura explica en gran medida la accesibilidad de Unity.
Se puede empezar con algunos objetos y scripts.
Y luego estructurar progresivamente los datos, las escenas, las herramientas, los contenidos distribuidos o el multijugador a medida que el proyecto crece.
Unity no exige, por tanto, comprender de inmediato toda su arquitectura para obtener un primer resultado.
Esta progresividad sigue siendo una de sus grandes fortalezas.
También tiene su reverso.
Un proyecto puede acumular muy rápidamente:
- scripts demasiado dependientes entre sí;
- referencias ocultas en el Inspector;
- plugins añadidos para resolver cada problema;
- packages cuyo ciclo de vida nadie controla realmente.
Unity facilita enormemente el ensamblaje.
No sustituye al diseño de software.
El motor también es muy modular.
Numerosas capacidades se distribuyen en forma de packages: renderizado, cámara, input, localización, multijugador, gestión de contenido, herramientas XR o arquitecturas orientadas a datos.
Esta flexibilidad evita imponer cada sistema a cada proyecto.
También introduce una verdadera responsabilidad:
elegir las piezas adecuadas y mantener sus versiones coherentes con la del motor.
Unity sigue siendo un producto propietario.
El desarrollo principal puede mantenerse local, mientras que ciertos servicios de colaboración, build, multijugador, analytics o explotación utilizan Unity Cloud y poseen sus propias condiciones.
Esta separación debe quedar clara.
Usar Unity no significa usar todos los servicios de Unity.
Y usar Unity en local no significa que cada flujo de trabajo asociado al proyecto seguirá siendo local.
Funcionalidades
GameObjects, Components, Prefabs y datos
El modelo GameObject / Component constituye la base más reconocible de Unity.
Un objeto recibe capacidades combinando varios componentes en lugar de concentrar todo su comportamiento en una sola clase.
Un personaje puede, por ejemplo, reunir:
- Transform;
- Renderer;
- Collider;
- Rigidbody;
- Animator;
- scripts personalizados.
Esta composición hace que los comportamientos sean fáciles de combinar.
También favorece el prototipado.
Un nuevo objeto interactivo puede construirse a partir de piezas ya existentes en lugar de crear una arquitectura completamente nueva.
Los Prefabs añaden un nivel de reutilización esencial.
Un enemigo, una puerta, una interfaz o un efecto pueden convertirse en modelos cuyas instancias comparten una estructura común.
Las variantes y los overrides permiten después adaptar ciertas propiedades sin duplicar todo el objeto.
Esta lógica resulta extremadamente productiva para juegos compuestos por numerosas familias de objetos.
Exige una buena disciplina cuando los prefabs se vuelven profundamente anidados o dependientes de muchos scripts.
Los ScriptableObjects completan esta arquitectura al almacenar ciertos datos de forma independiente de las escenas y de las instancias.
Pueden representar objetos, estadísticas, quests, diálogos, configuraciones u otros datos reutilizables.
Esta separación ayuda a evitar que toda la información del juego quede encerrada en GameObjects activos.
C#, herramientas y arquitectura del código
C# es el lenguaje principal de Unity.
Los scripts dirigen el gameplay, las herramientas, los datos y las interacciones con los componentes del motor.
El lenguaje constituye una ventaja mayor porque sigue siendo relativamente accesible y permite construir arquitecturas importantes.
Unity puede trabajar con distintos editores de código.
La verdadera cuestión no reside en la elección del editor, sino en la manera en que el proyecto organiza:
- responsabilidades;
- dependencias;
- eventos;
- datos;
- tests;
- módulos.
Las Assembly Definitions pueden, en particular, ayudar a separar ciertas partes del código y reducir las dependencias implícitas.
Unity utiliza también varios mecanismos de compilación y de ejecución según las plataformas.
IL2CPP transforma el código intermedio a C++ antes de la compilación nativa para numerosos destinos.
Esta capa mejora la compatibilidad con ciertas plataformas.
También puede poner de manifiesto problemas que no aparecen del mismo modo en el entorno de desarrollo.
Por tanto, una aplicación debe probarse en su verdadero modo de build.
Unity dispone, por último, de un sistema de herramientas de editor muy extensible.
Inspectores personalizados, ventanas, gizmos y otras extensiones pueden transformar el editor según las necesidades de un proyecto.
Un equipo puede así construir sus propias herramientas de colocación, validación o producción.
Esta capacidad resulta especialmente importante cuando el mismo gesto se repite cientos de veces.
Renderizado, materiales y pipelines gráficos
Unity no posee un único pipeline gráfico universal.
La elección del pipeline forma parte de las decisiones estructurantes del proyecto.
El Built-in Render Pipeline representa la arquitectura histórica.
El Universal Render Pipeline, o URP, apunta a una amplia gama de hardware y suele ser la elección más natural para proyectos multiplataforma.
El High Definition Render Pipeline, o HDRP, se dirige más bien a máquinas de alta gama y a necesidades de renderizado avanzado.
Estos pipelines no son simples perfiles de calidad.
Pueden influir en:
- materiales;
- shaders;
- luces;
- efectos;
- rendimiento;
- compatibilidad de ciertos assets.
Cambiar de pipeline en pleno desarrollo puede costar, por tanto, mucho más que un simple cambio de ajuste.
Shader Graph permite construir shaders mediante nodos.
Este enfoque acerca la programación gráfica al arte técnico.
Facilita la creación de materiales específicos sin exigir que cada efecto se escriba por completo en HLSL.
Los grafos complejos siguen siendo, no obstante, código visual.
Deben estar estructurados, ser reutilizables y estar optimizados.
Visual Effect Graph lleva esta lógica hacia efectos calculados principalmente en la GPU.
Resulta especialmente interesante para grandes cantidades de partículas y efectos complejos.
El sistema de partículas tradicional sigue siendo a menudo más adecuado para proyectos modestos o para plataformas con recursos limitados.
2D, 3D, animación, cámara y física
Unity posee una verdadera profundidad en 2D.
Sprites, Tilemaps, animación 2D, iluminación, física y herramientas de pixel art permiten construir producciones enteramente dibujadas sin recurrir a un motor separado.
Esta especialización explica por qué Unity sigue muy presente en el sector independiente, el móvil y los juegos 2D.
El 3D abarca escenas, meshes, terrenos, materiales, luces, navegación, animación y física.
Unity no es, sin embargo, un modelador generalista.
Los personajes, decorados y assets complejos se crean por lo general en Blender, Maya u otras herramientas especializadas y luego se importan.
Herramientas como ProBuilder facilitan el blockout y las geometrías temporales directamente en el editor.
La animación se apoya en clips, controllers, Blend Trees, retargeting y otros sistemas destinados a organizar los movimientos.
Timeline añade una lógica de secuenciación.
Cinemachine organiza las cámaras virtuales, seguimientos, composiciones y transiciones.
Estas herramientas van más allá de la simple cinemática.
También resultan útiles para el gameplay, las cámaras dinámicas y la narración.
La física 2D y la física 3D se apoyan en pilas distintas.
Unity ofrece así varios niveles de simulación sin convertir cada proyecto en un motor físico especializado.
Interfaz, input, audio y experiencia de usuario
Una aplicación en tiempo real no se reduce a lo que se encuentra en la escena.
Unity posee varios sistemas para construir la interfaz.
UI Toolkit representa un enfoque moderno que puede servir tanto a herramientas de editor como a ciertas interfaces en runtime.
uGUI sigue estando muy presente en proyectos existentes y en numerosos flujos de trabajo de juego.
La profundidad de estos sistemas se vuelve sobre todo importante cuando el producto debe funcionar en varios tamaños de pantalla y dispositivos.
El Input System abstrae las acciones del jugador de los dispositivos físicos.
Una misma acción puede corresponder a:
- teclado;
- mando;
- táctil;
- controlador XR.
Esta abstracción facilita el enfoque multiplataforma.
No elimina la necesidad de diseñar una interacción realmente adaptada a cada contexto.
Una interfaz pensada para ratón y teclado no se vuelve automáticamente cómoda en móvil o en un casco.
Unity integra también audio, espacialización y mezcla.
Para producciones muy exigentes, soluciones especializadas como FMOD o Wwise pueden complementar el motor.
Contenido, Addressables y producción a gran escala
Cuanto más crece un proyecto, más se plantea la pregunta:
¿qué debe cargarse, cuándo, desde dónde y en qué versión?
Addressables ayuda a organizar los recursos para que puedan cargarse de manera más flexible.
Algunos contenidos pueden quedarse en local.
Otros pueden distribuirse por separado.
Esta arquitectura resulta útil para:
- juegos como servicio;
- contenidos descargables;
- grandes bibliotecas de assets;
- aplicaciones cuyos recursos no deben cargarse todos de inmediato.
El principio es potente.
También añade una nueva capa que comprender: grupos, catálogos, versiones, carga asíncrona y distribución remota.
La gestión de contenido no debe añadirse únicamente porque el package existe.
Resulta interesante cuando el volumen o el modelo de distribución lo justifica realmente.
Multijugador, servicios y cloud
Unity proporciona varias piezas para el multijugador.
Netcode for GameObjects se mantiene cerca de la arquitectura clásica GameObject.
Otros enfoques están pensados para arquitecturas orientadas a datos.
Servicios como Lobby, Relay o Matchmaker pueden ayudar a organizar las sesiones y conexiones.
El motor también puede producir builds de servidores dedicados.
Esta profundidad aporta una base importante.
No hace que el multijugador sea simple.
Un proyecto de red debe tratar todavía:
- autoridad;
- latencia;
- predicción;
- seguridad;
- trampas;
- hosting;
- observabilidad.
Los Unity Gaming Services añaden otras piezas opcionales: autenticación, guardado en cloud, economía, analytics, configuración remota o contenido distribuido.
Estos servicios reducen la cantidad de infraestructura que hay que construir uno mismo.
Aumentan la dependencia del ecosistema Unity Cloud.
La decisión debe por tanto pesar tanto sobre el producto a largo plazo como sobre la velocidad del prototipo.
Rendimiento, DOTS y despliegue multiplataforma
Unity puede orientarse a desktop, móvil, Web, consolas y XR según los módulos, licencias y autorizaciones disponibles.
El mismo proyecto puede compartir una gran parte de su lógica entre varios destinos.
Esto no significa que un build único funcione en todas partes sin adaptación.
Las diferencias afectan, en particular, a:
- memoria;
- GPU;
- shaders;
- controles;
- tamaño de descarga;
- codecs;
- servicios de plataforma;
- certificación.
El Profiler, el Memory Profiler, el Frame Debugger y otras herramientas permiten analizar el rendimiento.
Esta capa es esencial porque un proyecto en tiempo real debe respetar un presupuesto permanente de rendimiento.
Lo que importa no es solo la velocidad media.
Hay que mantener una experiencia estable en el destino real.
Para ciertas simulaciones o proyectos muy masivos, Unity ofrece también una arquitectura orientada a datos con Jobs, Burst y Entities.
Este enfoque puede permitir tratar con eficacia grandes cantidades de objetos o de datos.
Representa un modelo mental distinto del GameObject clásico.
Adoptar DOTS únicamente porque promete mejores rendimientos puede añadir muchísima complejidad sin beneficio real.
La arquitectura debe elegirse en función del problema medido.
Casos de uso
Crear un juego independiente multiplataforma
Una misma base puede orientarse a varios sistemas conservando el gameplay, las escenas y gran parte de los assets.
Producir un juego 2D
Sprites, Tilemaps, animación 2D, física y renderizado dedicado permiten construir una producción enteramente 2D.
Prototipar rápidamente una mecánica
GameObjects, Components y Prefabs permiten ensamblar una interacción antes de invertir en una arquitectura más pesada.
Desarrollar un juego móvil o Web
URP, gestión de inputs y profiling permiten adaptar el proyecto a aparatos y restricciones muy distintos.
Construir un juego multijugador
Los sistemas Netcode y los servicios asociados pueden proporcionar una base para sesiones, conexión de los jugadores y explotación.
Realizar una experiencia XR
OpenXR, AR Foundation y las herramientas de interacción permiten orientarse a varios entornos inmersivos.
Construir una simulación o una aplicación interactiva
Unity puede emplearse fuera del videojuego cuando el tiempo real, la interacción y la portabilidad pesan más que un renderizado lineal.
Desarrollar un juego como servicio
Addressables, contenido remoto, analytics y servicios backend pueden acompañar a un producto que sigue evolucionando tras su lanzamiento.
Opinión PANACHES
La modularidad es su verdadera identidad
Unity da rápidamente la impresión de que casi todo es ensamblable.
Components, Prefabs, packages y assets comparten esta misma filosofía.
Esta flexibilidad funciona muy bien cuando el equipo conserva una arquitectura legible.
Se vuelve mucho menos cómoda cuando cada problema recibe un package adicional.
La modularidad solo resulta útil si el proyecto sigue siendo capaz de explicar de qué depende.
C# y la progresividad siguen siendo ventajas mayores
El lenguaje hace que Unity sea accesible a numerosos desarrolladores sin imponer de inmediato las restricciones de C++.
El motor permite también empezar con una arquitectura relativamente simple y luego introducir más estructura a medida que aparece la necesidad.
Esta progresión explica su lugar duradero en el aprendizaje, el prototipado y los equipos pequeños.
El multiplataforma es una fuerza, no una garantía
Unity reduce enormemente el trabajo necesario para mantener varios destinos.
La última parte del camino sigue siendo específica de cada uno de ellos.
Un proyecto serio debe probar pronto en su aparato más restrictivo en lugar de descubrir sus límites en el momento de publicar.
"Exportar hacia" y "estar correctamente diseñado para" son dos cosas diferentes.
Su ecosistema acelera tanto como fragmenta
El Asset Store y los packages pueden ahorrar semanas.
También pueden producir un proyecto dependiente de varias capas cuya evolución nadie domina realmente.
La selección de las dependencias forma parte, por tanto, de la arquitectura.
Un plugin central debe evaluarse casi como una biblioteca de código esencial.
Unity conviene especialmente a los proyectos que privilegian el alcance
Frente a Unreal Engine, Unity suele parecer más natural cuando el proyecto hace hincapié en C#, el 2D, el móvil, la variedad de plataformas o una arquitectura relativamente ligera.
Unreal ofrece una integración artística y técnica más masiva en torno a producciones 3D ambiciosas.
Unity sigue siendo a menudo más fácil de adaptar cuando el proyecto debe viajar entre numerosos aparatos y formatos.
Esta diferencia cuenta más que una comparación interminable de funcionalidades.
Puntos de atención
- Unity es propietario y su código completo no es libremente redistribuible.
- La elección de versión debe estabilizarse para una producción larga.
- Los packages pueden introducir incompatibilidades durante las migraciones.
- La elección del pipeline de renderizado debe hacerse pronto, ya que los materiales y shaders no siempre son intercambiables.
- El multiplataforma exige pruebas en cada destino importante.
- Los servicios Unity Cloud son opcionales, pero aumentan la dependencia del ecosistema.
- Los assets y plugins poseen sus propias licencias.
- El coste real puede incluir suscripción, servicios cloud, assets y herramientas de terceros.
- Los proyectos multijugador añaden restricciones de seguridad, hosting y explotación.
- Una arquitectura orientada a Entities exige un enfoque distinto del modelo GameObject clásico.
- Las condiciones de licencia y los umbrales comerciales deben verificarse en el momento del proyecto.
- Una escena que funciona correctamente en el editor debe aún ser perfilada y probada en un build real.
