I was just wondering ..the people who are using c++, are you doing everything in c++ or are you mixing it up whith blueprints. And how do you decide wich parts are in c++ and wich parts you keep in blueprint.
I do c++ base classes with BP Children.
I mostly only code the concrete things that wont change in c++ or things that need to be highly efficient and then let BP call them.
but structs/enums i do exclusively in c++ they’re easy to do for anyone and much better
2 Likes
I do almost exclusively Blueprints. I just HATE compile times. (and compile issues)
The only exceptions I make are:
- Heavy math - it looks too complicated in BPs as soon as you get more than 10 operations;
- Collection handling - looping through and modifying arrays - it looks awful;
I usually make a BP function library that gradually transfer to a C++ function library and base empty (with no overrides) C++ classes to later use if needed. (rarely needed though)
This is the time to note that I work mostly on prototypes, RnD and personal projects so I’m yet to reach proper production phase in any Unreal Engine project.
I’m guessing I’ll need to transfer some stuff to C++ when optimizing but I wouldn’t do that before profiling extensively.
I would take @Auran131 advice for structs and enums and remember:
You can expose anything from C++ to BP but you can’t expose anything from BP back to C++ so act accordingly - base classes on C++ game-play on BP.
2 Likes
Any successful C++ project is going to be a mix. You may be able to make a game 100% in blueprint without too many problems (depending on scope), but doing the same thing as pure C++ is just madness.
I agree with Auran’s suggestion for structs and enums being in C++ almost 100%. Migrating them can be a real pain. There are also some issues with making changes to blueprint structs that seem to cause blueprint issues not caused by similar changes to C++ structs.
UI’s a huge case where you do yourself a disservice trying to avoid blueprint, the Designer is too useful in setting those up. It’s not terrible to have a C++ class between UserWidget and your blueprint, but it’s not always needed and it’s easy to insert later.
Content hookups are another really important thing to setup through the creation of blueprints. Asset references should never be coming from code. Content or ini files. That way when files are deleted or moved, the Editor can help you keep your project in a working state by making sure the references continue to work (or warning you about ones it can’t do anything about like ini’s).
For building actual systems, it often depends on the who the user is or what sort of behavior I want. I will often do mission scripts in blueprint because I want the iteration wins of not shutting down the Editor. Or if the logic is unique to the gameplay I’ll do that in blueprint.
Something like: Systems in C++, Content in Blueprint.
The trick is recognizing which category what you’re building actually falls into.
1 Like
Everything in C++ except stuff that’s forced to be in blueprints, like UMG layouts, and skeletal animations.
1 Like
here a few stats of my game to give a perspective of how it can work.
my game is now almost 6 years old. its a racing game, it is written entirely in c++ and soon reaches its final state. it has ~ 300.000 lines of code.
- i am using blueprints as dataholders, like datatables, dataassets.
- i am using just 3-4 regular blueprints for gameinstance, gamemode etc. to reference all the dataassets and datatables and have access to these dataholders in code.
- i have >30.000 car meshes that i have to load/unload async on demand at various places in game with a lot of conditions
- i have >70.000 textures for cars i have to handle the same way
- if i have to place manually an actor into the world that uses (c++) code I create a blueprint version just for placing it, the code is still entirely coming from c++.
- my entire audio solution is using FMOD with custom plugins written as well in c++. it would’nt work in just blueprints because of exposed functionality of fmod to blueprints.
- the UI is entirely designed in the UMG widget designer.
- features of this game: custom vehicle simulation, day & night cycle with 26 weather types, custom fog implementation, traffic ai, racing ai, entire campaign with sms system, localization into 6 audio languages and 13 text languages, over 120 menues/screens, dyno for tuning cars in details (adjusting torque curves, tire friction etc.), an extensive customization system that lets you tune 31 cars with over 3000 upgrades per car. internally database like behavior for saving and loading the entire game or just parts of it, different pathfinding algorithms for different purposes (a-star, depth first search) to find different objectives on the routesystem during gameplay, pathsystem to track player progress, 8 different race modes + free roam mode where you can engage on demand roaming around racing ai for a race. a sophisticated unlock system to unlock all these cars, car parts, world regions, special events and races over a quick run through of gameplay within ~10 hours. sponsorships, contract fullfilments, open world discoverable items, shops and races, singleplayer, quick race multiplayer and a lot more.
because of the age of this project it is well optimized with includes, forward declarations etc. even on my old pc an initial compilation of the binaries took maybe 3 minutes, when I change anything in code it takes 3-5 seconds maybe. when I do any codechanges my workflow most often is to not compile for every function but first write down my entire idea and debug later after the first compilation if necessary.
my experience is that first of all source control is best with pure code files. especially when sharing them with other people they can simply have a look at it without even having the project downloaded. in my previous project i started with blueprint everything which was a mess (partially because i was a greenhorn, partially because the code was very complex, like an entire vehicle simulation). then i was transitioning into a hybrid doing the base in c++ and exposing everything to blueprints. sometimes blueprints broke and i had to recreate them, variables were no correctly reset in spawned actors and such things werer really annoying. that could have all been solved since then but even now, there are simple things to break a blueprint by changing something in c++. but if you know these reasons you can avoid them. but even this hybrid got me into a lot of brain overload, because i was searching problems inside the code although some blueprint somewhere overrode it, or didnt call the native function. additionally i hade to handle double the code file amount (c++ and the blueprint version of it) so 6 years ago i write code only in c++. to me its cleaner and the times where i have to prototype a lot of things are over as my understanding of creating a complicated systemarchitecture grew exponentially over time and i don’t have trouble with such things anymore.
also I can highly recommend using VS for debugging, especially with complex game logic i can easily step through every single line of code, i can see what data is in a all variables, i have a great stack on crashes, even during accidentally created infinite loops i can pause the programm and see at which point in code i am.
i can easily ship my game to testers, they send me back dump and crash files and i can see the exact location of a crash in VS with the generated .pdb files.
i would never go back to creating blueprints for code in a large project.
if it is a quickshotted game with simple gamelogic that can be completed by 1 person in 2 months by using blueprint coding I would use only blueprints, then i can skip the initial c++ setup overhead and making everything available in code (like assets).
caveats I encountered by preferring c++ over blueprints:
- there is a reason why it says “c++ makes it harder to shoot you in the foot, but when it does it blows off your whole leg” …or so. my c++ code more often crashes then a blueprint would but that is also an advantage, i can catch bugs early and debug them.
- in blueprints everything has a default value, in c++ when i forget to init a variable eg. in a constructor, it can be annoying to even find this bug
- when using c features (like c-arrays) i blew off my leg more often than i would like to admit, just because i was too lazy to use the TArray<> type (or other safer standard/unreal types) … but that can be avoided obviously.
1 Like
I’m exactly the opposite of @Shmoopy1701.
I don’t do game development, I do broadcast with really tight turn around times and a lot of last minute changes.
I do everything I possibly can in blueprints (even math, unlike several other posters, including things like solving the quadratic equation and basic kinematic equations). Only when something is not possible in blueprints - some very weird use cases, like getting the exact times of montage trigger points, or simply setting blueprint variables by name, do I fall back to C++.
But my UE usage is very different than a game developer.
1 Like
Thx a lot for taking the time for explaining. I’ve just started with unreal engine and c++. So i thought in the beginning that templates was the way to do it.
I’m making a AR App and will encounter exactly the points you guys mentioned.
I solved my first mayor obstacle and that was renaming structs. it crashed every blue print existing.
To avoid this in the future, i’ve build a substystems that do all the runtime math and is owner of temp cache and a single truth broadcast. all the blueprints are using only this 1 payload. ( i dont know if this will get me in trouble when the app grows in complexity and size).
Arpawn is orchestrator.
Initialization of the components.
and than every component has a bind blueprint chain.
@apfelbaum @dZh0 @Auran131 @MagForceSeven @Shmoopy1701 @wbd_fred
In light of the recent revelations about the UE6 roadmap, I wouldn’t put too much effort in BPs if I were you.
I wouldn’t go as far as suggesting you get your project in Fortnite but it is an option…
its sad news but you can always stay on UE5 or the inevitable forks forever.
I don’t object as much to this news as many people do, but it’s a LONG time coming.
Verse is NOT ready for prime time to start learning. You’re looking at 18 months before scheduled release where you can actually get hands on with a “full” version of Verse (and whatever visual editor they decide to include, if they do that at all). This is the normal course - certainly I could download pre-released versions, but I’m busier actually doing my work in production ready software.
Even then, BP is still available for the first few versions, at least, of UE 6… now you’re looking at probably 2.5 to 3 years or more.
Right now you simply can’t use Verse in anything but UEFN, which I am not using, but our efforts are fully into BPs because that’s what we need, that’s what we’re using for at least years.
(post deleted by author)
Blueprints as like the user-facing configuration area using DataAssets, DataTables, Blueprints with C++ defined variables exposed to then allow the end-user (often me myself) edit things easily and quickly.
Anything visual, I expose so I can tweak and eyeball in realtime.
Anything game feel, I expose so I can tweak and feel in realtime and make fast iterative decisions.
Sometimes I just expose what I need from C++ as nodes too and jam in BP, often for first experiments or to solve the problem at hand, to then convert to C++ as it is much easier to maintain between engine versions.
I use C++ for most everything, including Slate for the UI. Not one spec of UMG when the game is running… Except for a custom cursor.
That doesn’t mean that I don’t create child blueprint classes, but they usually remain nearly empty. As I produce more “content” than “systems” then maybe BPs will take a larger part. I’m trying to find a good place for them in my workflow, for premade actors.
The two, places where I’ve extensively used BP classes, which also coincides with places where my BPs aren’t parented to C++ classes, are for:
- In-editor BP tools to help me author special data that needs a visual representation (i.e volumetrics)
- Editor Utility Widgets (which technically use UMG, but I did say “only Slate when the game is running” hehehe)
Compilation time
Compilation time is a non-issue for me. It is true that it slows iteration speed down, but I feel like iterating too fast starts creating a mindset of “trial and error” that is good for learning, but bad for mastering.
Plus, what time I waste waiting for compilation, I gain easily 10x to 100x in terms of writing speed. It’s so slow to write BP when you have a good IDE and fast typing, that it’s laughable. Unless you speedrun the BP spaghetti and/or buy a ton of auto BP tidying plugins maybe? I haven’t tried.
Furthermore, compilation times create a “cost to trying” which encourages thinking more about your code beforehand, becoming better at executing code in your head, and ultimately better at knowing your codebase.
It also makes you better at translating logs into actual fixes, which is a very, very good skill to pickup for when your game is live! And obviously you learn to make better logs too!
Unsurprisingly, this reasoning in favor of compilation times, is also valid when making a case against abusing LLMs for making code: It makes you passive and reactive, instead of active and proactive.
Ironically, I work alone, but this balance of C++ and BP also works wonder for conflict resolution in version control systems. Although being able to quickly see when you changed what, can also be a godsend in the rare instances when I’ve had to track down a very nasty bug. Like a crash that doesn’t tell you what actually caused it, etc.
Whatever balance strikes your fancy, make sure to only use C++ Enums and Structs. There is no need to worry too much about the rest as there are no bad answers..
(..Although now that BPs are planned to be deprecated if Epic doesn’t change their mind in the face of overwhelming protest, it may be worth starting to pick up textual programming skills instead of sticking to visual programming)