Best practices for project architecture when using C++ and Blueprints

Hi Everyone,

I am currently evaluating UE4 for our next project and would like some guidance as to the best practices of when to use C++ and/or Blueprints. I remember reading post about the case for C++ that did the rounds when the engine was released and I think this resonated with a lot of developers, myself included.

But this now seems in contrast to the current documentation and training video trends that are promoting more of a ‘you can do everything in Blueprints’ vibe. I can understand if this is to make the engine more accessible to a wider audience, but is this the recommended work flow for teams that have a mix of C++ engineering backgrounds?

Is there an overview document that outlines best practices for project architecture, that covers C++/Blueprint efficency and productivity tradeoffs, workflow examples with a mix of skill sets in the team, and anything else to look out for, such as collaborative blueprint editing issues and debugging c++ code into blueprint execution etc?


Afaik there is no such guide.

From my understanding and own experience with my own team, the teams with some level of game dev experience and C++ do some prototyping in blueprint and all core systems in C++. C++ is on average 10x faster than blueprint and way easier to understand when it comes to the more complicated logic (as a engineer). I believe Epic’s focus on blueprint based documentation is to appeal to the larger mass of subscribers who are just getting in to development for the first time / indie folk. They probably assume if you have experience you’ll be able to figure out the code on your own (as it mostly was with UE3). My team hasn’t arranged a licensing deal with Epic yet, so maybe they have different support for the larger team licencors as they did with UE3.

In regards to workflow, there exists a diff tool for looking at the blueprint graphs, but not the property value changes. The blueprints are of course uassets so it can get annoying if the files aren’t locked when someone needs to have “ownership” of the file.
You can place breakpoints at bp nodes, but it is way less efficient than typical visual studio breakpoints. The C++ iteration side has improved over the past few months with the hot reload changes. I personally don’t use it as I primary work on plugins and not individual game projects.

Strictly speaking, you can do anything in Blueprints that any standard game developer would need. You can implement custom functionality if you find that the default Unreal Engine functionality is not enough.

Multiplayer is possible in Blueprint too but more ideally suited to C++, as there’s a lot of functionality that’s not currently exposed to Blueprint. If you’re developing for Console, you’ll have to get your hands dirty with code for Multiplayer too, as Blueprint is unsuitable for some use cases that we’ve found.

Blueprint is a bloody powerful tool though, one of the programmers that works with us has 12 years experience at EA, and he would say to use it wherever possible simply because it’s so fast in terms of iteration times. Prototype in BP, move to C++ if you absolutely need to.

Complex Math and computation should be handled in C++ if you do experience performance hits, but Blueprint can keep up in most areas. I like code personally because it can be tidier, but even then I use Blueprints to create discrete classes. There’s a lot of great example content available, ShooterGame being one of the best, which shows the integration and play between BP and C++. If you’re considering the engine, I would expect that you have a look at that.

Premature Optimzation??

A coding guideline exists. (dated to 4.5)

The Blueprint Best Practices has not been published yet. It’s description is “When to use Blueprints vs C++, Dos and Don’ts, tips and tricks, etc.”.

Hopefully both will be updated/ship for 4.7 release.

Also, if you’re unaware, if you go into Editor settings and add a key binding to Blueprint Editor->Generate Native Code(Generate C++ code from the blueprint) you will be able to get an easier idea on how to convert your Blueprint into C++.

I think Hourences videos would give you a better sense of UE4: – The Solus Project
BP and C++
Series 2 part 2 (miss labeled part 1) at around 4 minutes, or jump to 9:20
Series 1 part 3 at 5 minute mark.

Hopefully Epic will invite Hourences to Inside Unreal to give a post mortem after they ship.

thanks everyone, some good info there. Good to see that an offical doc is in the roadmap as well.

It’s a little picky, you have to have the BP open and selected and you’ll get a menu where to save the H and CPP files. Only crash i’ve seen is on really large BPs. If you don’t see menu you don’t have proper context selected to invoke it.

