Don't jump ship to UE4 unless you're ready/capable of learning the API / C++

I started programming with C++ in high school and a small bit in college. I have a Computer Science degree which doesn't really focus on one specific Language.

I've coded stuff in C, C++, C#, Java, Javascript, ADA, Visual Basic, Assembly. I can't even remember all the langues I had to do projects in...and I'm still a crappy programmer at times. I think I do something witty and some other guy slaps me in the face with his more creative way of doing the same thing.

My point is...it has been a VERY VERY long time since I coded in C++ and I have a decent amount of experience coding in general.

It took me over 2 weeks to get situated with UE4, pick C++ back up, and learn the API to a level where I can sort of understand what I'm doing and what needs to be done. I still run into stupid little errors resulting from learning the API.

If you're a complete beginner to programming, just getting into game coding, or ONLY know C#...I estimate that it would take you 1-2 months before you can even expect to code anything in UE4...and that's if you don't get sidetracked by the other non-coding related tools such as Blueprints and level prototyping. I still don't know how to do simple things like Destroy an object properly (It's not as straight forward as calling Destroy() in Unity)

Be real with yourselves before you make the change. You will have better results in Unity as a beginner.

 

Its my humble opinion that c++ is not so different than c# if you work within some library or framework.
C++ can ofc get pretty crazy but there's not always a reason to do that like writing templates etc.

 

Another Unreal thread?

I think that really depends on what you are beginning with. Okay, here’s the deal. When I started my new WIP my first instinct was to do it in Unreal, but I decided to do it in Unity Free because, let’s face it, my primary interest is coding. And you’re right that coding is easier in Unity than in Unreal Engine 4 because I can use C# in Unity, and I know next to nothing about C++.

When I tried to code in Ureal, I hit the proverbial brick wall, and while I think Blueprints can get me quite far, I think that it will turn out to suffer from the usual problems associated with such things. What has been made, has been made, and unless you write that which has been made from scratch, you’re going to be constrained through methodology and process into a linear way of doing things. It’s like picking up a prefab in Unity, wanting to do certain things, only to find out that the prefab constrains you to do things in a certain way.

But on the art front it’s a different matter, I think. I find that Unity is far more clumsy on the art front, and I can slap together a decent looking level with good looking assets much faster in Unreal Engine than I can in Unity. So, like I said, it depends.

 

UE4 is a very modulated system and it kind of forces you to code as such since you'll be extending various classes for different purposes and then communicating between them with pointers. OOD is very important...but it can cause a lot of issues where your code will compile perfectly fine but not work at all.

 

On the Art/Level Design side I would recommend UE4 every time.

I'm speaking strictly of programming. This is what happens to people in UE4 (I believe)

They jump ship a dreamer from Unity to UE4 thinking it's some magic pill. LOOK HOW GOOD THEIR TECH DEMOS LOOK! THOSE SHADOWS!!!...

They end up spending A LOT of time building things in Blueprints or prototyping their levels. What they don't spend time doing is building their game. The API/Code can be daunting and so it's VERY easy to avoid learning it.

 

I haven't had the chance to look into the details of the UE4 framework yet but if you used c++ boost for example, its almost like c#.

 

I'm not familiar with the boost libraries...

Someone is making a C# wrapper but I'd personally just stick to C++.

 

Yeah tbh it will probably be pretty flaky if its 3rd party, if its not built in there's probably a good reason.

 

You realize that same logic could be applied to every Unity asset, and I don't think many could even imagine using Unity without assets.

 

Hehe actually I had that logic in mind - I dislike virtually every non-art asset and its my opinion the unity asset store policy is lazy and creates flaky crap. In addition implementing so pivotal as c# is a monumental task compared to something like comparatively simple like ngui. But we'll see how epic will manage their store, hopefully a lot more tight controls than unity.

 

You're not going to learn a new API overnight, I'll be honest I've coded for 14 years in C++, C, Objective C, Lua.. It tooks me around 3 - 5 months to get used to Unity's API and even now I do silly mistakes and haven't got to autopilot mode with C# yet..

It just takes time, the fact you're making progress in two weeks is bloody good going.

 

"progress" in UE4 for me is converting pieces of my Unity project over while exploring the functionality of Behavior Trees. Basically nothing fully functional in UE4 yet, but I'm piecing the things back together.

Blueprints are a waste of time (and wasted a lot of my time) for things other than simple prototypes or level-design related things (ie doors/lights).
I also got a bit caught up in level prototyping with CSG...but this will pay off later when it comes time to actually work on this piece of the game.

 

It's rather "Don't jump ship from Unity unless you're ready/capable of learning API / C++".
Seriously, C# and C++ aren't as different as Mars and Venus are.
If you're used to C#, C++ only adds a little learning curve to it.
It works the same for the other way around.

On the Nintendo 3DS there is no Unity support and is most likely not even coming this generation (yes, I know the rumours about Unity for 3DS, it's already confirmed to be not true).
This means on the 3DS I was forced to pick up C++ after a long time of Unity (I switched from C++ to Unity some years ago).
Initially it looked like I forgot how to use C++ at all, but after a while I was like "why did I ever switch to Unity while I have so much more freedom in C++? and it's not that different at all".

 

Well when you get down to it....pretty much all languages are "the same" in that logic is logic. The process by which you do something logically is independent of which language you use.

That and C/C++ also share a lot of the same Syntax.

 

I have no problem with the languages. I like both C++ and C#. But I tried UE4 and it won't work for me.

Here are the top 3 reasons why:
1) C++ compilation is slow. UE4 and a empty project takes about 2 minutes to compile. Change 1 line of code in any of your headers - wait 2 minutes to compile;
2) Visual Studio Intellisense can not handle the size of the UE4 project. So you don't have decent code completion. I waited 15 min for it to parse all files before I could get the intellisense to response. Then you change 1 line of code in your header files - intellisense needs 15 more mins to reparse; = No good for me;
3) You need to stop the editor everytime you want to compile.

