Legacy Projects and Unity

I'm posting this as a place to organize my thoughts and perhaps get some opinions or insight.

I released an open world game called Nimian Legends : BrightRidge in 2014. I've been updating it since, as well as using the same project as the basis for my next game, Nimian Legends : Vandgels.



Unity is an amazing feat of engineering. Like with all software, sometimes updates break backwards compatibility, change APIs or remove features.

When you start a new project with a new version of Unity you are generally protected from these issues. But when you are upgrading a project from earlier versions, project breaking problems can appear.

I'm finishing my current game as is, but when I'm done, I'd like to figure out a way to minimize these issues.

I have a few ideas:

Start a new project from scratch
Use the knowledge ive gained and rewrite everything from the ground up. Cons are the extra time, losing work that has already been built up, and it won't stop the same problem eventually happening, especially since games can have more than a 2 year development cycle.

Architect the project so it minimizes dependencies on specific features
Try to build games in a way taht do not depend on a specific language or engine as much as possible. This could mean abstracting the objects from the code wherever possible.

Stick with boilerplate unity basics
An example is my recent switch to TextMesh pro in unity 5, which needs to be upgraded in unity 2018 or higher, I should have stuck with basic unity text. Avoiding "beta" features like LWRP, HWRP, ECS etc while they are still in a state of flux.

Vet Asset Store purchases more thoroughly
Only purchase assets when absolutely necessary. Built from code homegrown solutions using simple, basic code and APIs whenever possible. Stick with assets that are game engine agnostic - that can work in any game engine - such as FBX models and animation, and textures.

Hybrid Ugrades
Upgrade legacy projects so that you have access in project to your code, objects etc. Then separate out the ones that are not afected by upgrades (like fbx and textures). Then rebuild only the parts that are susceptible to upgrade breaks. Cons are a bloated project without a fresh start, but means only rebuilding some of what you've created.

I think my approach focuses on the separation in my project folder and in the scene of assets that are safe (fbx, text fields, textures and to some degree materials) from susceptible ones like scripts (unity script gone), particles (legacy particles gone), untested APIs etc. This may also have the benefit of creating a cleaner and simpler project structure just by virtue of thinking about these things.

It doesn't mean avoiding everything new, but maybe just not leaping into every pool right away if that makes any sense.

And external dependencies also need to be taken into account. in my case i also have to consider ios and android because i build for mobile. And the MacOS, Xcode and iOS environments changes very fast.

The ultimate would be completely engine and language agnostic games, but that's not a reality right now. But i think following these approaches will at least make things more portable and flexible.

Has anyone else had difficulties upgrading legacy projects? Do you have different solutions or approaches you use to mitigate this?