Unity

Presentación

Unity es un motor de videojuegos propietario y una plataforma de desarrollo en tiempo real creada por Unity Technologies.

El software permite crear videojuegos, aplicaciones interactivas, simulaciones, experiencias de realidad virtual o aumentada, visualizaciones, herramientas educativas y contenidos en tiempo real.

Reúne en una misma aplicación un editor de escenas 2D y 3D, un entorno de programación en C#, sistemas de renderizado, herramientas de animación, físicas, audio, interfaz, navegación, profiling y despliegue multiplataforma.

Unity no es únicamente un motor de visualización.

Su ecosistema también incluye Unity Hub, Package Manager, Asset Store, Unity Cloud, Unity Version Control, Build Automation, Unity Gaming Services, herramientas multijugador, servicios LiveOps y funciones opcionales de inteligencia artificial.

La principal versión estable disponible durante la última verificación es Unity 6.3 LTS, publicada en diciembre de 2025.

Esta versión dispone de dos años de soporte, hasta diciembre de 2027. Los suscriptores de Unity Enterprise y Unity Industry cuentan con un tercer año de soporte.

Unity distingue actualmente entre versiones LTS y versiones Update.

Una versión LTS prioriza la estabilidad, las correcciones y la compatibilidad durante un periodo prolongado. Está pensada para juegos en servicio, producciones avanzadas y equipos que quieren fijar su entorno de trabajo.

Las versiones Update también se consideran preparadas para producción, pero reciben con mayor rapidez nuevas funciones y compatibilidad con plataformas recientes. Se mantienen hasta la publicación de la siguiente versión Update.

Las versiones Beta y Alpha sirven para probar funciones en desarrollo. No deberían sustituir a una versión de producción en un proyecto que no disponga de copias de seguridad sólidas.

Unity funciona como editor en Windows, macOS y Linux.

La instalación y la gestión de versiones se realizan principalmente mediante Unity Hub. Esta aplicación permite instalar varias versiones del editor, sus módulos de compilación y las plantillas de proyecto.

Varias versiones de Unity pueden coexistir en un mismo ordenador.

Esta posibilidad es importante porque un proyecto suele permanecer asociado a una versión concreta del motor y a un conjunto definido de packages.

El editor de Unity se organiza mediante ventanas y paneles.

Scene View sirve para construir el mundo, Game View muestra el resultado desde las cámaras, Hierarchy presenta los objetos de la escena, Project Browser contiene los archivos e Inspector expone las propiedades del elemento seleccionado.

Una escena de Unity está compuesta principalmente por GameObjects.

Un GameObject es un contenedor al que se añaden Components. Un personaje puede reunir Transform, Renderer, Collider, Rigidbody, Animator y scripts personalizados.

Esta arquitectura basada en componentes facilita la reutilización y combinación de comportamientos.

El componente Transform define la posición, rotación y escala de cada GameObject.

Los scripts C# suelen heredar de MonoBehaviour para recibir eventos del motor como Awake, Start, Update, FixedUpdate, OnEnable u OnCollisionEnter.

Los Prefabs permiten guardar un GameObject y su jerarquía como una plantilla reutilizable.

Una modificación aplicada al prefab puede propagarse a todas sus instancias, mientras que los overrides permiten adaptar localmente determinados parámetros.

Unity admite prefabs anidados y Prefab Variants.

Los ScriptableObjects permiten almacenar datos en assets independientes de las escenas y de las instancias.

Se utilizan habitualmente para estadísticas de personajes, objetos, configuraciones, diálogos, inventarios y sistemas de datos.

La programación se realiza principalmente con C#.

Unity proporciona su propio entorno de ejecución y admite varios modos de compilación, entre ellos Mono para determinados flujos de trabajo e IL2CPP para numerosas plataformas.

IL2CPP convierte el código intermedio de C# en C++ antes de la compilación nativa.

Este método mejora la compatibilidad con determinadas plataformas y con las restricciones de ejecución anticipada, pero aumenta el tiempo de compilación y exige precauciones con la reflexión, la generación dinámica de código y el stripping.

Unity puede utilizarse con Visual Studio, Visual Studio Code, JetBrains Rider u otros editores compatibles.

Los archivos de proyecto y las soluciones pueden generarse automáticamente para facilitar la navegación, el autocompletado y la depuración.

Package Manager organiza una parte importante de las funciones del motor.

Sistemas como Input System, Cinemachine, Timeline, Localization, Addressables, Entities, Netcode, Visual Scripting o los pipelines de renderizado se distribuyen o actualizan mediante packages.

Esta modularidad evita cargar todas las herramientas en cada proyecto.

También crea dependencias entre la versión del editor, las versiones de los packages y sus posibles funciones experimentales.

Unity ofrece tres grandes familias de pipelines de renderizado.

El Built-in Render Pipeline es el pipeline histórico. Sigue siendo compatible con numerosos proyectos y assets antiguos, pero recibe menos innovaciones que los pipelines recientes.

El Universal Render Pipeline, o URP, está diseñado para cubrir una amplia variedad de hardware: móvil, Web, ordenador, consola y XR.

Busca ofrecer un equilibrio entre calidad visual, flexibilidad y rendimiento.

El High Definition Render Pipeline, o HDRP, está orientado a ordenadores y consolas de gama alta, visualizaciones realistas y proyectos que necesitan funciones gráficas avanzadas.

URP y HDRP se apoyan en el Scriptable Render Pipeline, que permite a Unity y a los desarrolladores construir pipelines de renderizado programables.

La elección del pipeline debe realizarse al principio del proyecto.

Los shaders, materiales, luces y efectos no siempre son directamente compatibles entre Built-in, URP y HDRP.

Shader Graph permite crear shaders mediante un grafo de nodos sin escribir sistemáticamente código HLSL.

Visual Effect Graph está destinado a efectos visuales complejos calculados principalmente en la GPU.

El sistema histórico de partículas, conocido habitualmente como Shuriken, sigue disponible para efectos más ligeros o ampliamente compatibles.

Unity 6.3 LTS mejora especialmente Shader Graph, VFX Graph, los materiales de terreno, las plantillas de shaders, el renderizado híbrido 2D y 3D y varios flujos gráficos.

Los elementos 3D pueden combinarse con mayor facilidad con las reglas de orden, luces y máscaras utilizadas en escenas 2D.

Unity dispone de un conjunto completo de funciones 2D.

Incluye sprites, Sprite Renderer, Sprite Atlas, Tilemap, Tile Palette, 2D Animation, 2D IK, Pixel Perfect Camera, 2D Lights y herramientas de físicas 2D.

Unity 6.3 también incorpora una API de físicas 2D de bajo nivel basada en Box2D 3, orientada al multithreading, a un determinismo mejorado y a la depuración visual.

Las funciones 3D abarcan meshes, materiales, luces, cámaras, terrenos, niveles de detalle, occlusion culling, navegación e integración con programas como Blender, Maya o 3ds Max.

Unity no es, sin embargo, un programa completo de modelado 3D.

Los assets suelen crearse en Blender, Maya, Cinema 4D, 3ds Max, ZBrush o una herramienta CAD y después se importan al proyecto.

El package ProBuilder proporciona herramientas de construcción y blockout directamente en el editor.

Es adecuado para prototipos, niveles sencillos y geometrías de referencia, pero no sustituye a una suite de modelado especializada.

El sistema de animación se basa en Animation Clips, Animator Controllers, máquinas de estados, Blend Trees, Avatars y diferentes tipos de rig.

Mecanim permite especialmente reutilizar animaciones humanoides entre personajes compatibles.

Timeline organiza animaciones, cámaras, sonidos, eventos y otras pistas a lo largo de una secuencia temporal.

Cinemachine proporciona cámaras virtuales, seguimientos, composiciones, transiciones, raíles y comportamientos adaptados a juegos y cinemáticas.

El package Animation Rigging añade restricciones destinadas a la animación procedural, IK y ajustes realizados después de la animación principal.

Las físicas 3D se apoyan principalmente en NVIDIA PhysX.

Incluyen Rigidbodies, Colliders, Joints, Character Controller, raycasts, lanzamientos de volúmenes y detección de colisiones.

Las físicas 2D utilizan una pila independiente basada en Box2D.

Los objetos y componentes 2D no deben mezclarse sin precaución con los sistemas de físicas 3D.

Unity integra varias soluciones de interfaz.

UI Toolkit es el sistema moderno recomendado para numerosos proyectos nuevos y extensiones del editor.

Se inspira en las tecnologías Web, con una estructura visual, hojas de estilo USS y un modelo de interfaz retenida.

Unity UI, llamado habitualmente uGUI, sigue siendo muy utilizado para interfaces de juego creadas con Canvas, RectTransform, Images, Buttons y EventSystem.

IMGUI se emplea principalmente en determinadas herramientas del editor e interfaces históricas.

El motor de audio incluye AudioSource, AudioListener, Audio Clips, Audio Mixer, efectos, snapshots y espacialización.

Pueden integrarse plugins externos como FMOD o Wwise cuando el proyecto necesita un flujo de audio más especializado.

Unity dispone de varias herramientas de diagnóstico y optimización.

El Profiler analiza el procesador, el renderizado, la memoria, las físicas, el audio y otros ámbitos.

Unity 6.3 añade especialmente un módulo Highlights destinado a resumir determinados datos y orientar el análisis.

El Frame Debugger descompone las llamadas de renderizado de una imagen.

El Memory Profiler ayuda a comprender la memoria ocupada por objetos, texturas, meshes y asignaciones.

El Profile Analyzer compara y agrega varias capturas.

Herramientas externas como RenderDoc, Xcode Instruments, Android Profiler, PIX o las herramientas de los fabricantes de consolas siguen siendo necesarias para determinados diagnósticos de bajo nivel.

Unity admite el desarrollo multiplataforma.

Un mismo proyecto puede dirigirse a Windows, macOS, Linux, Android, iOS, la Web, varios cascos XR, televisores, sistemas integrados y consolas, siempre que se disponga de las licencias y SDK necesarios.

Unity anuncia compatibilidad con más de veinte plataformas de ejecución.

El despliegue en PlayStation, Xbox, Nintendo Switch y otras plataformas cerradas requiere la aprobación del fabricante, acceso a su SDK y, por lo general, Unity Pro o una licencia proporcionada por el socio de la plataforma.

Unity 6.3 incorpora Platform Toolkit.

Este package proporciona una API común para funciones como cuentas, partidas guardadas, mandos, logros y servicios específicos de cada plataforma.

Su objetivo es reducir la cantidad de código específico necesario para Android, iOS, Steam, Windows GDK, PlayStation, Xbox y Nintendo Switch.

Unity también ofrece herramientas XR.

El sistema XR Plugin Management organiza las integraciones de plataformas.

OpenXR proporciona una base común para varios cascos y runtimes.

AR Foundation permite desarrollar experiencias de realidad aumentada basadas especialmente en ARCore y ARKit.

Las funciones disponibles dependen siempre del hardware, plugin, sistema operativo y versión de la plataforma.

El multijugador se organiza mediante varios packages y servicios.

Netcode for GameObjects está orientado a proyectos basados en GameObjects y MonoBehaviours.

Netcode for Entities está destinado a proyectos que utilizan Entities y una arquitectura orientada a datos.

Unity Transport proporciona una capa de red de bajo nivel compatible con las soluciones Netcode.

El Multiplayer Services SDK reúne los servicios Sessions, Lobby, Relay y Matchmaker mediante una API más coherente.

Relay permite conectar jugadores sin exponer directamente sus direcciones y sin mantener obligatoriamente un servidor dedicado.

Lobby organiza la creación, búsqueda y gestión de grupos de jugadores.

Matchmaker busca compañeros o servidores según reglas configuradas.

Vivox proporciona funciones de chat de voz y texto.

Unity también ofrece herramientas Dedicated Server, modos de prueba multijugador dentro del editor y ejemplos preparados para su estudio.

Unity Gaming Services incluye Authentication, Analytics, Cloud Code, Cloud Save, Economy, Leaderboards, Remote Config, Cloud Content Delivery, Push Notifications e In-App Purchasing.

Estos servicios son opcionales y pueden combinarse con backends externos.

Simplifican determinadas operaciones, pero crean una dependencia comercial, técnica y jurídica respecto a Unity Cloud.

Unity Cloud también incluye herramientas de colaboración y producción.

Unity Version Control, anteriormente Plastic SCM, está diseñado para proyectos que contienen grandes archivos binarios y para la colaboración entre artistas y desarrolladores.

Build Automation compila automáticamente el proyecto en la nube o, según la oferta, en infraestructuras controladas por la empresa.

Asset Manager organiza y comparte assets de gran tamaño.

Cloud Diagnostics recopila fallos, excepciones y datos de diagnóstico.

Addressables y AssetBundles facilitan la carga diferida y la distribución de contenidos.

Cloud Content Delivery puede alojar catálogos y bundles para actualizar contenidos sin publicar inmediatamente una nueva versión completa de la aplicación.

