Coming from Unity, transition questions

Hello everyone !

I have been developping games with unity for 4 years now. I am essentially a technical person, I used a lot C# to do all my gameplay systems and basically everything I needed for my projects.
But recently I came over issues with Unity and breaking bugs, and I am more and more looking over transitioning to Unreal.

I am quite afraid to do so, and that’s why I wanted to ask if there was any people from experience that did the transition and how it went for them.
Even though I programmed a lot, I don’t consider myself as an engineer or anything like that, so going into C++ is really intimidating for me.
Is there any technical / programmers that made the switch, how hard was it for you to transition from C# to C++ ? Did you end up using only blueprints instead of C++ ?

In your opinion what is the “limit” of blueprints that basicly forced you to go back to C++ to accomplish what blueprints was not capable of doing ?

Thanks a lot for your time !

I moved away from Unity when the original company founders stepped down and they brought in the guy from Electronic Arts to run the company.

They jumped into “services” and cloud stuff while I felt the engine itself was becoming a secondary business.
I could bet Unity one day wouldn’t even focus on game development anymore so I left…

Before doing that, never in my life had I touched a line of C++ code so I downloaded Unreal (was subscription based back then) and started with Blueprints. 4 months learning the tools.

Then early 2015 I started diving in the c++ world of Unreal.
Got a new job after that, also helped some games ship doing freelance work and even went to work abroad a few times.

Then I thought would be nice to join the “Unreal Marketplace” as well, focused on ironing my recently acquired so called ‘c++ skills’ ha!

I began to publish plugins for Unreal somewhere in 2016.
And still doing so, several commercial games have made use of my plugins, several games for PC, Mobile, Switch, VR and PS4!

The plugins became my part-time second job. They make me push forward and keep learning the deep secrets Unreal hides, helping me improve as a coder.
With that, I can help developers to achieve their goals providing dedicated support every day when they are stuck in some process they find difficult.

That makes me very proud of my work because I know I helped somebody to be successful while I build courage and expertise to one day publish my own Indie product :wink: [HR][/HR]
The “technical” side of things, well… I believe you must be patient with yourself and understand that “change is good!”
Be resilient, when the engine bites you (and it will) bite it back, don’t give up.

Understand that the people who created this software are million times smarter than you and me. Everything in there is there for a reason, specially when we can’t see where the reasoning is.

I bought and read (for real) ‘the c++ Bible’;
Honestly, that was useless. What really matters the most is to know the tools and how they work. Being a “C++ guru” won’t serve any purpose if I don’t know how engine architecture is meant to be used.

So I personally focus on being up to date with the tools the engine provides and “where can I find them and expand upon if needed, in engine source.”

I read engine source code. I do this a lot.
I think everybody should too. I feel like a monkey learning to talk, before having access to Unreal source I was just a monkey that thought I was very smart… Now I know I will never be THAT smart, but at least I’ve learned a word or two from the gods of programming :wink:

Hi. Start with blueprints, don’t start with C++.
Nowadays even AAA titles are mostly made with blueprints (it’s official statement, it was mentioned somewhere on gamedev conferences on youtube, but I don’t remember url). Lots of titles are 100% blueprints.
After you get the general idea of how things work in Unreal, you will decide if you need c++ (most likely you won’t even need it).

As of restrictions, honestly, I can’t say much, I didn’t come to that point when I can’t do something with blueprints and urgently need c++ for my projects.

Blueprints are exceptional, very different from any other “visual” scripting in other engines.

^^ This ^^…

Devs who’ve managed to tame UE4-C++ are incredibly talented imo (which isn’t most programmers unfortunately)… I’ve had the privilege or working alongside some seriously talented guys (ex-JPL / Nasa rocket scientists / Math Uni Professors / Quants). But I’d still put Epic’s team above them… Its not just about conquering the engine. Game work is also about struggling with gameplay mechanics and aesthetics, and blending that altogether to create a working game / simulation etc. In most programming jobs you only need to get functional code down, not all three. Added to which, every year with every new game released, the bar keeps on getting higher. Its just insane.

UE4 came out at an awkward time. Epic weren’t developing UDK anymore yet UE4 wasn’t stable in its first two years. So I switched from UDK to Unity instead. Unity didn’t even have the visuals of UDK, but it was such fun creating things without really having to worry about the underlying engine framework (magic methods). Unity-C# is like programming in VBA in MS-Office. Its a fully-integrated environment with rapid iteration, in a safe / forgiving space, where crashes even from your own stupidity are rare. Whereas the leap from Unity-C# to UE4-C++ is like bumping up against rocket scientists. Some devs will disagree and say nah its not that hard, UE4-C++ is more like simplified C++. Don’t believe a word of it. It will eat into your precious time, meaning other areas will suffer and those will likely be gameplay mechanics / aesthetics / experimentation / concept work.

In finance, a mixture of C++ / VBA is used, which is unusual. But it means that you can build systems rapidly without having to worry about the UI, because Excel takes care of that for you (users mostly create their own). But in game work you have to do everything perfectly, that’s what makes it so hard. Most devs opt to do the UI in Blueprints. So you can’t really escape BP, and neither would you want to. Now, if you’re the dedicated programmer on a team maybe you don’t care. But if you’re an Indie and have to wear lots of hats, which is normally the case, then UE4-C++ doesn’t make things easy.

^^ This ^^

Reading code used to be my life. Trains / Buses / Planes - non-stop. It certainly makes you more technical and desirable as a hire. But its also quite boring and it doesn’t help you make innovative games. Its just a distraction. So you’ll have to decide where your priorities are.

