Protección del código
Las ediciones Starter, Indie y Pro entregan el motor como DLL compiladas dentro del
.unitypackage, no como código fuente en C#. En esas DLL ofusco los nombres internos del motor,
de modo que el paquete no se pueda abrir y leer sin más como código fuente.
Las ediciones Source y Studio incluyen el propio código fuente en C#, así que nada de esto se les aplica.
Esta página te cuenta qué significa eso en la práctica: si puedes escribir scripts contra el motor, si tus prefabs y escenas están a salvo y qué se deja legible a propósito.
Qué obtienes, por edición
| Edición | El motor se entrega como | API pública | Documentación XML | Símbolos de depuración |
|---|---|---|---|---|
| Starter | DLL compiladas | Cerrada | No | Ninguno |
| Indie | DLL compiladas | Legible | Sí | Ninguno |
| Pro | DLL compiladas | Legible | Sí | Ninguno |
| Source | Código fuente en C# | Código fuente | Lo lees en el código fuente | No aplica |
| Studio | Código fuente en C# | Código fuente | Lo lees en el código fuente | No aplica |
Indie y Pro: programa contra el motor con normalidad
En Indie y Pro la API pública se deja legible. Los nombres de sus tipos y miembros no se renombran, y el paquete incluye la documentación XML correspondiente. En tu IDE eso significa autocompletado, sugerencias de parámetros e información emergente en cada miembro público, exactamente igual que con cualquier otra biblioteca de C#.
Todo lo que no es API pública, es decir, las partes internas del motor, está ofuscado. No necesitas esos nombres para construir un juego: la superficie pública es la vía de entrada soportada. Consulta la API pública para ver qué abarca.
Starter: la API está cerrada
El Starter es la edición de evaluación, así que su API pública está cerrada: los nombres están ofuscados y no incluye documentación XML. No está pensado para que escribas C# contra ella.
Aun así puedes hacer todo lo que ofrecen el Inspector, el Hub y los grafos de scripting visual, y los componentes y assets conservan sus nombres normales (siguiente sección), de modo que puedes añadirlos a escenas y prefabs y verlos en el Inspector como siempre. Para escribir tu propio código contra el motor, pasa a Indie o a una edición superior. En las preguntas frecuentes se comparan las ediciones.
Qué nunca se ofusca, y por qué
En todas las ediciones se dejan intactos dos tipos de nombres, porque Unity los necesita:
- Los nombres de las clases que derivan de
UnityEngine.Object: componentes (MonoBehaviour) y assets (ScriptableObject). - Los nombres de los campos serializados.
Unity los busca por nombre. Los nombres de los campos son las claves que se escriben en tus archivos de prefabs y de escenas, y son las etiquetas que lees en el Inspector. Si yo los renombrara, los datos guardados en tus prefabs ya no encontrarían sus campos y esos prefabs se romperían.
Como los nombres de los componentes, los nombres de los assets y los nombres de los campos serializados nunca cambian, los prefabs y escenas que construyes con el motor no se ven afectados por la ofuscación.
La consecuencia es sencilla y sincera: esos nombres son visibles, porque Unity tiene que poder leerlos. Son la parte del motor que tiene que seguir legible para que funcione en tu proyecto.
Sin símbolos de depuración
Abrí los paquetes de Starter, Indie y Pro y ninguno contiene archivos de símbolos
(.pdb o .mdb). Una edición compilada no incluye nada que permita a un depurador recorrer
el código del motor línea por línea. Si necesitas depurar dentro del motor, para eso están
las ediciones Source y Studio.
La importación no se ve afectada
Importé cada edición compilada en un proyecto nuevo de Unity 6 para comprobar que la protección deja que el paquete se importe sin problemas, y lo hice dos veces por edición.