Is it worth it for us to upgrade to a newer Unity version?

Edit: If anyone come across this old post:
My upgrade path went u4 -> u5.6 -> u2018.4(lts). 5.6 was def easier than expected (I later realized several issues I had were due to the outdated .blend mesh importer in older versions. I swapped the script with a newer one.

Beyond unity 5.6, I had to recomplie (I'm not a c++ guy) the outdated 64 bits dll of our in-house c++ bullet integration because since 2017, the unity editor is 64 bits only. The version of bullet we used had a bug with 64 bits, so I had to compile/upgrade that too.

the unity 2018 upgrade was almost automatic, except from one big thing. The jump to .net 4.6 caused a bunch of issues. Like TonyLi predicted, culture variance caused a big problem (our game loads worlds by parsing plain text) I think I fixed this by making the whole game culture-invariant with 2 lines of code. However, another issue then caused most maps to crash the editor.

I ran out of patience and chose 2018.4, since it lets you use the deprecated .net 3.5. I'm happy with it, since its past 2018.3, which was an important update. I'll try latest unity again in the future if some new feature catches my eyes. (Since our game is already written, adopting new features often requires rewriting a bunch of code)



We (small group) recently got access to the source of an old game dating from 2013. The source is working in U4.3 and we'd like to improve the game. We're not thinking about turning it into a commercial product.

The game uses bullet physics and a homemade wrapper for it. If this is an issue in the future, this could in theory be an option https://assetstore.unity.com/packages/tools/physics/bullet-physics-for-unity-62991 The game is bottlenecked by cpu performance for most people. We do not value improving the visuals that much, but improving performance is important. Implementing some netcode in the far future would be nice, but whenever we'll be attempting this is very uncertain.

I've tried opening the project in U5 because I had that in hand, while I've managed to solve complie errors then boot the game there was too many issues for it to be playable. One of us is a "if it's not broken don't fix it" kind of guy and for that reason wants to stick to unity 4 permanently.

I know you cannot make the decision of us, but I wanted to know what kinds of improvements and what degree of difficulty we can expect if we decide to upgrade the source to a newer version of Unity. That way, we can better weight the pros and cons for ourselves. Also, if we proceed would it be preferable to directly jump to the final Unity version we choose, or to do the upgrade in small steps, slowly incrementing the Unity version?

Thanks.

 

Well, here's some considerations.

Licensing changed significantly between Unity 4 and Unity 5. Do you have Unity 4 licenses for everyone, and are you happy with the licensing? Note that current licensing is free if you're under the income threshold, even if you do commercialise the game.

Next is target platforms. Chances are that you'll be fine making Unity 4 games for PC and Mac, but for other platforms it could be problematic. Often for particular platforms there's two or three year windows where you can deploy given any particular version of the engine, adn Unity 4 is older than that. Some build targets have been dropped since Unity 4, and some have been added.

Considering performance, for starters Unity's built-in physics got upgraded a couple of times since Unity 4, with performance being one of the big ticket items. I'd see if that helps with your own performance issues before deciding to continue maintaining a 3rd party integration. Outside of physics there's a whole bunch of other ways Unity's performance has increased - ECS might be directly relevant to your project (especially if you're CPU bottlenecked), non-allocating versions of various functions have been added, the Transform system has had significant improvements, I believe the Post Processing stack is more performant than the old individual effects, we've got instanced rendering functions (particularly useful if you've lots of similar objects)...

Considering general feature set, I'd take a look at what Unity has added in the last few years and see if there's anything that might save you time.

I strongly agree with not just upgrading for the sake of upgrading. Since you're newly picking up the project, though, I'd definitely give serious consideration to bringing it up to a current Unity version, particularly if doing so has a good chance of helping to address specific issues you've identified.

 

Since the jump is so big I'd probably go straight to the target version.

There's a couple of things you can do before you perform the jump, though:

• From memory, between Unity 4 and 5 some rules with Transforms changed. In particular, you can no longer do some things (reparenting, creating, destroying - from memory!) from the Awake() function.
  
• Similarly, activating and deactivating GameObjects has changed. Deactivating a parent now implicitly deactivates all children. Also, this is now done via SetActive(...) rather than by changing a public variable.

If you address those in Unity 4 and test that nothing has broken before you make the jump it'll simplify things a bit and maybe save some headaches on the other end. Others might be able to think of additional stuff to add, too.

 

The Unity 4 to 5 jump is likely more game breaking than the Unity 5 to 2018 jump, unless the game uses UnityScript (javascript), or Boo, which no longer exist in current versions of Unity.

AP mentioned licensing, and that is a big deal for Unity 4. Prior to Unity 5 the engine was feature crippled unless you bought a Unity Pro license, and Plus licensing did not exist yet. Shadows were one of the bigger features I remember, but there was a lot more. Unity 5 brought with it the Unity Personal license we have today, where there are very few features disabled.

Unity 4.3 will not be using the current UI system, which will be a pain doing any UI updates unless you upgrade to at least Unity 4.6 where the current UI system was introduced.

 

Joe, unity script is used, but only in small amounts i think. thank you. The game is very light with UI, it currently uses too many keyboards shortcuts + custom minimal ui that pops in only when you needs to use it. Also i did notice the performance profiler is greyed out, don't know if its because of what you mentioned. Thanks.

angrypenguin, I gotta say I'm impressed by how thorough your analysis was. Thanks a lot. Just using physX isn't something we've talked about. The physics' accuracy/performance is especially important for our project, but while everything else being equal we'd go with bullet, pragmatically speaking since PhysX is well integrated in an official way it might not be a bad option compared to Bullet from 2013. It will just be funny to go back since an older version used physx before being ported to bullet

Moving to 64 bits is something we'd like, would unity 4 be an hindrance in that?

 

Yeah Unity 4 had the profiler a Pro only feature. I think render to texture was another one. I can't remember the rest.

The Unity editor only got 64 bit versions starting with 5.0, but I think 64 bit builds of your game could be made long before that.

 

Spoiler: License Comparison Chart

 

You are most welcome!

What kind of issues were being solved by moving from PhysX to Bullet? I believe that Unity was using a dated version of PhysX for quite some time*, so it could have just been that, but there's also the consideration that Unity doesn't expose the full PhysX library.

Another performance consideration I didn't mention could be updates to the scripting system itself. We've now got stuff like IL2CPP, and newer C# compilers. Regarding the performance stuff, though, it really depends on what the core performance issues are. Running a poor algorithm in a faster environment is still probably not going to make a big enough different for the issues to go away.

* I think they ported it to a bunch of platforms it didn't support yet, so didn't do any updates until PhysX's own developers were supporting them. Or something like that?

 

More rigid joints and better collision detection/resolution I think, but I wasnt playing the game back then so I haven't experienced the older version firsthand and I'm not truly sure.

I do think we'll need to do a lot of work on optimization. We do have ideas for a few improvements to do there, at least.

Thanks to all of you.

 

Count on weeks if not months of simply getting the project to work in the new version before worrying about optimization. There are some really subtle things that can be hard to track down. For example, 2018 uses .NET 4 by default, which is culture-sensitive by default unlike .NET 3. If some deep-buried code does float to string conversion (e.g., .ToString()) and then parses it expecting a "." instead of "," as the decimal separator, you'll have issues on computers that use ",".

To make it easier on the script auto-updater, upgrade to 5.6 first, then 2017.3, then the latest. I wouldn't fully trust the 2018 updater be able to handle everything from 4.x.

 

I always always always wait a couple versions before upgrading. Because nothing sucks worse than a unity bug that is in beta crashing my development process and i have to wait for a fix.

 

Pretty useful info TonyLi, I've initially opened the project with 5.6 and had at least two severe issues (the screen in game mode is mostly black, maybe cause of issues with shaders and the .blend meshes and our custom map file loader made endless duplicates of every object in it)

Also, the guy thats reluctant to do the switch has authority in our team since he is the most skilled of us. Once I have a working version in hand, I might try to port it to the latest version of u4 I can since that would be a compromise he'd live with (I'm assuming, perhaps wrongly, that the transition from early 4 to late 4 would be substantially easier than 4 to 5)

I think I'll need real good arguments to convince him to go beyond that.

The optimizations I had in mind were really broad ones, but then again if we ditch the wrapper I'm assuming we'll basically have to rewrite the physics from scratch. So you're right that whatever direction we go, we'd need to commit to it asap.

 

I like how we can manage that now.

<stable----------------------latest>
LTS > Release > Beta > Alpha

And in reverse for the perverse!

<latest----------------------stable>
Alpha < Beta < Release < LTS

In UE4 land that's.... that's just not gonna happen. You stay with something or you forever play with features instead. You're quite far behind but you could:

1. just bite the bullet and go to latest beta near release (I'd recommend 2019.1 beta because it's pretty close to release and will be released by april and you'll be set for 2-3 years of only minor tweaks to the codebase IMHO). I am on this for production (but will ship using 2019.3 likely or even 2020, depending how sexy Unity is by then)

2. Go to Unity 5>2017>2018>2019.1

I recommend 2019.1 for both for a few reasons. Firstly, the scriptable render pipeline has been improved quite a bit, secondly GDC will make you really excited for 2019.1 and you might not be able to resist anyway

So 2019.1 is my recommendation for in-development projects with around 3 months to go, that have low to medium risk business factors. For high risk factors or projects that do not have lengthy dev time remaining, I would only go with latest LTS build.

 

Stick with 5.6

 

o.0

 

You are a tease... what is it this time?

 

Well, I had a project that I started in Unity 4, upgraded through 5, 2017, and 2018. I achieved the best performance in Unity 2018 with that project, but it was a bit of a pain each time upgrading. Version 4.3 is an absolutely clunker compared to 2018. There is a massive list of new features, bug fixes, and performance improvements between 4.3 and 2018.3.

If you have a teammate that does not want to upgrade that project, you could consider just making a new project in 2018 or 2019. You have more experience now than you did when you first built your project in v4.3, so you will be able to build a better project now and do it in less time.

 

I wasn't very attentive to new messages, sorry about that.

Thanks for describing your experience Shiloh, it gives support to the idea an upgrade (at least to u5, well worry about the rest later) would be a valuable use of our time. With that said, I wasn't involved in the old version, a team of paid (unlike us) developers was. We will definitely reuse a substantial part of their code.

With that said, I'll try to understand the codebase better for now, small steps.