Why C++ for Unreal 4?

Does Epic have some sort of style guide for C++ programming, that you either use internally or recommend for users of Unreal Engine 4?

(C++ is arguably a very “large” language, and every successful large C++ project that I’ve seen has chosen a certain subset of the language and adhered to that subset. For example, the google C++ style guide advises against exception, and the MISRA C++ standard (for industrial/embedded devices) prohibits heap allocation. And I can’t find the video right now, but I remember Carmack saying in a Q&A that he also has in his mind a “sane subset” of C++ he used for Quake 4/Rage/etc. I would love to know if Epic has something similar.)
[/]

Yes me too I was wondering this same thing.

I do believe some people are overlooking the obvious complexities of C++, thats not to say its bad once you actually know it and there are alot of learning resources but that is also one of the issues, with UScript for example there were a few trusted sources but for C++ there are literally topics all over which returns more false positive search hits when scouring the internet. I consider myself to be quite a capable programmer but with the removal of UScript I now consider myself largely a beginner based soley on my lack of experience with C++ and nothing more. Infact I have enough experience across C-Type languages to say I actually know more programming concepts than what the base C++ language provides.

Its easy to get a narrow field of view when youre always playing in that field but as soon as you step out into the surroundings things can be quite daunting, this case is non-specific but transferable skills will always trump everything else. If you honestly NEED C++ because you cant do it any other way then there is a problem, just like if I couldnt do what I was doing in UScript any other way, granted it’ll take time to learn the syntax and nuances especially in C++'s case because it seems to really enjoy being just obscure enough to be frustrating.

This is largely based on my experience with actually writing in various languages and has little to do with the underlying semantics, Im certain sure we could show clocked times of foreach in every language vs one and other but thats not real world is it. We all know that throwing more programmers at a problem wont necessarily get it solved quicker, you’ll probably just end up with multiple solutions because its clear we’ll never agree on a one size fits all. It largely comes down to personal preference and I find I actually prefer C to Epic’s UE4 C++ but thats an opinion and goes to how I feel about the usability and how productive I would rate myself which is actually the most important thing about this entire discussion, you can have all the speed in the world but if youre running in the wrong direction all the time its not going to help you.

Gameplay programmers need to be more productive than ever in this environment, we have people pushing for games to be made over a weekend and we cant do that while we are typing out macros and extra domain specific syntax all the time. That is why I would choose UScript over C++, is that its lean, I know full well the drawbacks which is why I think Blueprint is a great replacement and I do believe people saying blueprints isnt really for advanced programmers might need to open their eyes like I have. If a programmer is more productive in C++ I want to give them the tools and the backing to be able to strive in that environment and the same goes for blueprint, if I had other options like C# I could certainly be more productive in text based programming. In the end we’re in the business of making products, obviously we all weigh up the pros/cons for a specific project and base our choice in third party software on that, dont we?

[=MonsOlympus;17930]
In the end we’re in the business of making products, obviously we all weigh up the pros/cons for a specific project and base our choice in third party software on that, dont we?
[/]

Games to be specific,

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…

P.S.
The only sources on C++ you need:

  1. Bjarne Stroustrup - Programming: Principles and Practice Using C++
  2. Bjarne Stroustrup - The C++ programming Language 4th edition
  3. Andrei Alexandrescu - Template metaprogramming

In that order, study them, and you’ll will be flying.

I couldn’t agree more with that PINVOKING the entire UE4 engine is a nightmare. That was one of my earlier mistakes working on our UE4 C# . You’ll never PINVOKE this engine in its current development state and expect to be able to maintain it easily over time. Even using a tool like SWIG to do the majority of your script binds is a total nightmare… well maybe not a nightmare but at least a bad dream.

