So there’s a game, which has been made in 2022.3.62f2. It has been already released, but there will still be contents and fixes for the game.
We will need to port the game to an NDA platform (I don’t want to disclose anything about it). But it needs the Unity 6.
We are thinking of not upgrading the game to Unity 6 for every platform, but only for this NDA platform. The way we would do it, is to have a separate branch, and only for this branch the engine would be updated to Unity 6. Everywhere else it would still be 2022.3.62f2.
Would it be possible? If yes, could it cause a lot of issues, or even potentially blocking development?
I’m thinking of a scenario, when someone would push a scene or a scriptableobject change, and that exact change would not be compatible between the 2022.3.62f2 and Unity 6 version. And thus the scene file or the scriptableobject would be unreadable in the Unity 6. This is I’m afraid about.
And it would be hard to replicate all changes in the prefabs, scenes, etc. manually in the new engine.
Is this scenario is completely valid and thus updating the game to Unity 6 on each platform would be the safest thing to do?
Or it could be done, and if a similar scenario would happen, only then it would be enough to update all platforms to Unity 6?
If you must upgrade to 6, you already have to make fixes or change something, it’s worth it to also port every other version, I will suggest you to start with Unity 6.0 which is LTS and not 6.2, Next LTS will be 6.3 in December if you want to await for it.
While it’s technically possible to maintain two branches, you will encounter a lot of issues, such as format mismatches, reimports, having to re-do work twice, bugs appearing in one branch but not the other, the list goes on.
How come you want to stay on 2022.3 on some platforms?
You’d have to be very carefull to only merge from the 2022 branch into the 6 branch - Unity is pretty forwards compatible, but never backwards compatible. So if you build a scene or a prefab or whatever in 2022, it will be possible to open it in 6, although it will get automatic changes.
But, yeah, especially if you’re doing graphics development, things will be pretty nightmarish - shader defines will move around, what the shader graph does and outputs will change, URP does things differently now, etc. If you’re only using the standard shader, you’ll probably be fine, but if you have your own, or god forbid any custom scriptable renderer features, you’re going to essentially have to maintain two copies of everything.
It doesn’t really sound like it’s worth it to maintain two versions for your case - you’re expecting to add new content to the game, which will require a very painfull process where you need to make sure it works on two very different versions. And you need to make the game work on Unity 6 anyway, since you need it for the Swintendo Nitch or whatever, so there’s no big reason to keep the old version around.
If this is a mobile game and you have a lot of assets, the patch size going from 2022 to 6 might be painfull, and break download limits or whatever, so if that’s the case it might be worth it to keep the 2022 version.
Do you merely expect a lot of work, or do you actually know what kind of work you need to do (besides testing)?
I bet you will fare much better in terms of time/cost if you upgrade the entire project to Unity 6 compared to the things other have already warned about, and which will continue to accrue costs over time. I totally agree it’ll be a hellish nightmare.
But the worst is yet to come: when you decide to finally upgrade ALL platforms to the Unity 6 branch and find yourself in one hell of a merge operation which you cannot do feature by feature but only as a whole, and the outcome (whether it will work at all) is uncertain. That’s the potential (and self-inflicted) blocker you definitely want to avoid!
You may even find that the upgrade to Unity 6 isn’t all that much work, perhaps even no work at all besides testing. After all, going from 2022.3 to Unity 6.0 is just a small step. And you have to open the project in Unity 6 and fix any compile/build issues anyway which commonly is 99% of the work. So give that a spin, and then re-assess.
If you only need Unity6 to build, you can do what you contemplate fairly easily with git and branching.
For years I kept all of my games in Unity5 because a) I didn’t need any Unity2017 or later features, and b) Unity5/Mono launches incredibly fast, and it NEVER EVER tells me “HOLD…” Not even once! I’m not sure when it became acceptable to stall out the user interface for things like “domain reloads,” but I don’t want any part of that. But I digress.
To ship my games I created a shipping branch that had just enough changes to it to open in Unity2018 or Unity2019 or 2020 and now finally 2022, such that I can build it.
But I still did all development in Unity5, and when it was time to ship, I switched to the shipping branch, merged master up to it and built from there.
Fast forward to today, I’m still doing that with Unity2018 instead of Unity5. I do all my development in Unity2018 and merge it to shipping branch when necessary. Same reasons: 2018 rarely ever stalls me out with “HOLD ON…” messages.
I actually still build for iOS Xcode using Unity2018.4.19, and for Android and Android TV and web using the new Unity2022.2.62f2. If I had to use Unity6 for an NDA console, I would probably do the same thing, just do only the console integrations in that shipping branch.
Do you merely expect a lot of work, or do you actually know what kind of work you need to do (besides testing)?
Well, all other platforms need to be updated to Unity 6. It will mean that all other platform SDKs need to be refreshed, settings usually can’t be imported between different versions of SDKs (these are not Unity SDKs) so those need to be set again. Also for Unity 6, it will mean multiple hours of addressable building and normal build creation, which is again multiple hours. (these are from experience with this specific project).
So it will definitely involve at least 1-2 workdays at best, and for multiple people. Plus the testing.
Still sounds like the better course of action. Consider that in all likelihood, whether now or in 2-3 years, you will eventually be forced (or just have more reason) to perform the update anyway.
Oh my … that means the (supposedly) platform SDKs are bound to specific Unity versions? And they offer no clean upgrade path? That sounds unbelievable but then again it does remind me of the abysmal state of such platform dev tools back in the 00s. At one point it took two of our brightest engineers two weeks with lots of back and forth with support to get a working build on the PS2 dev hardware.
I do too.
You do notice that the user interface is effectively “frozen” while Unity is “thinking”?
As far as I remember you’re blocked from interacting with the UI either way, whether there’s a “Hold on..” progress bar or just that tiny spinning wheel that’s so easy to miss when it stops spinning. I do remember that was an issue in 2017 through 2019 since you had to focus on that spinning wheel or “click somewhere” and wait for the selection to change. The “Hold on..” progress was introduced early in Unity 2020.
You’re absolutely correct. Unity 3, Unity 4, Unity 5, all of them became unresponsive when compiling.
But they didn’t do it for more than perhaps a second or two, at the most. Usually it was so fast that by the time you found your mouse cursor you could do stuff.
Something fundamentally bad happened when they introduced that HOLD ON dialog, as now a bunch of other operations can simply stall out the UI without any recourse or indication why or for how long. How many times have you seen people poasting here asking “Is it supposed to be ten hours?” I’m sure those ridiculous extremes are something bad like antivirus, but even a proper devbox like mine still regularly and without apparent reason or indication, stalls out.
Bad, bad, bad, bad… and worse, there is absolutely zero intention or enthusiasm for fixing this. Instead there’s all this handwaving that “Unity does so much more now” and even fake false promises like “ASMDEFs will fix this” (spoiler: asmdefs do absolutely nothing for compile speeds in most practical applications in most commonly-found Unity projects).
And why does Visual Studio, which is at its core a text editor, take more than a half a second to start and become responsive to me?! What is it doing that it CAN’T do in the background?! It can compile and produce all the intellisense in the background (and it does!), so what else is it even doing?! Youtuber Casey Muratori pointed out that when VS sent out a poll about “how long do you think an IDE should take to boot up,” their lowest time was “under 10 seconds.”
At least that’s how I would explain it. It makes a huge difference watching a progress bar with an actual timer compared to waiting for the app to become responsive again. And granted, before the progress dialog the UI became about 1-2 seconds responsive earlier than the progress actually finished, so you could make a selection but the Scene/Game view didn’t actually refresh nor could you enter playmode at that time if I recall correctly. I think it would even show the playmode icon in pressed state, just not do anything for a short while.
So there was some sort of “fake responsiveness” effect at play here too. Just like Windows when it boots up and you can see desktop and start menu, and select icons but it just wouldn’t be able to run anything just yet, not even opening the start menu.
In Unity 6 my iterative compile times are 1-2s (I often don’t even see the progress bar) and some other user recently mentioned it was just 5 seconds in a 100+ GB project, which I found incredible. I don’t think it’s as bad as you say. Most of the time project compile times degrade because of all the things we do.
Asmdefs do help if you edit code in a high-level assembly but of course nothing changes when you make changes to mid or low level code that’s referenced pretty much everywhere. Unfortunately the difference is not a game changer and only comes through in complex projects with incremental changes in high-level code.
As to VS: Rider pops open those solution windows really fast and the rest like static analysis and syntax highlight is then running in the background. I feel it’s very close to VS Code when it comes to launching.
Nice issues. If you have any interest in resolving them, you could always try addressing them one at a time and perhaps asking useful questions in here.
Bugs are generally fixed one at a time, sorta like putting your shoes on.
How to report your problem productively in the Unity3D forums:
This is the bare minimum of information to report:
what you want
what you tried
what you expected to happen
what actually happened, log output, variable values, and especially any errors you see
links to actual Unity3D documentation you used to cross-check your work (CRITICAL!!!)
The purpose of YOU providing links is to make our job easier, while simultaneously showing us that you actually put effort into the process. If you haven’t put effort into finding the documentation, why should we bother putting effort into replying?
If you post code, only post the relevant code and always use the format button above. Do not post photographs of code.
