Unity vs. Unreal 4

Hello everyone,

Not asking you to trash talk, I know there will be some bias towards UE4 here on this forum.

How difficult is the change over from C# to C++, for someone who has completed a full game concept to launch? I will say, I like the engine quite a bit from years of being familiar with it, yet the real point of frustration atm for me is that Unity seems to be really drying up. Are you seeing similar trends with Unreal in any way, or what are you seeing from your perspective?

Thank you a lot, in advance.

1 Like

Good to know and thank you for the link on the other thread. I don’t really want to go the blueprinted route, and honestly not sure I want to dig in atm on something that is 3x-4x rougher than C# atm without being on a team and having someone to collab with, seems like a poor choice/time sink for a solo guy.

1 Like

There are places for C++ and there are places for blueprints.

Usually, it’s not like “use only blueprints or use only C++”. In a project, it makes sense to use both. There are things, where using C++ over blueprint provides no real benefit. If you can make things faster and easier in a blueprint, then why not do it? Because you are a purist? Blueprints are in no way worse, they are just a visual method and sometimes faster or less problematic method. Even Epic uses blueprints besides C++ in their games too, as they have said many times and some of their examples you can download, contain both.

If you have the possibility to do something with 1/10 of the difficulty, then by all means, do it. Otherwise, we would not use even game engines but do everything from scratch and the hard way, like in the old days, before game engines emerged.

So, imho, it isn’t that hard to switch from Unity to Unreal, if you consider that. I dived into Unreal engine straight from zero, and it was easy. As you’re someone who has created a whole game already, I believe, you may be very well able to gradually start using C++ with Unreal, when and where you need it. You will only know for certain, once you give it a try. Don’t let the fear of difficulty stop you - after all, I bet, there were for certain difficulties with Unity too here and there and things to learn, isn’t it so?

For me, the one thing which finally - after considering many so other things - gave the final decision to start with Unreal vs Unity, was too, that I liked the engine and it’s concepts quite a bit more over Unity’s, when I first dived in. So, there you have a good motivation to work with it, which can be quite enough to learn using it.

1 Like

The Unity community is much bigger than Unreal so if you are a solo developer you might feel a bit lonely in Unreal compared to Unity. If you chose Blueprint then you will find plenty of resources though but on the C++ side you will need a sparring partner at-least or you are in for a rough ride.
If you are completely on your own then the source code is your best friend.

From time to time I keep reading forums in search for any news regarding a scripting language. Being a long C/C++ dev myself (not games), when you developed in blueprints and in UE4 C++, you know there something missing in the middle that would give the best of two worlds.
I heard some rumors years ago about SkookumScript, but nothing happened since then and what it’s worse not even official announcement for it.
Blueprints have it’s place for artists or quick prototyping. But there is a real need for quick-compile, ue4 editor and sdk full integrated scripting language.

I came from Unity and am using both still, I learned C# on Unity and within a few days got a hang of C++ with UE4. The worst part is trying to reference assets in your folders, couldn’t figure that out. The most important thing is to familiarize yourself with the engine first because a lot of things you can do in Unity you can’t do in UE4, like the most basic thing in the world - disabling an object. In Unity its one click boom disabled but in UE4 you have to turn off rendering remove tick and disable collision and even then it’s still there.

Really the only reason I’d ever go with UE4 over Unity is for the graphics. You can come close but never get the same visuals because Unity has color tearing even with every post-processing filter available. But yes definitely go with blueprints I switched over to blueprints and whilst it can becum incredibly drawn out and confusing it’s a lot easier to work with everything inside the engine then to build every 5 seconds and alt tab back. I got suprisingly good performance with blueprints too just make sure to turn on C++ Nativization. The viewport interface still needs some fixing my camera speed is never the same and you can’t even disable or change the shift key which is really annoying cause it stops your movement within the viewport. Also placing actors is really tough if you have multiple collisions in the scene they never place correctly like in Unity.

Unity is still way easier to do everything but doesn’t have the graphical capacity of UE4

1 Like