There are more things I don't like but there are not C++ related. I looked at the community forums and answers hub. The solution to intellisense (as stated by Epic) is to use Visual Assist. That plugin is paid and also requires Visual Studio Pro. So there you have 800$ to spend.

Unity - works out of the box. The performance gain of C++ over C# is not worth it in my opinion.

 

You seem to be misinformed on a lot of your statements...

 

I think the discussion shouldn't really be about languages that much but rather about APIs.
C++ or C#, oh well, that's semantics. Obviously one has a lot of advantages over the other and they mostly serve different purposes. But the language itself it not really what matters. The amount of features the bare language brings to the table is negligible compared to having to get used to the standard APIs AND additionally a whole engine framework.

That's what it really comes down to and UE4 is a large beast. If you're not that fluent in standard C++, it only adds to the initial confusion.

However, I stand by what I said: I believe Unity has a cleaner and more flexible API, which is quite easy to pick up and apply to any kind of game idea. Whereas UE4 has quite an extensive API, with many predesigned use cases and might be more powerful at its core, because if you have the knowledge you can extend core engine features as you like. However, as soon as you start doing something that isn't mostly readily predefined in UE4's API you're really on your own and it will take you a lot of time and research to actually understand what you have to do in order to make it work. The fact that the documentation itself is quite sparse apart from an API definition only adds to that.

 

This is the case for both Unity and UE4. However, the Documentation does go heavily in favor of Unity.

There's nothing in Unity/UE4 that handles something like AI group behavior. You need to code that yourself either way. In both cases, the logic is the same.

In Unity: I build a GroupHandler that uses a List of all enemy objects in scene to distance check between all Enemies. If they want to group and are close enough, a Container object is built to store a List of group members. Each object in that list points to the container in order to "speak" to other members of the group.

In UE4: I build a GroupHandler that uses built in Object iteration to iterate through all objects of class type "AAIEnemy". Distance check between All AIEnemies and check if want group. Build a Container at runtime and add AIEnemies to TArray in container. Make a pointer on each object to the container so that they can access the TArray of group members to "speak" to eachother. I use drag and drop in editor to setup references to the Handler. AIEnemies must find and point to the Handler @ BeginPlay.
-AIEnemy is extended from Character. (he needs to move)
-GroupHandler is extended from Actor.
-GroupContainer is extended from Actor.
-All 3 of these access each others' class functions/properties.


You'll never build a game without solving problems like this for yourself. Engines don't build your game for your. Engine is just a tool. Logical processes for the code you create will be almost exactly the same regardless of the language you use.

With that said...I do have access in UE4 to the source code so that I can add a constructor or function to a base class like Actor.h

 