El Asset Store ofrece modelos, animaciones, texturas, sonidos, shaders, herramientas, plantillas, SDK y extensiones.

Los assets pueden ser gratuitos o de pago.

La mayoría son creados por editores externos y se conceden bajo la EULA estándar de Unity Asset Store.

Determinados productos utilizan una licencia no estándar o aparecen marcados como Restricted Asset.

Una licencia de asset no significa que el archivo fuente pueda redistribuirse, venderse por separado o compartirse libremente con otra organización.

Unity ofrece un sistema de inteligencia artificial integrado o conectado al editor.

Las funciones disponibles pueden incluir asistencia de código, agentes, búsqueda contextual, generación o modificación de contenido y conexiones MCP.

Unity AI utiliza precios, créditos y condiciones independientes. No debe confundirse con las funciones fundamentales incluidas gratuitamente en el motor.

Unity se distribuye mediante varios niveles.

Unity Personal es gratuito y está destinado a juegos y aplicaciones de entretenimiento cuando los ingresos y la financiación aplicables se mantienen por debajo de 200 000 dólares durante los doce últimos meses.

Unity Pro pasa a ser obligatorio cuando esas finanzas superan los 200 000 dólares, salvo reglas particulares relacionadas con clientes, socios o plataformas.

Unity Enterprise pasa a ser obligatorio por encima de 25 millones de dólares de ingresos o financiación.

Unity Industry se aplica a las aplicaciones realizadas fuera de los videojuegos y el entretenimiento. Este plan pasa a ser obligatorio cuando las finanzas totales de la empresa superan el millón de dólares.

Los usuarios que trabajan para un cliente deben comprobar si las finanzas del cliente intervienen en el cálculo del nivel de licencia.

Todos los usuarios de una misma organización deben emplear un nivel de plan compatible. La combinación de licencias Personal, Pro y Enterprise está estrictamente regulada o prohibida.

Unity Pro se factura por puesto.

La suscripción anual prepagada cuesta 2 310 dólares por usuario, mientras que la opción mensual cuesta 210 dólares al mes con compromiso anual.

Enterprise e Industry se facturan bajo presupuesto.

Los servicios cloud, el alojamiento, los créditos de inteligencia artificial, los assets, el soporte y determinados módulos pueden facturarse por separado.

La Unity Runtime Fee anunciada en 2023 fue eliminada en 2024.

Las condiciones actuales permiten distribuir Unity Runtime sin costes por instalación, royalties ni reparto de ingresos para proyectos creados con Unity 6 o versiones anteriores, siempre que se respeten las reglas de licencia y nivel financiero aplicables.

Su eliminación no impide que Unity modifique los precios de las suscripciones, los umbrales financieros o las condiciones para futuros usos.

Los proyectos, juegos y contenidos creados con Unity siguen siendo propiedad de sus autores.

No obstante, los derechos sobre assets, plugins, fuentes, músicas, modelos y servicios de terceros deben comprobarse por separado.

Funcionalidades

• Editor de escenas 2D y 3D: construcción visual de entornos e interacciones.

• Scene View: navegación y manipulación de objetos dentro del espacio de creación.

• Game View: previsualización del resultado desde las cámaras activas.

• Hierarchy: presentación jerárquica de los GameObjects presentes en una escena.

• Inspector: modificación de los componentes y propiedades del elemento seleccionado.

• Project Browser: navegación por los archivos y assets del proyecto.

• Console: visualización de logs, advertencias, errores y excepciones.

• Search: búsqueda de assets, objetos, escenas, comandos y datos.

• Overlays: visualización de herramientas contextuales en Scene View.

• Layouts personalizables: organización de los paneles según el flujo de trabajo.

• Varias ventanas: distribución del editor entre varias pantallas.

• Modos oscuro y claro: selección de la apariencia general del editor.

• Atajos configurables: modificación de los comandos de teclado.

• Shortcut Manager: consulta y personalización de atajos.

• Comandos contextuales: funciones que dependen del objeto, componente y ventana activa.

• Unity Hub: instalación y gestión de versiones del editor.

• Módulos de plataforma: incorporación de herramientas de compilación para Android, iOS, Web o escritorio.

• Plantillas de proyecto: inicio con configuraciones 2D, 3D, URP, HDRP o especializadas.

• Varias versiones simultáneas: conservación de ramas LTS y Update en una misma máquina.

• Archivo de versiones: descarga de versiones antiguas compatibles con un proyecto.

• Proyectos locales: conservación de los archivos del proyecto en el almacenamiento del usuario.

• Unity ID: cuenta utilizada para licencias, organizaciones, servicios y Asset Store.

• Unity Organisations: agrupación de proyectos, usuarios, suscripciones y servicios.

• GameObjects: contenedores principales de los objetos de una escena.

• Components: comportamientos y datos asociados a los GameObjects.

• Transform: posición, rotación, escala y relación padre-hijo.

• Jerarquía de objetos: creación de estructuras parentales anidadas.

• Activación de GameObjects: desactivación temporal de un objeto y sus componentes.

• Tags: identificación lógica de categorías de objetos.

• Layers: filtrado del renderizado, las físicas y los raycasts.

• Static Flags: indicación de los objetos que pueden participar en determinadas optimizaciones.

• Prefabs: creación de plantillas de objetos reutilizables.

• Prefab Instances: inserción de copias vinculadas a su prefab de origen.

• Nested Prefabs: inclusión de prefabs dentro de otros prefabs.

• Prefab Variants: creación de variantes que heredan de un prefab principal.

• Prefab Overrides: modificación local de una instancia.

• Apply y Revert: propagación o cancelación de overrides.

• Prefab Mode: edición aislada de un prefab.

• Scenes: organización de niveles, menús y entornos.

• Additive Scene Loading: carga simultánea de varias escenas.

• Scene Management: carga, descarga y cambio de escenas mediante scripts.

• Multi-Scene Editing: edición de varias escenas dentro del editor.

• Scene Templates: creación de nuevas escenas a partir de una estructura preparada.

• DontDestroyOnLoad: conservación de determinados objetos entre cambios de escena.

• ScriptableObjects: almacenamiento de datos como assets.

• Unity Serialization: guardado de campos compatibles en escenas y assets.

• Custom Editors: creación de inspectores adaptados a un componente.

• Property Drawers: personalización de la visualización de un tipo de dato.

• Editor Windows: creación de ventanas adicionales.

• Gizmos: dibujo de guías y referencias en Scene View.

• Handles: manipulación visual de propiedades personalizadas.

• Editor Tools: incorporación de herramientas interactivas propias del proyecto.

• C#: lenguaje principal para scripts de gameplay y herramientas.

• MonoBehaviour: clase base para numerosos componentes programados.

• Eventos del ciclo de vida: Awake, OnEnable, Start, Update, FixedUpdate y otros callbacks.

• Coroutines: ejecución de rutinas distribuidas entre varios frames.

• Eventos C#: comunicación entre sistemas mediante delegates y eventos.

• UnityEvent: evento serializable configurable desde Inspector.

• Interfaces C#: definición de contratos entre componentes.

• Generic Types: creación de estructuras y sistemas reutilizables.

• Async y Await: programación asíncrona en contextos compatibles.

• Assembly Definitions: separación del código en assemblies.

• Assembly References: control explícito de las dependencias entre módulos.

• Compilación condicional: activación de código según la plataforma o configuración.

• Scripting Define Symbols: definición de símbolos propios del proyecto.

• Mono: backend de ejecución disponible para determinados entornos.

• IL2CPP: conversión del código intermedio a C++ y compilación nativa.

• Managed Stripping: eliminación del código considerado inutilizado.

• Link XML: conservación de tipos necesarios para la reflexión.

• Burst Compiler: compilación optimizada de código compatible.

• C# Job System: ejecución paralela de tareas.

• Native Collections: estructuras de memoria adaptadas a Jobs y Burst.

• Entities: implementación moderna de un Entity Component System.

• Entities Graphics: renderizado de entidades y grandes cantidades de instancias.

• Baking de entidades: conversión de datos de authoring en datos ECS.

• ECS Systems: ejecución de lógica sobre grupos de componentes.

• ECS Queries: selección eficiente de entidades según sus datos.

• Netcode for Entities: red orientada a ECS para simulaciones multijugador.

• Visual Scripting: creación de lógica mediante grafos de nodos.

• Script Graphs: representación visual de operaciones y eventos.

• State Graphs: creación de máquinas de estados visuales.

• Variables visuales: datos de grafo, escena, aplicación u objeto.

• Custom Units: incorporación de nodos personalizados.

• Package Manager: instalación y actualización de packages.

• Package Manifest: definición de las dependencias del proyecto.

• Packages integrados: conservación de una copia modificable dentro del proyecto.

• Packages locales: carga de herramientas desde el disco.

• Packages Git: instalación desde determinadas URL Git compatibles.

• Scoped Registries: utilización de registros de packages externos.

• Samples de packages: importación de ejemplos y recursos educativos.

• Version Locking: conservación de versiones precisas en el archivo de bloqueo.

• Built-in Render Pipeline: pipeline histórico del motor.

• Universal Render Pipeline: pipeline adaptable a numerosas plataformas.

• High Definition Render Pipeline: pipeline destinado a hardware de gama alta.

• Scriptable Render Pipeline: base programable para pipelines modernos.

• Custom Render Pipelines: posibilidad de construir un pipeline específico.

• Render Pipeline Assets: definición de los principales parámetros de URP o HDRP.

• Quality Levels: configuraciones gráficas diferentes según el hardware.

• Pipeline por nivel de calidad: uso de configuraciones distintas según la calidad.

• Forward Rendering: renderizado directo adaptado a diferentes tipos de escenas.

• Forward+: gestión de un mayor número de luces en configuraciones compatibles.

• Deferred Rendering: renderizado diferido adaptado a determinadas escenas con numerosas luces.

• GPU Resident Drawer: reducción de determinados costes de CPU asociados al envío de objetos a la GPU.

• SRP Batcher: agrupación de llamadas de renderizado compatibles.

• Dynamic Batching: agrupación de pequeñas geometrías en determinados casos.

• Static Batching: agrupación de objetos estáticos.

• GPU Instancing: renderizado eficiente de numerosos objetos similares.

• Occlusion Culling: exclusión del renderizado de elementos ocultos por otros objetos.

• Frustum Culling: exclusión de objetos fuera del campo de visión de la cámara.

• LOD Group: cambio de modelo según la distancia.

• LOD Cross Fade: transición entre niveles de detalle.

• Mesh Renderer: renderizado de meshes estáticos.

• Skinned Mesh Renderer: renderizado de personajes y meshes deformables.

• Sprite Renderer: visualización de imágenes 2D.

• Line Renderer: generación de líneas en el espacio.

• Trail Renderer: creación de estelas detrás de un objeto.

• Particle System Renderer: visualización de partículas del sistema histórico.

• Sorting Layers: organización del orden de visualización 2D.

• Sorting Groups: agrupación de elementos para su ordenación.

• Renderizado 3D con ordenación 2D: integración de objetos 3D en las reglas de visualización 2D.

• ShaderLab: definición de shaders de Unity.

• HLSL: programación de shaders personalizados.

• Shader Graph: construcción visual de shaders.

• Sub Graphs: agrupación de bloques reutilizables en Shader Graph.

• Custom Function Nodes: inserción de código personalizado en un grafo.

• Lit Shaders: materiales que reaccionan a la iluminación.

• Unlit Shaders: materiales independientes de la iluminación.

• Decals: proyección de detalles sobre superficies.

• Terrain Shaders: creación visual de materiales para terrenos.

• Post-Processing Shaders: efectos aplicados después del renderizado principal.

• Shader Variants: versiones compiladas según las funciones activadas.

• Shader Variant Stripping: reducción de variantes innecesarias durante la compilación.

• Materials: conexión entre shaders, texturas y parámetros.

• Material Property Blocks: modificación de propiedades sin duplicar sistemáticamente los materiales.

• Render Textures: renderizado de una cámara o efecto en una textura.

• Custom Passes HDRP: inserción de etapas personalizadas en el renderizado.

• Renderer Features URP: extensión del pipeline URP.

• Render Graph: organización y optimización de pases de renderizado compatibles.

• Ray Tracing HDRP: efectos que utilizan ray tracing en hardware compatible.

• Path Tracing HDRP: generación de imágenes mediante path tracing en configuraciones compatibles.

• Indirect Ray Tracing: incorporación mediante GPU de numerosas instancias en Unity 6.3.

• Screen Space Reflections: reflejos calculados a partir de la imagen visible.

• Screen Space Ambient Occlusion: oclusión calculada en el espacio de pantalla.

• Volumetric Fog: niebla y volúmenes en HDRP.

• Cloud Layers y Volumetric Clouds: creación de cielos y nubes en HDRP.

• Sky Systems: cielos procedurales, HDRI y entornos de iluminación.

• Physical Sky: simulación de cielo inspirada en principios físicos en HDRP.

