Why C++ for Unreal 4?

anonymous_user_e5c32abf · April 13, 2014, 10:32pm

[=DWORD;17158]
This is where you missed the mark. C# programmers should not be looking for blueprint nor the source code (provided through ). The Equivalent of Unity’s C# in this case is the C++ API provided with the engine
[/]

Blueprints are the replacement for unreal script in UDK/UE3.

Infact short of creating procedural geometry, anything you can do in Unity through c# you can do with Blueprints.

Unity’s scripting interface exposed through C# are not the guts of the unity engine. The c++ level release of UE4 just gives you much more direct access and power to extend, and there are direct ways of doing anything in C++ that you can do in Blueprint.

The exact equivalent would apply to the C++ source of unity. You wouldn’t tell people that use Unity through C# that they should suddenly switch to C++ just because Unity released the source.

Epic could very well have released UE4 with only blueprints just like UDK only had unreal script and no C++ access.

They released the source so the community could truly extend the functionality and collaborate with them at a level that you can’t in Unity.

DWORD · April 13, 2014, 11:26pm

[=;17198]
Blueprints are the replacement for unreal script in UDK/UE3.
[/]

Blueprints are the replacement to kismet.

[=;17198]
Infact short of creating procedural geometry, anything you can do in Unity through c# you can do with Blueprints.
[/]

No, you can’t. To do anything (outside of standard nodes) in blueprints that is not written in the standard API (create new functionality) you must write it first in C++ then use the custom stuff with blueprints.

[=;17198]
Unity’s scripting interface exposed through C# are not the guts of the unity engine. The c++ level release of UE4 just gives you much more direct access and power to extend, and there are direct ways of doing anything in C++ that you can do in Blueprint.
[/]

I didn’t say it was written in C#. I just said that Unity’s C# is the equivalent of UE4’s higher-level API (not the source code).

[=;17198]
The exact equivalent would apply to the C++ source of unity. You wouldn’t tell people that use Unity through C# that they should suddenly switch to C++ just because Unity released the source.
[/]

You are mixing programmers with random people. For a programmer to switch from C# to C++ doesn’t take a day.

[=;17198]
Epic could very well have released UE4 with only blueprints just like UDK only had unreal script and no C++ access.
[/]

Like I said, if you want a new functionality you must first write it in C++ (or UnrealScript in UDK). Also UnrealScript is nowhere near as powerful as C#. As a example I could write a unique video encoder/decoder, write a low-level network api, integrate kinect… using C#, that is not be possible in UnrealScript which is just a script language like Lua.

[=;17198]
They released the source so the community could truly extend the functionality and collaborate with them at a level that you can’t in Unity.
[/]

They can extend Unity in a absurd amount of ways (as stated above). They can’t change the core, but C# is a very powerful language that can do anything.

I’m not saying that Unity is better than UE4 (I’m migrating to UE4 after all), just saying that you are somehow blinded and probably didn’t use both. To compare C# with a visual scripting language like blueprints (that requires “binding/wrapping” like Lua to extend its functionality) is ludicrous since both C# and C++ are on the same level (high-level languages).

Shadowriver · April 14, 2014, 1:54am

[]
… since both C# and C++ are on the same level (high-level languages)
[/]

emmm C# is higher then C++, C# with VB.NET and J# is language made to interact .NET Framework not native APIs, it’s compiled to CIL code and then compiled by CLR to machine code based on .NET/Mono structure which requires bindings.

where C and later extended to C++ was made to generate machine code that you CPU executes, as writing assembler (human readable machine code) is so bottom low level which over time became too complicated to write directly to it.

I think you confused from fact that C# aside to do binded calls to engine can also use .NET or Mono frameworks which allows to stuff in system, but that does not means it’s low as C++ is.

If you want to compere C# to something, Java is the closest thing… in fact they very, very, very similar.

hbiblia · April 14, 2014, 2:17am

Unreal Scripts es lo mejor yo puedo utilizar con cualquier IDE y la compilación es mas rápida el problema es que tengo que cerrar UDK.

C++ con UE4 es interesante aun que aun hay que cerrar el editor para algunas cosas y el IDE es muy lento y pesa mucho.

