I am thinking about changing my project over from Unity to UE4

I don’t really think that this is something anyone else can honestly tell me to do, but I still want to mention this and see if anyone has some thoughts on the matter.

I have a project that I’m working on (by myself) that I’ve been building in Unity for a little over a year. And I’m thinking about switching to UE4, but I’m not exactly sure if that would be worth my time, or if that would just delay my finished game even more. Probably the latter, but still…
I don’t have any real levels built for my game right now (just placeholders) so if I were to transition, now would be the time.

The game I’m working on is a simple 2D platformer, and I have seen that UE4 now has a host of 2D tools like Unity has, so the core system stuff I would need seems to be taken care of. (Although, I have not actually looked deep enough to know if the 2D physics is set up as well as it is in Unity. Not that I need anything complicated, but it is nice that I can build actual 2D collision in Unity.)

I’m not terribly experienced with programming, but I still know that porting over my code will not be an easy process; I’m pretty sure that basically everything will have to be completely re-written. On top of any differences between C# and C++, there are a lot of things that are dependent on systems that are specific to Unity.

As for advantages of switching to UE4…
-I have this aggravating problem (that no one else seems to have) where my player gets caught on flat collision, if a surface is made up of multiple colliders. If I can never get a fix for it, it will constrain my level design so that I can’t have ramps; any surface you can walk on must be one single flat surface. Not actually a big loss, but it is a little disappointing.
-All of the code I still need to write will presumably be easier in UE4, if my experience with UDK is anything to go on. A lot of things just worked more reasonably in UDK than in Unity. Collision calls, for example, were much more sensible.
-Console commands, better animation trees, and I hear good things about BluePrints.

Overall I don’t see anything extensive for this project that will be improved with UE4, and really it looks like I would just be starting over again from scratch. But it still keeps bugging me; I still keep wanting to use Unreal. I probably just need to put this to rest and finish what I started. But like I said, I’m curious if anyone has anything to say about this matter.

Come on over!

Use this to get started: Unreal Engine 4 For Unity Developers | Unreal Engine Documentation

Then learn about Paper2D (There’s even free projects in the Launcher to help you get started!) - Unreal Stick Figure 2D | Live Training | Unreal Engine - YouTube

Also, the power of Blueprints will blow your mind! For example, collision calls:

Create a trigger volume in your scene. Then simply right click in Blueprints, “Overlap” (To create “BeginOverlap”) - Destroy Actor (Or whatever) - DONE.

Especially now it’s free, There’s no excuse :stuck_out_tongue:

I used to be a Unity user like you, But now? Pfft. Never looking back!

Enjoy your stay :wink:

Welcome!:slight_smile:

Do it!

You will not regret it!

I’m coming from C# and XNA. I built my own homebrew engine to create a prototype for my game. I’m slowly starting to port my code over while building other aspects of my game in UE4.

I can say from first hand experience that it’s really not that bad. Porting code is a lot easier than writing it from scratch since the code already solves the problems you needed to solve. You just have to translate it into another language and familiarize yourself with the different naming for commonly used datastructures.
A C# list is a TArray in UE4.
A C# dictionary is a TMap in UE4.
etc.
Pretty much, you’ll have to refer to the API documentation a lot if you want to port things over.

The real decision that you’ll find yourself making is “Should this section of code be done in C++ or blueprints?”

The C++ code requires a game project recompile, and if its a structural change to your classes, then you can’t do a hot recompile. If you use blueprints, the logic is a little less straight forward and harder to use than C++ (compare for loops for example, or what it takes to add one to an integer, or modify a struct variable) but it will let you iterate super fast on game logic.

I don’t know how big your project is, but I imagine it wouldn’t take more than a month or two to port it over to UE4. What do you lose? Time and the opportunity cost. What do you gain? Your game is now built in UE4, so you have access to all of the capabilities it offers. You have full access to the engine source code, so if the engine doesn’t do what you need it to do, you can add it in yourself. Epic also releases some pretty significant engine updates every two months, so you can always be at the cutting edge of modern tech. Is it worth it? That’s for you to decide :slight_smile:

I came from unity and using ue since 4.0. I can say you will not regret both for engine and community. I’m a 3d artist but having fun with blueprint and learning c++ at the same time. If you want, you can add me to your friend list on launcher and ask any question you want. I’ll be glad to help anyone if i can.

Well, porting from c# to c++ is a rather easy task to do I’d say, and the api is very similair to udk.

True, although I would have to revise the logic of a lot of things. It’s not the code itself, but the foundations that Unreal uses. I doubt it handles physics in the same way, so I’d need to make a lot of revisions to anything that moves. I doubt I can keep anything from my HUD/UI. Not to mention things like handling game structure and loading. (Although that I would look forward to; I had to craft a bunch of stuff into my game that Unreal already handles. Would it seriously kill Unity to incorporate a built-in “level properties”?"

I assume “Hot recompile” is what they demonstrated in the early promo videos where the game was running while the code recompiled? So, what classifies as a structural change? And how inconvenient is a “cold” recompile? It was annoying to recompile in UDK; I had to order the recompile in the “front end” application, (which made three programs I was running, WOTGreal, front end, and the actual editor,) and then wait a while for everything to compile, which took a while since there was a LOT of scripts that were needed. It wasn’t bad enough to change my decision about what engine to use, but I am curious.

Heh heh, that is kinda pointless when you’re talking about something patterned off of games that run on a nearly 30-year-old video game console. :wink:

Yeah… I don’t know anything about unity physics vs. unreal physics. I imagine that if they’re both using classical Newtonian physics equations, the behaviors can’t be THAT different.

Yeah, the editor has a “Recompile” button you can click to recompile your C++ code while the game editor is still running. It shortens your coding iteration loop a bit, but comes with a few limitations. The hot recompile can’t handle changes to a class, so if you want to add extra variables or methods to an existing class, or create a new class altogether, you’re going to have to recompile your game code. As far as inconvenience goes, it costs me about 2 minutes to compile my game code and get back into the editor – but my code base isn’t huge at the moment. It’s slightly annoying to have to completely shut down the editor to recompile code since it means I have to shut down all my open tabs. The simple rule of thumb is that if you don’t need to modify a .H file, you can just hot recompile and that takes around 10-20 seconds to finish. It’s super convenient :slight_smile:

IF you want to download and build the entire engine from source code though, you can look forward to a 30-45 minute compile time depending on your processor speed. For this reason, I hesitate to modify the engine source. Got a run time bug? Fix it and have fun waiting another 45 minutes. It seems almost better to just put your engine changes into a game project and spend 2 minutes compiling to get it right before migrating it into the engine runtime. But, maybe someone else more knowledgable has a better time saving technique for engine mods.

Hey, if it ain’t broke, don’t fix it! :slight_smile: Instead, push the boundaries on the tech.