Backstory:
My team and I are currently developing a project and have been forced to spend the last 6 months essentially redoing most of our completed work in 4.12, due to its apparent incompatibility with 4.14. From what I understand, this is because we skipped updating to 4.13. UE 4.14 had bugfixes and features we deemed necessary and now we are again facing the same issue with a particular bug in 4.14 that appears to have been fixed in 4.15 preview. While many of our assets were easily migrated, we had to rebuild nearly all our Blueprints from scratch, as well rebuilding all the maps, and essentially lost half a year to backtracking in the process. We would like to avoid repeating this situation if at all possible.
Questions:
Can we avoid having to rebuild our game ever again, while still taking advantage of the latest updates and advances in the Unreal Engine? Is it common to continuously and incrementally update during active development? If so, what are the recommended ways of dealing with or avoiding these types of problems? We were planning a release sometime toward the end of this year and can’t really afford another setback like that. Our team lead is now very reluctant to upgrade at all because of what happened and it would be very reassuring to know that regular updates are safe and recommended. Is it a good idea to take all engine upgrades until the game reaches Alpha stage or beyond?
Any tips or suggestions would be greatly appreciated. Thanks.
The long version - once you get so far into development, you lock down your engine version and stick with it. If you *need * specific feature changes, manually integrate them into your engine version.
Thanks for the reply. That’s a bit disheartening, but are you saying that it’s possible to somehow integrate features from a new version into an older version? I’m not sure what you mean by that.
Should be common sense that once you are using a lot of different functionality or new features in general, that the next update will change something that might break your code. You can check the Unreal Engine 4 roadmap, but nobody can tell what will be changed and if it will affect your project. You can also read the whole changelog of the new version (or if you are hardcore, pull new engine upgrade from github) and check if anything could break your stuff. But in the end, simply upgrading your engine version without looking at every code change will always remain a gamble, no matter what engine you use.
Back to your last reply @Poofox, “manually integrate” means reading the free source code from github and adding these lines of code into your project. There is no button for “I only want nativize Blueprint, but skip all the other stuff”. <3
Well I guess I just assumed new Engines would be backwards compatible with Blueprints made in older versions. I’m not one of the programmers, I’m just doing all the audio and like to muck around with stuff I don’t understand. The big bummer for me is that the audio front seems to be one getting key improvements. I will mention to the programmers the possibility of cherry picking code from Git though. I’d really hate for any of us to redo our work yet again. All project development is all done in people’s free time, since we are just an indie team with no funds.
If there’s an absolutely critical piece of code in a later version you need…do as I said. Make a branch, try the new version, evaluate the effort required to make the upgrade, is it worthwhile? If you do, test the hell out of it. If it’s not looking worthwhile, consider moving to a github version of the engine code and merging in the critical commits while remaining on your current major version.
One of the most common mistakes rookie programmers make is automatically updating to the latest shiny versions of everything.
This is the intention, but it is not so simple and things often break due to oversights and such. If you’re not actively modifying engine code, it’s usually not too had to migrate between engine revisions, but do so one step at a time as there’s often code in place specifically to handle asset engine transitions. Generally speaking, it’s better to simply not port large projects between versions.
OK well I will certainly take all of these suggestions and admonitions very seriously, but I’ve just converted a copy to 4.15preview and while there are a couple obvious broken things, the game seems about 90% functional. This is encouraging. Just hope our programmers can fix the few problems and we can move forward with development in 4.15. We definitely won’t be upgrading again before launch.
We do absolutely need a certain bugfix in 4.15 and I’m not sure if they will want to dig through the source code to do the branch thing. But I’ve linked this thread for them as well and for my part, I’m closing my eyes and crossing my fingers…
One sort of OT question if I may: Is there an easy way to migrate my Collections Folders to the new engine? I use them a lot and it’s kind of annoying to redo.
My experience with upgrading mid project is not as bad as some others. It has mostly been pretty painless. If you do upgrade, do it as quickly as possible, never waiting two versions.
That said, you should never be dependent on an upgrade working.
Important information on the new Audio engine, only part of it’s coming in 4.15 due to the release date of Robo Recall they pushed the PC portion of the audio engine and all the other platforms are coming with 4.16 so you may want to hold off on it. Dis regard if you’re only building for PC.
You should never need to redo any work when updating to a newer engine version. Some BP nodes might be deprecated, but then you just switch those with the newer ones. BP nodes are never just deleted or something like that, so if something worked in 4.14 then it will also work in 4.15. If you had to redo anything after an update, you probably did something wrong.
I am usually on the latest preview or on the master branch, and BPs always just continue to work, C++ code can sometimes break because a function got a new parameter or something like that, but nothing major. If you did custom engine modifications, those are most likely what you spend most time with after an update, since internally some stuff might be different in a new engine version.
I have been upgrading since 4.17 and now on 20 and have very few issues when upgrading. I did have a few issues with plugins not working, one plugin got stuck and it is still there LOL but everything works fine. It would seem like you would want to keep your project current. When I talked with Microsoft about my game the first question they ask me was what version of Unreal Engine that I was using.
After over a year learning to use UE4 and going hard at it I’ve realised it’s best to stick to the engine version you’ve started your project in, for myself I’ve split the main project into a lot of smaller projects which when i’m happy with what i am trying to achieve I will merge it into one project to the latest stable engine version at the time and even before doing this you can upgrade all of the smaller projects first, and when I merge i’ll do everything bit by bit and test it that way your not stuck with a huge amount of stuff that you need to somehow check and find the incompatible stuff and replace. Either way it’s not easy but there are ways to work smarter which i’m learning over time.
Well when a new version is released there is always a need for a recompile. This is true with 4.0 as it was with 4.20 so I don’t see this changing in the future.
To avoided the pain of a recompile only to find a problem the content pipeline is managed as individual projects so to test the waters during the preview each project is updated one at a time and not all at once. so the problems can be sorted and fixed in content and not with in the consolidated build.
Rule 1 never break the main build compile and if there is a problem the project is reverted.
Example.
We decided to switch to forward rendering and started with a single project and discovered a lot of small minor problems. Took a bit of time to solve them, mostly related to material construction as well as lighting set up, and once figured out the rest of of the stand alone projects are updated and then consolidated to the main build “after” the preview has gone gold.
Long way of saying anything important is never updated on preview release and completed no sooner than a month after the version update has gone gold giving plenty issues plenty of time to become known issues.
Alter all
There are no rules that says you have to follow Epic’s update time table.