Though while C++ may be superior because of its the lowest common denominator (well… whose discrediting assembly here :wink: its not particularly the best for game scripting when you start lacing it with what C++ really is which is templates and complex macros which is evident by the presence of BluePrints in UE4 which simplifies all that and packs it down to ByteCode. If you are working with a diverse indie team with many different skill sets you are unlikely to be able to utilize your team with just C++. Game designers that work in BluePrint often prototype and then programmers need to pull that logic down to a scripting language like C++. Its nice to have alternatives. Most game engines I’ve worked with had this ability in some form or another.

This is why I opted for the PINVOKE’LESS methodology provided by the Mono Runtime. I only picked Mono because they already had the technology developed for internal calls and I believe C# is a great addition to UE4.

How does it work?

The Mono runtime provides two mechanisms to expose C code to the CIL universe: internal calls and native C code. Internal calls are tightly integrated with the runtime, and provide no support for marshalling between runtime types and C types.

For example, passing a C# string will result into a MonoString* in the C function when using an internal call (that is, it will be a pointer to the managed heap object representing the string). A C# string passed to a PINVOKE C function will result instead in, for example, a utf8 char pointer, depending on the marshalling attributes.

To make the runtime lookup the symbol in the current executable, we use the special library name __Internal.

The “__Internal” library name will instruct Mono not to look this up in an external library, but to try to satisfy the symbol referenced (DoSomething) in the current executable image.


using System.Runtime.InteropServices;
 
[DllImport ("__Internal", EntryPoint="DoSomething")]
static extern void DoSomething ();

If you want direct access to managed objects you can register C code with the runtime, and later bind to it from managed code.


mono_add_internal_call ("Hello::Sample", sample);

From there its just a matter of declaring it on the C# side and calling the method.

What we’ve done with our C# implementation is created a macro which understands BluePrint callables and uses Epic’s very own logic for exposing native C functionality to BluePrint. We are able to adhere to the rules of BluePrint yet produce a fully working C# API.

Combined with Mono’s SGEN GC its a fairly efficient approach. Certainly nothing prevents developers from still maintaining complex code at the C++ level and allowing game design to take place in C#.

[=vincemektek;18003]
I couldn’t agree more with that PINVOKING the entire UE4 engine is a nightmare. That was one of my earlier mistakes working on our UE4 C# . You’ll never PINVOKE this engine in its current development state and expect to be able to maintain it easily over time. Even using a tool like SWIG to do the majority of your script binds is a total nightmare… well maybe not a nightmare but at least a bad dream.

Though while C++ may be superior because of its the lowest common denominator (well… whose discrediting assembly here :wink: its not particularly the best for game scripting when you start lacing it with what C++ really is which is templates and complex macros which is evident by the presence of BluePrints in UE4 which simplifies all that and packs it down to ByteCode. If you are working with a diverse indie team with many different skill sets you are unlikely to be able to utilize your team with just C++. Game designers that work in BluePrint often prototype and then programmers need to pull that logic down to a scripting language like C++. Its nice to have alternatives. Most game engines I’ve worked with had this ability in some form or another.

This is why I opted for the PINVOKE’LESS methodology provided by the Mono Runtime. I only picked Mono because they already had the technology developed for internal calls and I believe C# is a great addition to UE4.

How does it work?

The Mono runtime provides two mechanisms to expose C code to the CIL universe: internal calls and native C code. Internal calls are tightly integrated with the runtime, and provide no support for marshalling between runtime types and C types.

For example, passing a C# string will result into a MonoString* in the C function when using an internal call (that is, it will be a pointer to the managed heap object representing the string). A C# string passed to a PINVOKE C function will result instead in, for example, a utf8 char pointer, depending on the marshalling attributes.

To make the runtime lookup the symbol in the current executable, we use the special library name __Internal.

The “__Internal” library name will instruct Mono not to look this up in an external library, but to try to satisfy the symbol referenced (DoSomething) in the current executable image.


using System.Runtime.InteropServices;
 
[DllImport ("__Internal", EntryPoint="DoSomething")]
static extern void DoSomething ();

If you want direct access to managed objects you can register C code with the runtime, and later bind to it from managed code.


mono_add_internal_call ("Hello::Sample", sample);

From there its just a matter of declaring it on the C# side and calling the method.

What we’ve done with our C# implementation is created a macro which understands BluePrint callables and uses Epic’s very own logic for exposing native C functionality to BluePrint. We are able to adhere to the rules of BluePrint yet produce a fully working C# API.

Combined with Mono’s SGEN GC its a fairly efficient approach. Certainly nothing prevents developers from still maintaining complex code at the C++ level and allowing game design to take place in C#.
[/]

I genuinely hope that UE4 will always be C++ and no C# or Java (or other slow creature) will creep up and hit performance of it. I really hope so.

[=;18011]
I genuinely hope that UE4 will always be C++ and no C# or Java (or other slow creature) will creep up and hit performance of it. I really hope so.
[/]

No one is arguing that the core UE4 Engine shouldn’t be in C/C++, this is clearly the most sensible thing to do.

What many people want is an easy way to program game/scripting logic in something besides C++(but that is an established programming language, and not visual like blueprints). As vince points out, the performance of most game logic is completely inconsequential, When somethings using less than 1% of the resources, does it really matter if it’s 0.8 or 0.6? No, as programmers we have more expensive problems to tackle, so anything that makes our job faster saves time, and time is money.

C++ is as if you’re hitting the lowest ground. It’s like you got NDK in Android, it’s like you got Objective-C with C++ in iOS, it’s like you got asm.js for HTML5. In terms of me being a coder, this idealism of using one of the most powerful engine using C++ is one of the satisfying moment in my whole programming life. For me, even though C++ is fast whatsoever with disadvantages of high learning curve and/or harder code management, it is merely a fun language you will ever mess up with, but also crucial in commercial terms, so all the fun won’t go to waste. Since Unreal has reached deep down here in indie community, as a hobbyist I find this very, very mutual and amusing at the same time, you know, touching those to the very bones of the engine. FOR $20 A MONTH. It’s like I’m subscribing to a living museum and being able to touch them all. :cool:

[=vincemektek;18003]

What we’ve done with our C# implementation is created a macro which understands BluePrint callables and uses Epic’s very own logic for exposing native C functionality to BluePrint. We are able to adhere to the rules of BluePrint yet produce a fully working C# API.

Combined with Mono’s SGEN GC its a fairly efficient approach. Certainly nothing prevents developers from still maintaining complex code at the C++ level and allowing game design to take place in C#.
[/]

This is very cool. But just to clarify the C# runtime is restricted to using existing blueprint callable functions. You aren’t getting a UActor reference in C# with full access right? You are essentially able to script the connections between blueprint nodes? Do you have some example code that demonstrates it, for example setting the XYZ position of a UActor in C#?

[=DWORD;15588]
UnrealScript was the wrong choice indeed. It’s slow (20x slower than C++) and C# is way more powerful. I wound’t say that C# is the future of game programming, but its very good. I prefer C/C++ as a programming language, C# is the second best.

The “easy” transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.
[/]

Comparing the “speed” of a scripting language versus a “real” language is a completely useless thing to do – there’s no good use comparing two completely different things.

Adding a scripting language to even UE4 would not be a useless endeavour, simply because one has access to the source code. I seem to recall that there was at least one developer who had replaced UnrealScript with Python in UE3, and they obviously had source access, but felt it would be advantangeous to have a more accessible language to do some work in.

Certainly, overall, C++ is probably “best” to work in, speedwise, considering that the engine is built in it, but I think that a lot of the supposed advantages/disadvantages to doing so are vastly overstated.

Until I started working with Unreal professionally a bit over 4 years ago?, I was over 20 years rusty (probably closer to 25) on C++. C++ in Unreal is completely different from C++ in any other project that I’ve seen, they’ve pretty much built a complete language inside C++. I’ve been working with C++ in other projects ever since then … and else’s C++ doesn’t even resemble the language that I learned back in the late 80’s/early 90’s. Programming in Unreal doesn’t even resemble any other modern C++ project that I’ve worked with since.

Of course, one nice advantage, is that you can go off and write all your own things, in whatever the heck style you want, using or not using Unreal’s macro language, and then glue it in with a few uses of that, and off you go.

Frankly, I think it would be super awesome if someone could figure out a way to rapidly implement QML as a UI framework into Unreal, but unfortunately, I imagine that either decoupling QML from Qt, or integrating Unreal with Qt would be proposing a nightmare. :slight_smile:

[=;17996]
Games to be specific,

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…

P.S.
The only sources on C++ you need:

  1. Bjarne Stroustrup - Programming: Principles and Practice Using C++
  2. Bjarne Stroustrup - The C++ programming Language 4th edition
  3. Andrei Alexandrescu - Template metaprogramming

In that order, study them, and you’ll will be flying.
[/]

I would totally dispute that – You can write a **** in any language, and you can write something that is fast and performant in any language*

I think my favorite example, is the Guitar Hero clone that was written (mostly) in Python. And I was running it at full speed on hardware that doesn’t even compare to my lowest end tablet right now (4 year old tablet)

  • of course, there will be some things where your bar of performance may be vastly different, but for some tasks, C++ doesn’t give acceptable performance, either.

[=;18011]
I genuinely hope that UE4 will always be C++ and no C# or Java (or other slow creature) will creep up and hit performance of it. I really hope so.
[/]

No offence, but your comments are pretty common to the amateur mindset. The C++ == speed meme is something you really have to get over. A pragmatic ( read – good ) programmer looks at all tools available to do the job and choose the right one for the situation. Even in games, and other realtime perfomant applications, C++ isn’t always the right tool, although often it is. Dismissing other tools based mostly on reputation is silly at best.

Would you hire a contractor that thought a hammer was the solution to every problem?

[=]
I don’t think any blanket statements have been made advocating C++ as the only solution to any problem. I think the case has been made that there are downsides to any managed language, and that C# and IL languages in particular lack the comparative speed and language features relative to C++ and therefore make it a less optimum choice for a large complex real-time application.

No one is trying to make some kind of crusade for or against any particular language here.

[/]

Did you read the thread? There are quite a few garbage posts such as:

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

The comment you were referring to was directed at posts such as these.

Note that in my reply, I did state that native code is a very appropriate choice for many of the performance critical subsystems in the engine; but may be significantly less so for game logic, AI, networking code and so on (i.e. a majority of the game-specific logic you may wish to implement).

[]
This is a bad generalization in my opinion. Domain specific knowledge is critical in certain classes of problems, but that does not mean that language choice is irrelevant by any means. There are trade-offs.
[/]

Of course there are trade offs. My point was simply to state that if you cannot enumerate the exact reasons why writing code in a particular language, and using particular language features that aren’t available in other languages, then you are not qualified to make the statement “X is faster than Y”. That’s because C++ being inherently faster than C# is a myth. Writing the same logic in either language will produce fairly similar results in regards to performance; unless you are specifically taking advantage of things that are impossible to replicate in C#.

[]
Generally speaking, across an application, C# is slower than C++, ranging from 2x to possibly many times slower…
[/]

This is untrue. C# is compiled into IL, IL is compiled (at runtime) into machine code. There are certain things that the runtime does that makes it slightly slower (array references are bounds-checked for example - though scoff at this all you want, but this feature has removed a metric crapload more critical (and potentially security related) bugs than C#'s lack of constness has added). However, for the most part, the machine code produced by a .net assembly will be very similar to that produced by C++. The biggest performance hit is the time it takes to warm up - but this only affects startup times (and the first time a method is invoked) but can be completely eliminated by using a tool such as nGen.

[]
But UE4 is meant to push the bleeding edge. Potentially losing a factor or 2x or more off the top of a program just based on your choice of language before you write any code at all is a discussion worth having.
[/]

As I said before; C# is not a good choice for the core engine and certain sub-systems such as collision detection, physics simulation or rendering. That’s because these are general systems (that don’t require per-game modification) and that are maintained by a team of expert developers who have the time and energy to optimize them, all day, every day. Many other systems, the kinds that a gameplay programmer, tool developer, or AI developer would write are not performance critical. Giving them a leg up in productivity and correctness is worth a slight performance hit - hell, while this figure is absolutely incorrect, I’d even say a 2x performance hit is more than worth it. Remember: these systems do not need to be executed many times in a frame.

And what if, one day, they do need to write something performance critical? They can still certainly jump into C++ and make their modifications that way.

[]
There are no inherent stability advantages or disadvantages inherent to either language, except for garbage collection. The good and bad of GC in a real-time application is a big topic. It’s also not a trivial issue. GC cycle hitches in Unity are a real issue.
[/]

Safety Features:

  • Array bounds checking
  • Better type safety
  • An exception system that developers aren’t embarrassed to use
  • No raw/dangling pointers
  • Requirement that variables be definitely assigned before access

OO Features:

  • Interfaces
  • Better enums
  • Lack of multiple inheritance (I’ve yet to see a proper use-case of multiple inheritance in C++, except in the case where classes with only pure virtual methods are used to emulate interfaces). This especially holds true as the programming industry, at large, now discourages heavy use of inheritance in favor of composition-based OO strategies.
  • Arguably better generic type system. C++ templates are glorified macros, while generics in C# are baked straight into the runtime. 90% of cases where C# generics can’t emulate something that you can do with C++ templates are unnecessary in C# - such as traits. Furthermore, generics in C# do not affect the size of the assembly, nor the time it takes to compile.

Runtime Features:

  • Proper reflection - which includes instantiating generic types at runtime. Yes, reflection can be emulated in C++ though heavy use of templates, but this adversely affects compile times as well as runtime performance.
  • Type safe dynamic code generation via expression trees

Other Features:

  • Unicode (UTF-16) is baked straight into the framework and requires no additional thought. The existence of a string primitive (and lack of support of C-style strings) removes complexity and increases compatibility with third party code.
  • The existence of a delegate type. This, yet again, can be emulated in C++ though clever use of templates and other features - yet, delegates are a first class citizen of the .net world.

Productivity Features:

  • Much, much (much much much much) faster compile times
  • Visual 's C# support, combined with ReSharper, destroy any toolset of any language I have come into contact with. Ever.
  • The way in which the compiler handles errors (C++ errors, especially linker errors, can be quite cryptic)

[]
The expressive power of C++ as compared to C# allows for significantly more elegant and powerful code architecture. Slate in UE4 is a good example of this. In-fact the entire Unreal Object system is a living breathing example of the type of architectural expressiveness allowed by C++ that would never be possible in C#.
[/]

C++ is hardly more “expressive” than C#. C++ is a hodgepodge of features that, with dedication and discipline, can be cobbled together into sensible code. Most of the time, however, these “expressive” features of C++ are simply used to emulate features that are inherently available in C# and other .net languages. Slate is some sort of odd subset of C++ that cleverly uses some of C++'s unique features (such as C++'s obscene list of overloadable operators) to create a programming experience that is some kind of imitation of a C# like language combined with a declarative DSL.

Furthermore, it may have been advantageous for Epic to have created an actual, outside-of-C++, DSL for slate layout files. Creating DSLs is incredibly easy to do in C#, especially with tools such as Antlr - and if you combine them with the dynamic code generation features of C#, they can have the same performance characteristics of straight-up managed code.

Also, what do you mean by:

[]
the ability to do full static analysis
[/]

?

You can statically analyze C# pretty easily; and, in fact, it is much faster and less error prone to do so.

I don’t know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it’s something that i think most people still don’t get it, C++ didn’t replace anything, it’s Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day… so can be happy… yes, right now :stuck_out_tongue:

I really recommend to learn C++ thru, because without that knowledge you won’t be able to go deep in to the engine and extend thru it’s borders… which was the same with UE3,2,1 for licenced users

[=;17996]
Games to be specific,

P.S.
The only sources on C++ you need:

  1. Bjarne Stroustrup - Programming: Principles and Practice Using C++
  2. Bjarne Stroustrup - The C++ programming Language 4th edition
  3. Andrei Alexandrescu - Template metaprogramming

In that order, study them, and you’ll will be flying.
[/]

Wow you totally missed the point of me easing into that post didnt you, I knew someone would be offended. None of those will tell me about UE4 C++ in specific so I have to learn 2 fold, which Im not complaining about by the way! For Engines Im not going to argue but as a gameplay programmer I feel the language complexities and learning new languages is a huge barrier holding me back which is why Blueprint is great since it focuses on math and not syntax but ofcoarse as always thats glossed over and I get called a noob. For an industry where things change all the time we do tend to find ourselves locking things down, if it wernt for the great physicists challenging the status quo we wouldnt be where we are today, I’ll leave you with that thought because you continue your religious mantra (Im used to dealing with zealots).

Basically I dont feel bound by an underlying language, engineers might need to do that but honestly thats why I use third party engines, because I want to make games not the technology and Im sure there are people wanting to make technology so more power to them. I just hope they dont get caught up in making technology to lose sight of what it was they wanting to do to begin with. I agree with eblade too, any language can be used poorly that even includes visual languages, my goal is to make people aware that game design actually goes outside the bounds of any programming language and runs much deeper in the fabric of the cosmos and that mathematical concepts transcend syntax.

[=;18197]
I don’t know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it’s something that i think most people still don’t get it, C++ didn’t replace anything, it’s Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day… so can be happy… yes, right now :stuck_out_tongue:

I really recommend to learn C++ thru, because without that knowledge you won’t be able to go deep in to the engine and extend thru it’s borders… which was the same with UE3,2,1 for licenced users
[/]

I think we’re mostly disputing the people who are saying C++ is the end-all be-all of everything. Personally, I don’t know anything about C# (other than submitting some bug fixes in some tools, I’ve never had any reason to learn it), but I know a whole lot about Python, PHP, Unrealscript, Javascript, and a lot of other things that I’ve had reason to use. I use the tools that get the job done, but I’m rarely the guy deciding what those tools should be for a product. And I’m really certain that there are very good reasons why people don’t just write everything in C++. :slight_smile:

[=eblade;18203]
I think we’re mostly disputing the people who are saying C++ is the end-all be-all of everything.
[/]

And other people disputing those who saying that C++ is terrible of a choose for game play use… which it isn’t :stuck_out_tongue: UE4 API in C++ are not much diffrent from UE3 UnrealScript, other the fact it is C++ it’s feel the same and it’s faster.

[=MonsOlympus;17720]

Ahh thank you that is extremely helpful. My main concern is Blueprint Classes and calling Blueprint functionality from within C++, I would prefer to keep those calls all C++ native and override in Blueprint. I think its similar to what you are saying about data objects but in this case its class references because of the need to call functionality, even if I cast I still need the class of Blueprint to call the appropriate function. I was having some issues calling through C++ into the blueprint layer but that may just be a project specific issue. With the Archetypes to explain that, is that you would have to:

  • Create the class for the archetype compile.
  • Then open the editor and create the archetype.
  • Copy the reference to the asset to the clipboard close the editor and copy it into Uscript.
  • Then recompile with the asset reference linked so you could access the archetype.

This is what creates the interdependency and if we are modifying blueprint callables or *native implemented events * I cant help but see us running into issues pretty quickly.
[/]

Yeah, that archetype method is what we generally use in fortnite, but basically without the 4th step. We avoid having asset references from C++ to Asset, so that step #4 is usually “open a different asset in the editor and point it to the new blueprint”.

Refactoring blueprint events and functions can be a bit complicated. Luckilly, there are some pretty handy redirectors built into the engine. Here’s a few examples of how you do this kind of refactoring, from our defaultEngine.ini file.



+ActiveClassRedirects=(OldClassName="FortGameInfoBase",NewClassName="/Script/FortniteGame.FortGameModeBase")
+K2FieldRedirects=(OldFieldName="BuildingActor.ReceiveDestroyed",NewFieldName="BuildingActor.OnDeathServer")
+TaggedPropertyRedirects=(ClassName="FSM_AIProjectileThrow",OldPropertyName="InitialAccuracy",NewPropertyName="InitialAccuracyMax")
+K2ParamRedirects=(NodeName="/Script/BlueprintGraph.K2Node_CallFunction", OldParamName="FortMissionLibrary.SpawnMissionItemPickup.MissionItemData", NewParamName="MissionItemDefinition")


Using redirectors you can set up a situation where the old blueprints will fix themselves automatically on load, and then eventually you want to resave the blueprints to make the changes “stick”. It’s basically the same way that data redirectors work.

[=;18214]
And other people disputing those who saying that C++ is terrible of a choose for game play use… which it isn’t :stuck_out_tongue: UE4 API in C++ are not much diffrent from UE3 UnrealScript, other the fact it is C++ it’s feel the same and it’s faster.
[/]

I must have missed those posts, Ive seen alot of highlighting of issues with C++ that people tend to overlook. The API still relys heavily on the base C++ syntax which is why Im saying that there are complexities that wernt there before and ofcoarse its faster in terms of computation, not production capacity which entirely depends on the programmers. I will always be of the opinion that just because a person knows C++ or an API for that matter doesnt make them a good game designer, thankfully we have blueprint otherwise we would be leaning heavily on a community that has a very ingrained ideology that anyone who doesnt know their language must obviously know less then they do, nothing against the guys at Epic and Im not going to single anyone out but even they do it (granted they might actually know more ;)).

The point is that C++ is just a tool, we use it, it doesnt elevate anyone to some higher level on its own, the concepts behind the language were around long before the actual syntax took shape and there are reasons why the syntax can seem obscure at times because things have been shoehorned in. Newer languages can see the mistakes that older languages have made and improve upon them, Im not going to say anyone is right or wrong but we need to compare them to know what works and what doesnt. Every single time I mention the innate complexities of C++ I get shrugged off, without fail, It would just be nice for people who like C++ to tell us about their issues with the language too from a more experienced perspective but as eblade said its rare to hear people who work with C++ criticize it and Im going to bet that it isnt because the language is perfect because I can say without a doubt it certainly is not.

[= Zeigler;18243]
Yeah, that archetype method is what we generally use in fortnite, but basically without the 4th step. We avoid having asset references from C++ to Asset, so that step #4 is usually “open a different asset in the editor and point it to the new blueprint”.

Refactoring blueprint events and functions can be a bit complicated. Luckilly, there are some pretty handy redirectors built into the engine. Here’s a few examples of how you do this kind of refactoring, from our defaultEngine.ini file.



+ActiveClassRedirects=(OldClassName="FortGameInfoBase",NewClassName="/Script/FortniteGame.FortGameModeBase")
+K2FieldRedirects=(OldFieldName="BuildingActor.ReceiveDestroyed",NewFieldName="BuildingActor.OnDeathServer")
+TaggedPropertyRedirects=(ClassName="FSM_AIProjectileThrow",OldPropertyName="InitialAccuracy",NewPropertyName="InitialAccuracyMax")
+K2ParamRedirects=(NodeName="/Script/BlueprintGraph.K2Node_CallFunction", OldParamName="FortMissionLibrary.SpawnMissionItemPickup.MissionItemData", NewParamName="MissionItemDefinition")


Using redirectors you can set up a situation where the old blueprints will fix themselves automatically on load, and then eventually you want to resave the blueprints to make the changes “stick”. It’s basically the same way that data redirectors work.
[/]

That is just amazing, I have been looking over the document you linked and the asyncronous stuff does seem promising, its certainly concepts I havent worked with before but Im hoping they dont turn out to add too much complexity. These redirectors sound like they could really help with the possible issues of linking C++ and Blueprints so I appreciate you taking the time to talk about these, I honestly had no idea these were even there so I’ll pass this information on to the other programmers on the team also, they might be able to make more use of the C++ end of things than I can currently.

Im guessing by the removal of the 4th step we are talking as in the GameModes how we can link to classes within the editor from a blueprint but we can link to either C++ or Blueprint Classes for Pawn, Controller, etc.

[=;18197]
I don’t know why you guys still writing walls of text about something irrelevant. For now we got C++ because it easier to hook up right now, C++ always been in unreal, simply not accessible for mare mortals until now (it’s something that i think most people still don’t get it, C++ didn’t replace anything, it’s Blueprint that replace both UnrealScript and Kismet). But as there source code people can implement support for any language they wish for, there already people doing C# bindings even with editor integration, you can even recreate UnrealScript, i bet some crazy person will do that one day… so can be happy… yes, right now :stuck_out_tongue:

I really recommend to learn C++ thru, because without that knowledge you won’t be able to go deep in to the engine and extend thru it’s borders… which was the same with UE3,2,1 for licenced users
[/]

Extending the borders of the engine? How many AAA multi-million dollar developers do we have on this forum? I doubt 99% of people could really make any use of the source code. I’ve been coding in C++ for 14 years and I’ve built game engines, there is nothing wrong with Java or C# in fact it’s been great to prototype engines with LWJGL and I never came across a difference in performance when switching to C++. I do so because the amount of resources available is staggering compared to resources in C# and it would make life hell constantly trying to reinvent the wheel.

It doesn’t matter about having knowledge of low-level interactions with hardware and memory management, we are in this to make games right? Not engines!..

Whatever get’s the job done quickly the language is just a tool, if people are serious about making games. They’ll leave their pride outside the room, an art pipeline alone for a AAA game is enough to make teams of 10 or 20 sweat horribly.

[=;18245]
Extending the borders of the engine? How many AAA multi-million dollar developers do we have on this forum? I doubt 99% of people could really make any use of the source code. I’ve been coding in C++ for 14 years and I’ve built game engines, there is nothing wrong with Java or C# in fact it’s been great to prototype engines with LWJGL and I never came across a difference in performance when switching to C++. I do so because the amount of resources available is staggering compared to resources in C# and it would make life hell constantly trying to reinvent the wheel.

It doesn’t matter about having knowledge of low-level interactions with hardware and memory management, we are in this to make games right? Not engines!..

Whatever get’s the job done quickly the language is just a tool, if people are serious about making games. They’ll leave their pride outside the room, an art pipeline alone for a AAA game is enough to make teams of 10 or 20 sweat horribly.
[/]

Did anyone saying here you need to rewrite UE4 or something? People acting here like C++ is something terrifyingly hard and time consuming, in reality engine APIs is no different from seem in other UEs, it feels like using UnrealScript just it’s C++… and thanks to that you can do anything unlike it was in UnrealScript, which also required C++ to go beyond things. And it also got same object management and garbage collection. Blueprint missing something which is in APIs? just bind it with child class which you can use in blueprint and there you go… you exteded borders of this engine already… and it actually easier then making Kismet nodes in UnrealScript :slight_smile: And not to mention all i did is recommand, not command people

But again there no point of argueing really, if people hate C++ so much that they even don’t what to try it and want to use C# or anything else… no problem, there people already doing even C# editor integration for that and i bet they are not AAA ( that have AAA reviews by definition? :p), and there JUST one person who works on JavaScript support for , over time i bet where will a hell lot of plugins for lot of stuff for others to use, extending borders of this engine