Im not sure how supported it is as BP are converted to a VM bytecode and interpreted from what i understand. (Just select some Nodes, Ctrl+C and than ctrl+v into a text editor to see bytecodes). Either way you’ll see what C++ functions are being called.

What I personally do is create SomeClassBase in code, then have my BP_SomeClass extend that. That way I get to do core stuff in C++ but also extend it via BP functionality. It works quite well. Obviously all of the structs and enums are pure C++ in order to make sure that both C++ and BPs can see them.

hello Structure.

I have a certain design philosophy about UE4 that seems to work very well. My CORE gameplay objects are written in C++. My custom Actors, Pawns, Objects that are going to be utilized by my game. I build these things with blueprints in mind so that a designer can blueprint my core objects and extend them and hook into various exposed events through blueprints without needing to know C++.

As an example one of the systems I designed was an magic effect system. I began by creating an effect object from UObject and making it blueprintable. I added some basic functions such as “ApplyToTarget” and “RemoveFromTarget” that can be implemented in blueprints but also overriden in C++ if I want to extend the C++ object. Now my designers can take that base magic effect object in the editor and create any any effect they want from it and they don’t have to know C++. There are several other objects written in C++ that worry about the details of containing the effects, when and how they are applied, and even replication; but the designer gets full control of what the effect does when it is applied.

So build in C++ to be utilized in Blueprints.

I wanted to make a quick note on the main reason why. In the situation I described above, imagine having over 100 different effect classes in your solution. I personally like to keep my code as clean as possible, so having that many effects (to me) seems WAY more manageable from the editor than in hard coded objects in C++.

Overall when I am building my C++ object I always ask myself (What do I want control of in Blueprints, and How could I make changes to that without C++).


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.

I personal really heavily use the hybrid-way since this is really great to get things from both worlds. Doing code has its downside of course. A bit more downtime, even with Hot Compile (thanks for that it helps a lot) whereas Blueprint sometimes tend to get huge in terms of maintainability.

But anyway I personally think to start off producing framework insensitive systems in code. Meaning such as Game Mode, being Rules, Game States, its commitment and checking, Player State, its managing of certain mechanics of the Player and of course any function and variable that has a more global scope to it, saying having a Actor Type class for abilities that has an IsActive Variable/Function.

But from there I would consider to do the rest in Blueprint and than evaluate what needs to be pushed back. You have something going on that manages some state, lets say a Puzzle System that is very complex and has Controls, UI, Player State, Actor States etc in it? Well do it and build it in Blueprint and than gradually put away contained Systems which you believe remain the same and give you some advantages into code. For instance in my Puzzle I push the Click Queue and Solution Check into Code, but the HUD output of Results I leave in Blueprint, since that can vary from Puzzle to Puzzle.

What I though wanted to add is, that yes you can do everything in Blueprint and I believe you should do as much as you can. It is possible to do so for most everything you need, especially when its more about Gameplay Mechanics and not Framework Systems. Because what Blueprint allows is real rapid prototyping.

And honestly, being a beginner coder, I would say that most stuff I do in Code would be probably faster in Blueprint, since I lack the experience and the knowledge. But since I am learning I really do dig the path to use both.

Similarly I create native C++ classes, from which some BP classes inherit.
I think ‘Architect’ mean something like MVC, MVVM, etc.
I use the UE4 build-in design, MVC.
For data sharing, there are several stores keeping some ‘static data’.
M - Stores
V - Characters, BP Widget, BP Mesh
C - PlayerControl / AIController / Actor (UserWidget, Static Mesh) holding lots of stores, managed classes
Eventually those controllers have complex logic and states, especially the primary PlayerController.
I feel it is difficult to maintain my project now, not mention to adding new features.
I have no clue or guidance that tells me how to do layering a UE4 game project, which make me stop for a month already. :face_vomiting:

1 Like