It took me one week to write and build my first small published app in Unity using NGUI and Playmaker. Publishing to Android was one button click and changing about a dozen settings. I spent more time finding a problem with a USB port on the front of my machine than time in Unity for the Android build.

 

and what was your first published app?

You could make a flappy bird clone in a weekend including all art using either Unity or UE4 if you wanted...

I'm not writing an app or a simple mobile game. I'm writing a first person game with Behavior Tree driven AI including AI interactions with each other, the environment, and the player. Behavior Trees are experimental and not officially released/supported (no documentation yet) and I'm not using Blueprints (visual scripting) in any way outside of laying the Behavior Tree.

 

A Flappy Bird clone including all art can be made in less than one day without using Unity or UE4.
It actually depends on your own experience.
Although I never used UE4, Flappy Bird should be done in 4 hours using Unity for me (again, including art).

Edit:
Oh right, you meant to say it to someone who never programmed before. Sorry.

 

Just a little particle trigger/previewer thing. I wanted to start small and iron out bugs in the iOS and Google Play store submission processes.

Why aren't you using RAIN in Unity? Behavior trees are a solved problem.

 

Because i'm not using Unity right now

I coded an entire AI system in Unity without even knowing about RAIN...that's not a plus in favor of Unity. You can't use the availability of an Asset store to defend the lack of out-of-box features a game engine has.

UE4 is a much more effective solution on the Art/Level-Design side and as a programmer, the C++ and API does not turn me away.

 

You enjoy doing things the hard way. You want CSG/BSP modelling tools and typing lots of C++ and never using tools that aren't "out-of-the-box".

Nothing wrong with that. If you get personal satisfaction out of that sort of grind then its end of argument, grind away.

 

I never liked the way unity just offloaded so much onto the asset store where it just becomes crap. You had all these bits and pieces and inconsistencies and they never worked well together. I think unity needs to re-think assets to be more publisher consumer friendly, and also more strict to get some consistency.

RAIN was ok I suppose because it was free but I found it more difficult than just writing my own. Everything asset felt like such a hack, and more hassle to use and easier to write my own.

Since unity were too lazy to create gui, behaviour trees, etc unity should have done something like have special unity approved asset providers/packages e.g. RAIN, but also gone a step further and introduce some sort of consistency and standards.

 

I began programming using pure C++, and only learned C# much later on. I must say that purely based on the languages you will be considerably more productive in C#, with a tradeoff for performance. For most, unless you are making a console game or writing a server for an MMO you would be well advised to stick with C#, simply because the time you saved gives you a greater chance of actually finishing the game.

 

There is a substantial amount of information on this topic already, albeit scattered about the forum.

 

?

My experience with tools from the asset store has been excellent. Playmaker and NGUI are fantastic. Tons of support from the developers on their forums. I've got two more plugins waiting to be tested on the next project.

 

What are you even talking about?

CSG/BSP is fantastic for level prototyping. So fantastic in fact, that UE4 left it in their engine and routinely uses it in the level-design workflow of AAA titles. How is it "more difficult". Furthermore, it's your choice whether you even use the tool.

I'm not against using tools that are out-of-the-box? Where did I state this? I said it's poor design when basic features are left out of the editor because a user can build these and sell them on the Asset store for $100. (decent snap to grid toolset for example)

-I have UFPS which I had to heavily modify without support in order to get it to function the way I required (build into UE4)
-I have A* Pathfinding which I had to heavily modify without support in order to get it to function the way I wanted (built into UE4)
-I have used a Networking/Multiplayer asset which I AGAIN, had to heavily modify w/o support in order to get it to run properly (built into UE4)

Imagine if Microsoft removed Tables from word and told you that you could buy the feature off of some store. People would rage even if they don't need tables.

Also...I fail to see how C++ is so difficult to use that you would choose one solution over another simply to avoid learning C++.

 

I've had pretty negative experience with asset store in general, I'm not alone there either. Never tried playmaker, but I hated ngui and the support guy is rude as well so I deleted that and just used unity gui. Theres hundreds of assets there that are just broken or need so much work to get them running. I think out of 50 or so maybe 2-3 worked as expected.

 

All of these points are pretty much dead wrong. No offense to this poster. Granted, #1 can be true though depending on hardware and if you don't update your build.cs to compile for a small project. Not your fault, they should have covered this in the intro vids.

Point #2 never happens too me. But I use VS2013. [edit] Nevermind, point #2 is correct. Intellisense has always been rather terrible for huge codebases. I've disabled it in the past and just used Visual Assist

Point #3 is true if you change memory layout of Classes (add vars) due to the way the DLL registers the classes when Editor starts

 

In response to the main topic, I agree UE4 appears to have a much deeper learning curve. This is due to the fact Unity out-of-the-box is stripped down and pretty basic. To be specific, I refer to particle, terrain, etc. There is no built in shader graph (edit- shader node editor), no networking layer already inplace (if you follow what I mean), etc.

Unity is amazing don't get me wrong. But the API is very slim due to not sharing source code.

In UE4, you will no doubt try to build on top of the preexisting codebase which is quite massive. I agree with the original post but for a different reason

It's not C++ that will kill you but rather the UE4 API. Not to mention the massive amount of Tools you'd want to learn and master

 

Obviously no engine will build your game for you. However, with UE there is in certain cases A LOT of functionality coming out of the box, which you wouldn't have in Unity. Especially if you're building an FPS demo or some third person demo where you additionally get wowed be lighting, terrain and fantastic shaders. UE brings a lot of a "game framework", because of its nature. Setting up Unity from scratch, without any controller code from the asset store to resemble an FPS is much more work for example.

However, again, once you leave this path, documentation is spotty (try google searching regarding UE, all you get is announcements) and it will take you a considerable amount of time actually scanning the bare API for what classes and types(!) you might want to use and how to integrate them properly.

I believe the learning curve is quite a bit steeper here. That's why I don't buy any of those comments saying how much more productive one is in UE. That can only be the case with extensive prior knowledge of the Engine and a toolset and workflow already optimised specifically for it.

Of course none of this is to say UE were not good. The code in itself is a masterpiece, don't get me wrong.

 

This thread has actually been quite informative for me. I want to thank the original poster (Slyder I believe?) for letting people like me know about their UE4 experience. And quite frankly, it sounds like I thought it would be if I tried to switch -- which is to say, it sounds time consuming.

I wish the Unreal engine and Unity could sort of "mind-meld" so-to-speak and become one lol. I wish UE4 could have the API documentation, community base, and language support of Unity. And, conversely, I wish Unity could have the raw out-of-the-box graphical power and performance of UE4.

All that being said, I think the main reason I can't switch to UE4 from Unity is mainly because I don't know C++, at all. I think it would take me 2+ years to be proficient enough in the Unreal engine that I could even currently do what I'm doing right now in Unity. That's just too much time. I want to finish a game, even if it means I have to sacrifice some performance and eye-candy

 

Is that true?

 

Sometimes, yes.

Generally if C++ projects are either:
a) Really big
b) Contain a S*** load of external library's
c) Are poorly written
They can take a while to compile.

In the case of UE4, it would have large chunks of the API that need to be linked into the compiled binary, which in turn slows down the compilation time.

 

Another thing I don't like about CPP

Header files, in this day and age? Nobody wants to declare things twice.

 

But... But... I like header files

 

https://answers.unrealengine.com/qu...compile-times-for-a-c-project.html?sort=votes

 

