Hello!
Speaking from my personal experience on Fortnite, I suspect while there are probably some good best practices, the split on how much is done in C++ and how much is done in blueprints is going to be a per-project decision, accounting for staff, project type, etc.
Fortnite’s dev team includes plenty of different disciplines from traditional gameplay programmers to level designers to artists and everything in between. We’ve structured our game fairly similarly to how ArcainOne was describing. We have native C++ versions of most all of our core classes, each with varying degrees of functionality exposed to blueprints. In essence, anyone on the team can possibly work on various aspects of certain features depending on what has been exposed. Our game has tons of building actor pieces at any one given time, which also require certain rules to be followed to work properly, so we have a lot of the core logic parts about how our buildings behave, can be placed, etc. inside C++ with appropriate hooks for the content guys to be able to fiddle around with. Every single actual building piece that shows up in our game though is actually a blueprint extending from one of the native C++ classes. That pattern allows us to avoid hard-data references directly in C++ and allows the content guys to tweak all kinds of settings very easily. Our code knows only that it is going to spawn a building actor subclass when the code to allow a player to build something executes, but doesn’t explicitly care what its mesh is, etc.
As we’ve worked on the project, we’ve used the C++/blueprint interaction in numerous ways. In some cases, our engineers intentionally expose a very custom/catered set of functions and variables for content creators to use in an effort to either a) speed up their workflow so they don’t have to care about gritty details, or b) guard them against intricacies of a particular feature that might be error-prone or confusing or otherwise require more technical/programming knowledge than the intended user might know. As an example with our buildings again, an artist probably doesn’t care about the math involved in placing the building piece down if his task is to make new walls with different meshes/effects. We expose those things as properties so the artist can just quickly sub things out in the details view and not have to worry about any innards. Similarly, sometimes our content guys find they are constantly repeating operations and ask us if we can make them a C++ version to just do things behind the scene for them (they could also make re-usable pieces in blueprints as well, if they wanted). On the flip side, on something like our traps, the content creators wanted a lot more control, so the C++ side only manages some basics that all traps have in common and then the blueprints themselves can implement all kinds of custom logic, if they so choose. We provide some common things (spawn projectile, etc.), but the content creators can largely do what they want in the event graphs.
Given the make-up/experience of our team, we tend to have our engineers mostly in C++ and most of our content creators in blueprints. The engineers sometimes also do things in blueprints, depending on the feature in question and their level of comfort using them (some are still learning!). In all, I think it will come down to the make-up of your team and project demands. There’s nothing wrong skewing one way or the other, though honestly I’d have a hard time going back to a purely C++ project now given the convenience and power of a mixed project. Blueprints are not as performant as native C++, as has been mentioned, but neither was the old UnrealScript in UE3. If I was working on a feature in *Fortnite *that was massively performance-reliant or computationally very intense, I’d probably put it in C++. If it’s just one-off gameplay logic, I’d have no problem putting it in blueprints. In the same way that games were made entirely in UnrealScript in UE3/UDK, games could be made entirely in blueprints as well.