• Iluminación en tiempo real: cálculo dinámico de luces.

• Baked Lighting: precálculo de iluminación en lightmaps.

• Mixed Lighting: combinación de luces precalculadas y dinámicas.

• Lightmapper: generación de lightmaps.

• Progressive Lightmapper: cálculo progresivo de la iluminación.

• xAtlas Lightmap Packing: organización optimizada de lightmaps en Unity 6.3.

• Light Probes: muestreo de iluminación para objetos dinámicos.

• Reflection Probes: captura del entorno para reflejos.

• Adaptive Probe Volumes: representación volumétrica de la iluminación indirecta.

• Light Cookies: texturas proyectadas por las luces.

• Light Layers: control de los objetos afectados por determinadas luces.

• Shadows: sombras dinámicas y precalculadas.

• Shadow Cascades: mejora de las sombras direccionales a diferentes distancias.

• Contact Shadows: sombras de proximidad en configuraciones compatibles.

• Post-processing: efectos aplicados después del renderizado.

• Bloom: difusión de luz alrededor de zonas brillantes.

• Tonemapping: conversión de rangos dinámicos elevados para su visualización.

• Color Grading: corrección y estilización de colores.

• Vignette: oscurecimiento o coloración de los bordes.

• Film Grain: incorporación de grano visual.

• Chromatic Aberration: desplazamiento de colores inspirado en objetivos fotográficos.

• Depth of Field: desenfoque según la distancia de enfoque.

• Motion Blur: desenfoque asociado al movimiento.

• Lens Distortion: simulación de deformación óptica.

• Optimizaciones móviles de Bloom: filtros Kawase y Dual en Unity 6.3.

• Post-processing on-tile: efectos optimizados para GPU móviles y XR compatibles.

• Visual Effect Graph: creación de efectos visuales calculados en la GPU.

• GPU Events: activación de sistemas VFX desde otros efectos.

• VFX Instancing: utilización de instancias para determinados efectos.

• VFX Templates: ejemplos y bases para sistemas visuales.

• Particle System: sistema histórico de partículas.

• Emission Modules: control de la creación de partículas.

• Shape Modules: definición de su zona de emisión.

• Collision Modules: interacción de las partículas con la escena.

• Sub Emitters: activación de sistemas secundarios.

• Particle Trails: creación de estelas.

• Particle Lights: asociación de luces a partículas en los casos compatibles.

• Sprites: imágenes utilizadas en escenas 2D.

• Sprite Editor: recorte y preparación de sprites.

• Multiple Sprite Mode: extracción de varios sprites desde una imagen.

• Sprite Atlas: agrupación de sprites en texturas optimizadas.

• Sprite Atlas Analyser: análisis del uso de atlas en Unity 6.3.

• PSD Importer: importación de documentos Photoshop con sus capas compatibles.

• 2D Animation: rigging y deformación de sprites.

• Sprite Skin: deformación de un sprite mediante un esqueleto.

• 2D IK: cinemática inversa para rigs 2D.

• 2D Pixel Perfect: mantenimiento de una visualización coherente para pixel art.

• Tilemap: construcción de niveles mediante tiles.

• Tile Palette: selección y pintura de tiles.

• Rule Tile: adaptación automática de un tile según sus vecinos mediante herramientas compatibles.

• Animated Tiles: animación de tiles.

• Isometric Tilemaps: construcción de escenas isométricas.

• Hexagonal Tilemaps: utilización de cuadrículas hexagonales.

• Sprite Masks: enmascaramiento de sprites.

• 2D Lights: iluminación de sprites mediante el renderer 2D de URP.

• 2D Shadows: creación de sombras en escenas 2D compatibles.

• Normal Maps 2D: reacción de los sprites a la iluminación.

• Ordenación 2D y 3D combinada: integración de objetos volumétricos en una escena 2D.

• Physics 2D: simulación basada en Box2D.

• Box2D 3 Low-Level API: API multithread y depurable en Unity 6.3.

• Rigidbody2D: movimiento físico de un objeto 2D.

• Collider2D: formas de colisión 2D.

• CompositeCollider2D: combinación de varios colliders.

• Joints 2D: conexiones físicas entre objetos.

• Physics Material 2D: control de la fricción y el rebote.

• Raycast 2D: consulta de colliders en el espacio 2D.

• Effector 2D: zonas que aplican comportamientos físicos.

• Meshes 3D: geometrías trianguladas utilizadas en los objetos.

• Mesh Filter: referencia a la geometría de un objeto.

• Mesh API: creación y modificación de meshes mediante código.

• Mesh Data API: acceso eficiente a datos geométricos.

• Model Importer: importación de FBX, OBJ y otros formatos compatibles.

• Scale Factor: adaptación de la escala durante la importación.

• Rig Import: lectura de esqueletos y animaciones.

• Material Import: creación o vinculación de materiales desde un archivo 3D.

• Texture Importer: configuración de texturas según su uso.

• Compresión por plataforma: formatos y tamaños diferentes según el destino.

• Mipmaps: versiones reducidas de una textura según la distancia.

• Texture Streaming: carga de los niveles de textura necesarios.

• Mesh Compression: reducción del tamaño de determinadas geometrías.

• Read/Write Settings: conservación o eliminación de datos de CPU después de la importación.

• ProBuilder: blockout y geometría directamente en Unity.

• PolyShape: creación de volúmenes a partir de contornos.

• ProBuilder UV Editor: ajustes sencillos de UV.

• ProGrids histórico: snapping y colocación incorporados a herramientas modernas.

• Terrain System: creación de terrenos.

• Terrain Sculpting: modificación del relieve.

• Terrain Layers: pintura de texturas sobre el suelo.

• Trees y Details: colocación de vegetación y pequeños elementos.

• Terrain Holes: creación de aberturas en el terreno.

• Terrain Tools: herramientas adicionales de escultura e importación.

• Tree Editor histórico: creación de vegetación sencilla.

• SpeedTree Integration: importación y renderizado de vegetación compatible.

• NavMesh: representación de zonas transitables.

• AI Navigation Package: generación y actualización de superficies de navegación.

• NavMesh Agent: desplazamiento de un agente hacia un destino.

• NavMesh Obstacle: obstáculo dinámico para la navegación.

• Off-Mesh Links: transiciones como saltos, escaleras y teletransportes.

• NavMesh Components: superficies y volúmenes configurables.

• Physics 3D: simulación basada en PhysX.

• Rigidbody: movimiento físico de un objeto 3D.

• Colliders: Box, Sphere, Capsule, Mesh y otras formas.

• Triggers: detección de presencia sin colisión sólida.

• Physics Materials: fricción y rebote.

• Joints: Fixed, Hinge, Spring, Character y Configurable Joints.

• Raycasts: pruebas de colisión a lo largo de un rayo.

• SphereCast y CapsuleCast: pruebas de volúmenes en movimiento.

• Overlap Queries: búsqueda de colliders dentro de una zona.

• Collision Matrix: definición de las layers que pueden interactuar.

• Continuous Collision Detection: reducción de determinados atravesamientos a gran velocidad.

• Character Controller: desplazamiento controlado de un personaje sin un Rigidbody convencional.

• Cloth Component: simulación de tejidos en determinados meshes.

• Wheel Collider: físicas especializadas para vehículos.

• Fixed Timestep: frecuencia de actualización de las físicas.

• Manual Physics Simulation: control del momento en que se calcula la simulación.

• Animation Clips: almacenamiento de curvas y keyframes.

• Animation Window: creación y modificación de animaciones.

• Animator Component: ejecución de un Animator Controller.

• Animator Controller: máquina de estados de animación.

• Animator States: estados correspondientes a clips o Blend Trees.

• Animator Transitions: transiciones condicionales entre estados.

• Animator Parameters: booleanos, triggers, enteros y flotantes.

• Blend Trees: combinación de varias animaciones.

• Animation Layers: superposición de varios estados de animación.

• Avatar Masks: limitación de una animación a determinadas partes del cuerpo.

• Humanoid Rig: retargeting entre personajes humanoides.

• Generic Rig: animación de esqueletos no humanoides.

• Legacy Animation: compatibilidad con determinados proyectos históricos.

• Root Motion: desplazamiento basado en la animación.

• Animation Events: llamada a funciones desde una animación.

• State Machine Behaviours: scripts asociados a los estados del Animator.

• Inverse Kinematics Mecanim: ajuste de manos y pies.

• Animation Rigging: restricciones procedurales adicionales.

• Two Bone IK: resolución de una extremidad articulada.

• Multi-Aim Constraint: orientación hacia uno o varios objetivos.

• Multi-Parent Constraint: combinación de varias referencias parentales.

• Rig Layers: activación de grupos de restricciones.

• Timeline: secuenciación de pistas.

• Playable Director: componente que ejecuta una Timeline.

• Animation Tracks: animación de GameObjects.

• Activation Tracks: activación de objetos durante un periodo.

• Audio Tracks: colocación de sonidos.

• Signal Tracks: envío de eventos.

• Control Tracks: control de partículas, prefabs o timelines secundarias.

• Custom Playables: creación de pistas y comportamientos propios del proyecto.

• Cinemachine: sistema de cámaras virtuales.

• Virtual Cameras: cámaras de composición sin multiplicar los Camera Components.

• Camera Blending: transiciones entre encuadres.

• Follow y Look At: seguimiento y orientación hacia objetivos.

• Camera Noise: movimientos simulados de cámara.

• Confiner: limitación de una cámara a una zona.

• Dolly Tracks: desplazamiento sobre un raíl.

• Target Groups: encuadre de varios objetivos.

• Impulse: reacción de la cámara ante un evento.

• Cinemachine 2D: seguimiento adaptado a juegos bidimensionales.

• Cinemachine con Timeline: creación de cinemáticas.

• AudioSource: reproducción de sonido en una escena.

• AudioListener: punto principal de escucha.

• Audio Clips: archivos de sonido importados.

• Audio Mixer: mezcla y procesamiento de grupos de audio.

• Mixer Groups: organización jerárquica de sonidos.

• Mixer Snapshots: guardado de estados de mezcla.

• Audio Effects: filtros y procesamientos integrados.

• Spatial Blend: transición entre sonido 2D y 3D.

• Doppler Effect: modificación del tono según el movimiento.

• Audio Reverb Zones: ambiente sonoro localizado.

• Native Audio Plugins: integración de efectos nativos.

• FMOD y Wwise: integraciones externas disponibles.

• Video Player: reproducción de vídeos dentro de una escena.

• Render Texture Video: visualización de vídeo sobre un material o una UI.

• Timeline Video Workflows: sincronización de vídeos dentro de una secuencia.

• UI Toolkit: sistema moderno de interfaces.

• Visual Elements: elementos básicos del árbol de UI.

• UXML: definición estructural de una interfaz.

• USS: hojas de estilo inspiradas en CSS.

• UI Builder: construcción visual de interfaces UI Toolkit.

• Data Binding: vinculación de datos en contextos compatibles.

• Runtime UI: interfaces mostradas en juegos y aplicaciones.

• Editor UI: creación de herramientas e inspectores modernos.

• Runtime Debugging UI: integración de interfaces de herramientas en una aplicación.

• Unity UI o uGUI: interfaz basada en Canvas.

• Canvas: superficie principal de las interfaces uGUI.

• RectTransform: posición y dimensiones adaptadas a interfaces.

• Anchors: adaptación a diferentes resoluciones.

• Canvas Scaler: escalado según la pantalla.

• Images y Raw Images: visualización de sprites y texturas.

• Buttons: elementos interactivos.

• Sliders y Scrollbars: controles de valores y navegación.

• Scroll Views: visualización de contenidos desplazables.

• Layout Groups: organización automática de elementos.

• Content Size Fitter: adaptación al tamaño del contenido.

• EventSystem: gestión de entradas de la UI.

• TextMesh Pro: renderizado tipográfico avanzado.

• Signed Distance Fields: texto nítido a diferentes tamaños.

• Fallback Fonts: fuentes de sustitución.

• Rich Text: etiquetas de formato.

• Localization Package: gestión de idiomas y contenidos localizados.

• String Tables: almacenamiento de textos traducidos.

• Asset Tables: variantes de assets según el idioma.

• Smart Strings: cadenas dinámicas y variables.

• Pseudo-localization: prueba de longitud y compatibilidad de caracteres.

• Input System: gestión moderna de entradas.

• Input Actions: acciones abstractas como Jump, Move o Submit.

• Action Maps: agrupación de acciones según el contexto.

• Control Schemes: configuraciones de teclado, mando o pantalla táctil.

• Input Bindings: asociación de una acción con un control.

• Interactive Rebinding: modificación de controles por parte del usuario.

• Composite Bindings: ejes y vectores compuestos por varias teclas.

• Player Input: gestión de las entradas de un jugador.

• Player Input Manager: creación y asociación de jugadores locales.

• Local Multiplayer: varios dispositivos en una misma máquina.

• Touch Input: gestos y contactos táctiles.

• Sensor Input: acelerómetro, giroscopio y sensores compatibles.

