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: