[=Gigantoad;134709]
How about gameplay programming? You know, opening doors? I brought the example up before, including the usefulness of blueprints. You never adressed it.
[/]
Sure, some very trivial tasks like door opening, light switching on/off can be done via blueprints and I agree with this. To a gameplay I was rather referring as AI, game logic and the likes. Not to very trivial tasks as opening/closing door.
[=timconwell;134689]
I meanā¦seems pretty clear that a larger portion of the anti-C++ debate comes from people who donāt primarily program in itā¦so, letās help them make it their go-to language. Right?
[/]
I donāt think there is an āanti-C++ debateā. Thereās an anti-āC++ is the best for everything everywhereā one though.
[=The_E;134724]
I donāt think there is an āanti-C++ debateā. Thereās an anti-āC++ is the best for everything everywhereā one though.
[/]
True, that was a poor choice of wording. Just, wow, Iāve been involved with internet forums for so long, mostly involving gaming starting back with original EQ. After so much time, the patterns are always the same. Debates rage on not so much about right vs wrong, but about perspective. Like in a yeah youāre right but not in the right way. If here got together for beers, in about 20 minutes would be on the same page since youād have body language and tone of voice to aid the discussion. But failing those aids, the debates drag on, never end, and little is ever accomplished to justify the effort.
Just, thereās usually a point where the dead horse has been beaten so much that the ābeatersā have nothing else to hit but each other. So, letās not go there, better productivity to be had elsewhere.
[=;134722]
Sure, some very trivial tasks like door opening, light switching on/off can be done via blueprints and I agree with this. To a gameplay I was rather referring as AI, game logic and the likes. Not to very trivial tasks as opening/closing door.
[/]
So you contradict yourself.
[=;129511]
If I have option a - run 200% faster (at least) and option b - run 200% slower (at best), I use option a - every time.
C# doesnāt give you anything, takes virtually everything from you. Why would I want that?
[/]
Clearly, you do not use the fastest option every time, and for good reason. Guess what a large part of any game consists of? Trivial stuff like that. Not to mention you can do a lot less trivial things in blueprints and get away with it, but I wonāt even try to convince you of that.
[=;129511]
C# doesnāt give you anything, takes virtually everything from you. Why would I want that?
[/]
You answered your own question. Just substitute C# with blueprints, which both serve the same purpose.
[=;134438]
Iām in AAA industry not in mobile thatās why I would never ever drive my Ferrari in such place. It is simply not my kind of place, as Iām considering myself and the work I do as AAA and not mobile as the picture shows.
[/]
Good for you. How many of the rest of us are making AAA games? I for one am definitely not. I donāt have millions of dollars to throw around and I likely never will. That probably describes most of the people here.
[=;134488]
P.S.
Iāve been using C++ for over a decade now. Nothing beats it, especially in game industry.
[/]
Iāve been using it for something like 16 years and I still think performance is a bad reason to code an indie game in C++. I would probably use C++ for the engine of any sizeable game I make, but it would be for its compatibility with libraries, not for performance. Even then, if the game is sufficiently large, Iād use a scripting engine for game logic.
Itās also worth noting that Carmack once seriously pondered the idea of writing a game engine in Haskell. Not just the scripting stuff, but the whole game. As much as I donāt like to make āappeal to authorityā arguments, I would say Carmack probably knows a lot more about performance than you.
[=;134100]
Macros, are used for code reflection (RTTI) and code generation. I have no idea, why you jumping on macros. C++ doesnāt have any build in decoration semantics for class, functions, properties, etc.
[/]
Macros can be used for code reflection - there are better ways. Itās not 1989 any moreā¦
[=furrykef;134935]
Good for you. How many of the rest of us are making AAA games? I for one am definitely not. I donāt have millions of dollars to throw around and I likely never will. That probably describes most of the people here.
[/]
Thereās actually a funny foot note on that. AAA games arenāt doing very well. hereās just one story:
The notion that AAA game developers would use C++ only because of performance while ignoring development productivity is actually hilarious in that context. You can bet that AAA studios will be the first to use lighter scripting wherever they can get away with it.
Hell, if the existance and importance of Blueprints in UE4 isnāt convincing enough, listen to what they do in the SnowDrop engine:
https://wwwā¦com/watch?v=-hWGbwo0Q4E
[=Gigantoad;134980]
The notion that AAA game developers would use C++ only because of performance while ignoring development productivity is actually hilarious in that context.
[/]
C++ more productive than C#. Period.
UE4 C++ 10x times more productive than normal C++ and 20x times more productive than C#.
Here the graph:
&stc=1
[=;135057]
C++ more productive than C#. Period.
UE4 C++ 10x times more productive than normal C++ and 20x times more productive than C#.
[/]
Absolutely. Especially since there is no C# in UE4 which makes it fairly unproductive.
A comparison with blueprints would make more sense.
[=;135057]
C++ more productive than C#. Period.
UE4 C++ 10x times more productive than normal C++ and 20x times more productive than C#.
[/]
Do you have actual data supporting that graph, or did you just make it up based on your preconceptions?
[=furrykef;134935]
Carmack probably knows a lot more about performance than you.
[/]
Sure, and I tell you even more - Iām nowhere near the league Carmack is in. Period. Most likely never will be.
This is not the point.
Also when I said ānothing beats C++ā I didnāt just mean performance. I meant flexibility, power, portability, with C++ YOU ARE UNRESTRICTED. Period.
[=Gigantoad;134980]
The notion that AAA game developers would use C++ only because of performance while ignoring development productivity is actually hilarious in that context.
[/]
C++ isnāt used just for itās performance. It is used because gives you unlimited possibilities. Performance with C++ youāre getting for free.
For :
[]
flexibility, power, portability, with C++ YOU ARE UNRESTRICTED. Period.
[/]
This is pure fantasy/hype/nonsenseā¦
There is no such thing as āunrestrictedā and there never ever will be.
What DOES exist in reality, are ārelationsā between āconstraintsā and ārequirementsā.
Every language has itās own set of real-world constraints.
Every game has itās own set of requirements.
If your requirement-set easily falls well within the boundaries of a languageās set of constraints, then you would be āeffectivelyā boundless in what you need to accomplish - this would create a āsensationā of unlimited-power/flexibility - which is only a feeling, and not a true description of reality - an is entirely ācontextualā - meaning, it exists within the ārelationā between what you want to accomplish (a gameās requirements) and what you are able to accomplish (a language/platformās constraints).
[]
Yeah, I get it. It looks like mobile market to me and Iām in AAA industry not in mobile thatās why I would never ever drive my Ferrari in such place. It is simply not my kind of place, as Iām considering myself and the work I do as AAA and not mobile as the picture shows.
[/]
Nothing to do with mobileā¦
Iāll describe the āintendedā analogy:
Crowded-area = all non-scripting tasks that are going on (rendering, physics, AI, etc.)
Available room to move = the CPU-clocks available for scripting.
Slow-moving vehicle = all game-logic using a scripting-engine
Fast-moving vehicle = all game-logic using C++
Meaning:
You can drive a Ferrari in a crowded-area, but you would not benefit much from it - you could drive as fast as possible in that environment just as well with a Fiesta.
You can code game-logic in C++, but you wonāt benefit much from it - your code would run just as fast written in a scripting-language, given that any game-logic code would probably be āwaitingā MOST OF THE TIME for other NON-game-logic-code to completeā¦
Many people here with years of AAA game experience have already given you real-world examples.
ALL AAA games use a scripting language and a scripting-engine - with no apparent (or even in-any-way āmeasurableā) performance-penaltiesā¦
If anything, MOBILE and NON-AAA games are actually the ones that could suffer from a scripting-language - as they are more resource-constraint, so the same scripting-environmentās resources would constitute a larger-portion of the overall system resources available (!)
If anything, AAA games are the ones in which a scripting-environmentās resource-cost would be MOST NEGLIGIBLE (!)
They tend to have much more intensive GPU-work, more/larger-textures, more complex shaders, etc.
Plus, they tend to target faster machines with more/faster CPUs and more/faster-caches/ram - and as of yet it is still difficult to take advantage of all the multi-cores of machines like that - itās an on-going research these days/past-few-years.
And so in such machines running AAA games, you tend to have much more āidleā CPU-cycles for a scripting-environment to take advantage ofā¦
So, it seems you got it all completely 180-degrees backwardsā¦
And as for productivity, weāre talking about āgame-logicā, which is ***ideally ***NOT done by software-engineers.
As you could see in the Snowdrop Engine, most of the benefit comes from being able to quickly iterate and prototype new ideas, optimally by as many people in the production as possible. A close friend of mine actually worked on that exact project ( Clancyās āThe Divisionā) at Massive in Sweden for almost 2 years, as a creative-director - and he has some programming-background and is very technical. His impression was that the free-flow of ideas and free-experimentation capability was the single strongest factor in making a quality game.
So, to conclude:
C++ for game-logic-scripting ESPECIALLY FOR AAA GAMES (!!!), gives you little-to-no advantages, and costs you A LOT by raising the barrier-to-entry for MOST of a productionās personnel, keeping them from being able to experiment/iterate on game-logic ideas quickly - Hence Blueprints was created by Epic (to mimic what engines like Snowdrop haveā¦)
A scripting-environment is not much different then a Visual-Scripting environment - except for potentially being a little faster, and much more flexible, while keeping the barrier-to-entry still very low - here is a real-world proof:
[=EruArnold;135540]
This is pure fantasy/hype/nonsenseā¦
There is no such thing as āunlimitedā and there never ever will be.
What DOES exist in reality, are ārelationsā between āconstraintsā and ārequirementsā.
Every language has itās own set of real-world constraints.
Every game has itās own set of requirements.
If your requirement-set easily falls well within the boundaries of a languageās set of constraints, then you would be āeffectivelyā boundless in what you need to accomplish - this would create a āsensationā of unlimited-power/flexibility - which is only a feeling, and not a true description of reality - an is entirely ācontextualā - meaning, it exists within the ārelationā between what you want to accomplish (a gameās requirements) and what you are able to accomplish (a language/platformās constraints).
Nothing to do with mobileā¦
Iāll describe the āintendedā analogy:
Crowded-area = all non-scripting tasks that are going on (rendering, physics, AI, etc.)
Available room to move = the CPU-clocks available for scripting.
Slow-moving vehicle = all game-logic using a scripting-engine
Fast-moving vehicle = all game-logic using C++
Meaning:
You can drive a Ferrari in a crowded-area, but you would not benefit much from it - you could drive as fast as possible in that environment just as well with a Fiesta.
You can code game-logic in C++, but you wonāt benefit much from it - your code would run just as fast written in a scripting-language, given that any game-logic code would probably be āwaitingā MOST OF THE TIME for other non-game-log-code to completeā¦
Many people here with years of AAA game experience have already given you real-world examples.
ALL AAA games use a scripting language and a scripting-engine - with no apparent (or even in-any-way āmeasurableā) performance-penaltiesā¦
If anything, MOBILE and NON-AAA games are actually the ones that could suffer from a scripting-language - as they are more resource-constraint, so the same scripting-environmentās resources would constitute a larger-portion of the overall system resources available (!)
If anything, AAA games are the ones in which a scripting-environmentās resource-cost would be MOST NEGLIGIBLE (!)
They tend to have much more intensive GPU-work, more/larger-textures, more complex shaders, etc.
Plus, they tend to target faster machines with more/faster CPUs and more/faster-caches/ram - and as of yet it is still difficult to take advantage of all the multi-cores of machines like that - itās an on-going research these days/past-few-years.
And so in such machines running AAA games, you tend to have much more āidleā CPU-cycles for a scripting-environment to take advantage ofā¦
So, it seems you got it all completely 180-degrees backwardsā¦
And as for productivity, weāre talking about āgame-logicā, which is ***ideally ***NOT done by software-engineers.
As you could see in the Snowdrop Engine, most of the benefit comes from being able to quickly iterate and prototype new ideas, optimally by as many people in the production as possible. A close friend of mine actually worked on that exact project ( Clancyās āThe Divisionā) at Massive in Sweden for almost 2 years, as a creative-director - and he has some programming-background and is very technical. His impression was that the free-flow of ideas and free-experimentation capability was the single strongest factor in making a quality game.
So, to conclude:
C++ for game-logic-scripting ESPECIALLY FOR AAA GAMES (!!!), gives you little-to-no advantages, and costs you A LOT by raising the barrier-to-entry for MOST of a productionās personnel, keeping them from being able to experiment/iterate on game-logic ideas quickly - Hence Blueprints was created by Epic (to mimic what engines like Snowdrop haveā¦)
A scripting-environment is not much different then a Visual-Scripting environment - except for potentially being a little faster, and much more flexible, while keeping the barrier-to-entry still very low - here is a real-world proof:
[/]
Utter, utter nonsense. I disagree with what youāve said.
[=;135601]
Utter, utter nonsense. I disagree with what youāve said.
[/]
I stand in awe of your detailed and eloquently argued rebuttal, sir.
[]
And as for the C++ code examples? You simply donāt understand what Bjarne is trying to explain.
[/]
Since Iāve been reading his writings, listening to his interviews/talks, and watching him lecture for many many MANY hours these past few months, I think I have a very clear understanding on his outlook by now. I would be far more comfortable betting on THAT then of your obscure/vague statements of āmy misunderstanding himāā¦
He has been frustrated by the situation of C++, fully acknowledging itās problems and dangers (even giving real-world examples, like with the NASAās space-probe that failed to reach Marsā¦) and openly discussing them (which is something that I never saw you do), and has been for many years now, and is very excited about the C++11/14 standard that he and his colleagues have been working on this past decade or soā¦
He talks about how compilers from different vendors produce artifacts that are incompatible with other vendorās compiles, mainly due to political-factors, and how bad this is for .
He talks about the issues of āresource-ownershipā that is SO EASY to get wrong, and why RAII, move-semantics and smart-pointers are so important and how they circumvent many of the potential pitfalls relating to resource-ownership (and thus why STLās ācontainersā and other such āhandlesā as he calls them, as so crucial for the future of C++).
He talks about how the current implementation of Templates creates a situation in which compiler-errors are so overly verbose, obscure and unintelligible, and why āConceptsā are so important to resolve that (by providing point-of-use checks/error-reporting), and why he pushed for āconcepts-liteā for C++11/14 (ultimately unsuccessfullyā¦ they will be a C++14-TR, and a C++17 featureā¦).
He talks about how inevitably SLOWLY the industry is going to adopt the new standards, due to how slowly academic-curriculum and their reading-materials change, and the huge mess of ālegacy codeā laying-around that people would have to suffer through in the next few decades, and what can be done to ease this pain. While the new standards donāt brake backwards-compatibility in existing code, the DO BRAKE existing LITERATURE and CURRICULUMs, which will be a grate difficulty for C++ in the decade to come.
He talks about how SMALL the standard-library is, compared to ācommercialā languages, due to the fact that C++ has no owner and hence no financial-backing, and what a disastrous-effect that has had on the immense FRAGMENTATION of disparate-incompatible solutions to common recurring use-cases (like file-system, sockets, GUIs, etc.), and how this is finally starting to be addressedā¦
He talks about how the existence of the ā#includeā model has made compile-times go through the roof, and how there is no standard-description of avoiding that, and how badly C++ is in need of a āmodule-systemā (which is in the works for C++17).
He talks about all of these things (and many more) that are very well know inside-and-outside of the C++ community, and make it look-bad and rightfully-so, things that you are NOT even considering.
So yeah, Iām sorry, but Iāll take the words of the wordās biggest C++ standards contributor and inventor of the language, much more then I would take some anonymous obviously-overly-enthusiastic poster on some forumā¦ (No offenceā¦)
Really, given the enormous plethora of issues plaguing the C++ language, that are so well-known and wide-spread, and so often talked about, you would have to be willfully and intentionally blind, deaf and mute to ignore all of them and still admire itā¦
Kinda like this:
Really, the more your current attitude persist, the more you are making a fool out of yourselfā¦
So just stopā¦
[=EruArnold;135622]
Really, the more your current attitude persist, the more you are making a fool out of yourselfā¦
So just stopā¦
[/]
It is you who is making fool of yourself by writing something that long and pointless. So perhaps you should stop.
[=EruArnold;135622]
Since Iāve been reading his writings, listening to his interviews/talks, and watching him lecture for many many MANY hours these past few months, I think I have a very clear understanding on his outlook by now.
[/]
Months? Wow, boy, I program with C++ over a decade now, had personal conversations with Mr Bjarne, etc etc, and you, you, someone who cannot grasp concepts says that after a few months of watching some videos you understand? Let me tell you, you understand very little and there is pretty huge chance that this will not change in future.
Seriously, months? You are just making huge fool of yourself saying such things and showing how limited you are if you are really thinking that way.
Just a heads up; lets stop calling each other fools and continue the discussion in a more mature and friendlier manner please.
[]
Hence Blueprints was created by Epic (to mimic what engines like Snowdrop haveā¦
[/]
kismet is more old that Snowdrop and node scriping even more old.
Look, , everything youāve said so far may be perfectly true and may work perfectly fine for you. But that doesnāt mean that your insistence that people who operate with different standards and priorities are wrong is correct too. You got your approach, we (and, as far as we can tell, a good part of the industry) have ours.