• Haptics: vibraciones en dispositivos compatibles.

• Input Debugger: inspección de dispositivos y eventos.

• Legacy Input Manager: sistema histórico de entradas aún disponible.

• Accessibility APIs: funciones destinadas a mejorar la accesibilidad.

• Native Screen Reader Support: compatibilidad con lectores de pantalla en Unity 6.3 para plataformas compatibles.

• Color and Contrast Controls: posible adaptación de la interfaz y el contenido.

• Subtitles y Captions: creación mediante los sistemas de UI y audio del proyecto.

• Platform Toolkit: API común para servicios de plataformas.

• Account Management: abstracción de determinadas cuentas de plataforma.

• Platform Save Data: interfaz común para partidas guardadas compatibles.

• Controller Ownership: gestión del mando principal.

• Achievements: interfaz común para logros.

• Pruebas en el editor: simulación de determinadas funciones de plataforma.

• Android Google Play Services: integración compatible con Platform Toolkit.

• iOS GameKit: integración de servicios de Apple.

• Steam: funciones de plataforma en Windows.

• Windows GDK: integración de servicios compatibles de Microsoft.

• PlayStation 5: compatibilidad sujeta a las condiciones de acceso del fabricante.

• Xbox One y Series: compatibilidad sujeta a condiciones de acceso.

• Nintendo Switch y Switch 2: compatibilidad sujeta a condiciones de acceso.

• Build Profiles: configuraciones de compilación guardadas.

• Perfiles por plataforma: parámetros diferentes para cada destino.

• Player Settings: configuración del producto final.

• Quality Settings: niveles de calidad gráfica.

• Graphics Settings: pipeline y parámetros generales de renderizado.

• Physics Settings: configuración de la simulación.

• Time Settings: frecuencia y escala temporal.

• Audio Settings: frecuencia y configuración de audio.

• Package-specific Settings: parámetros propios de cada package.

• Build Settings históricos: interfaz conservada en determinados flujos.

• Windows Builds: creación de ejecutables para Windows.

• macOS Builds: creación de aplicaciones macOS.

• Linux Builds: creación de aplicaciones Linux.

• Android Builds: generación de APK o Android App Bundles.

• iOS Builds: generación de un proyecto Xcode.

• Web Builds: compilación a WebAssembly y WebGL.

• Universal Windows Platform: creación de aplicaciones UWP en versiones compatibles.

• Console Builds: despliegue en plataformas cerradas autorizadas.

• Apple Vision Pro: creación de aplicaciones espaciales con un plan compatible.

• tvOS: creación de aplicaciones para Apple TV.

• Android TV: creación de aplicaciones Android adaptadas.

• XR Builds: compilación para cascos y plataformas compatibles.

• Dedicated Server Builds: creación de Players sin renderizado para servidores.

• Headless Mode: ejecución sin interfaz gráfica.

• Command Line Arguments: automatización del editor y de las compilaciones.

• Batch Mode: ejecución sin interacción del usuario.

• Execute Method: llamada a un método C# desde la línea de comandos.

• Development Builds: compilación con herramientas y símbolos adicionales.

• Script Debugging: conexión de un depurador al Player.

• Autoconnect Profiler: conexión automática de un build al Profiler.

• Deep Profiling: instrumentación detallada del código.

• Managed Debug Symbols: conservación de información de depuración.

• Code Stripping: eliminación de código inutilizado.

• Compresión de texturas por plataforma: adaptación de los assets a cada dispositivo.

• Managed Code Compilation: compilación de scripts C#.

• Incremental Builds: reutilización de resultados intermedios.

• Build Cache: conservación de datos para acelerar compilaciones.

• Build Report: análisis del contenido y tamaño del build.

• AssetBundles: agrupación de assets que pueden cargarse por separado.

• Addressables: gestión de referencias y cargas asíncronas.

• Addressable Groups: organización de assets distribuidos.

• Local y Remote Groups: separación de contenidos integrados o remotos.

• Addressable Labels: agrupación lógica de recursos.

• Addressable Profiles: parámetros diferentes para desarrollo y producción.

• Content Update Workflow: actualización de assets sin recompilar toda la aplicación.

• AssetBundle Compression: LZ4, LZMA y modos compatibles.

• AssetBundle Variants históricos: mecanismos utilizados en determinados proyectos antiguos.

• StreamingAssets: inclusión de archivos conservados en su formato original.

• Resources Folder: carga sencilla pero difícil de optimizar en proyectos grandes.

• Async Loading: carga sin bloquear sistemáticamente el frame principal.

• Scene Streaming: carga progresiva de niveles.

• Profiler: análisis del rendimiento.

• CPU Profiler: medición del tiempo de procesador.

• GPU Profiler: medición del tiempo gráfico en plataformas compatibles.

• Rendering Profiler: estadísticas de renderizado.

• Memory Profiler: análisis de memoria.

• Audio Profiler: observación de voces y procesamiento de audio.

• Physics Profiler: análisis de cálculos físicos.

• UI Profiler: observación de interfaces.

• Network Profiler histórico: análisis disponible según los packages utilizados.

• Profiler Highlights: resumen estadístico incorporado en Unity 6.3.

• Profiler Markers: instrumentación personalizada de código.

• Custom Profiler Modules: incorporación de datos específicos.

• Profile Analyzer: comparación y agregación de capturas.

• Frame Debugger: inspección de las etapas de renderizado.

• Memory Snapshots: capturas detalladas de memoria.

• Rendering Statistics: triángulos, batches, SetPass y otras métricas.

• Editor Iteration Profiler: análisis de determinados tiempos de iteración.

• RenderDoc Integration: captura de un frame gráfico.

• Crash Reporting: notificación de incidentes mediante servicios compatibles.

• Cloud Diagnostics: recopilación de errores, excepciones y fallos.

• Log Files: registros del editor y de los Players.

• Stack Traces: visualización de la pila de llamadas.

• Debug Class: logs y assertions mediante scripts.

• Assertions: verificación de condiciones durante el desarrollo.

• Test Framework: creación de pruebas Edit Mode y Play Mode.

• Edit Mode Tests: pruebas ejecutadas sin iniciar completamente el juego.

• Play Mode Tests: pruebas en un contexto de ejecución.

• Parameterized Tests: pruebas con varios conjuntos de datos.

• Unity Performance Testing: mediciones repetibles de rendimiento.

• Code Coverage: análisis del código recorrido por las pruebas.

• Build Automation Tests: ejecución de pruebas en un pipeline automatizado.

• Unity Version Control: control de versiones adaptado a archivos grandes.

• Branches: desarrollo de variantes del proyecto.

• Changesets: grupos de modificaciones guardadas.

• Smart Locks: bloqueo de archivos binarios.

• Gluon Workflow: interfaz simplificada para artistas.

• Merge Tools: combinación de escenas, prefabs y archivos de texto compatibles.

• UnityYAMLMerge: combinación especializada de archivos serializados de Unity.

• Git Compatibility: utilización posible de Git con ajustes adaptados.

• Visible Meta Files: conservación de GUID en el control de versiones.

• Force Text Serialization: almacenamiento legible de escenas y prefabs.

• Build Automation: compilación cloud automatizada.

• Build Triggers: activación desde una rama o modificación.

• Cloud Build Machines: entornos Windows, Linux y macOS.

• Pipeline Automation: orquestación de procesos cloud.

• Asset Manager: gestión centralizada de recursos 3D.

• Cloud Storage: capacidad variable según el plan y el consumo.

• Unity Gaming Services: conjunto de servicios backend.

• Authentication: identificación anónima, mediante plataforma o personalizada.

• Cloud Save: almacenamiento del progreso y datos del jugador.

• Cloud Code: lógica de servidor ejecutada en la nube.

• Economy: monedas, inventarios y compras virtuales.

• Leaderboards: clasificaciones configurables.

• Analytics: análisis de eventos y comportamientos.

• Remote Config: modificación de parámetros sin publicar una nueva versión del juego.

• Game Overrides: adaptación de experiencias a segmentos de jugadores.

• Push Notifications: mensajes enviados a dispositivos compatibles.

• In-App Purchasing: gestión de productos y suscripciones de las tiendas.

• Cloud Content Delivery: alojamiento de contenidos descargables.

• Triggers: activación de acciones como respuesta a eventos o programaciones.

• Environments: separación de datos de desarrollo, staging y producción.

• Service Accounts: autenticación de procesos y herramientas de servidor.

• UGS Dashboard: configuración de servicios desde la Web.

• SDK de cliente: acceso a servicios desde un proyecto Unity.

• Web APIs: integración desde backends externos.

• Multiplayer Services SDK: interfaz común para varios servicios multijugador.

• Sessions: gestión de grupos y conexiones de jugadores.

• Lobby: creación y búsqueda de salas.

• Relay: conexión entre jugadores sin un servidor dedicado expuesto.

• Matchmaker: asociación de jugadores y servidores.

• Multiplay Hosting: alojamiento de servidores según la oferta disponible.

• Vivox: chat de voz y texto.

• Friends: funciones sociales entre jugadores.

• Unity Transport: capa de red de bajo nivel.

• Netcode for GameObjects: sincronización de proyectos basados en GameObjects.

• NetworkObjects: objetos con una identidad de red.

• NetworkVariables: datos sincronizados.

• Remote Procedure Calls: llamadas entre clientes y servidores.

• Client-Server Authority: control de la autoridad de red.

• Network Prefabs: prefabs registrados para la red.

• Netcode for Entities: red adaptada a ECS.

• Ghosts: entidades sincronizadas.

• Prediction: simulación local que anticipa los datos del servidor.

• Interpolation: suavizado de los estados recibidos.

• Host Migration: posible continuación de una sesión tras perder al host en flujos compatibles.

• Dedicated Server Package: optimización de builds de servidor.

• Multiplayer Play Mode: prueba de varios jugadores desde el editor.

• Multiplayer Tools: estadísticas y simulación de condiciones de red.

• Network Simulator: simulación de latencia, pérdidas e inestabilidad.

• Unity Building Blocks: componentes preparados para adaptar funciones habituales.

• Achievements Building Blocks: base para integrar logros.

• Leaderboards Building Blocks: base para integrar clasificaciones.

• Multiplayer Session Building Blocks: inicio de sesiones multijugador.

• XR Plugin Management: organización de plugins XR.

• OpenXR: estándar común para varios cascos.

• AR Foundation: abstracción para realidad aumentada.

• ARCore Integration: funciones AR en dispositivos Android compatibles.

• ARKit Integration: funciones AR en dispositivos iOS compatibles.

• XR Interaction Toolkit: interacciones mediante mandos, manos y objetos.

• Locomotion System: desplazamiento dentro de una experiencia XR.

• XR Grab Interactable: objetos manipulables.

• XR Ray Interactor: interacción a distancia.

• XR Device Simulator: prueba parcial desde el editor.

• Hand Tracking: seguimiento de manos en plataformas compatibles.

• Spatial Anchors: anclaje de contenidos en el entorno compatible.

• Passthrough: combinación de visión real y virtual según el hardware.

• Apple Vision Pro Support: creación de aplicaciones espaciales con un plan compatible.

• Android XR Support: integración con dispositivos y packages compatibles.

• Asset Store: catálogo de assets y extensiones.

• Assets gratuitos y de pago: recursos bajo diferentes licencias.

• Modelos 3D: personajes, entornos, objetos y vehículos.

• 2D Assets: sprites, tilesets, interfaces y efectos.

• Animations: clips, rigs y controladores.

• Audio: sonidos, músicas y plugins.

• Shaders y VFX: materiales, efectos y pipelines.

• Editor Extensions: herramientas que incorporan funciones a Unity.

• Templates: bases de proyectos y sistemas completos.

• SDK: integraciones con servicios externos.

• AI y ML Assets: herramientas y modelos propuestos por Unity o terceros.

• Package Import: incorporación de assets descargados al proyecto.

• My Assets: biblioteca vinculada a la cuenta.

• Publisher Tools: herramientas destinadas a creadores de assets.

• EULA estándar: licencia aplicada generalmente a los assets.

• Licencias no estándar: condiciones propias de determinados editores.

• Restricted Assets: recursos sujetos a restricciones adicionales.

• Seat Extensions: assets cuyo número de licencias depende de los usuarios y del tipo de recurso.

• Unity Learn: plataforma de tutoriales y recorridos de aprendizaje.

• Microgames: proyectos educativos preparados para su modificación.

• Pathways: recorridos guiados para aprender el editor.

• Samples oficiales: ejemplos de sistemas y buenas prácticas.

• Unity Discussions: foro comunitario oficial.

• Documentation Manual: explicaciones conceptuales y guías.

• Scripting API: referencia de clases, métodos y propiedades.

• Package Documentation: documentación específica de cada package.

• Release Notes: lista de modificaciones y problemas conocidos.

• Upgrade Guides: instrucciones de migración entre versiones.

• Unity AI: herramientas opcionales de inteligencia artificial.

• Agente de IA: asistencia contextual según la oferta disponible.

