I created some game prototypes in Unity a few years back, and found it to be an excellent platform for rapid prototyping, with a ton of useful productivity-focussed features.
However, when I recently updated to the latest Unity v6.x and tried to load my v3.x game project prototypes it wouldn’t load my earlier prototypes – throwing numerous Object-Specific Compatibility Errors, which may be symptomatic of a potentially more serious issue with using the platform over an extended period.
No doubt I could have worked my way through all the numerous errors & fixed them – after all it’s not much different from upgrading to the latest SDK when you take a dependency on a Feature-rich C++ Library, but I did expect to be given the opportunity to Stick with the v3.0 API.
Had that been an Option I would have had a more satisfying User Experience – as it was it was an off-putting experience that significantly reduced my Confidence in using and recommending use of the Platform in the future.
I’m going to cut the Unity Team some Slack however, as it’s no Mean Feat to pull off this kind of complex but elegant Cross-Platform Indie-focussed Game Engine – and credit where credit’s due!
Critically, from an Indie Game Developer Perspective, The Unity Engine remains Free-to-use with a Sensible Tiered Licensing Plan – despite some quite recent unfortunate and decidedly Corporate-America Inspired “Monetization” Shenanigans.
A Fast Pivot was Executed, but the Damage was Done.
– Something for the Unity Team to be more Mindful of, Focus on, & Improve…
Based solely on my earlier experience using v3.x, overlooking the API Upgrade Issue, I would certainly recommend Unity, unless you’re following the somewhat unfortunate modern trend of Mega-Teams chasing Photo-Realistic, High-Performance, Multi-Platform, AAA-Quality Ray-Traced Graphics.
I won’t Bang On about this Trend (don’t get me started!) as it is Symptomatic of a Larger Industry-Wide Ecosystem Issue.
This requires a more Performance-Centric Approach, and requires an Engine built on C++, Architected from the ground up for Performance.
C# simply isn’t the right Programming Language choice for ensuring Optimal Runtime Performance – it’s Fundamentally Performance Limited by it’s reliance on a Garbage Collector (GC) based memory management model, and, to a lesser extent, the JIT on-demand compilation to Native Code.
Otherwise a have no beef with C# – I don’t use it personally as Modern C++20 has evolved to the point where it’s closed the gap between the programming model of C# & C++ – in the Key Areas of Feature set, Code Execution Reliability, Memory Management & Ease-of-use.