The first time you build the source it can take a long time. After that, it can take a long time still (2 mins) if you do not update the build script (ironically tools are in C#). Epic has already given the solution. Problem is I think the average person will probably build an empty project, see a bad compile time, not bother to research, and run back to Unity. Which is probably a really good thing. The barrier to entry is still much lower on Unity side I think

Folks are typing some very good comments above. I like both engines but I agree with much that is being said.

 

Just thought I would reply to this thread.

Currently I am using unreal engines blueprint system for gameplay and game logic prototyping.

But there is a group of people (MekTek) making Mono C# bindings with Script Editor. It will not be ready until June at the latest. But something to look forward too.

Here is a link

 

How long have you been using Blueprints?

 

Since I started with UE4 ~3 weeks ago. I still use them. My point is that people think they can ignore C++ and do everything in blueprints and it gets really messy.

If anything, understanding C++ and how it works with the UE4 API makes Blueprints easier to use and understand. I now use blueprints to throw something fast together like a conditional check on a BehaviorTree node so that I can focus my time at that moment on the more important(complex) pieces. However, I'll go back through and replace those blueprints with C++ at a later time.

 

I really miss the Asset Store on ue4 side. Their tools are truly Epic but anything they did not think to add yet will mean it falls to you. And when will their Asset Store in these other engines be fully functional?

Looking forward to seeing Unity 5 come out. I bet there is a LOT of info they are not sharing with us. I have the feeling they are aiming for AAA quality out-of-the-box. Hopefully unity 4 plugins will still work

 

C++ :

Code (csharp):

1. accumulate(n,f) := f(0) + f(1) + ... + f(n)
2.  
3. template <int n, template<int> class F>
4. struct Accumulate
5. {
6.     enum { RET = Accumulate<n-1,F>::RET + F<n>::RET };
7. };
8.  
9. template <template<int> class F>
10. struct Accumulate<0,F>
11. {
12.     enum { RET = F<0>::RET };
13. };
14.  
15. template <int n>
16. struct Square
17. {
18.     enum { RET = n*n };
19. };
20.  
21. cout << Accumulate<3,Square>::RET << endl;
22.  

But hey! It executes like mother F***ing lightning!

 

Or it can look like..

Code (csharp):

1.  
2. void AAIHordeHandler::Tick(float DeltaSeconds)
3. {
4.     Super::Tick(DeltaSeconds);
5.     //GEngine->AddOnScreenDebugMessage(-1, 2, FColor::Red, TEXT("WORKING"));
6.  
7.     UWorld* const World = GetWorld();
8.     for (TObjectIterator<AAIEnemy> Itr; Itr; ++Itr)
9.     {
10.         for (TObjectIterator<AAIEnemy> ItrOther; ItrOther; ++ItrOther)
11.         {
12.             float itrDist = Itr->GetDistanceTo(*ItrOther);
13.             if (Itr->GetName() != ItrOther->GetName()  itrDist <= 750) {
14.                 if (Itr->GetIsHorde()  ItrOther->GetIsHorde())
15.                 {
16.                     if (!Itr->GetInHorde()  !ItrOther->GetInHorde()){
17.                         Itr->HordeContainer = World->SpawnActor<AAIHordeContainer>();                            //HordeContainer object is created here
18.                         ItrOther->HordeContainer = Itr->HordeContainer;
19.                         Itr->HordeContainer->AddMember(*ItrOther);
20.                         Itr->HordeContainer->AddMember(*Itr);
21.                     }
22.                     else if (!Itr->GetInHorde()  ItrOther->GetInHorde()){
23.                                                //Adds ItrOther to existing HordeContainer
24.                     }
25.                     else if (Itr->GetInHorde()  ItrOther->GetInHorde()){
26.                         //Check if in same Horde
27.                         //Merge Hordes or steal members                   /* -- NEED TO DESTROY ItrOther->HordeContainer after merging the TArrays.
28.                                                                                                                 Calling ItrOther->HordeContainer.Destroy() results in crash.*/
29.                     }
30.                 }
31.             }
32.         }
33.     }
34. }
35.  

Which isn't much different from C#. I'm pretty sure there are other less complex ways of doing the same thing that you wrote there such as recursively calling the function and summing the return n times.

This isn't the full code, but when you compare this to the identical code from my Unity project...the C++ one is actually much easier to follow.

In C#/Unity you're doing Object.GetComponent<>().GetComponent<>().etc.whateverYouwantToDo
In C++ you do it like PtrToObject->whatever->whatever->whateverYouWantToDo

 

If you were writing c++ from scratch then I understand people being scared but operating with a framework its almost as easy as c#. This seems the case with UE4.
Can you post a few other examples of how you do a few other basic activities?

 

Not at the moment. I pulled this from an old thread I made on UE forums. At work so dont have access to my code. I have mostly made BTServices and BTTasks which run as part of my Behavior Tree to check and set things.

For example, one BTService iterates through all Players, checks direction towards player, checks angle from direction forward to Player. If the Angle is <30 degrees then we know that the Player is in front of the Enemy within a 60 degree cone field of view. We can now set enemy Target to Player and the Behavior Tree will traverse through that part of the tree to handle Enemy->Player interactions.

It's almost exactly the same as how I did it in Unity.

 

Yeah it's not as bad within a framework, providing the framework handles your needs. For instance, using boost isn't so bad, but if you looked at some of boost's implementation, it would turn your head inside-out.

But it wouldn't execute as fast. The template meta-programming version pre-compiles all that stuff for you, at the expense of being quite hard to read. How important is the faster version? Subjective I guess. But C++ let's you do it!

 

That's an ugly way of writing code but hey it runs freaking fast!