• Unity AI Gateway: conexión con funciones y modelos compatibles.

• Créditos Unity AI: cuotas consumidas según las operaciones.

• Conexiones MCP: exposición de herramientas o contexto mediante Model Context Protocol.

• Prueba limitada: acceso temporal a determinadas funciones de IA.

• Suscripción separada: pago necesario más allá del acceso incluido o de prueba.

Casos de uso

Crear un juego móvil

Unity está especialmente adaptado a juegos Android e iOS.

El equipo puede compartir gran parte del código y de los assets entre ambas plataformas y después aplicar configuraciones específicas para controles táctiles, rendimiento, tiendas y formatos de pantalla.

URP, Sprite Atlas, Addressables, Input System y las herramientas de profiling facilitan la adaptación a dispositivos muy diferentes.

Producir un juego independiente en 2D

Sprites, Tilemaps, Physics 2D, 2D Animation y Pixel Perfect Camera cubren gran parte de las necesidades de un plataformas, RPG, puzle o juego narrativo.

El código C# permite superar las funciones visuales y construir sistemas personalizados.

Asset Store puede acelerar la creación, pero una acumulación de plugins hace que el proyecto sea rápidamente difícil de mantener.

Desarrollar un juego 3D multiplataforma

Unity permite construir niveles, integrar personajes, programar el gameplay y desplegar el proyecto en varios sistemas.

URP es adecuado para una amplia variedad de hardware.

HDRP resulta relevante para proyectos orientados a ordenadores y consolas de gama alta, pero exige más recursos y no cubre las mismas plataformas.

Prototipar rápidamente una mecánica

GameObjects, Components, Prefabs y scripts MonoBehaviour permiten montar rápidamente un prototipo.

ProBuilder puede utilizarse para el blockout del nivel.

Después deberá reestructurarse el prototipo si la arquitectura inicial no resulta adecuada para una producción prolongada.

Participar en una game jam

Unity Hub, las plantillas y Asset Store permiten comenzar rápidamente.

La disponibilidad de numerosos tutoriales facilita la resolución de problemas habituales.

Sigue siendo preferible utilizar una versión ya instalada y conocida, porque la descarga de módulos puede tardar bastante tiempo.

Crear un juego de plataformas

Character Controller, Rigidbodies o Physics 2D pueden gestionar el movimiento.

Cinemachine sigue al personaje y adapta el encuadre.

Tilemaps, Prefabs y escenas aditivas facilitan la construcción de niveles.

Crear un RPG

Los ScriptableObjects pueden representar personajes, objetos, habilidades y misiones.

Los Prefabs sirven para enemigos, efectos y elementos interactivos.

Cloud Save, Economy o un backend externo pueden conservar el progreso y los inventarios.

Crear un juego de estrategia

Los sistemas de navegación, UI, datos y selección pueden combinarse con centenares de unidades.

Jobs, Burst o Entities resultan interesantes cuando la escala supera lo que una arquitectura MonoBehaviour convencional puede gestionar con eficiencia.

El paso a ECS exige, sin embargo, una concepción diferente y mayores conocimientos.

Producir un juego multijugador cooperativo

Netcode for GameObjects puede sincronizar jugadores y objetos en un proyecto convencional.

Lobby y Relay facilitan la creación de sesiones sin desarrollar inmediatamente toda la infraestructura de red.

La lógica crítica debe permanecer controlada por una autoridad fiable para limitar las trampas.

Crear un juego competitivo con servidores dedicados

Unity puede generar un build de servidor sin renderizado.

Matchmaker busca una partida y un servidor disponibles.

Los costes de alojamiento, la seguridad, la observabilidad y el despliegue deben planificarse antes de la apertura al público.

Desarrollar un juego como servicio

Remote Config, Analytics, Cloud Code, Economy, Leaderboards y Cloud Content Delivery permiten hacer evolucionar una experiencia después de su publicación.

Los entornos separan desarrollo, staging y producción.

Este enfoque aumenta la complejidad operativa y la dependencia de servicios cloud.

Desplegar en consola

Por lo general se necesita Unity Pro o una licencia proporcionada por el fabricante.

El equipo debe ser aprobado por Nintendo, Sony o Microsoft antes de recibir los módulos, SDK y documentación confidencial.

El juego debe respetar las restricciones de rendimiento, almacenamiento, mandos, partidas guardadas y certificación de cada plataforma.

Crear un juego Web

Unity compila a WebAssembly y WebGL para ejecutar el contenido en un navegador compatible.

Este formato es adecuado para demostraciones, experiencias promocionales, juegos cortos y contenidos educativos.

El tamaño de descarga, la memoria, el multithreading, los códecs y el acceso al sistema siguen siendo más limitados que en una aplicación nativa.

Crear una experiencia de realidad virtual

OpenXR y XR Interaction Toolkit proporcionan una base común para varios cascos.

El equipo puede crear locomoción, agarre de objetos, interacciones a distancia y UI espacial.

La frecuencia de imágenes, la latencia y la comodidad deben probarse directamente en cada dispositivo de destino.

Crear una aplicación de realidad aumentada

AR Foundation permite compartir parte del código entre ARKit y ARCore.

La aplicación puede utilizar detección de planos, anclajes, cámara, profundidad y seguimiento según el hardware.

Las funciones realmente disponibles difieren entre dispositivos y versiones de los sistemas.

Desarrollar una aplicación para Apple Vision Pro

Unity Pro y las herramientas compatibles permiten crear aplicaciones espaciales.

El proyecto puede combinar contenido volumétrico, ventanas, interacciones y el entorno real.

Siguen siendo necesarios un Mac, Xcode, el hardware apropiado y las condiciones de Apple.

Crear una visualización arquitectónica

HDRP puede producir iluminaciones, materiales y reflejos adaptados a una visualización realista.

Cinemachine y Timeline permiten preparar un recorrido.

Unity no es una herramienta BIM y debe recibir datos limpios desde Revit, Blender, 3ds Max o un pipeline especializado.

Realizar una simulación industrial

Unity Industry está destinado a visualizaciones, configuradores, formación y aplicaciones ajenas a los videojuegos.

El motor puede mostrar máquinas, procedimientos, datos e interacciones en tiempo real.

Las empresas que superan el umbral financiero deben utilizar el plan Industry y comprobar las condiciones aplicables a los datos industriales.

Crear un gemelo digital

Los modelos 3D pueden vincularse a datos procedentes de sensores, API o sistemas externos.

Unity muestra el estado de un equipo y permite simular determinadas interacciones.

La precisión depende del modelo de datos y de los cálculos científicos, no únicamente del renderizado visual.

Producir una formación interactiva

Unity puede presentar un procedimiento, comprobar las acciones del usuario y registrar los resultados.

La misma base puede dirigirse a ordenadores, tabletas o cascos XR.

La accesibilidad, seguridad de los datos y mantenimiento de contenidos deben integrarse desde la fase de diseño.

Crear una experiencia para un museo

El motor puede controlar una pantalla táctil, una proyección, una instalación inmersiva o un dispositivo interactivo.

Las aplicaciones pueden funcionar localmente sin exponer toda su lógica a Internet.

Una instalación pública necesita modo quiosco, reinicio automático y supervisión del hardware.

Realizar una cinemática en tiempo real

Timeline, Cinemachine, Animation Rigging, HDRP y VFX Graph pueden producir una secuencia dentro del motor.

Los cambios de cámara, iluminación o animación son visibles sin esperar un renderizado offline completo.

Para una imagen final extremadamente compleja, Blender, Maya, Houdini, Unreal Engine o un motor de renderizado especializado pueden seguir siendo más adecuados.

Construir una interfaz interactiva

UI Toolkit o uGUI pueden crear menús, paneles de control y paneles.

Input System permite navegar con ratón, teclado, mando o pantalla táctil.

Unity sigue siendo más pesado que un framework Web o de escritorio para una aplicación compuesta principalmente por formularios y texto.

Crear un configurador de productos

El usuario puede cambiar el color, los materiales, las variantes y los accesorios de un producto 3D.

Addressables permite cargar opciones adicionales.

El proyecto puede desplegarse en ordenador, móvil, Web o casco según la complejidad del modelo.

Producir una aplicación educativa

Unity puede combinar texto, imágenes, vídeo, sonido, simulación e interacción.

Los sistemas de escenas y Prefabs facilitan la creación de varios capítulos o ejercicios.

Una herramienta más ligera puede resultar preferible cuando la experiencia no necesita renderizado en tiempo real ni interacciones complejas.

Crear una novela visual

ScriptableObjects, TextMesh Pro, Timeline y sistemas de datos pueden organizar diálogos, personajes y elecciones.

Los plugins de Asset Store ofrecen frameworks preparados.

El proyecto debe conservar sus scripts y datos en un formato exportable para evitar una dependencia completa de un plugin abandonado.

Desarrollar un serious game

Unity permite transformar un procedimiento o aprendizaje en una experiencia interactiva.

Analytics puede medir el progreso y las dificultades.

Las reglas de evaluación deben ser validadas por especialistas del ámbito correspondiente.

Crear un juego con contenido descargable

Addressables y Cloud Content Delivery pueden separar el programa principal de los nuevos assets.

El equipo puede añadir niveles, eventos o elementos cosméticos sin reconstruir todos los datos.

Los cambios de código suelen exigir una nueva versión distribuida por la tienda.

Publicar una herramienta en Asset Store

Un desarrollador puede crear una herramienta de editor, un sistema de gameplay, un shader, un modelo o una plantilla.

El package debe respetar las normas técnicas, las licencias de las dependencias y los requisitos de documentación.

Los assets se conceden mediante licencia y no se venden como una propiedad transferida al cliente.

Integrar un SDK externo

Unity puede recibir SDK de pago, publicidad, analytics, audio, red o inteligencia artificial.

Los packages pueden utilizar C#, bibliotecas nativas y plugins específicos de cada plataforma.

Cada SDK aumenta los riesgos de conflicto, tamaño, recopilación de datos y mantenimiento.

Automatizar builds

Batch Mode y la línea de comandos permiten compilar sin abrir manualmente el editor.

Build Automation ejecuta estas operaciones en la nube.

Las versiones de Unity, packages, SDK y secretos deben fijarse para producir builds reproducibles.

Utilizar Unity para Character Creator

Unity podría servir para mostrar personajes 3D interactivos y gestionar animaciones, expresiones, comportamientos y entornos.

Puede integrar audio, lip-sync, conversaciones e interacciones en tiempo real.

Este enfoque sería mucho más pesado que mostrar imágenes y vídeos pregenerados y necesitaría modelos 3D, rigs y animaciones adaptados.

Preparar una aplicación multiplataforma con una sola base

Platform Toolkit reduce parte del código necesario para cuentas, partidas guardadas y logros.

Las secciones de gameplay pueden mantenerse comunes.

No obstante, las interfaces, el rendimiento, los mandos, las compras y las reglas de certificación deben comprobarse por separado en cada plataforma.

Opinión de PANACHES

Unity es uno de los motores de videojuegos más importantes de la historia reciente del desarrollo independiente, móvil y multiplataforma.

Su principal fortaleza reside en el equilibrio entre accesibilidad, potencia y amplitud del ecosistema.

Un principiante puede desplazar objetos dentro de una escena, añadir un script C# y producir un primer build sin tener que construir un motor completo.

Un equipo experimentado puede desarrollar sistemas complejos, crear sus propias herramientas de editor, automatizar builds y desplegar en numerosas plataformas.

Esta progresión relativamente continua explica la presencia de Unity en escuelas, formaciones, game jams y estudios independientes.

La arquitectura GameObject y Component sigue siendo fácil de comprender.

Fomenta la composición en lugar de jerarquías de clases excesivamente rígidas.

Los Prefabs añaden un sistema de reutilización muy eficaz para personajes, objetos, interfaces y elementos de nivel.

Esta flexibilidad puede conducir, sin embargo, a una arquitectura desorganizada.

Un proyecto puede acumular rápidamente MonoBehaviours dependientes entre sí, referencias ocultas dentro de Inspector y objetos responsables de demasiadas funciones.

Unity no sustituye, por tanto, al diseño de software.

Los patrones, pruebas, convenciones y límites entre sistemas siguen siendo necesarios.

C# constituye una ventaja importante.

El lenguaje resulta más accesible que C++ para numerosos desarrolladores y permite construir herramientas y arquitecturas sólidas.

El ecosistema .NET también facilita la integración de bibliotecas, aunque no todas sean compatibles con las restricciones de Unity o IL2CPP.

El modelo de iteración sigue siendo una de las fortalezas históricas del motor.

Los diseñadores pueden modificar una escena y probar inmediatamente el resultado.

Los valores expuestos en Inspector facilitan los ajustes sin una recompilación completa.

Los tiempos de domain reload, importación y compilación pueden convertirse, sin embargo, en un problema importante en proyectos grandes.

Assembly Definitions, Enter Play Mode sin recarga completa y una buena separación del código reducen parte de estos retrasos.

