Why C++ for Unreal 4?

C++ has been one of the best low-level coding languages for a long, long time. The compiled code runs efficiently and performance is hard to beat. Since it has been around longer than C#, C++ has been the core language for serious pro coders for a long time. With that said, what Epic is doing is catering to the upper echelon of serious programmers who probably have deeper skillsets and experience than do those who only code in C# or Javascript. That’s not to say that the latter two are bad, they’re fantastic languages, but C++ is the king of the pack. I’ve coded in all of them, and many others, and for serious game development, I’d do all my core game coding in C++.

Just my $.02.

I don’t think Unrealscript was ever the wrong choice because it originated from Unreal Engine 1. It wasn’t a system designed for Unreal Engine 3…

UnrealScript was rough back then too. Sure it gave us a nice ‘sandbox’ environment. But we couldn’t debug. Couldn’t rapid prototype. Took quite awhile to compile

I see these threads complaining about 2 min compiles and intellisense not working. Really? We had no IDE period back then and I am pretty sure compiling Unrealscript took awhile back then. And oh yeah, restarting UnrealEd…

  • State based programming and replication blocks were very nice tho. So were delegates, etc when they were added. Nice language it was.

Coming from a Java/C# background a lot of these posts seems misinformed on how programmers who never Learned C++ looks at this monolith of a language.

C++, while technically not that much harder to learn syntax-wise than the above-mentioned gives you SO MUCH POWER that it’s intimidating like crazy.
I’ve tried to do C++ from time to time but every single time I run into the problem of Pointers. I understand what a pointer is. I understand what a pointer is supposed to do. But I have no idea when to use one and I have yet to find a definitive explanation that says “These are the scenarios dum dum”.

All they do is tell you what a pointer is, how to access the data from a pointer and also how to get the address of a pointer. But other than that? Good luck!
I have no idea where to start or where to end when I start on a C++ file. I have the header file which is an infuriating system to begin with (function prototyping? Seriously?) and then I have to match my cpp file with the header file and even if you manage that, good luck trying to understand any of the garbage debugging message it spits out at you which might even be a downright lie. I realize that other languages can lie to you as well during errors but at least most managed languages seems to remember that it’s humans who code these programs and not electric engineers.

And then there is the issue of mixed C and C++. Half the time I can’t tell when it goes between the two, but even following books to the letter and posting about it on Stackoverflow reveals that even those books lie to you and have the approach of mixed C and C++ syntax.
I would love to see D get the spotlight over C++ because in D it’s at least build from the ground up as language that supports Objects and Data instead of a tagged on addition that is C++, the superset of C.

Also in D you can write in-line assembly code, use all previous C code still and even in the memory management department you have options.

  • Garbage Collector
  • Partially Garbage Collector / Partially Manual
  • Completely manual
  • Define Blocks in Memory that are off-limits to the Garbage Collector

You can have the best of all worlds.
I love C# and Java languages. They are so d@mn easy to comprehend and the talk about memory leaks is absurd. I have not found anything on that other than age old articles . I don’t say switching to C++ was a bad choice as I am convinced it was going to happen regardless, but I find it quite upsetting that there are not other options (Yes Blueprint but lets face it that gets tedious very fast).

C++ is great language for epic things like UE4. And the whole engine is now extandable. You can use even V8 now, if you want to write a code so much. If you’re not familiar with cpp you can possible create the whole game using blueprints, and that’s really cool :slight_smile:

P.S. - Unreal Script was “easier”, but not so flexible. And we have to use it because of old Kismet limits, now we can make games, not code.

Dear Vipar,

I did my best to provide a very inventive explanation of pointers and how they work and when to use them and why they are awesome here:

I am linking you to my subsection on “Why Use a Pointer?” as per your quote above, since my article strives to specifically expand on this topic beyond just the basics.

Why Use A Pointer?

Please let me know if it helps!

I first introduce the concept of pointers here:

Again I tried to be very innovative with my explanations.


(I am posting this for any other readers to enjoy as well)


GAH! Pointers, the one thing that wracked my brain in C++ classes. Pointing to memory addresses, changing them on the fly and reallocating the memory to be called a different variable…

…O_O. I WILL be reading and watching many of those tuts. I mean, I am alright at C++, but pointers always made me freak out. Thanks again guys!

C++ is the industry standard for game development. Since Unreal Engine targets more AAA it makes sense to keep it C++.
C++ also gives you finer control over the little things, which can sometimes be essential for larger budget projects.

To guys having problems with pointers.
Guys, nobody uses raw/naked pointers in modern C++ anymore. Check unique_ptr and smart_ptr, learn how to use them, and you will never have to think about memory management again.

C++ is simply beautiful.

As for headers and source files. Agreed, pain in the neck. Check out C++ modules though, and you’ll understand what I mean when I say ISO committee is working hard on constantly and frequently improving C++.

It is a common fallacy that C# performs worse than C++. C# and C++ can perform equally well when compiled to native code because C# is optimized in the same manner as C++ and in some cases better. It is true that the default behavior is to compile C# to IL, however, this can be changed. Even still, C# has a just-in-time-compile feature, which means the first time an application’s execution path leads to IL, it is compiled to native code and from that point on it’s just as fast as anything else compiled to native code. However, C# and managed languages have other issues at run time, which make them challenging for games development. This is also the reason managed languages will NEVER be used for game engines. I’m sure there are examples of attempts to make a game engine in C# but it will never be a serious contender in the AAA world.

