Skip to main content

Code Protection

The Starter, Indie and Pro editions deliver the engine as compiled DLLs inside the .unitypackage, not as C# source. In those DLLs I obfuscate the engine's internal names, so the package cannot simply be opened and read back as source code. The Source and Studio editions ship the C# source itself, so none of this applies to them.

This page tells you what that means in practice: whether you can write scripts against the engine, whether your prefabs and scenes are safe, and what is deliberately left readable.

What you get, by edition​

EditionEngine delivered asPublic APIXML documentationDebug symbols
StarterCompiled DLLsClosedNoNone
IndieCompiled DLLsReadableYesNone
ProCompiled DLLsReadableYesNone
SourceC# sourceSourceRead it in the sourceNot applicable
StudioC# sourceSourceRead it in the sourceNot applicable

Indie and Pro: program against the engine normally​

In Indie and Pro the public API is left readable. Its type and member names are not renamed, and the package carries the XML documentation for it. In your IDE that means autocomplete, parameter hints and tooltips on every public member, exactly as with any other C# library.

Everything that is not public API, the engine's internals, is obfuscated. You do not need those names to build a game: the public surface is the supported way in. See Public API for what it covers.

Starter: the API is closed​

The Starter is the evaluation edition, so its public API is closed: the names are obfuscated and it carries no XML documentation. You are not meant to write C# against it.

You can still do everything the Inspector, the Hub and the visual scripting graphs offer, and the components and assets keep their normal names (next section), so you can add them to scenes and prefabs and see them in the Inspector as usual. To write your own code against the engine, move to Indie or above. The FAQ compares the editions.

What is never obfuscated, and why​

Two kinds of names are left alone in every edition, because Unity itself needs them:

  • The names of classes that derive from UnityEngine.Object: components (MonoBehaviour) and assets (ScriptableObject).
  • The names of serialized fields.

Unity looks these up by name. The field names are the keys written into your prefab and scene files, and they are the labels you read in the Inspector. If I renamed them, the data stored in your prefabs would no longer find its fields and those prefabs would break.

Your prefabs and scenes are safe

Because component names, asset names and serialized field names never change, the prefabs and scenes you build with the engine are not affected by the obfuscation.

The consequence is honest and simple: those names are visible, because Unity has to be able to read them. They are the part of the engine that has to stay readable for it to work in your project at all.

No debug symbols​

I opened the Starter, Indie and Pro packages and none of them contains symbol files (.pdb or .mdb). There is nothing in a compiled edition that lets a debugger step through the engine's code line by line. If you need to debug inside the engine, that is what the Source and Studio editions are for.

Import is not affected​

I imported each compiled edition into a new Unity 6 project to check that the protection leaves the package importing cleanly, and I did it twice per edition.