La elección entre Built-in, URP y HDRP sigue siendo una fuente de confusión.

URP suele representar la opción más equilibrada para un nuevo juego multiplataforma.

HDRP ofrece más funciones gráficas de gama alta, pero aumenta las exigencias de hardware y reduce la lista de plataformas adecuadas.

Built-in sigue siendo útil para mantener proyectos antiguos, pero resulta menos relevante para una nueva producción a largo plazo.

La migración entre pipelines nunca es completamente neutra.

Los materiales, shaders y efectos adquiridos en Asset Store deben comprobarse antes de elegir un pipeline.

Shader Graph constituye un buen puente entre arte y programación gráfica.

Un artista técnico puede crear efectos sin escribir todo el shader.

Los grafos complejos siguen siendo código visual y deben estructurarse, documentarse y optimizarse.

VFX Graph permite producir efectos muy ricos.

Depende en mayor medida de la GPU y no resulta adecuado para todas las plataformas.

El sistema de partículas convencional suele ser más predecible para juegos móviles o Web.

Las herramientas 2D son actualmente lo bastante completas para numerosos juegos.

Tilemap, Sprite Atlas, 2D Animation, Physics 2D y URP 2D evitan tener que utilizar un motor separado.

Unity mantiene, sin embargo, una organización fundamentalmente heredada del 3D. Algunos motores especializados en 2D pueden resultar más directos.

La integración mejorada entre 2D y 3D en Unity 6.3 es especialmente interesante para juegos que combinan sprites, entornos volumétricos e iluminación.

La animación es muy completa.

Mecanim, Timeline, Cinemachine y Animation Rigging cubren tanto gameplay como cinemáticas.

La multiplicación de sistemas puede hacer difícil identificar la fuente real de un movimiento: Animator, Timeline, un script, un rig, las físicas o root motion.

El profiling es indispensable.

Unity puede ofrecer un rendimiento excelente, pero no lo garantiza automáticamente.

Una mala gestión de asignaciones, luces, texturas, scripts Update, físicas o Draw Calls puede ralentizar un proyecto incluso en un ordenador potente.

Las críticas de la comunidad sobre juegos Unity mal optimizados reflejan a menudo tanto las decisiones de los desarrolladores como las limitaciones del motor.

Esto no significa que el motor esté libre de problemas.

El editor puede volverse pesado, las importaciones largas y determinados sistemas presentar regresiones o cambios de comportamiento entre versiones.

Una versión LTS reduce el riesgo, pero no lo elimina.

La compatibilidad multiplataforma constituye una de las mayores ventajas de Unity.

La idea de crear una vez y desplegar en todas partes debe entenderse, sin embargo, como una base de código ampliamente compartida, no como un botón que produce automáticamente un resultado óptimo en todas las plataformas.

Cada plataforma posee sus propios mandos, memoria, API, tiendas, reglas de privacidad y restricciones de certificación.

Los builds deben probarse en dispositivos reales desde el principio.

Platform Toolkit representa una mejora pertinente.

Una API común para cuentas, partidas guardadas y logros reduce las capas de código propias de consolas y tiendas.

No elimina la obligación de obtener los SDK y autorizaciones de los fabricantes.

El multijugador fue considerado durante mucho tiempo una zona fragmentada dentro de Unity.

La combinación actual de Netcode, Transport, Multiplayer Services SDK, Lobby, Relay y Matchmaker ofrece un conjunto más coherente.

Sigue estando compuesto por varios packages y servicios, cada uno con su propio ciclo de vida.

Un equipo debe elegir rápidamente entre modelo cliente-host, servidor dedicado, autoridad de servidor, GameObjects o Entities.

Relay simplifica las conexiones iniciales, pero no sustituye a un servidor autoritativo para un juego competitivo.

Unity Gaming Services acelera la creación de un backend.

Authentication, Cloud Save, Economy y Remote Config evitan desarrollar inmediatamente cada componente.

Su utilización introduce costes variables y dependencia de las API de Unity.

Una abstracción interna sigue siendo útil para permitir una migración posterior.

Asset Store es una fortaleza inmensa.

Contiene herramientas capaces de ahorrar varios meses de desarrollo.

También permite comenzar un prototipo con modelos, sonidos, interfaces y sistemas existentes.

La calidad varía considerablemente.

Algunos assets se mantienen durante años, mientras que otros dejan de funcionar después de una versión de Unity.

Los usuarios deben comprobar la fecha de actualización, las opiniones, el pipeline de renderizado, las plataformas y el nivel de soporte.

Un proyecto construido como un ensamblaje de decenas de assets puede volverse imposible de actualizar.

Los estilos, convenciones y arquitecturas entran en conflicto.

Asset Store debe complementar un proyecto, no sustituir su dirección técnica.

Las licencias de los assets merecen una atención especial.

La EULA estándar permite generalmente integrar un recurso en un producto, pero no redistribuir su archivo fuente como una biblioteca independiente.

Determinadas herramientas se conceden mediante licencia por puesto.

Algunos assets utilizan una licencia no estándar o contienen componentes open source marcados como Restricted Asset.

La historia de la licencia de Unity ha afectado profundamente a la confianza de la comunidad.

El anuncio de Runtime Fee en 2023 generó una preocupación legítima sobre la posibilidad de modificar las reglas económicas después de que un equipo hubiera elegido el motor.

Unity terminó eliminando estas tarifas.

Las condiciones actuales indican que no se aplican Runtime Fee, royalties ni reparto de ingresos a la distribución del motor.

Su eliminación no borra la historia ni el riesgo comercial.

Unity sigue siendo un producto propietario cuyas suscripciones, umbrales y condiciones pueden evolucionar.

Una empresa debe conservar las condiciones aceptadas, las versiones utilizadas, las facturas y las pruebas de elegibilidad.

Unity Personal es generoso para un creador independiente de videojuegos situado por debajo del umbral financiero.

La eliminación de la obligación de mostrar el splash screen en Unity 6 suprimió una diferencia visual que antes era muy visible.

El umbral de 200 000 dólares ofrece más margen que el umbral anterior.

Las reglas se vuelven más complejas cuando el desarrollador trabaja para clientes.

Las finanzas del cliente pueden determinar la elegibilidad para un nivel de licencia.

Un freelance no debe tener en cuenta únicamente su propia facturación.

Unity Pro sigue siendo relativamente caro para un equipo pequeño.

Con 2 310 dólares por puesto y año, cinco desarrolladores ya representan un gasto importante antes de añadir servicios y assets.

Las suscripciones suelen estar asociadas a un compromiso y no pueden reducirse libremente durante el periodo contratado.

Unity Enterprise añade soporte, acceso de solo lectura al código fuente, opciones de build y soporte LTS ampliado.

El acceso de solo lectura no convierte Unity en un motor open source.

El equipo no dispone de la misma libertad que con Godot, Stride o un motor interno.

Unity Industry separa actualmente de manera clara las aplicaciones ajenas a los videojuegos.

Esta segmentación puede resultar costosa para empresas de visualización, arquitectura, automoción, salud o formación.

El umbral de un millón de dólares se refiere a las finanzas totales de la empresa y no únicamente a los ingresos del proyecto Unity.

Unity funciona localmente para la edición y compilación de numerosas plataformas.

No obliga a almacenar todos los proyectos en la nube.

Esta característica sigue siendo compatible con parte de la filosofía local-first de PANACHES.

La cuenta Unity, la activación de licencias, los packages, Asset Store y varios servicios crean, sin embargo, dependencias de red.

Unity ofrece menos soberanía que Blender o Godot.

Unity Version Control resulta interesante para equipos que combinan código y archivos binarios.

Git sigue siendo posible, pero exige una configuración correcta de los archivos .meta, la serialización de texto y Git LFS.

Una mala gestión de los GUID puede romper las referencias entre assets.

Los archivos .meta deben versionarse siempre junto a su archivo asociado.

Los servicios cloud de Unity son prácticos, pero no deben convertirse en la única copia de un proyecto.

El repositorio fuente, los builds, los assets comprados, los packages internos y las configuraciones también deben guardarse en otros lugares.

La inteligencia artificial integrada puede acelerar determinadas tareas.

No debería introducir silenciosamente código que el equipo no comprende o assets cuya licencia sea incierta.

Las condiciones de tratamiento, la confidencialidad y el coste de los créditos deben comprobarse antes de enviar código propietario o datos de clientes.

Entities, Jobs y Burst permiten alcanzar una escala importante.

Exigen una arquitectura orientada a datos muy diferente del modelo tradicional de GameObjects.

Su utilización no debe estar motivada únicamente por una promesa abstracta de rendimiento.

Un juego convencional puede seguir siendo más sencillo y suficientemente rápido con MonoBehaviours bien optimizados.

AlternativeTo clasifica Unity entre los motores freemium propietarios y destaca principalmente Godot, Unreal Engine y Stride como alternativas.

Las opiniones de la comunidad están muy divididas.

Los comentarios positivos suelen centrarse en la facilidad de aprendizaje, C#, la comunidad, Asset Store y la publicación móvil.

Las críticas se dirigen a la confianza en la empresa, el peso del editor, el rendimiento de determinados proyectos, la fragmentación de los sistemas y la evolución de las licencias.

Las críticas antiguas relacionadas con Runtime Fee deben contextualizarse: estas tarifas fueron eliminadas oficialmente.

Unreal Engine constituye la principal alternativa propietaria para proyectos 3D de gama alta.

Ofrece en varios casos una licencia basada en royalties, acceso al código fuente y una integración sólida de herramientas artísticas.

Su editor y C++ pueden resultar más exigentes, aunque Blueprints facilite el prototipado.

Godot es la principal alternativa libre y open source.

Es ligero, transparente y especialmente agradable para numerosos proyectos 2D.

Su ecosistema, compatibilidad con plataformas cerradas y herramientas de gama muy alta siguen siendo menos amplios que los de Unity.

Stride es un motor open source en C#.

Puede interesar a los desarrolladores que quieren permanecer cerca de .NET sin depender de Unity.

Su comunidad y Asset Store son mucho más pequeños.

GameMaker ofrece un flujo muy directo para 2D.

Resulta menos adecuado para proyectos 3D complejos o equipos que buscan un pipeline generalista.

Para PANACHES, Unity ofrece varios modelos de interfaz interesantes.

La combinación de Hierarchy, Scene, Project e Inspector muestra cómo separar estructura, espacio visual, archivos y propiedades.

El sistema de Components constituye una referencia pertinente para construir funciones modulares.

Los Prefabs ilustran la diferencia entre un recurso reutilizable y sus instancias personalizadas.

Los ScriptableObjects muestran cómo separar los datos del comportamiento y de las escenas.

Package Manager muestra el interés de un núcleo extensible, pero también los riesgos de fragmentación y dependencias incompatibles.

Asset Store puede inspirar una biblioteca PANACHES de módulos, plantillas y recursos.

La calidad de la búsqueda, las versiones, licencias, dependencias y opiniones deben tratarse como datos esenciales.

Addressables constituye una referencia útil para diferenciar un recurso lógico de su ubicación física.

PANACHES podría inspirarse en este modelo para gestionar medios locales, remotos, almacenados en caché o descargados bajo demanda.

Platform Toolkit ilustra el interés de una capa común por encima de varios proveedores.

Una abstracción comparable podría permitir a PANACHES conectar diferentes modelos de IA, sistemas de almacenamiento o servicios sin reescribir toda la aplicación.

Profiler recuerda que un software modular debe hacer visible su rendimiento.

PANACHES se beneficiaría de mostrar el consumo de memoria, los tiempos de carga, la actividad de los módulos y el tamaño de las cachés.

Para Character Creator, Unity podría convertirse en una plataforma de avatares 3D realmente interactivos.

Podría gestionar animaciones idle, expresiones faciales, lip-sync, cámaras, entornos, audio espacial e interacciones.

Esta vía exige, sin embargo, una cadena completa de modelos 3D, rigging, retargeting, optimización y renderizado en tiempo real.

El pipeline actual basado en SDXL, WAN y vídeos pregenerados sigue siendo más accesible con el hardware disponible.

Unity no debería integrarse únicamente porque pueda ofrecer una demostración espectacular.

Debe responder a una necesidad real de interacción en tiempo real que las imágenes y los vídeos no puedan satisfacer.

Unity merece un lugar destacado en el directorio PANACHES.

Sigue siendo un motor extremadamente capaz para crear rápidamente experiencias interactivas y distribuirlas en numerosas plataformas.

Su adopción debe acompañarse, sin embargo, de la elección de una versión estable, una arquitectura controlada, un estudio preciso de las licencias y un plan que limite la dependencia de servicios propietarios.

Puntos de atención

• Unity es propietario: el código completo del motor no puede modificarse ni redistribuirse libremente.

• Acceso limitado al código fuente: Enterprise ofrece principalmente acceso de solo lectura, con otras opciones que pueden facturarse por separado.

• Unity Personal está limitado por el uso: está destinado a juegos y aplicaciones de entretenimiento.

