I still play CRPG mod for M&B 
good times.
I have spent the past couple of days reading through this very long, sometimes-interesting, and mostly-tedious thread, and would like to share a summary of what I see.
*( For the record, I know C++, C# and Python, and have experience using all 3 and more )
*
I just started watching a course I bought from 3DBuzz, about developing plugins for UE4, and was thoroughly-horrifiedâŚ
They spend the first HOUR AND A HALF, about 25% of the entire course, just composing the most basic of scaffoldsâŚ
It involves a huge-mess of stuff:
- A very complex folder-hierarchy that one MUST manually create and maintain (doing things from within visual- brakes everything and it doesnât work)
- A custom file that is used to be a manifest, which you MUST manually create and fill-out, with tons of cryptic data.
- A custom C# file that is ONLY used to guide their custom build-tooling - and again, you canât use VS properly for managing that, as it needs to be injected into a solution-file that UE itself needs to re-generate.
- Tons of headers you must #include, that must manually-match the ones you already noted in your C# file.
- IntelliSense doesnât even work - not for the MANDATORY C# file, and not even later for the C++ code - it CONSTANTLY brakes-down, as well as having tons of âsquigglyâ lines all-over the place, because VS canât reason-about the solution, since the entire reference-mechanism is heavily-macroâed and relies on an external custom build-tool. So, you CANâT see you mistakes (as you canât trust non-squiggly-lines) AND you donât have IntelliSense at all AND you have to re-compile all the time AND it takes a lot of time each time you do, which would more-often-then-not result in it eventually failing, and giving you errorsâŚ
They actually had to stop the video when compiling, and fix things on-camera when itâs done trying to compile, and do so without any help from VS, which resulted in them having to go through ~7 cycles of such non-sense in a row, just to get a foot in the door of UE4 ans seeing their show-upâŚ
What a complete nightmareâŚ
How can anyone in their right-mind could possibly fathom such a process as being anything even remotely-reminiscent of being ââproductiveââ - is completely beyond meâŚ
The fact of the matter is, that using a heavily-templateâd and macroâed flavor of C++, with a custom and non-standard build-process that brakes all of VS strengths, just for doing simple-to-moderately-complex non-performance-critical game-logic, makes ZERO pragmatic-sense - itâs a huge encumbrance, and adds such a productivity-overhead that is very difficult to justify FOR THAT TASK.
Let me tell you what it REALLY is meant for, if yourâe actually interested:
Big Game-Studios (!)
When you have a staff of hundreds, many of them experienced C++ programmers, and you have a huge budget to invest in paying them for a few years, than having something like a code-base of UE4 all accessible for them to study and build-upon, is a god-sent - it very-well may save them many millions of dollars and a few years development of their own equivalent (if they had had to start from scratchâŚ) - This is very welll worth the 5% revenue, and Epic knows that, and thatâs why theiy are charging it - THIS is the REAL target-audience of this code-base!
For the rest of us, it SHOULD be - at best - a ânecessary-evilâ of LAST-RESORT, when ALL else fails with Blueprints/other-scripting-languages, either in terms of flexibility or performance-critical parts - end EVEN-THEN, it would be for just a small number of pain-points, that should be relatively rare.
As for the people posting here on this thread:
On one camp, there are those who are content with the current situation, and looking forward to writing their games in C++.
For the most part, it seems to me that NONE of them have had ANY experience using higher-level languages, so they can only speak out of what they know, and not what they donât know (thatâs just how the human-brain works - itâs not magical, itâs simple physics). It seems that anyone that has posted here that has experience in both C++ AND higher-level languages, either has trouble justifying using C++ in the context of coding âmostâ general game-logic for âmostâ games, or is actually in the second camp that is NOT comfortable with the current situation, and is actually willing to leave his ego aside and acknowledge that publicly.
I would further sub-categorize this first camp into 3 sub-camps (DISCLAIMER: Much scorn on this part⌠SorryâŚ):
-
The Noobs : People who are new to the whole fiasco, and just know that âAAA games are written in C++â⌠They just regurgitate mantras, without necessarily knowing what they are talking about (I can live with those - they are cuteâŚ)
-
The Wannabees : People who have little-to-no experience in C++, who are just comparing d***-sizes, and shouting in favor of the biggest-one - they want their Ferrari⌠Itâs Fast⌠Itâs Sexy⌠(This is so immature⌠But a little amusing⌠I can live with those also, because it is easy to disregard themâŚ)
-
The Zealots (These are the worst of the threeâŚ): People who actually have experience using C++ and know it well. They obviously like very-much the fact that they have full-access to the source-code in their preferred language. The thing is, I am having real trouble buying their âactâ, as if they are âactually enjoyingâ the prospect of coding in C++ against a heavily-templateâd and macroâed API - whatever it may be - you have to be clinically-masochistic to enjoy that, and the only way I can explain that otherwise, is a very deep-state of âdenialâ on their part. And that is actually understandable - Unreal Engine 4 is by-far the best thing that has ever happened to the game-industry - period, full-stop. - and the prospect of having full-access to the C++ code of the engine and the editor, is nothing short of âsexyâ (IN THEORY! In âpracticeâ, it is VERY painful⌠Hence the âdenialââŚ). Probably, some barely-conscious-part of them secretly wishes there were better alternatives, but since itâs UE4 and is so cool, and since they already know C++, their conscious-mind can-not acknowledge that fact⌠It just doesnât register⌠Their entire âidentityâ and self-esteem is by now very-much wrapped-around their amazing-skills as C++ developers, and they can not hear anything jeopardizing their world-view in which C++ is the ultimate-language, and their proficiency in it makes them grate. (These I just hate⌠They would have their time better-spend at a shrink, then posting long-comments in forumsâŚ)
As for the second camp - I would call them âthe pragmaticâ or âthe reasonableâ or at all âthe rationalâ:
These people know what C++ IS and what it IS NOT, what it IS FOR and what it IS NOT FOR, and also know what managed-languages ARE and what they ARE NOT, and what they ARE FOR, and what they ARE NOT FOR. Some of them explain it remarkably well (These I like a lotâŚ) - but some less then othersâŚ
These people (myself included), are rightfully and justly frustrated, for nowâŚ
They KNOW in their âgutâ that there is currently a missing piece in the UE4 puzzle, and they canât wait to get the gap filledâŚ
They are anxious to start learning to use UE4, but not wanting to have to go the deep dive just yet into the C++ (which is currently a huge pile of messâŚ)
My suggestion for them and myself is:
Start learning what you can about the Blueprints and experiment a lot - by doing so, we would get comfortable and familiar with the API. This would take many months anyways, and by that time, hopefully, there would be language-bindings for one of your preferred managed-languages, and perhaps even a better build-story for C++, with more/better starter-projects (for plugins and other use-cases) and perhaps even a wizard/GUI-tool for managing build-definitions, as well as faster compile-times and/or a more fully-featured âlive-reloadsâ story⌠(Hell, we might even get IntelliSense working for usâŚ)
Maybe Epic-engineers would even jump-the-wagon at some-point and go for re-factoring much of their macros into more powerful and concise templates, using some of the new C++14 features in the next VS release⌠(DreamâŚ)
In general, though, I think learning the API and the event-model is going to be beneficial down the line anyways, as it is going to be useful for whatever language one may ultimately choose to use to develop UE4 games with (of which there are bound to be plenty in years to comeâŚ)
And remember - these are STILL very early-days for UE4 - Things WILL get better for in the years to come - I have no doubt!
Cheers!
[=EruArnold;103107]
I have spent the past couple of days reading through this very long, sometimes-interesting, and mostly-tedious thread, and would like to share a summary of what I see.
*( For the record, I know C++, C# and Python, and have experience using all 3 and more )
*
I just started watching a course I bought from 3DBuzz, about developing plugins for UE4, and was thoroughly-horrifiedâŚ
[/]
Not sure that bashing C++ in UE4 is justified when you look at development specifically. From what I gathered, itâs still very much a work in progress. To develop your game you donât need to develop your own plugins.
Or in other words, if the engine was developed in C# that doesnât mean that development would necessarily be so much easier. It could still be a mess.
Intellisense not working is mostly an issue of Visual unable to handle a huge code base like that. VisualAssist does a much better job.
I vote to have this thread locked. answered it. Itâs just a waste of internet ink now.
[=Bino;103156]
I vote to have this thread locked. answered it. Itâs just a waste of internet ink now.
[/]
But where would we then get our drama from? Soap operas on TV just wonât do.
In any case, to add my two Zimbabwean dollars for those who feel intimidated by C++, hang in there baby, itâs just a programming RPG - just keep playing, you will eventually level up.
[=EruArnold;103107]
âŚ
[/]
Actually, to the intellisense part - it works for me, raise the number in VS which is responsible for the limit of memory used by intellisense.
To the c++ part, actually I didnât have problems yet, I was using the old engine (udk) a lot, so Iâve got experience with UScript too,and I must say that, if you know the api, c++ is not so much difference.
To the compile times, yep they are pretty long, but if youâve got a decent pc itâs not that long, and epic is working on compile times so you can expect it to be better in the near future.
[=EruArnold;103107]
I just started watching a course I bought from 3DBuzz, about developing plugins for UE4, and was thoroughly-horrifiedâŚ
They spend the first HOUR AND A HALF, about 25% of the entire course, just composing the most basic of scaffoldsâŚ
It involves a huge-mess of stuff:
- A very complex folder-hierarchy that one MUST manually create and maintain (doing things from within visual- brakes everything and it doesnât work)
- A custom file that is used to be a manifest, which you MUST manually create and fill-out, with tons of cryptic data.
- A custom C# file that is ONLY used to guide their custom build-tooling - and again, you canât use VS properly for managing that, as it needs to be injected into a solution-file that UE itself needs to re-generate.
- Tons of headers you must #include, that must manually-match the ones you already noted in your C# file.
- IntelliSense doesnât even work - not for the MANDATORY C# file, and not even later for the C++ code - it CONSTANTLY brakes-down, as well as having tons of âsquigglyâ lines all-over the place, because VS canât reason-about the solution, since the entire reference-mechanism is heavily-macroâed and relies on an external custom build-tool. So, you CANâT see you mistakes (as you canât trust non-squiggly-lines) AND you donât have IntelliSense at all AND you have to re-compile all the time AND it takes a lot of time each time you do, which would more-often-then-not result in it eventually failing, and giving you errorsâŚ
They actually had to stop the video when compiling, and fix things on-camera when itâs done trying to compile, and do so without any help from VS, which resulted in them having to go through ~7 cycles of such non-sense in a row, just to get a foot in the door of UE4 ans seeing their show-upâŚ
[/]
To add more to the drama.
I completely disagree with all this. Visual was never good for C++ to begin with, Intellisense for C++ was always sloppy at best. And huge code bases (regardless of software type), are always bringing visual to itâs knees.
Custom Build Tool-Chain is here to allow easy portability between platform, to build naively on the platform you happen to develop your game.
Is the Build Tool Chain very easy to use ? No. Is it hard. You must have never used make, if you think that UBT is nightmare (;.
For added benefit os portability, I could even use make, if I had to.
I honestly donât see where you have problem. Or Unreal Engine is the first game engine you had work with, using C++.
I can tell, itâs easiest to use from engines I have used so far.
As a side note. I find C++ in UE4 much more confotable to use than UnrealScript in UDK.
I can honestly say, I could never get anything done in US ;).
[=;103564]
I honestly donât see where you have problem. Or Unreal Engine is the first game engine you had work with, using C++.
I can tell, itâs easiest to use from engines I have used so far.
As a side note. I find C++ in UE4 much more confotable to use than UnrealScript in UDK.
I can honestly say, I could never get anything done in US ;).
[/]
I have to agree with inside on this one. Since using UE4, I have only worked on the C++, I rarely use blueprints (except for my 2D game, and that was an experiment to only use blueprints, I much prefer the C++ side) except to prototype some basic functionality before I write it up in C++.
Just to mention C/C++ compilers are more than 30 years old and are very highly optimized!
Why would you develop a game and graphics stuff in javascript/C# or in any other language that is not as highly optimized as a compiler?
Also if you use some good practices developing in c++ is not memory management.
Both C# and c++ has their disadvantages but if you need more power you will decide to use c++.
[=;103668]
Just to mention C/C++ compilers are more than 30 years old and are very highly optimized!
Why would you develop a game and graphics stuff in javascript/C# or in any other language that is not as highly optimized as a compiler?
[/]
Modern optimizing JIT compilers like Javaâs HotSpot and LuaJIT offer performance that can often match or even beat statically compiled code. Add to that no waiting for compiles and live in-game debugging tools that scripting languages can offer and scripting languages often make sense for development.
Not every game needs AAA FPS type performance. Do you think a game like should be written in C++?
[]
Also if you use some good practices developing in c++ is not memory management.
Both C# and c++ has their disadvantages but if you need more power you will decide to use c++.
[/]
A good software developer should have many tools in his toolbox and know how and when to use each.
[=;103564]
To add more to the drama.
I completely disagree with all this. Visual was never good for C++ to begin with, Intellisense for C++ was always sloppy at best. And huge code bases (regardless of software type), are always bringing visual to itâs kneesâŚ
[/]
I think this is important for many to understand, one can find complaints about this on other frameworks going back some time. For Epicâs sake, sometimes feel as if this particular issue is directed wrongly at them. OtherwiseâŚ
Seems like there are plenty of arguments to go around no matter which side you prefer. I have my preference and itâs not C++, but whatâs the point of complaining if we are using UE4? Itâs not like programming games is easy in any language. If those here are looking to build in UE4, then C++ is what you have and blueprints which IMHO are about as innovative and advanced as it gets. There was some talk from some developers about adding more language interfaces, Iâd recommend finding those threads for those who are interested to lend support and suggestions since the debate over languages will never be settled. In an effort to be neutral on the subject, there are probably better outlets in helping to add new features than an attempt to change anotherâs opinion.
Could be that this thread may have a happier home under General? Maybe itâs more fitting in this group, but this is a topic that generates more anger than being informative.
[=jCoder;103692]
Not every game needs AAA FPS type performance. Do you think a game like should be written in C++?
[/]
Well 10-15 years ago a style game was written in c, for a good reason.
[=jCoder;103692]
A good software developer should have many tools in his toolbox and know how and when to use each.
[/]
Itâs true but if youre making a game that must run on any device and it needs the best performance you may consider to write it in c or java.
But itâs your choice what language you use. I prefer to write my things in C++ or C#.
[=jCoder;103692]
Modern optimizing JIT compilers like Javaâs HotSpot and LuaJIT offer performance that can often match or even beat statically compiled code. Add to that no waiting for compiles and live in-game debugging tools that scripting languages can offer and scripting languages often make sense for development.
[/]
Eh?
[=;103668]
Just to mention C/C++ compilers are more than 30 years old and are very highly optimized!
Why would you develop a game and graphics stuff in javascript/C# or in any other language that is not as highly optimized as a compiler?
[/]
Did you even read the thread? Performance has been discussed to death already, and wasnât even one of the reasons Sweeney cited.
[=;103719]
Well 10-15 years ago a style game was written in c, for a good reason.
[/]
The last I checked, itâs not 10 or 15 years ago.
All Iâm really waiting for is for JetBrains (who do absolutely fantastic IDEâs and Plugins) to finish working on their C++ IDE, and for Epic to allow us to generate MAKE files for different IDEâs. In the meantime, if you have VSPro, you can buy a great called Visual Assist X from WholeTomato. It certainly offsets the pain a little.
[=furrykef;103722]
The last I checked, itâs not 10 or 15 years ago.
[/]
If by that you mean to say that was written in C++, youâre wrong. It was done entirely in blueprint.
Stop crying and get to work. Seriously.
âWhy C++ for Unreal 4?â - Why are you crying? If you donât like it, fix it or use something else.
Unreal Engine 4 is one of the best engines and a Engines with all possibilities that we have to day needs c++.
And by the way⌠for game programers is c++ one of the main languages what you learn at the universitiy.
So if you want create a game just4fun⌠you donât need the unreal engine 4 or you use blueprints⌠more then easy as unreal script 
I donât see any problem with the engineâs C++. Honestly, C++ is a fact of life in professional grade game dev. At some point or other you will need that level of access and performance. Do you always? No. But when you do it needs to be there, or it potentially means grinding your entire project to a halt, because without that access you have zero capability to get it fixed yourself, and are totally at the mercy of the engine developers fixing what might amount to a very specific problem.
Experienced devs will understand why thatâs not something they even want to touch.
Further I donât really see the problem with the split between BP and C++. If you need more BP functionality - expose it via C++. If itâs too slow in BP, same thing, etc. Thatâs not really an unusual paradigm for any engine - almost all of them feature some sort of scripting functionality which must have underlying engine code exposed to it. Itâs the same thing here.
If you want some specific scripting language for another reason, thereâs facility for doing that via plugins.
I agree that most language-debates are futile, but I am frustrated that most people here donât even understand what is being debated here, and mistakenly think this is a language-debate - it is not.
Let me say it loud and clear so people wonât have the slightest chance of continuing to misunderstand:
âUnreal Engine 4 - like ANY modern game engine - MUST have been programmed in C++ (!!!)â
No one in their right-mind would fathom coding something of this magnitude and quality in any other language! (at least not yetâŚ)
THAT IS NOT WHAT IS BEING ARGUED HERE, SO EVERYBODY PLEASE STOP REACTING AS IF IT IS!!!
What IS being argued, is something entirely different - âWhat should be the ideal way of coding GAME-LOGIC?â (!!!)
Let me give some analogies:
Networking-code is very difficult to do right (by ârightâ I mean fast, efficient and flexible).
So some smart people got together and coded a library called Zero-MQ (a.k.a: zmq, or 0mq), which implements the lower-levels of networking-code in an extremely optimized way, and exposes a pretty high-level API for system-engineers to be able to build whatever network-topologies they could even need (publish/subscribe, request/response, in-process, inter-process, etc.). After they had done so, many developers started to use it (by âuseâ I mean, âbuild-uponâ), instead of starting from scratch and implementing lover-levels themselves. Whatâs the benefit? You get many man-hours of development and many years of experience, already coded-in for you so you donât have to go through the pain of making all the past-mistakes all over again. Now, since it is C++, it is VERY fast always, and also very easy to âbe wrappedâ and âbounded-intoâ other languages. Nowadays, there are upwards of 40 different languages binding to it! 40!!! All the way to the âslowestâ ones like Python and Ruby⌠And applications using it in these last 2 languages are, guess what, âevery bit as fast as systems coded in C++ that are using itâ (!), at least in terms of networking-performance and resiliency/stability. The idea is not new at all - the execution still happens at C++ native-speeds, but the input/output of the execution is routed to another language - whatever it may be.
This is how you get the best of both worlds.
I recently had performance issues with a server I was developing in Python, and I ended up solving it by using PyZMQ, which is a thin-layer of python around a ZMQ C++ compiled core. I went one step further, and optimized the encoding/decoding process by using another such solution, called Messagepack (a.k.a: msgpck). There is another example of such arrangement - you got a highly-optimized very target-focused library that does one thing and does it well, and you got thing-layered wrappers around it, that âbindsâ it to other languages (last I checks, msgpack had around 17 language-bindings) - itâs fast, itâs efficient, itâs easy-to-use, even when you are using it from a âslowâ language.
Other examples may include:
- simplejson - A Python package, that is a C-extention - is also C++ code compiled to efficiently decode/encode formatted text, and wrapped in a thin layer of Python.
- The Qt UI-Toolkit - Python has 2 binding-packages (PySide and PyQt) that are equally as performant as their C++ counterparts, because guess what - THEY ARE THE SAME CODE COMPILED IN C++ UNDERNEATH, AS ONE WOULD USE FROM A C++ APPLICATION(!)
âŚ
(I could go on forever with such examplesâŚ)
Now, imagine people in the ZeroMQ forums, or the Qt forums, arguing about why it was good that the library was âwrittenâ in C++ and not PythonâŚ
Then you would get how I feel when reading such posts hereâŚ
Can you see where the confusion lies? Can you see why I am saying that ââŚthis is not what is being argued hereâ?
Itâs a total misunderstanding of the entire story.
Itâs NOT about what langue to âwriteâ a game-engine, it is about what other languages it should be âbound-toâ (!!!) HUGE DIFFERENCE (!!!)
I ended-up being able to code my server in Python (using ZMQ and msgpack), in a FRACTION of the amount of code and in a FRACTION of the time it would have taken me to do in C++ (using the same libraries without the binding-layer), and guess what - IT IS SCREAMING FAST (!!!) EVERY-BIT AS IT WOULD HAVE BEEN CODED IN C++ (!!)
So, I say again - and please get it through your skulls already:
Itâs NOT about what langue to âwriteâ a game-engine, it is about what other languages it should be âbound-toâ (!!!)
95% of game-logic code is non-performance-critical (at the very least) - most-if-not-all of the code that IS performance-critical, has already been coded in C++ by Epic⌠Physics, collision-detection, rendering, particles, path-finding⌠Even AI stuff is on the way and will get better GUIsâŚ
Most of game-logic is a huge pile of âglue-codeâ to put-together these awesome already-performance-optimized systems in all sorts of new and exciting ways - the essence, if you will, of the game-play.
And NO, you DO NOT need C++ to write glue-code - there are MANY languages which are leaps and bounds superior FOR THAT TASK(!) then C++, no way around that, itâs just a fact.
And NO, for 95% of it is just NOT performance-critical by itself - you would NOT notice it AT-ALL, even if you REALLY-TRY with advanced profiling-toolsâŚ
It is just a clever use of resources, and much more efficient and pragmatic to do that - it is simply silly not toâŚ
And just one note to finish this up:
Epic engineers themselves has already stated on multiple occasions (I can provide referencesâŚ), that âcompiledâ Blueprings are roughly 10X âS-L-O-W-E-Râ (!!!) then coding the same in pure C++(!) Why? Because of the way their data-model is designed: To fit a Node-Based GUI. They are NOT (I repeat âNOTâ(!)) âcompiledâ down to C++ native code(!) They are compiled to a binary format that is then (wait for itâŚ) âINTERPRETEDâ (yes, you read it correctlyâŚ) by the UE4 run-time⌠And guess what - NOBODY NOTICES(!) You know why? Because it DOESNâT MATTER(!!!) It is non-performance-critical pieces of logic, that use otherwise âidleâ cpu-cycles (for the most partâŚ). NOW I want somebody to tell me why this same thing can-not be accomplished by a X2 (or even X3) âslowerâ programming-language run-time such as C#, or (god-forbidâŚ) PythonâŚ
There is simply NO reason whatsoeverâŚ
Absolutely no reason, and some people already understood that and are working to fix the situation - please support them in any way you can, and stop posting BS posts about irrelevant-arguments that are not even being madeâŚ
[=EruArnold;103892]
Itâs NOT about what langue to âwriteâ a game-engine, it is about what other languages it should be âbound-toâ (!!!) HUGE DIFFERENCE (!!!)
[/]
So, then use a to provide a different binding?
[]
Epic engineers themselves has already stated on multiple occasions (I can provide referencesâŚ), that âcompiledâ Blueprings are roughly 10X âS-L-O-W-E-Râ (!!!) then coding the same in pure C++(!)
[/]
That doesnât jive with you saying it needs to have other bindings - most scripting languages are even slower than 10x less than C++. By a lot.