Mono is a magical sauce mixed into the Unity recipe, which gives it a lot of its cross-platform capability. Mono is an open source project that built its own platform of libraries based on the API, specifications, and tools from Microsoft's .NET Framework. Essentially, it is an open source recreation of the .NET library, was accomplished with little-to-no access to the original source code, and is fully compatible with the original library from Microsoft.

The goal of the Mono project is to provide cross-platform development through a framework that allows code written in a common programming language to run against many different hardware platforms, including Linux, macOS, Windows, ARM, PowerPC, and more. Mono even supports many different programming languages. Any language that can be compiled into .NET's Common Intermediate Language (CIL) is sufficient to integrate with the Mono platform. This includes C# itself, but also several other languages, such as F#, Java, Visual Basic .NET, pythonnet, and IronPython.

A common misconception about the Unity engine is that it is built on top of the Mono platform. This is untrue, as its Mono-based layer does not handle many important game tasks such as audio, rendering, physics, and keeping track of time. Unity Technologies built a native C++ backend for the sake of speed and allowed its users control of this game engine through Mono as a scripting interface. As such, Mono is merely an ingredient of the underlying Unity engine. This is equivalent to many other game engines, which run C++ under the hood, handling important tasks such as rendering, animation, and resource management, while providing a higher-level scripting language for gameplay logic to be implemented. As such, the Mono platform was chosen by Unity Technologies to provide this feature.

Scripting languages typically abstract away complex memory management through automatic garbage collection and provide various safety features, which simplify the act of programming at the expense of runtime overhead. Some scripting languages can also be interpreted at runtime, meaning that they don't need to be compiled before execution. The raw instructions are converted dynamically into machine code and executed the moment they are read during runtime; of course, this often makes the code relatively slow. The last feature, and probably the most important one, is that they allow simpler syntax of programming commands. This usually improves development workflow immensely, as team members without much experience using languages such as C++ can still contribute to the code base. This enables them to implement things such as gameplay logic in a simpler format at the expense of a certain amount of control and runtime execution speed.

Note that such languages are often called managed languages, which feature managed code. Technically, this was a term coined by Microsoft to refer to any source code that must run inside their Common Language Runtime (CLR) environment, as opposed to code that is compiled and run natively through the target OS.

However, because of the prevalence and common features that exist between the CLR and other languages that feature their own similarly designed runtime environments (such as Java), the term managed has since been hijacked. It tends to be used to refer to any language or code that depends on its own runtime environment, and that may or may not include automatic garbage collection. For the rest of this chapter, we will adopt this definition and use the term managed to refer to code that both depends on a separate runtime environment to execute and is being monitored by automatic garbage collection.

The runtime performance cost of managed languages is always greater than the equivalent native code, but it is becoming less significant every year. This is partly due to gradual optimizations in tools and runtime environments, and partly due to the computing power of the average device gradually becoming greater although the main point of controversy with using managed languages still remains their automatic memory management. Managing memory manually can be a complex task that can take many years of difficult debugging to be proficient at, but many developers feel that managed languages solve this problem in ways that are too unpredictable, risking too much product quality. Such developers might claim that managed code will never reach the same level of performance as native code, and hence it is foolhardy to build high-performance applications with them.

This is true to an extent, as managed languages invariably inflict runtime overheads, and we lose partial control over runtime memory allocations. This would be a deal-breaker for high-performance server architecture; however, for game development, it becomes a balancing act since not all resource usage will necessarily result in a bottleneck, and the best games aren't necessarily the ones that use every single byte to their fullest potential. For example, imagine a user interface that refreshes in 30 ms via native code versus 60 µs in managed code due to an extra 100% overhead (an extreme example). The managed code version is still fast enough that the user will never be able to notice the difference, so is there really any harm in using managed code for such a task?

In reality, at least for game development, working with managed languages often just means that developers have a unique set of concerns to worry about compared to native code developers. As such, the choice to use a managed language for game development is partly a matter of preference and partly a compromise of control versus development speed.

Let's revisit a topic we touched upon in earlier chapters but didn't quite flesh out: the concept of memory domains in the Unity engine.