This is a general question about structuring UE4 projects, so I didn’t think it was suitable for UE4 Answers
I have found in my (very limited) trial of Unreal, that mixing Blueprints and C++ causes more issues that it’s worth. Specifically, because you can’t reference BP classes in C++, as soon as you start putting functionality into BPs you are very limited in what you can achieve in C++.
Am I missing something? Is there some text based way of circumventing the one way flow of information?
Failing that, should I pick one and if so, what do people recommend. Before starting, I would have assumed I’d have felt more comfortable in C++, being a coder. That said, iteration time is so much faster with the blueprints and it seems a shame to lock out non-coders at such an early stage.
Anyway, general thoughts on how to mix and match C++ and BP and what people finds work for them as a good divide.
One of the best methods I find are that you are able to create the variables and components etc you need in C++ for your actor and make that variable or component exposed and editable in Blueprint. Meaning that you are able to manipulate the variable/component from both C++ and BP whenever you want.
For example if I wanted to declare a number that I want to later edit in either C++ or BP I would put something like this:
There is tons of helpful information on the Wiki and documentation
EDIT:
My advice would be to play around with the project settings. Maybe start off a small project with just BP and then maybe try mixing them up and then make your own mind up to which you would prefer
I would try and divide the line between blueprints and c++ by thinking about two different “users”, the Programmer and the Game Designer. Only put in to C++ what the Programmer needs to be in C++, while the rest should go in to blueprints for the Game Designer. Pretend your Game Designer can’t code.
Imagine you’re making monsters for an RPG, you’ll have lots of different types of monsters but they are all going to have a lot of the same basic functionality and properties. Functions such as OnDamage, or OnMove and properties like Health, XP for killing them, drops etc. The Programmer shouldn’t care too much about what kind of monster he is coding, the C++ should keep things generic while exposing properties and functions so the Game Designer can change the health, xp, etc and hopefully even some of the behavior of the monster just by using blueprints. The Game Designer can then balance, tweak and create new content inside the editor easily while the Programmer can move on to more important things like fixing bugs or working on networking.
Netizen I really like your example and would have to agree 100%. Even if you are doing both if you are able to separate you mind away from the task and look at it from a program and or a game designer you will save yourself a lot of trouble later if you end up adding more people to your team. It will also be good practice if you ever decide to join a team. Well said
Basic core class stubs can go to C++ and maybe some time-sensitive functions/processing. All gameplay code goes in blueprint. If for some reason a blueprint routine where to impact performance I’d move it into C++ (but that hasn’t happened so far). In the end, I do not expect to see much code at all in C++ for my game
If I might add to 's thread, I am also trying to bridge some of the basic conceptual elements of Blueprint vs C++. If one is aiming to mix Blueprint and C++, should projects always be started as a C++ project? Or is it possible to add C++ functions into a Blueprint library such that the library can be shared with pure Blueprint users?