However, the good news is that scripting is coming to UE5 eventually, and that will make it a lot easier with faster iteration and less crashes… However it won’t ever be componentized Unity-C#. Meantime, you basically have to be a platform coder as if you were working on writing browser code or an operating system etc. Whereas most game devs just want to be application developers, and have all that low-level boilerplate taken care of for them.

Reading source is great, but it comes at a cost. Do you want to be a game dev or a platform coder… Search on threads titled BP vs C++. For most devs, Blueprints are too limited to make pro games with…

Unreal comes with enough out-of-the-box stuff, if you want to make a “normal” indy game I don’t think you have to go down to C ++ unless you really don’t like blueprints. Or you enjoy programming more than creating games.
Also, and increasingly, there are many plugins that save you from go back to c++ for special things.
I have two games on steam, with completely different gameplay styles, and now I am with the prototype of another.
And they are 100% blueprints + marketplace plugins.

But Plugins are C++, just someone else’s… It highlights the weakness of Unreal today, which is you need to learn two distinct systems (Blueprints and C++). Whereas in Unity you can get by with just one for the entire duration of the project…

What if the devs behind any of those plugins you use retires, gets hit by a bus, or just gives up on the Marketplace as so many talented devs have in the past 1-3 years… What then? Then your project is in serious jeopardy!

There are so many use cases where Blueprints just don’t deliver. Anything beyond simple vanilla CMC Multiplayer is one… When someone says they’ve made games on Steam using BP solely, but doesn’t define any of the Plugin dependencies, what does that mean? It’d be better for the OP to check out past BP vs C++ threads and decide for themselves…

there is something about the unity vs unreal thing u might not realize :

unreal can be optimized to the extreme because of c++

where as unity doesn’t have that option.

and unreal still has the option of blueprints!

God Bless you. May Jesus Christ be Charitable unto you.

Acts 10 : 33 - 48, google it, its Awesome.

but it is not necessary to look at them, for me they are black boxes, I have no idea of c ++ it gives me chills to look at written code.

I do not know very well what you mean, if you use a pluging it is because what it has is already valid for your project.

The first thing to advise is that you decide on the engine based on the game and the target, but the OP has not made it very clear.

Yes, I would not advise a multiplayer game, unless it is a prototype, if you do not know C ++ why you ended up getting to touch things. But games only with bp are an empirical fact, and if they have already been released you have no dependencies on the plugins that you use.

Hey guys,

Thanks for your answers and for the insights.

I didn’t know there was such a harsh line between C++ and BP, I thought C++ was more accessible as a ‘additional posibiility’ when for exemple you want performant gameplay systems, rather than an entire platform that you need to dig into.

My projects are mainly third person shooters, so I believe unreal is of course a pretty good platform for that kind of things.

However, I always like to have all the possibility in my hand, even though BP seems really really powerful, I like knowing that I could get around issues by just writting code myself, which is not a problem, after all C++ is just another language to learn. But from what I can see, it is more complex than that in this situation and goes beyond just implementing some lacking functions in a project.

I guess the best thing I can do right now is to just go ahead and learn BP, and whenever I will feel limited switch to C++ and see if I can handle it or not !

Unreal pretty much gives you a third person shooter 50% done.
You mostly have to worry about graphic assets in that kind of project.
Multiplayer is absurdly solid too, but not easy to manage.

It suits Epic’s marketing dept to not correct that misconception. :wink: But comments from the Epic engineers who worked on the ARPG release tell the real story. As Bruno hints, the engine is geared towards shooters though, so you should be well placed for your own work. However for UE5, Epic need to elevate Blueprints (they brought in more investment recently so it can’t be about lack of resources).

The truth is, Epic have been leaning on 3rd-Party plugin developers to fill in the holes in BP for years. This has to stop, as many devs have left because the economics aren’t worth it. This gets talked about in Marketplace threads so I won’t digress. But here’s hoping that UE5 sees Blueprints get true first-class status within the engine, and not just a marketing ploy. Overall BP is critical to the future of Unreal (for both Enterprise and Game Devs), or more people will leave for other Tools (including Godot etc).

Not quite… Its a whole other environment to master including having to buy a 3rd-Party tool (re-sharper / visual-assist etc). Maybe this is more obvious on the Linux side, but it applies to Windows also. That’s the killer weakness of not offering a fully-integrated environment like Unity / UDK. There are lots of gotchas here. Follow some of the Vis-Studio / C++ Release threads to see why.

But a key area is iteration time. There are a number of things Epic has added to speed this up, but they all have their own gotchas! Whereas compiling Blueprints is near instantaneous. Then there are all the brutal C++ crashes. This is why adding Scripting has become so important. What happens when BP isn’t enough is you actually go looking for Plugins instead of opting for C++. That’s why its so important to know the support you can expect in the medium to long term.

Even if you’ve shipped a game, you often want to keep working with the same Plugins across multiple projects because: A. you’re familiar with them and so productive now and want to keep going. B. Plugins are often quite costly, so you need them to keep working to pay for themselves. C. You often want access to the latest features of the engine too, so plugins have to keep working and being updated. But changes to the underlying engine (especially in recent versions) shows that the workload to plugin writers isn’t trivial. So the economics have to make sense…

Not to scare you people, but to get productive in C++ you will also need good spec computer with an ssd of course. Otherwise the compilation is so slow and it will quickly wear you off.
A lot of time, code plugins bought in the marketplace will straight away plug-in ie it just works without any tinkering. However, to minimize the risk of the plugin being dead (and you are stucked), here are two considerations:

  1. Do not buy code plugins which do not sell well… even though it fits your requirement perfectly. These plugins may not get updated in the new version. You may try compile but there is no guarantee it will just work.
  2. Do not try to upgrade every time there is a new version. This way, your plugin stay intact and usable.