Should I continue work on a project in 2019.3.9f1, or should I try to update

[D-Coy]

I put down Unity about 4 years ago and have just recently returned… trying to pick up the piece from where I left off.
I have a bunch of old projects, some Id like to continue on, and find myself torn between updating and sticking to the version I left off on… which is pretty old now.
I have tried updating a few of these, most projects have worked, but Im finding some little glitches here and there in performance and other things.
So, any suggestions? Is it worth sticking with the old, or should I try (perhaps in vain) fixing problems in an upgrade to Unity 6?
Thanks

[Kurt-Dekker]

Unity is amazingly good at forward compatibility, but of course there’s always a chance for issues.

You should at least try to come a bit newer than 2019. You might even need to be newer depending on where you intend to publish, such as Google Play Android requiring at least (from memory) about Unity2020.3.41 or later (for 64bit and for the FMOD bug).

But be careful… put the entire thing in source control first, if it isn’t already, work in a branch, and spend whatever amount of time you think you need to in order to prove that all is well.

One helpful positive framing for your own brain is to look at it as an opportunity to review the full scope of your game, find out what is what, and take a good close look at stuff.

Here’s my general notes:

ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)

Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also “play nice” with the new version of Unity. Since you didn’t write the third party library, it is up to you to vet it against the new version to make sure it still works.

If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

Do not upgrade “just for fun” or you may become very unhappy.

PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL

I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

Prefab links keep getting dumped on Git pull

There really isn’t any fix because git works perfectly with Unity when configured properly. Best practices involve saving your work and closing Unity before using git. But if you understand how Unity does and does not flush changes to disk (or at least ALWAYS do a save-project), you can get away with leaving Unity open. The only thing linking EVERYTHING together in Unity is the GUID assigned to a script or asset. Name is irrelevant. Only the GUID connects it. This GUID is in the meta file. I…

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

2 steps backwards

Yeah, what Praetor said is it… Debug.Log is your friend, and also since this is animation related, you can open up the Animator window when you expect the animations to go, and actually visually see where the state machine is, see which state it thinks it is in. You can combine this with Debug.Log() output at the locations where you set the animations to be what you think they should be, and that should lead you to some intel. I highly recommend setting up git source control. It really plays ni…

Using fine-grained source control as you work to refine your engineering:

When to make a separate object or class/script? Help me think like a programmer! (Example in text.)

This is a reasonable initial approach. The problem is you have listed the parts, but you haven’t really listed how they interact, and even if you did, it’s still sorta up to you how to organize it. Only YOU will know how to organize it, and the only way you can tell is to do the work. I recommend this: first, develop ALWAYS with source control (such as git), and every time you get even the slightest thing working, commit those changes with good commit messages. Then move to the next thing, c…

Share/Sharing source code between projects:

Your techniques to share code between projects?

I have found that bundling your own code into DLLs only serves to slow down your workflow. I base this on several years of experience dealing with other teams well-intentioned packaging mishaps. With games, it is almost always useful to reach into library code, make a temporary tweak to isolate a problem, and then revert it. With DLLs this is impossible, making workflow harder and more brittle. I prefer to share source code at the C# level. That way I can reach into libraries trivially and inje…

Setting up an appropriate .gitignore file for Unity3D:

Removing IL2CPP_cache from Project

Not sure what you are “auto generating” with… I usually start from one of my other projects, or a gitignore example online, and reason about all the parts inside it, and start from there. Like any other configuration change, after you make it, pay attention for a while to make sure it is what you want. You can always clone the repo somewhere else to verify that the correct files are being tracked. Doing so to a brand-new computer is the acid test to make sure you can still build the project. …

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)

Setting git up with Unity (includes above .gitignore concepts):

How to Git with Unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

Source control does require learning, but there are TONS of tutorials and courses and online reference.

You should strive to use source control as confidently as you use your file/folder system.

“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards

[tleylan]

I’ll suggest that it depends in part what the target for these projects are. I have to assume they are experiments of some sort?

You would probably do well to create a new project using Unity 6 (of the same type of course) and trying to migrate parts over. If you build up from a base you should be able to determine when something stops working and tidy up just that part.

Some solutions will in fact automatically update but that may less than optimal if older libraries have been deprecated and replaced with newer ones. It will be easier in some cases to rearchitect your solution with the newer components.

[D-Coy]

Wow, thanks for the info. Lots here.
Some projects are definitely smaller and experimental. I wouldnt mind just rebuilding a couple from scratch (time depending) just to remember C# and tricks in Unity in general. But there are also a couple of bigger projects.
I think aiming for upgrading to a later version, rather than the latest version might be a solid route for these, and issues like the FMOD bug is something I was unaware of, so good to know.
Im mainly looking at creating for Win, so sounds like another reason I probably dont need to go to 6.
Thanks again for the info, much appreciated.

[Kurt-Dekker]

@D-Coy

I think aiming for upgrading to a later version, rather than the latest version might be a solid route for these,

I still keep a ton of my older personal projects in Unity5, since it is just so incredibly performant and relatively bug-free compared to more recent versions of Unity.

When I make a build I use Unity2018 for iOS builds and I use Unity2020 for Android and Android TV builds. I do this with source control branches, merging from my master branches into my u2020 and tv branches and keeping a separate machine that is only my build machine.

There are only a few minor warnings about API upgrades, and the ones that are annoying I simply handled by guarding them with conditional compilation directives, such as this one:

#if UNITY_2018_1_OR_NEWER
            ScreenCapture.CaptureScreenshot( filename);
#else
            Application.CaptureScreenshot( filename);
#endif

Minor stuff like that.

For my actual work / job stuff, yes, of course we all work in a much newer LTS version.