• Umbral Personal de 200 000 dólares: los ingresos y la financiación aplicables se miden durante los doce últimos meses.

• Unity Pro pasa a ser obligatorio por encima del umbral: la organización debe actualizar sus licencias cuando deja de ser elegible.

• Las finanzas del cliente pueden contar: un proveedor debe comprobar el nivel de sus clientes, no únicamente sus propios ingresos.

• Unity Enterprise pasa a ser obligatorio por encima de 25 millones de dólares: la tarifa es personalizada.

• Unity Industry se aplica a proyectos ajenos a los videojuegos: las aplicaciones industriales siguen reglas diferentes.

• Unity Industry pasa a ser obligatorio por encima de un millón de dólares: el umbral se refiere a las finanzas totales de la empresa.

• Unity Personal no está destinado a aplicaciones industriales: incluso un equipo pequeño debe comprobar las condiciones aplicables.

• Una licencia por usuario: cada persona que utilice el editor debe disponer de un puesto autorizado.

• No se pueden compartir puestos: una misma cuenta o suscripción no debe circular entre varios usuarios.

• Los planes no pueden mezclarse libremente: los usuarios de una organización deben utilizar un nivel compatible.

• Comprobar Unity Organisations: los puestos y proyectos deben estar asociados a la entidad correcta.

• Unity Pro se cobra por puesto: el coste aumenta directamente con el tamaño del equipo.

• Compromiso anual: el pago mensual de Pro no significa necesariamente una suscripción cancelable cada mes.

• Ausencia de una política general de reembolso: los contratos pueden seguir debiéndose hasta el final del compromiso.

• Sin reducción inmediata del número de puestos: las reducciones pueden tener que esperar hasta la renovación.

• Precios mostrados sin impuestos: IVA, divisa y región modifican el importe final.

• Enterprise e Industry bajo presupuesto: pueden aplicarse mínimos de puestos o de gasto.

• Servicios facturados por separado: cloud, alojamiento, IA, soporte y assets pueden aumentar considerablemente el coste.

• Runtime Fee eliminada: actualmente no se aplica ninguna tarifa por instalación.

• Sin royalties actualmente: la distribución de Runtime está permitida sin reparto de ingresos bajo las condiciones actuales.

• Cumplimiento permanente del nivel de licencia: la ausencia de Runtime Fee no elimina los umbrales financieros.

• Los precios pueden cambiar: Unity aplica ajustes de suscripción durante compras y renovaciones.

• Los umbrales pueden cambiar: deben supervisarse los anuncios y condiciones antes de cada renovación.

• Conservar las condiciones aceptadas: archivar la versión del contrato asociada al editor utilizado.

• Unity 6 exige condiciones recientes: las condiciones antiguas no permiten necesariamente utilizar una nueva versión.

• Versiones antiguas y condiciones antiguas: comprobar con precisión los derechos antes de permanecer en un editor histórico.

• No basarse en artículos de 2023: la Runtime Fee anunciada durante ese periodo fue cancelada.

• La historia sigue siendo un riesgo de confianza: una eliminación anterior no garantiza que las ofertas futuras permanezcan sin cambios.

• Las creaciones pertenecen a sus autores: esto no cubre automáticamente los recursos de terceros.

• Comprobar cada asset externo: modelos, texturas, músicas, fuentes y plugins conservan sus propias licencias.

• Los assets se conceden mediante licencia: una compra no transfiere necesariamente la propiedad intelectual.

• EULA estándar de Asset Store: la mayoría de los productos siguen las condiciones comunes de Unity.

• Pueden existir licencias no estándar: su presencia debe indicarse en la página del producto.

• Restricted Assets: determinados recursos contienen componentes que imponen restricciones adicionales.

• Assets por puesto: algunas herramientas del editor requieren una licencia para cada usuario.

• Los assets artísticos suelen poder integrarse: no deben redistribuirse como archivos fuente independientes.

• No revender un asset aislado: el producto final debe aportar una creación real.

• No compartir libremente los packages comprados: otra organización puede necesitar adquirir su propia licencia.

• Comprobar los derechos de los subcontratistas: todos los colaboradores deben estar cubiertos por una licencia adecuada.

• Conservar las facturas de Asset Store: permiten demostrar la adquisición de la licencia.

• Descargar los packages importantes: un asset puede retirarse de la tienda.

• Archivar la documentación de los assets: las guías en línea pueden desaparecer.

• Comprobar la fecha de la última actualización: un package antiguo puede dejar de funcionar con Unity 6.

• Comprobar el pipeline gráfico: un shader Built-in no es automáticamente compatible con URP o HDRP.

• Comprobar las plataformas anunciadas: un plugin de escritorio puede no compilar en móvil, Web o consola.

• Comprobar IL2CPP: determinados plugins funcionan con Mono pero fallan durante una compilación AOT.

• Comprobar las arquitecturas nativas: Windows x64, Apple Silicon, Android ARM64 y consolas utilizan binarios diferentes.

• Examinar las DLL incluidas: pueden introducir vulnerabilidades o licencias incompatibles.

• Las extensiones ejecutan código: instalar únicamente herramientas de editores y fuentes fiables.

• Un package puede modificar el editor: realizar una copia de seguridad antes de importar una herramienta importante.

• Las dependencias pueden entrar en conflicto: dos assets pueden exigir versiones diferentes del mismo package.

• Limitar la acumulación de plugins: cada dependencia aumenta el coste de mantenimiento.

• Evitar frameworks abandonados: un sistema central sin mantenimiento puede bloquear una migración.

• Mantener separada la lógica de negocio: reducir la dependencia respecto a la API de un asset externo.

• Probar la eliminación de un asset: comprobar que no deja referencias ni scripts rotos.

• Unity Hub está muy recomendado: gestiona las versiones y módulos de compilación.

• Comprobar la versión exacta del editor: los parches 6000.3.x pueden incluir diferencias.

• Utilizar una versión LTS para fijar la producción: las versiones Update introducen más cambios.

• LTS no significa ausencia de errores: leer los problemas conocidos y las patch notes.

• No actualizar automáticamente un proyecto crítico: probar cada parche en una rama separada.

• Realizar una copia de seguridad antes de cualquier migración: Unity puede modificar archivos y datos al abrirlos.

• Una migración puede ser irreversible: una versión antigua puede no ser capaz de volver a abrir un proyecto guardado recientemente.

• Conservar la instalación anterior: varias versiones pueden coexistir.

• Archivar los módulos de plataforma: una versión antigua puede resultar difícil de reinstalar.

• Fijar las versiones de los packages: una actualización indirecta puede modificar el comportamiento del proyecto.

• Examinar packages-lock.json: describe las versiones realmente resueltas.

• Evitar packages Preview en producción: sus API y datos pueden cambiar.

• Comprobar el estado Released o Verified: la compatibilidad depende de la versión de Unity.

• Leer las guías de actualización: determinadas funciones necesitan una migración manual.

• Elegir el pipeline de renderizado desde el principio: una conversión tardía afecta a materiales, shaders e iluminación.

• Built-in recibe menos innovaciones: resulta principalmente relevante para mantenimiento y determinados assets históricos.

• URP es la opción generalista: aun así debe configurarse para cada plataforma.

• HDRP está destinado a la gama alta: no resulta adecuado para la mayoría de móviles y navegadores.

• Los pipelines no son visualmente idénticos: un mismo material produce resultados diferentes.

• Los shaders personalizados deben dirigirse al pipeline: comprobar el código y los pases utilizados.

• Shader Graph puede generar muchas variantes: supervisar el tiempo de compilación y el tamaño del build.

• Reducir variantes innecesarias: configurar el stripping sin eliminar shaders necesarios.

• Probar los shaders dentro de un build: el editor puede utilizar una variante ausente del producto final.

• VFX Graph depende de la GPU: no todos los dispositivos admiten las mismas funciones.

• Prever una alternativa móvil: un efecto de gama alta puede necesitar una versión simplificada.

• Ray tracing limitado a hardware compatible: proporcionar un renderizado alternativo.

• Path tracing no es adecuado para gameplay convencional en tiempo real: sirve principalmente para renders y previsualizaciones de gama alta.

• El post-processing consume recursos: medir cada efecto en el hardware de destino.

• Bloom y transparencias pueden saturar el fill rate: problema frecuente en móvil y XR.

• Las luces dinámicas son costosas: limitar su número, alcance y sombras.

• Las sombras aumentan considerablemente el coste de GPU: adaptar su resolución y distancia.

• El baking de iluminación tarda tiempo: incluir los cálculos en la planificación.

• Los lightmaps utilizan almacenamiento y VRAM: supervisar su resolución.

• Adaptive Probe Volumes exige preparación: los volúmenes y escenarios deben configurarse correctamente.

• Reflection Probes debe organizarse: demasiadas capturas aumentan la memoria y el coste de renderizado.

• Static Batching puede aumentar la memoria: medir el equilibrio.

• Dynamic Batching tiene limitaciones: no asumir que resolverá todos los Draw Calls.

• GPU Instancing exige materiales compatibles: una modificación puede romper la agrupación.

• SRP Batcher exige una organización compatible de shaders: comprobarlo mediante herramientas de profiling.

• Occlusion Culling necesita un bake o configuración: no resulta útil en todas las escenas.

• El LOD debe prepararse dentro de los assets: un único modelo muy detallado no se optimiza automáticamente.

• El tamaño de las texturas suele dominar la memoria: adaptar resolución, compresión y mipmaps.

• Una textura 4K no siempre es necesaria: tener en cuenta el tamaño visible en pantalla.

• Las texturas sin comprimir son costosas: utilizar formatos propios de cada plataforma.

• Read/Write duplica determinados datos en memoria: desactivarlo cuando no sea necesario.

• Los meshes muy densos ralentizan la importación: realizar la retopología antes de Unity.

• Unity no es una herramienta completa de modelado: mantener Blender u otro DCC dentro del pipeline.

• Los cambios en un FBX reimportan sus dependencias: organizar los archivos fuente.

• No modificar directamente un asset importado: utilizar Prefabs, Materials y datos separados.

• Comprobar la escala de los modelos: unidades incoherentes afectan a las físicas, iluminación y navegación.

• Aplicar las transformaciones en el DCC: evitar escalas negativas y rigs incorrectos.

• Los materiales importados suelen necesitar conversión: comprobar los mapas y canales.

• ProBuilder resulta adecuado para blockout: no sustituye a una topología final optimizada.

• Terrain puede volverse pesado: controlar resolución, vegetación y distancias.

• Los árboles y detalles generan muchas instancias: analizar su renderizado.

• Los NavMeshes deben recalcularse: una modificación del nivel puede invalidar la navegación.

• Los agentes de diferentes tamaños necesitan ajustes separados: radio, altura y pendiente cambian.

• La navegación dinámica tiene un coste: evitar actualizaciones completas demasiado frecuentes.

• PhysX no es perfectamente determinista entre plataformas: actuar con precaución en simulaciones de red sincronizadas.

• Box2D 3 mejora determinados comportamientos: probar los proyectos migrados desde las antiguas físicas 2D.

• No mezclar Rigidbody y Transform sin estrategia: los movimientos directos pueden alterar la simulación.

• Utilizar FixedUpdate para las físicas: no depender únicamente de la frecuencia de imágenes.

• El timestep afecta a estabilidad y coste: una frecuencia elevada aumenta los cálculos.

• Continuous Collision Detection es más costoso: activarlo únicamente cuando sea necesario.

• Un Mesh Collider dinámico es costoso: preferir formas sencillas o convexas.

• Las colisiones por layer deben limitarse: reducir pares innecesarios.

• Los raycasts frecuentes tienen un coste: agrupar y filtrar consultas.

• Las físicas no sustituyen a una animación controlada: elegir el sistema según el gameplay.

• Root Motion puede complicar la red: decidir dónde reside la autoridad del movimiento.

• Los Animator Controllers grandes se vuelven difíciles de mantener: separar responsabilidades.

• Las transiciones deben controlarse: demasiadas conexiones crean estados impredecibles.

• Animation Events depende de nombres de métodos: resultan frágiles durante refactorizaciones.

• Timeline puede controlar las mismas propiedades que Animator: evitar conflictos.

• Cinemachine depende del orden y las prioridades: documentar las cámaras virtuales.

• Animation Rigging añade una etapa de cálculo: medir el coste de las restricciones.

• El retargeting humanoide no es perfecto: comprobar proporciones y orientaciones.

• Los blendshapes consumen memoria: eliminar las formas innecesarias.

• El audio comprimido reduce el tamaño pero utiliza CPU: elegir los ajustes según la duración.

• Decompress On Load aumenta el uso de memoria: evitarlo para músicas largas.

• Streaming utiliza el almacenamiento: probarlo en móviles y consolas.

• Por lo general solo debe estar activo un AudioListener: varios listeners generan errores.

• El audio espacial depende del plugin y la plataforma: probarlo con el casco o sistema de destino.

