Entry 3 - Selection of Game Engine. Part 2

Unity

It turned out that the C# language is very well suited for interacting with the external development environment. Unity uses pure C#, without any changes, and supports all its features, including the most modern. Native lambda expressions, events, and enumerators can save a lot of time. But how Unity adapted the embedded enumerator mechanism to create coroutines — emulation of the parallel code in one thread, at first seemed like some kind of magic for me. As a result, a person who knows C# needs exactly 1 day to start writing code for Unity. Also, the terrain system supports any changes in real time. In a month and a half I managed to do much more than in Unreal. Therefore I decided to stay on Unity. And since the first part of the game was written in C#, I could use pieces of code from it without any changes.

After two years of using the engine, I better understood how the engines work in principle. To form a picture, all the engines have a chain of methods - Rendering Pipeline. Both Unity and Unreal provide the opportunity to customize this chain. Only the default settings differ. For Unreal these default settings are designed for powerful hardware and for Unity - for mobile devices. However, you can always reconfigure Unreal for mobile devices or Unity for maximum graphics. Yes, for Unity this reconfiguration is not quite simple - it is not just a set of sliders and toggles. Some filters you should install separately and some you should buy or write your own. The initial feeling I had that games on Unity have worse graphics was caused by the reason that Unity has a much lower passing threshold, which has led many inexperienced users who are not able to adjust the graphics and use the default settings. However, there are also experienced teams that make beautiful games on Unity.

So I can officially declare that if the graphics in Force of Nature 2 is bad, then this is not because of Unity, but because of my crooked hands.