My team comes from such engines as Unity, where 90%+ of the work is all in code. This is our new Unreal 4 workflow, hopefully it will help you out in answering your question:
Prototype every mechanic and function via Blueprints
Playtest and make adjustments
List all actors and functions that are shared between players, enemies, core item stats, etc
Begin to script those the actors and functions in #3
Modify Blueprints to allow modification to the code parameters (i.e. movement speeds, jump heights, damage values, etc)
Playtest and make adjustments
Create Blueprints for all aesthetics (doors, lights, etc)
Since you can build near complete games with blueprints without writing a single line of code in C++, I’m wondering how people decide when to make something a native implementation or not?
As Zortalas as said, you can make just about anything in Blueprint, and I would highly encourage it as it is VERY easy to visually debug any issues that may occur. With that being said, there are a few instances where you may prefer to use C++. For instance, I’m a programmer by trade, so I can visualize complex mathematics in C++ much easier than I can in Blueprint, however it is still possible to do in Blueprint. As well, I believe BP is compiled to bytecode, which depending on the underlying framework (which may be C#, as I’ve seen a few files within the source) may be just as fast as C++, so choosing BP or C++ may not matter as far as execution speed is concerned.
The last main determining factor may be the most important. Not all of the functions available in C++ are available in BP. For instance, changing a Vector into a Rotator, and vice-versa. In C++, the functions are FVector.Rotation() and FRotator.Vecter() respectively, while BP would require you to figure it out manually (and use more nodes in the process). Personally, for the above example, I create the function in C++ and make it BlueprintCallable so that all of my Blueprints can make use of the function as if it were built-in.
I’d concur with this, especially the last point. If you have something that can be done quite simply in code, but with difficulty in BP, or even just more complex functionality that will be used quite often, we tend to get the programmers to make a native implementation that can be called from blueprint by the designers.
To be perfectly honest the decision how are you going to split game logic between C++ and blueprint is very arbitrary, and really depends on your personal preferences or your team. This is how I do it (and I would recommend this workflow to everyone else, as I believee it encapsulates best both of blueprints and C++):
Define bases classes in C++. From my Example it would Character, Item, Power (like spells, or special attack), Weapon, Effect (persistent object that affect actors in some way). You got the idea.
I create basic implementation of each class in C++. Those implementation do not contain any game mechanics specific code. At the start each class is pretty small. For example Effect class implements Ticker, events (like applied, removed, tickEverFrame, TickOnSet. etc.
Then I implement specific game mechanics inside Blueprint which derive from specific object.
Back to C++ code. I refactor blueprint implementation into functions, in each object, or into Blueprint Library functions that are not dependent on specific object.
This way I can simplify how Blueprints are implemented, as common tasks, are encapsulated inside specific functions, that simply can be dropped inside blueprint and set parameters. I refactor blueprints once I have implemented functions in C++.
For me it is all about making things easier and faster. Some tasks are easier made in C++. Some complexities of blueprint implementation can be easily hidden in C++ and exposed as single function.
C++ have compilation time, which makes iteration slower. Blueprint compile at instant can be ready for testing very quickly.
Well you probably won’t understand what I’m talking about anyway, so I give very simple example:
Actually you don’t really have to chose: every time you need to create a custom item with custom behaviors and properties you better create a Class for it. That class will then be available in Blueprint for you to use it via visual coding.
Basically in UE4 (like in any other tool supporting visual coding) the moment you need to create a real project with many complexities you’ll find yourself in need to write a c++ class, otherwise your Blueprint network even for a simple enemy becomes such a huge net that you won’t be able to manage it.
Can anybody confirm that Blueprints are functioning in-game just as fast as C++ and do not affect performance? I mean, after having been compiled to binary code?
I agree with you on this. However I think there is a Blueprint node called MakeRotator from Vector, which can be used to create a Rotator from a Vector.
That was not said by Epic devs. Not sure what was exactly said, but it had nothing to do with Blueprints as well, it was about scripting engines being generally slower than native code. The number of 10 is unreasonable high, depending on scripting language of course, but the number is rarely bigger than 3-4 times.
This is a good post. However, Blueprints are compiled to byte code. Epic has stated it is about 10 times slower than C++ or more (which indirectly means it is slower than .net C# & Mono C#)
It depends. Basically as a rule of thumb if you plan to add any non-programmers to your team (or already have a few) then you want to expose gameplay centric classes to Blueprints. I personally have been coding in C++ for many years so I am quite comfortable there. So here is my workflow:
Create a Native class in C++. This way, if something ever pops up in the profiles and is not as fast as I’d like, I have the freedom to easily transition it into C++. That case hasn’t happened yet and I hope it does not. But I have come across code samples that I might find useful already written in C++. So it is an easy matter to just drop the function in C++ and expose it to Blueprint. I do not expect to have very many Native classes. Just classes for core concepts like Character, Power, Attributes, and so forth
As of UE4 Version 4.1.1, You have to define structures in C++. There is some other functionality that Blueprints may not easily have access to. These things I may drop into C++
For the most part I try to do all the gameplay code on the Blueprint side. The C++ side of the game is really just there mostly as a ‘service’. It may perform some routine AI task like search for an Enemy and so forth. This allows me to iterate fairly quickly on the game since I do not have to close the Editor too extensively beyond setting up Core Framework.
Sorry to resurrect but could someone comment on why would blueprints be so slow in comparison to C++ ?
I always thought that BPs are being translated into C++ on compile and that there is a one to one match between a BP and the C++ class it creates in the background. Isn’t that so ?
Does BP need to interpreted at runtime instead of pre-processed into a fully-fledged, optimized C++ class ?
What exactly causes this huge jump in performance ?