• FMOD y Wwise añaden dependencias: sincronizar sus versiones con Unity.

• UI Toolkit y uGUI son diferentes: elegir según el proyecto y la experiencia del equipo.

• UI Toolkit no siempre sustituye a uGUI: determinados flujos de juego siguen siendo más sencillos con Canvas.

• uGUI puede generar rebuilds costosos: separar los Canvas dinámicos y estáticos.

• Layout Groups puede recalcularse con frecuencia: evitar jerarquías excesivamente complejas.

• Las interfaces deben adaptarse a las proporciones de pantalla: probar teléfonos, tabletas y monitores ultrapanorámicos.

• Safe Areas móviles: evitar muescas y zonas del sistema.

• Debe probarse la navegación con mando: una interfaz de ratón no es automáticamente utilizable con gamepad.

• TextMesh Pro necesita atlas de glifos: planificar idiomas y conjuntos de caracteres.

• Las fuentes tienen sus propias licencias: comprobar los derechos de integración en el juego.

• Los idiomas aumentan la longitud de los textos: proporcionar más espacio en la interfaz.

• La pseudo-localization debe utilizarse pronto: revela elementos demasiado cortos o sin traducir.

• Las escrituras de derecha a izquierda necesitan validación: los plugins y versiones no cubren todos los casos del mismo modo.

• Input System y el antiguo Input Manager coexisten: evitar una migración parcial no controlada.

• Los nombres de los mandos varían: utilizar acciones abstractas en lugar de botones codificados directamente.

• Permitir rebinding: los usuarios deben poder modificar sus controles.

• Los dispositivos pueden desconectarse: gestionar los cambios durante la ejecución.

• El control táctil no es simplemente un ratón: adaptar gestos, tamaño de botones y precisión.

• Las vibraciones varían entre dispositivos: proporcionar una opción para desactivarlas.

• La accesibilidad debe diseñarse: una API de lector de pantalla no vuelve automáticamente accesible un juego.

• Añadir subtítulos y ajustes visuales: tamaño, contraste y velocidad deben poder configurarse.

• Probar sin sonido: la información importante no debe depender únicamente del audio.

• Probar el daltonismo: no utilizar únicamente el color para comunicar información.

• Platform Toolkit no elimina los SDK de los fabricantes: proporciona una abstracción, no una autorización.

• Las consolas exigen validación como desarrollador: Unity Pro no garantiza el acceso.

• Los SDK de consola son confidenciales: respetar los NDA y los espacios de trabajo seguros.

• La certificación puede tardar: planificar varias presentaciones.

• Las partidas guardadas deben respetar la plataforma: tamaño, cuotas y perfiles varían.

• Los logros deben probarse por separado: los identificadores y reglas difieren.

• Los mandos no poseen los mismos botones: adaptar los glifos.

• Apple exige un Mac para varias etapas: un PC Windows no basta para publicar directamente en iOS.

• Android necesita SDK, NDK y JDK compatibles: utilizar las versiones incluidas o recomendadas.

• Las normas de las tiendas evolucionan: las API de destino, privacidad y facturación cambian regularmente.

• Las compras integradas deben validarse en sandbox: no probarlas únicamente dentro del editor.

• La Web impone límites de memoria: una escena de escritorio no funciona automáticamente en un navegador.

• Los builds Web pueden ser grandes: comprimir y cargar progresivamente.

• WebAssembly no admite todas las API .NET: probar las bibliotecas externas.

• El multithreading Web depende del navegador y de los headers: configurar correctamente el servidor.

• Los códecs de vídeo Web varían: proporcionar formatos compatibles.

• Los navegadores móviles imponen restricciones de audio: puede ser necesaria una interacción antes de reproducirlo.

• El almacenamiento local Web puede ser limitado: no asumir que equivale a un sistema de archivos.

• Las aplicaciones móviles pueden suspenderse: guardar el estado durante las interrupciones.

• Los dispositivos de gama baja deben incluirse desde el principio: no optimizar únicamente al final.

• La temperatura reduce el rendimiento móvil: probar sesiones largas.

• El fill rate limita a menudo interfaces y partículas: supervisar las transparencias.

• La batería es un criterio de rendimiento: reducir cálculos y frecuencia cuando sea posible.

• XR exige una frecuencia de imágenes estable: las caídas pueden provocar incomodidad.

• Probar directamente en el casco: el editor no reproduce la latencia ni la ergonomía reales.

• Ofrecer varios métodos de locomoción: teletransporte, movimiento continuo y rotación configurable.

• Evitar aceleraciones de cámara no controladas: aumentan el mareo por movimiento.

• Las interacciones de manos varían: no todos los cascos ofrecen el mismo seguimiento.

• AR Foundation oculta solo una parte de las diferencias: determinadas funciones siguen siendo específicas de ARKit o ARCore.

• La detección de planos depende del entorno: la iluminación y las texturas afectan al seguimiento.

• Los anclajes pueden desviarse: no asumir precisión industrial sin validación.

• Los datos de cámara son sensibles: aplicar reglas de consentimiento y privacidad.

• El multijugador no puede añadirse al final: la arquitectura de red debe planificarse desde el principio.

• Elegir la autoridad de red: cliente, host o servidor dedicado modifican la seguridad y el coste.

• Netcode for GameObjects no es universal: determinados proyectos prefieren Mirror, FishNet, Photon o una solución interna.

• Netcode for Entities exige ECS: no puede integrarse como un simple sustituto dentro de un proyecto MonoBehaviour.

• La predicción es compleja: exige rollback, corrección e interpolación.

• Probar latencia y pérdidas: una conexión local perfecta oculta los problemas.

• Relay no es un servidor de gameplay: transporta conexiones sin ejecutar toda la lógica autoritativa.

• Un host puede hacer trampas: el modelo cliente-host no resulta adecuado para todos los juegos competitivos.

• Host Migration tiene limitaciones: probar los datos que realmente se conservan.

• El alojamiento de servidores tiene costes continuos: calcular el coste por jugador y región.

• Los servicios multijugador tienen precios independientes: comprobar las cuotas gratuitas y tarifas actuales.

• Prever el cierre de un servicio: documentar una solución de migración o funcionamiento degradado.

• No colocar secretos dentro del cliente: un jugador puede inspeccionar el build.

• Validar las acciones en el servidor: no confiar en los valores enviados por el cliente.

• Limitar los RPC: las llamadas frecuentes aumentan el ancho de banda y la carga.

• Comprimir y cuantificar los datos: sincronizar únicamente lo necesario.

• Utilizar identificadores estables: evitar depender de objetos creados en un orden impredecible.

• Proteger las API Web: utilizar autenticación, cuotas y validación.

• Cloud Save no es una base de datos general ilimitada: almacena principalmente pequeños datos del juego.

• Cloud Code añade latencia: no llamar a una función remota en cada frame.

• Economy debe controlarse desde el servidor: evitar compras y monedas modificables por el cliente.

• Remote Config puede romper una experiencia: validar las configuraciones antes de publicarlas.

• Separar los entornos: no realizar pruebas directamente con datos de producción.

• Analytics implica datos personales o seudónimos: informar a los usuarios y respetar el consentimiento.

• Minimizar los eventos recopilados: no enviar datos innecesarios.

• Prever la eliminación de datos: respetar los derechos del RGPD y las normativas locales.

• Push Notifications exige consentimiento: no acosar a los usuarios.

• Los servicios Unity crean dependencia del proveedor: aislar sus API detrás de una capa propia del proyecto.

• Los precios cloud son variables: estimar costes con un crecimiento realista.

• Las cuotas gratuitas no garantizan gratuidad a gran escala: configurar alertas presupuestarias.

• Cloud Content Delivery necesita un plan de versiones: un cliente antiguo debe recibir bundles compatibles.

• Addressables exige disciplina estricta: catálogos y grupos mal configurados provocan errores difíciles de diagnosticar.

• No mezclar Resources y Addressables sin estrategia: evitar duplicaciones dentro del build.

• Probar los contenidos remotos sin conexión: proporcionar una caché o un mensaje claro.

• Los catálogos deben permanecer accesibles: una avería remota puede bloquear la carga.

• Conservar una copia de los bundles publicados: permitir un rollback.

• Unity Version Control no debe ser la única copia de seguridad: mantener copias y políticas de restauración.

• Git exige los archivos .meta: su ausencia rompe los GUID y las referencias.

• Nunca regenerar voluntariamente todos los archivos .meta: las escenas y Prefabs perderían sus vínculos.

• Utilizar Force Text: facilitar diffs y determinadas fusiones.

• Las escenas siguen siendo difíciles de fusionar: repartir responsabilidades y utilizar varias escenas o Prefabs.

• Git LFS resulta útil para grandes archivos binarios: supervisar sus cuotas y costes.

• Bloquear los archivos que no pueden fusionarse: PSD, Blender, audio y determinadas escenas necesitan coordinación.

• Definir una convención de ramas: evitar varias versiones divergentes de los mismos assets.

• Los builds deben ser reproducibles: fijar Unity, packages, SDK y variables.

• Build Automation depende de Unity Cloud: prever una solución local o alternativa.

• Los minutos cloud están limitados o facturados: supervisar el consumo.

• Las máquinas macOS suelen ser más caras: planificar los builds de iOS.

• Los secretos de firma deben protegerse: no almacenarlos en texto plano dentro del repositorio.

• Conservar los certificados y keystores: perderlos puede impedir actualizar una aplicación.

• Profiler puede añadir sobrecarga: comparar Development Builds y Release Builds.

• Deep Profiling es muy intrusivo: utilizarlo en capturas cortas.

• El profiling dentro del editor no equivale al Player: medir en el dispositivo de destino.

• El rendimiento del editor puede ocultar el del build: probar ambos.

• Garbage Collector genera picos: limitar las asignaciones por frame.

• Evitar LINQ en bucles críticos: puede crear asignaciones y costes adicionales.

• Guardar en caché las referencias de componentes: evitar búsquedas repetidas.

• Limitar los métodos Update: centralizar o desactivar comportamientos inactivos.

• Utilizar pooling: evitar crear y destruir objetos continuamente.

• Las coroutines no son threads: se ejecutan principalmente en el thread principal.

• Jobs exige datos compatibles: los objetos gestionados no pueden utilizarse libremente.

• Burst no admite todo C#: comprobar los tipos y API compatibles.

• ECS aumenta la complejidad: utilizarlo únicamente cuando resuelva un problema real.

• La conversión GameObject-Entity exige una estrategia: definir el límite entre authoring y runtime.

• Los sistemas híbridos pueden ser difíciles de depurar: documentar los flujos de datos.

• Visual Scripting no elimina la lógica: un grafo grande puede ser más difícil de mantener que el código.

• Versionar los grafos visuales: sus diffs son menos legibles que los de C#.

• Crear unidades reutilizables: evitar la duplicación de grafos.

• Probar el stripping IL2CPP: puede eliminar tipos a los que solo se accede mediante reflexión.

• Conservar los tipos serializados: utilizar los atributos y archivos de linking necesarios.

• Los builds IL2CPP tardan más: tener en cuenta ese tiempo dentro de la CI.

• Los errores nativos son más difíciles de interpretar: conservar los símbolos de depuración.

• Los plugins nativos pueden bloquear el Player: aislar y probar sus llamadas.

• El código generado por IA debe revisarse: comprobar API, versión y coste.

• Unity AI utiliza créditos: supervisar consumo y suscripciones.

• No enviar código confidencial sin comprobar las condiciones: leer las normas de tratamiento de datos.

• Los contenidos generados pueden tener licencias inciertas: comprobar los derechos sobre los assets creados.

• Un agente puede modificar varios archivos: utilizar control de versiones antes de permitir su actuación.

• La IA no siempre conoce la versión del package: comprobar la documentación oficial.

• Las API de Unity evolucionan: un ejemplo encontrado en línea puede estar destinado a una versión antigua.

• La documentación está repartida: Manual, Scripting API, documentación de packages y servicios utilizan varios sitios.

• Las traducciones automáticas pueden ser imprecisas: consultar la versión inglesa en caso de duda.

• Los tutoriales antiguos siguen visibles: comprobar su fecha y versión del editor.

• Los ejemplos de Asset Store no siempre representan buenas prácticas: auditar su arquitectura.

• La comunidad es enorme pero heterogénea: comparar varias fuentes antes de una decisión importante.

• Unity Learn resulta útil para comenzar: una producción profesional exige más que los recorridos para principiantes.

• Comparar con Unreal Engine para 3D de gama alta: su renderizado, herramientas y acceso al código responden a otras prioridades.

• Comparar con Godot para libertad y ligereza: reduce la dependencia respecto a un proveedor.

• Comparar con Stride para C# open source: su ecosistema sigue siendo considerablemente más pequeño.

• Comparar con GameMaker para un desarrollo 2D rápido: su flujo de trabajo es más especializado.

• Elegir Unity por su equilibrio general: destaca cuando C#, el despliegue multiplataforma, el desarrollo móvil y el ecosistema son criterios centrales.