Well, as described here https://www.gameplaydeveloper.com/unity-vs-unreal-in-the-gaming-industry/
can it be true? I would appreciate it if you could give me detailed information. thank you

So being on the band wagon since 4.0 up to 4.27 4.X has always felt like the alpha of things to come . Familiar with game engines a lot of the features added seemed half way complete as to usability and seem lacking unless you consider framework building as the objective.

As a perspective a lot of the feature sets requiring setup could easily be handled engine side, using components for example, as a make it once use it many resource and consolidate everything under a single channel, gameplay plugin perhaps.

What I feel of interest though is Unreal 5 is trending towards being a real time rendering engine and not just a game engine which you can only go so far with. I mean do we reallllllyyy need ray tracing in a video game. :wink:

Not much information available out there. Just that it was bought by Epic like two years ago, then we assume something is in the works… but nothing more than that.

Why change from C# to C++ when you could perhaps go from C# into Blueprints and maaaaybe a pinch of C++ ?

Hello & welcome ,
See my thread for a discussion on how to navigate your C++ self learning journey if you are coming from Unity C#.

In my personal experience I had to abandon almost everything I learned or took for granted in Unity. I finally decided to learn the engine as if I was learning game dev for the first time. Others have managed to transfer with moderate effort so ymmv.

Is UE drying up ?
On the contrary ,they are becoming a force to reckon with. It’s hasn’t been a “Game Engine” for a few years now. UE is now RTT (Real Time technology). Whatever your needs are , UE will accommodate them or give you ways to do it yourself. Which is where C++ and the time investment to make it work for you come in.

So yes ,beginning and gaining proficiency in “UE” C++ is excruciatingly panful vs Unity C#. But you are investing in an engine that is seeping into every conceivable market that needs Real Time Technology . That’s the Bounty you hunt for Mando !

Hope you stay and grow with us.
Cheers,
b

I’ve been using both Unity and UE4, started with Unity then learned UE4.

As said above, there is things you do all the time in Unity you cannot do in UE4 (yes, disabling an Actor you put in the scene just for testing, and referencing Actors by drag-and-dropping it from the scene hierarchy to the reference slot).

But if you know one, you can learn the other quickly.
And Blueprints are great to make things working without getting your hands in C++.

So, from my point of view, the choice of one or the other depends on your project.
Unity :

  • 2D Games
  • Augmented Reality
  • Mobile

Unreal :

  • 3D Games
  • ArchViz
  • Movies

Use construction Helpers .
For example I need to reference a mesh asset in my content folder so :

  1. select the asset in the content browser > right click > copy reference
  2. in VS c++ paste the path to the asset

auto MeshAsset = ConstructorHelpers::FObjectFinder(TEXT(“StaticMesh’/Game/Geometry/Meshes/SM_pill.SM_pill’”));

This kind of hardcoding can come back to bite you if you change the name of the asset or move it’s location so try and let a BP do this.

Here’s some example code for a constructor of a Pill class:

AMagicPill::AMagicPill()
{
 	// Set this actor to call Tick() every frame.  You can turn this off to improve performance if you don't need it.
	PrimaryActorTick.bCanEverTick = true;
	PillEffect = 0.0f; 
	// Create a Static Mesh component 
	PillMesh = CreateDefaultSubobject<UStaticMeshComponent>("BaseMeshComponent");
	// find mesh asset in the UE editor by pasting a path to it
	auto MeshAsset = ConstructorHelpers::FObjectFinder<UStaticMesh>(TEXT("StaticMesh'/Game/Geometry/Meshes/SM_pill.SM_pill'"));
	
	// check to see if we actually have a valid refrence to the object
	if (MeshAsset.Object != nullptr)
	{
		// Assign the static mesh to the Static mesh component 
		PillMesh->SetStaticMesh(MeshAsset.Object);
	}
}

cheers,
b

I’ve seen too many times people trying to do things Unity way in UE4 or go 100% C++ when the engine is designed to work as combo of C++ AND Blueprints. Understand the way engine works and is meant to be worked with before diving into C++ all the way and most of your issues will vanish.

1 Like