Hello,
This may be an odd question, and for those that have gone from Unity to UE:
is there an approach to building/structuring Unity projects so aspects of them can be easily ported to UE?
Context: I want to move my future projects to UE5.x, however, my days are filled with current work tied to Unity (12+ yrs experience). I’m wondering if I can optimize my approach in Unity so it’s more compatible with how Unreal does things. So, when the time comes, I can move over some/all of it instead of redoing everything from scratch.
I understand the basics in the Guide for Unity Developers, and various videos/articles online, but they don’t get into the weeds gotchas when porting.
Outside of art assets, I’m assuming everything will need to be re-thought and re-done, but figured I’d ask the experts first.
Thanks in advance!
Hello and welcome!
We have done everything from scratch. The way Unreal Engine works in my opinion is very much “the correct” way once you get used to it. One of the things that confused me in the beginning coming from Unity; for example; is camera controls. In Unity’s Cinemachine, you control the camera whether it is a Virtual Camera or FreeLook Camera directly. In Unreal, you control the “Controller” which is the Player Controller.
Porting your game is very easy. You can kind of copy-paste your logic (not literally) like any programming language and just implement it in C++.
Don’t let others scare you off C++, it is UnrealC++, not bare-bones C++. There is a garbage collector, and many great macros. If you don’t want to use C++, go for Blueprints. I recommend you to use both. Since you have a lot of C# experience, UnrealC++ looks like it in some way, but it is still C++ at heart.
Try to skim through the Documentation as much as you can. Most of the search engine results and tutorials are old, and Epic Games are trying to push the new ones on top. There could be many things that are now built-in or ready to implement, so you don’t have to reinvent the wheel.
Look at the plugins that come with UE. I highly recommend Gameplay Ability System (GAS) and CommonUI. There are many more, check them out.
Out-of-the-box multiplayer support! No need to fiddle with Mirror/MLAPI (Netcode for Gameobjects). Amazing replication system, a new one is in the works (Iris).
The move to Unreal Engine is worth it. I am very glad we did. I can’t believe how much time we wasted in Unity!
Great response. Thanks!
Since you’ve been through the fire already, are there any tools used to control logic or program flow that don’t really translate to UE? For example, past projects I’ve used coroutines, nested prefabs, and centralized systems sitting on empty game objects to control things.
I suspect these types of things will need to be rethought using UE best practices…?
You are welcome!
All “GameObjects” in Unreal Engine are of type Object that originate from UObject. Prefabs are blueprints of type Actor, so the empty GameObjects can be made as a blueprint of type Actor. Each blueprint can have components, just like Unity. So you can have a mesh with its logic as a blueprint of type Actor and place it in the world or Spawn it from another blueprint. You can have child Actors that inherit from a base parent class if you want too.
I am not sure if coroutines as it is in Unity exist in Unreal Engine, but there are Delay nodes in Blueprints that can pause the execution for a time – also check SetTimerByEvent. There are also a lot of flow control nodes that will do exactly what you want.
The logic layout will be different, but like I said, “the correct” way of handling stuff. Game Instance is the persistent script that runs when the game starts until its shutdown, the singleton equivalent in Unity. Almost all of the things that you manually do in Unity is already laid out for you in Unreal Engine.
Lastly, Unreal Engine is open source! So you can build it however you like. There are so many things, I can sit here and make a wall of text telling you how amazing UE is.
Try it out, it is free! But have a spare ~80 GB disk space
1 Like
Perfect! Thanks for taking the time to respond. It all makes sense.
I played around with UE a couple months back (character movement, lumen, etc) and things were clicking. Much of it just made sense as long as i approached it as ‘not unity’. (I.e. don’t try and do things like unity and just go with the UE way) However, i was just doing one off experiments, which can be very different from a full project. This info helped me better understand the structure.
Thanks again! I am looking forward to the move.
1 Like
You are most welcome!
You are correct. One off experiments are completely different than a full project. The most important thing to me is that the process is very fun and graceful, I am sure you will find it the same.
I am looking forward for your return and see your work. Good luck and take care.
1 Like