Con una integración de LUA o C# funcionaria mejor , creo que este ano intentare implementarlo.

DWORD · April 14, 2014, 2:34am

[=;17235]
emmm C# is higher then C++, C# with VB.NET and J# is language made to interact .NET Framework not native APIs, it’s compiled to CIL code and then compiled by CLR to machine code based on .NET/Mono structure which requires bindings.

where C and later extended to C++ was made to generate machine code that you CPU executes, as writing assembler (human readable machine code) is so bottom low level which over time became too complicated to write directly to it.

I think you confused from fact that C# aside to do binded calls to engine can also use .NET or Mono frameworks which allows to stuff in system, but that does not means it’s low as C++ is.

If you want to compere C# to something, Java is the closest thing… in fact they very, very, very similar.
[/]

Again, I never said that C# is as low-level as C++, but both are high-level languages. Even though I would like to call C a mid-level language it’s still a high-level language. It’s just how things are expressed (labeled) these days.

The whole thing I said above was just to counter the whole blueprints >= C# that was talking about.

P.S. slam_ This is a English section of the forum. No one understands Spanish around here (probably).

anonymous_user_e5c32abf · April 14, 2014, 2:51am

No DWORD,

Blueprints are UE4’s equivalent of Unity’s C# API for creating and scripting games. I’m not saying blueprints are the equivalent of the C# language or the C# runtime. Please don’t misinform and overwhelm people coming from Unity by implying that they need to learn C++ in order to use UE4 to create a game.

UE4 is more accessible precisely because you don’t ever have to learn to program at all to create a game with it.

[=DWORD;17210]
Blueprints are the replacement to kismet.
[/]

No they are full scripting solution for UE4 that empower people with zero programming experience to make a complete game (and it is also a replacement for Kismet). I refer you to the beginning Unreal engine video about Blueprints at the relevant time index: 6:15. I recommend this entire series as it will clear up some misconceptions you have about what it is meant for. It is a full replacement for UnrealScript (and Kismet).

https://www…com/watch?v=cRhWc2kAhqIPLZlv_N0_O1gaG5BW72It4chjhypxIO9ZB#t=375

[=DWORD;17210]
Also UnrealScript is nowhere near as powerful as C#. As a example I could write a unique video encoder/decoder, write a low-level network api, integrate kinect… using C#
[/]

That’s no basis for saying that people coming from Unity to UE4 should crack open a C++ file to dig for the equivalents to creating MonoBehaviours and scripting GameObjects. The vast majority of the API’s provided by Unity in C# have equivalents in Blueprints, that’s what they are designed for.

You are misinforming and overwhelming people converting from Unity by telling them they need dive into the C++ API to find the equivalents. You are mixing the “use the C# runtime library to open sockets” use case with the “Creating and scripting game objects, sounds, triggers, events, and game flow and logic” use case.

[=DWORD;17210]
Like I said, if you want a new functionality you must first write it in C++ (or UnrealScript in UDK).
[/]

“New functionality” is too vague a term. If you want open a socket or communicate HTTPS with a webserver, or write a spreadsheet application the yes you need C++. If you want to create AI behaviors or things actually pertaining to your game then no you don’t need C++: that’s what UnrealScript was and what Blueprints are for.

The fact that you do both in C# in Unity is a casual relationship and it’s not applicable to UE4.

[=DWORD;17210]
I’m not saying that Unity is better than UE4 (I’m migrating to UE4 after all), just saying that you are somehow blinded and probably didn’t use both.
[/]

I’ve used Unity extensively and written lots of C#. Let’s avoid these unpleasant characterizations. I’m only here to try and dispel some of the misinformation people have about UE4 and C++ and the false pretense that you need to learn C++ to make games with UE4. You never need to read or write a line of C++ to create games in UE4.

Shadowriver · April 14, 2014, 3:35am

Blueprint replacing UnrealScript, thats what Epic was stating multiple times on forums. Anyway i don’t see point of arguing, there already people working on C# bindings even with editor integration, so if somebody likes C# he will be able to set it up. Thats one of the reason why Epic gives access to code so people can extend the engine whatever they like

