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.
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.
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:
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;
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;
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.
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.
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.
