I bitch about Unity a lot, so it seems fair that I should give them a shout out when they’re doing good shit. Here’s some of the stuff in 2018 that I am looking forward to making my gamedev experience better.
IL2CPP for Standalone
This only works on Windows at the moment, but that’s enough really. The short version is that it converts c# into c++. That’s meant to be faster (in my tests I saw no difference but I didn’t test it in Rust, just a simple prototype).
When you compile normal Unity builds you get these dlls (76 dlls)
When you compile il2cpp you get this.
How is that better? Well, you can easily open any of the C# dlls in ILSpy and it’ll decompile the code.
And while decompiling isn’t perfect, it’s enough to make things like cheating really really stupidly easy. You can obfuscate and try to protect it in any number of ways, but then you’re making a rod for your own back in terms of error reports and callstacks and virus detectors.
With IL2CPP you’re compiling to a big dll. C++ can be decompiled, but not easily. And to be fair even if you handed them the source code they wouldn’t get on that great. Unity’s compiler actually makes a folder with all the converted c++ source code, here’s the “Die” function that was decompiled above. Keep in mind that this is what it looks like before it’s compiled so while you can see the basic layout of the function here, I doubt you’d even be able to find it after it’s compiled and decompiled.
The other big benefit, for me, is that if you’re compiling your game to work on il2cpp for Windows, it’s less of a hurdle to make it work on consoles at a later date (which all require compiling to il2cpp afaik). I’ll do another blog some time on some of the hurdles you need to jump to get your shit working on il2cpp.
I’m pretty sure this is in one of the later 2017 versions too, but it’s worth mentioning. In Rust we have a folder outside of the Assets folder with shit like this.
We tried to move a lot of our code into Dlls so that Unity doesn’t have to recompile it all. In 2018 they have Assembly Definitions, which mean that you can mark a folder in Assets as a separate assembly.
You can choose what platforms it should run on – which instantly makes things clean as fuck if you have platform specific code. (Please let us define our own platforms Unity, having a Server platform instead of using defines would make things so much cleaner).
The nice thing about this (and splitting into libraries in general) is that you can manage the references manually, so you can come up with a nice hierarchy of assemblies.
Using C# is awesome. A big part of that is nuget packages. The unity package manager seems to be an attempt to move towards that. So instead of downloading packages from the asset store you’ll use the package manager.
This is nicer because you don’t have to include the asset in your project, so you don’t have to commit that code. It’s a json file with a bunch of packages and when you open the project it downloads them, and includes them with your project.
It’s not opened up yet, so all it’s got is a few Unity packages. But I imagine in the future I’ll be able to stick Facepunch.Steamworks on there and it’ll just work. And when you want to update it you just press update and it updates and uses that version.
Again, don’t know whether this is new in 2018, but something I noticed that is useful. On the profiler you get these pink blocks – which is when memory is allocated.
Which is nice – because I remember in Rust wrapping everything in Profiler.Start’s to try to isolate where they were happening. But even nicer is that when you click on it you get a big dirty call stack showing exactly what’s allocating memory.
This would have saved us day, maybe even weeks of effort in Rust. Very very useful. (Although can we stop allocating shit in the editor unless it’s gonna allocate in the player please, or maybe just highlight that it won’t be a problem in release)