Eazfuscator.NET and games are good friends.
The friendship is threefold:
- Code produced by Eazfuscator.NET is blinding fast
- Eazfuscator.NET covers Unity, MonoGame and XNA out of the box
- Existing titles at Steam and other distribution platforms prove this
MonoGame and XNA
MonoGame and XNA projects are very similar to generic .NET projects. They are developed in Microsoft Visual Studio or MonoDevelop IDE.
There is nothing special when it comes to obfuscation. Simply drop your project in the green zone of Eazfuscator.NET. Once protection is applied, the assembly gets obfuscated automatically every time you build the project in Release configuration.
Unity is kind of different. It supports a considerable amount of target platforms: iOS, Android, Windows Phone, Windows and Mac desktops among others. This affects Unity in a way that while it can be treated as IDE, in fact it is a Disintegrated Development Environment.
Everything is split into parts: rendering, behaviors and even a building pipeline. For example, when Unity targets Windows Phone it does not produce the Windows Store package you would expect. Instead, it outputs the Microsoft Visual Studio solution that should be built separately.
The same approach is used for iOS games where Unity outputs the project for Apple Xcode IDE. And yes, it should be built separately.
What about automation? That's possible but not a requirement. And most of developers just do it manually. This is a gaming world, after all!
The mindset is fueled by natural workflow diversity: doing paintings and design on Mac, coding in Visual Studio under Windows, building on Mac to get the iOS package.
If you are a Mac guy then it may go as follows: doing everything on Mac, going to Windows and Visual Studio just to get that Windows Phone game everybody wants to play.
The main game logic is defined in Assembly-CSharp.dll assembly. Assembly-CSharp-firstpass.dll may have the important code too, though it is rarely used.
Once Unity finishes the build, drag and drop Assembly-CSharp.dll assembly in the green zone of Eazfuscator.NET:
You are done. Then, please do the final build in Xcode or Visual Studio as usual. Some targets like Windows Desktop do not need further building. It just depends on target platform.
What about Unity Script?
Unity Script is a homebrew language for Unity. Like C#, it is based on .NET CLR. Probably it may be useful for some purposes but for the most it is hugely broken in many ways. It will work with obfuscation but renaming coverage will be non-existent. This happens due to reasons that go directly to weak Unity Script design.
Beware of Unity Script, use C#.
Web Player and Android Unity Targets
Web Player and Android Unity targets have a more complex build pipeline, so it may be problematic to integrate obfuscation there, though still possible. It requires significant amount of knowledge and manual work which goes out of the scope for most Unity users. That's why Eazfuscator.NET should be directly embeddable into Unity's build pipeline. While we are going to provide that great integration path in the future, Eazfuscator.NET is not there yet currently (but pretty close!)Get notification when seamless Unity integration is ready
Is Eazfuscator.NET special?
Yes. It just works and makes your code faster thanks to built-in optimizer. This is a good fit for games where every CPU cycle counts.