Issue: Small Team Unity Projects can be hard to maintain with Unity’s many changes
Working with Unity is great fun and allows developers of all levels to create astonishing games. It literally unites platforms and allows the same code to run on all devices of importance.
So everything could be perfect, and for most people it certainly is, but Unity changes a lot. With every update they have a tendency to introduce new concepts, new classes, new editor features and sometimes new bugs. When working in a small group on a game it can get very time consuming to jump to a new version of Unity.
One solution could be to simply stay with the given Unity version. Unfortunately every now and then external requirements change in way that you have make the update (e.g. when a new file system becomes mandatory).
Reading this Tweet gives one an idea of the level of discomfort an old Unity project can have. Opening a Unity 4.x project in Unity 2020 isn’t exactly fun.
Solution: Use Unity as a Platform
Depending on your skill set, especially when you are used to do most tasks in code, I suggest an additional way of thinking about Unity: see it as a Platform abstraction. Something in the lines of SDL or SFML, maybe.
Write your entire game in C# and avoid the Unity Editor, Unity’s Entity Component System (ECS) and Resource management. Implement your game on top of your own resource and game management classes. Write your game in a way where Unity abstracts the operating system and rendering for you. Use tools like Tiled but don’t import the data into a scene. Put all assets in a Resource folder. Avoid all automagic and Drag&Drops.
Back in the old times, Flash game developers did the same. They ignored the Flash Tools and used no (or little) of the graphical designer features and implemented everything in Action Script directly. Of course they still used the Flash rendering engine and asset loading features of the platform but they did the game relevant parts in their own code base.
In Unity the same is possible. Create your own Entity Component System in a way that suits your purpose and only use Unity’s components if you want to make use of their engines (e.g. Rendering, Physics).
Make sure that you store all your game relevant assets in a way that can be parsed in a pure C# environment (e.g. use JSON instead of ScriptableObjects). If you do so you get an excellent abstraction which hides away many pain points of modern operating systems and consoles.
If Unity changes it’s behavior from one version to another, most of your code won’t even notice. Only your custom resource manager and maybe some other bits. But your game assets stay in tact.
Obviously you throw away many of the good stuff Unity has to offer and you have to re-implement vital parts yourself. On the sunny side those vital parts will stay in tact as long as C# stays part of Unity. This won’t help big teams and low-code approaches but small teams with strong development background may benefit.