anonymous_user_e5c32abf · April 14, 2014, 4:11am

[=;17259]
Blueprint replacing UnrealScript, thats what Epic was stating multiple times on forums. Anyway i don’t see point of arguing
[/]

I totally don’t want to argue, I genuinely just want to make sure people coming over get the right information. There’s a lot of confusion floating around over here and over on the Unity forums and it’s best to try to nail some of that down so people can make an informed decision.

[=;17259]
There already people working on C# bindings even with editor integration, so if somebody likes C# he will be able to set it up. That’s one of the reason why Epic gives access to code so people can extend the engine whatever they like
[/]

For technical reasons it’s unlikely that will ever be as robust as Unity’s C# API since the Unreal object system requires metadata and introspection for class member offset and the packing rules of the compiler and stuff. There’s probably no good way to glue the C# runtime stuff in such a way that you can actually export new class interfaces and types from C# into Unreal which means it’ll likely be limited to the same set of things you can do in Blueprints except with the downsides of the C# GC I spoke about above.

BUT you would have the C# runtime at your disposal, which I admit could be very useful for the people that don’t know C++…

anonymous_user_7af3b797 · April 14, 2014, 9:32am

[]
BUT you would have the C# runtime at your disposal, which I admit could be very useful for the people that don’t know C++…
[/]

Guys, from other than C++ background. Get a life. Stop moaning. Stop complaining that if you’d have C#/Java/javascript/python it would be easier for you, you’d have familiar environment, you wouldn’t have to learn new things etc etc.
This is gaming industry. Every tick really matters hear like nowhere else.
You’ve been given at your disposal the most powerful, wonderful, most mature tools on this planet and instead of being greatful what are you doing? You are complaining.
OOOww, why C++…
Ooowww, why not C#
ooowww, why not python
ooowww, now I have to learn new things.
ooww it is so difficult now, each error in my code blows and does not allow to compile…

Poor you.
You must understand that:
a) This is gaming industry and so it follows:

In order to have best performance you have to use C++.
In order to have best flexibility you have to use C++.
In order to have AAA games with AAA performance/visuals you have to use C++.

Get it!

No java, c# or other slow mo creature can provide you with it. Get it, deal with this and be grateful that you can actually work with these tools. The entire world is open to you. No barriers, no constraints. You can do whatever you like. Don’t be scared of freedom. Embrace it and you will never look back!

And if you don’t like it there is always plethora of mediocre tools with mediocre performance/capabilities that you can choose from and use them. Unity comes to mind. Familiar environment, with chains around your wrists and ball chained to your leg, but that’s how you like it, isn’t it? Familiar, cosy, three meals a day at regular ours, 10 o’clock nightime call, on every other sunday you can actually watch your favorite program on telly (but for no more than half an hour).

anonymous_user_fa4a31eb · April 14, 2014, 10:19am

[=;17325]

And if you don’t like it there is always plethora of mediocre tools with mediocre performance/capabilities that you can choose from and use them. Unity comes to mind. Familiar environment, with chains around your wrists and ball chained to your leg, but that’s how you like it, isn’t it? Familiar, cosy, three meals a day at regular ours, 10 o’clock nightime call, on every other sunday you can actually watch your favorite program on telly (but for no more than half an hour).

[/]

I think the reason ppl love unity is because its easy to make quick crappy little games. The reason they hate it is because its a nightmare to do anything good with it.

anonymous_user_fa4a31eb · April 14, 2014, 10:28am

[=;17083]
Why C#'s garbage collection is bad, and why UE4’s GC is better.

[/]

I feel slightly annoyed that ppl are building c# plugins because I think it will be a performance nightmare.
If c# was implemented how would c# GC sync to UE4 GC?

MonsOlympus · April 14, 2014, 10:40am

[=;16252]

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.

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.
[/]

Okay so Im not going to disagree but I would like to highlight a few things in terms of interop barriers I have witnessed in regards to c++ and blueprints so while I agree that C++ was the logical move and while on the strict topic of C++ its easy to gloss over extended topics.