C# and other managed languages are only the future for applications where more hardware is the solution to memory and performance problems, aka business applications. In games, memory management is super important and managed languages don’t really offer the degree of control you need in most cases. For example, garbage collection will cause rather large lag spikes if you don’t consider strategies to deal with this. If I create an instance of an object each frame at 60 frames a second, it means I’m creating 60 instances of garbage that needs to be collected each frame. If I extrapolate that out over many objects, you can see that the garbage collector could easily become overwhelmed as significant pressure is applied to the CPU during garbage collection, which causes a visible drop in frame rate. In a large game, this can become very difficult to manage. In severe cases you can see situations where the game skips every couple of seconds due to garbage collection. Having shipped several games in Unity3D, this is a huge problem, which typically requires strategies like object pooling but, even with strategies like this, it’s still a real pain to deal with. In C++ you have complete control over memory so you can make it work exactly the way you need it to work, rather than being forced to deal with a memory management solution that is not optimized for games.

In C#, resolving a property on a reference type requires a memory read where resolving a property on a struct does not because it’s a value type that lives on the stack. Also, value types can be boxed inside a reference types (aka object), so you need to be aware of this. While this is a very minor optimization example, it’s one of many you have to be aware of when dealing with managed languages that either don’t apply or have a more elegant solution in C++. The bottom line is that managed languages have a place in games but it’s not the future. Business applications are different story because they usually don’t have the same type of performance and memory requirements that games do.

When looking at what language is the best tool for the job, it’s important to consider both functional requirements AND non-functional requirements, aka memory and performance…

^^ Blizzard used Unity for Heartstone. Is that game considered AAA or not? I dunno. Regardless, it would be rather strange to claim C# will not be used in AAA games when it is already being heavily utilized in several titles

It won’t be used for writing the actual engine. The game is another thing.

Yep true. When I speak of managed languages (or rather any high level language) becoming more widely used I am thinking far into the future (basically, pure thoerycrafting). Defintely not within this decade. On Consoles, there are still a lot of assembly optimizations etc that folks were doing. At least- on ‘current’ gen for sure. I cannot speak on next gen at this time. We are still getting up to speed on those [edit- We meaning my studio I am employed at]

No they can’t.
Please stop believing in fairy tales.

People who belive in this are the once that can’t grassp why so simple games like Minecraft or Fez have so high requirments and yell “opimize” at developers

C++ compiles to direcly to CPU machine code it does not have manage code which makes you code easier in cost of prefermence. You cant go faster then that or else you create more optimal assebler code. I ammused that developer now days are so lazy and addicted to assist code that they start to discredit C++, where i belive C/C++ is first thing they should learn as this way you understand software a hell lot of better. When i first used c++ i felt free like a bird.

Also small reminder… Unreal Engine always had C++ coding since very begining, with *.u file you could also see associated *.dll file, but it was not avable to nonlicence users… until this point (or rether licence become cheaper). If you wonder why licenced developers could do more with UE thats a reason, they could do call to even deepest point of engine, could implement external code liberies and so on. Epic states that Blueprint is what replace UnrealScript, and give access to C++ so things fit perfecly

I really think that if this thread is going to continue in this direction it needs to be locked. It’s all downhill from here. OP got way more than he bargained for.

Why C++ for Unreal Engine 4? In short, performance and portability concerns mean the core of the engine is going to be written in C++. The original question could alternatively be interpreted as “why was UnrealScript removed, and not replaced with something like C# for quickly iterating on game logic?” That would be a better discussion to have, but that’s not the discussion that’s occurring here.

What we have arrived at instead is a C++ vs C# argument that is indistinguishable from billions of others that echo throughout the internet, and is not constructive. Ultimately, for most people, that choice comes down to personal preference, and no one here is likely to change anyone else’s mind.

The first three generations of the Unreal Engine included a sandboxed scripting language, UnrealScript, which provided a simple interface for gameplay programming that was shielded from the complexity of the C++ engine.

The scripting approach is very welcoming to new programmers, but eventually it breaks down and becomes an obstacle to innovation and shipping. We experienced this over time as the Unreal Engine grew until finally, in 2011, we moved to a pure C++ architecture. The causative factors were both pervasive and general:

  • As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.

  • As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or “interop” layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.

  • Developers seeking to take advantage of the engine’s native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.

  • Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can’t trace the C++ that code led to it, and vice-versa.

It is these reasons, ultimately, that led to Epic’s move to pure C++. And the benefits are numerous: UE4 is a unified and fully-debuggable code base, freed from Interop Hell and totally open to programmers to study, modify, and extend. There are side-benefits, too, such as increased performance in gameplay code, and ease of integrating other middleware written in C++.

Building Unreal Engine 4 as a unified C++ codebase has been very freeing, giving engine and gameplay programmers enormous flexibility to write code without unnecessary interop barriers.

This isn’t to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that it’s more powerful.

By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.

Thanks for taking the time to post Tim, it is appreciated. A long time C++ coder myself, I can only agree with maintainability.

The seas are a bit rough right now with the engine, and Slate being somewhat of a major weakness. However, by opening up the engine, and seeing that Epic is being very attentive to the developer community, things will improve, and I can only see success going forward.

The Words of Wisdom from Tim Sweeney himself :)! Still am thankful for you and the hundreds of developers for this powerful and beautiful engine!

Thanks for posting Tim! It is great to read how things went from your point of view. Way back in Unreal Tournament days while working on my mods I always wanted more and more access to the internals. Eventually I got my wish when I got my first job in the industry. I don’t think any of that would have ever happened without Unreal. Such happy times. Still talk to a friend I made from my first publically released mod (we lived in the same city at one point too!)