As usual, Im having the Nth argument with my main artis about “next project is a larger RPG and we should use Unreal”, and there are dozens of tutorials about how to implement everything with Blueprint. I agree that Unreal is superior to everything else, but I dont see Blueprint as a tool to fully create a complex game, lets say, Lord of the Fallen.
So, my question is, how much Blueprint and how much C++ there are in AAA games made with Unreal?
rogerdv said:
I agree that Unreal is superior to everything else,
I disagree with that statements. UE has its flaws, but that's not important. You should always use the ideal tool to do given job - slapping UE on everything doesn't make it magically better, easier, etc.
rogerdv said:
So, my question is, how much Blueprint and how much C++ there are in AAA games made with Unreal?
I'm not sure whether any AAA game used exclusively Blueprint - but they were partially used even in Fortnite, Ark or Bright Memory - which used them quite extensively (not really being AAA tough).
I don't know unreal or blueprint, but at a high level view it seems to me you have 2 programming languages for the engine, C++ and blueprint.
Assuming both are turing-complete, you can in theory program everything in either language. The difference between languages is thus about how easy it is to express what you want. The latter includes technical properties as well.
For example, if you need a lot of raw speed and want to exploit problem properties to improve performance, you'll probably end up in a language like C or C++. You can code the same ideas in eg Python to some extent, and it will work, but since the baseline performance of Python is slower, the result will be slower than the C/C++ version. Depending on what exactly you want, this may or may not be acceptable.
As another example, if you are at a high level, connecting big building blocks into a functioning application, then Python is likely going to win. Other (quite relevant!) reasons to chose a language are personal preferences, or knowledge/fluency in a programming language.
To get forward with your problem, you may want to make a list of strong/weak points of both languages, so you can determine where using blueprint is likely better and where using C++ is likely better. I expect overlap in these areas (either language would be fine then). I feel this would give a more solid foundation for your choices than “game X has Y% blueprint” where things like the mentioned overlap, programmer preferences, etc have an influence on the result but are not known.
rogerdv said:
So, my question is, how much Blueprint and how much C++ there are in AAA games made with Unreal?
There is always a mix, but I couldn't give a percentage number. There are a lot of blueprints, and there is a lot of plain C++. Blueprint compiles and ultimately shakes out as c++ code, and ultimately it matters very little what percentage.
Designers and artists fill in a lot of blueprint. If it isn't something you'd trust those groups with, don't expose it as a blueprint, or instead work out an interface that they could use.
Vilem Otte said:
they were partially used even in Fortnite, Ark or Bright Memory
My name is on both of the first two. For both Fortnite and Ark, every creature, weapon, and tool had some amount of blueprint script on them. Programmers provided the building blocks, then everybody built from them. As the games grew designers had a broad base of tools needing less fresh c++ work, although there was still always more to do. Later in development designers were able to build up many creatures and weapons using no new c++ code, building entirely from the library of existing code.
Alberth said:
I don't know unreal or blueprint, but at a high level view it seems to me you have 2 programming languages for the engine, C++ and blueprint. … The difference between languages is thus about how easy it is to express what you want.
Yes. Blueprint is a visual language, c++ is a more traditional language. Both get compiled. Both are used, and more besides.
When something is easier or makes more sense in blueprints, leave it on that side. There are plenty of scenarios where it is easier on the c++ side to just leave certain tasks to the blueprint's code generator rather than hooking it up in c++. I've made plenty of blueprint-accessible functions and simply provided handlers and delegate interfaces rather than doing the work of making a properly asynchronous system in c++, easy since functions are synchronous and expected to be fast, custom events are async.
Similarly, when something is easier in c++, leave it on that side. Plenty of times designers will have a massive set of math they've built in a blueprint and just want a series of math operations based on a few parameters. I can encode the function in minutes when it would take ages to build in blueprint, so c++ is the clear winner there.
Object lifetimes are expressed differently between the two, which is neither good nor bad, just a difference in the two languages. Sometimes it is easiest to rely on the C++ lifetimes of objects, managing them through the way they're processed in code, using them with a lifetime known better by the programmer. Sometimes it is easiest to rely on the blueprint's lifetimes of objects, creating them and reusing them through a series of operations with a lifetime known better by the designer. Both have strengths.
Blueprints are slower to call and work with than C++, and they've also got boilerplate stuff before and after, built-in safety requirements and error handling, and do lots of work behind your back. Sometimes that's a good thing, sometimes that's a bad thing.
Blueprints do a lot of things well, and some things badly. C++ can do whatever you want, but some is difficult or ungainly. Both have their strengths, use them both.
I worked at Tripwire. We went in partnership with Chivalry 2 team. They had tons of blueprint bubbles everywhere running the animation controls logic for each character. For a game that was many players multiplayer, the animation controller would take (I don't remember the number) but well say 1ms-3ms per character. That didn't include anything other than the animation logic per player/character, so other updates to game logic etc. Basically it ran SLOW.
I've worked with designers who request blueprint functionality so they can make their little bubbles and what not to setup in-game quests. Blueprint does have some kind of optimization somewhere that allows you to compile it to full run-time code, or at least I remember hearing about it, that can make it run faster.
In simple terms, an entire game in Blueprint, 3D AAA? No. Impossible. And it would be VERY hard to maintain. I had to oversee designers make so many mistakes and debug their blueprints and they would do so many stupid things. You need a programmer in C++. And there are lots of things not exposed to the blueprint side. You can only use some functionality. I've seen some weird gotchas too. Blueprint running every frame to do long lists of work is what I would say no to.