Now what Im having to do is to tell my C++ programmers not to create classes without first checking to see if there is a core Blueprint extending the C++ which could circumvent these Core Blueprint Classes. Now this is workflow specific and ofcoarse if you use pure C++ the need for these types of guidelines are not required but as far as I can tell there is still an interop layer but it is more refined compared to C++ and Uscript, in fact duplication is still occurring with Blueprint also but I do believe it is much more beneficial in this case because my experience of Blueprint has been that it out performs UScript quite significantly.

Core C++ Classes -> Core Blueprints -> Extended Blueprints

The workflow is like this, every Core Blueprint has a C++ Class and every C++ Class created has a Core Blueprint, this allows code injection on either layer without having to re-base or extend new classes and make new branches in the hierarchy. From there extended Blueprints contain the specific functionality and the Core classes are the framework classes. Im not sure if what Im doing is the best practice but it’ll work for the project Im working on since we’ll need to rapidly make extensions from the core Blueprints, the issue Im having is Im not wanting to reference Blueprint objects directly from C++ because it leads to a similar situation to archetypes which I dont believe is ideal but I might not have any choice if I want to keep core functionality within C++.

I cant deny the benefits of having C++ there if its required but we came to an agreement amongst the team that modifying the engine code wasnt required and we should focus on the gameplay layer which actually gives us an interop layer that there never used to be, unless ofcoarse we were using UScript and Kismet. Its been easier for me to pickup the Blueprint code so thats a bonus and my experience, its also far more powerful than Kismet so thats a big reason for making use of it, it also supports replication too. My main issue with the interop between C++ and Blueprint is that some things are actually easier done in the editor and theres no way to get that back out into text based code, typing out components is something Im sure you get used to eventually but still picking things up I find it easier to work with the component tree in the editor but Core Blueprint changes dont propagate back into the Core C++ without manual porting unfortunately.

I would be curious to hear how Epic has been dealing with these things on Fortnite as it could give me some insight before I move forward, Im happy with where Im heading but as stated I might encounter the need to have C++ Blueprint dependencies like Archetypes and Id prefer not have those hard links between external and internal classes

Thanks greatly for taking the time to explain the reasoning behind the move to C++, Ive actually been curious and wanting to hear your thoughts for some time on the matter.

anonymous_user_eacab62d · April 14, 2014, 11:45am

[=]
I think the reason ppl love unity is because its easy to make quick crappy little games. The reason they hate it is because its a nightmare to do anything good with it.
[/]

You get the point :
Unity -----> good to prototype gameplay quickly and test if your game concept works and if it’s fun.
UE4 ------> Develop your game in order ro release it.

For example Ubisfot develop with Unity only for their mobile productions.

In general, software development is better with a low level program language, isn’t it ? Such as C and C++.

Shadowriver · April 14, 2014, 12:36pm

[=jpilyas;17370]
For example Ubisfot develop with Unity only for their mobile productions.
[/]

Because Unity is only good engine for mobile and still be atleast for a while looking on how UE4 preforms on Android

Nico_de_Poel · April 14, 2014, 12:58pm

[=jpilyas;17370]
You get the point :
Unity -----> good to prototype gameplay quickly and test if your game concept works and if it’s fun.
UE4 ------> Develop your game in order ro release it.

For example Ubisfot develop with Unity only for their mobile productions.

In general, software development is better with a low level program language, isn’t it ? Such as C and C++.
[/]

That’s not really giving Unity enough credit. Unity can be used just fine to create a finished and polished game, but Unity caters more towards the indie scene than to triple-A developers. For some reason Unity also has a bad reputation with gamers; a lot of people are put off when they see the Unity logo in a game. That’s not really fair though, you really can do a lot with Unity if you get the right people together. Perhaps the bad reputation comes from the large number of hacks who use Unity, whereas Unreal Engine has always been more closed off to inexperienced developers. Unreal Engine does have a much better track record when it comes to large scale projects.

Both engines are kind of converging to each other however; Unity keeps adding more triple-A features while UE4 is making steps towards indie.

I would say the major thing holding Unity back right now is the outdated Mono run-time they use for their C# support. It’s slow and lacking in features, and the latest Mono is a lot better than the ancient version that Unity uses. They’re having licensing troubles with the current owners of Mono and they really need to sort that out. Other than that Unity has gone from strength to strength the last couple of years.

MonsOlympus · April 14, 2014, 1:06pm

Guys Im not sure Unity has a place in a topic titled “Why C++ for Unreal Engine 4”, sorry to break up the discussion but back on topic aye, Unity have their own forums.

Rama · April 14, 2014, 4:42pm

Thank you Epic Devs for UE4 C++!

I was only able to make my new game mechanic thanks to this awesome C++ opportunity that you’ve given us!

Here I demo how players can use my in-game editor at Runtime to combine meshes into larger physics objects.

And these runtime physics combinations can be destroyed and will break into realistic subgroups of physics objects!

The power of UE4 C++ has enabled me to offer my end users the ability to do this at runtime, in-game!

The editor was never loaded in this video, and as you see in video these combinations can be changed or added to any time.

Thank you Epic!

https://.com/watch?v=sOl5uKe16ZM

anonymous_user_e5c32abf · April 14, 2014, 4:55pm

[=MonsOlympus;17344]
Okay so Im not going to disagree but I would like to highlight a few things in terms of interop barriers I have witnessed in regards to c++ and blueprints so while I agree that C++ was the logical move and while on the strict topic of C++ its easy to gloss over extended topics.

…

I cant deny the benefits of having C++ there if its required but we came to an agreement amongst the team that modifying the engine code wasnt required and we should focus on the gameplay layer which actually gives us an interop layer that there never used to be, unless ofcoarse we were using UScript and Kismet. Its been easier for me to pickup the Blueprint code so thats a bonus and my experience, its also far more powerful than Kismet so thats a big reason for making use of it, it also supports replication too. My main issue with the interop between C++ and Blueprint is that some things are actually easier done in the editor and theres no way to get that back out into text based code, typing out components is something Im sure you get used to eventually but still picking things up I find it easier to work with the component tree in the editor but Core Blueprint changes dont propagate back into the Core C++ without manual porting unfortunately.

I would be curious to hear how Epic has been dealing with these things on Fortnite as it could give me some insight before I move forward, Im happy with where Im heading but as stated I might encounter the need to have C++ Blueprint dependencies like Archetypes and Id prefer not have those hard links between external and internal classes
[/]

I’m not sure exactly what you mean by dependencies in terms of Blueprints. Blueprints in C++ are just normal UObject classes that have some meta data via UPROPERTY and UFUNCTION macros that make blueprints aware of them so the engine can instantiate and connect them together. Any dependencies you have should only be your direct parent class.

You should be able to place any common code you want to reuse in non-blueprint cases in a simple class of your own that is called from your Blueprint class and your non Blueprint class (i.e. a class that has no blueprintcallable properties and functions).

Maybe I’m not understanding the complete picture?

Tim_Sweeney · April 14, 2014, 7:13pm

[=MonsOlympus;17344]
I would like to highlight a few things in terms of interop barriers I have witnessed in regards to c++ and blueprints so while I agree that C++ was the logical move and while on the strict topic of C++ its easy to gloss over extended topics.
[/]

This is a great point, that an interop layer must necessarily be present at the interface between code and sufficiently powerful visual tools. The layer enabling C++ programmers to expose features to Blueprint layers is one example. Another example is the visual material system, where code generated for shader nodes is essentially strcat’d together behind the scenes into a shader program that is sent to DirectX or OpenGL for realtime execution on the GPU.

The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.

BTW: It’s fine to compare to Unity and other engines here. Each engine arrived at a very different solution to gameplay programming, and comparing their decisions is a valuable exercise that increases 's understanding of the tradeoffs.

Rama · April 14, 2014, 7:32pm

[=;17538]
The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.
[/]

Dear ,

I know I speak on behalf of many beta and new licensees when I tell you that I absolutely adore your choice to share UE4 C++ with all of us!

Thank you for sharing your heart with the world!

Programming in UE4 C++ has been one of the greater joys of my adult life