There are two main considerations when deciding when to use C + + or a blueprint:
- Speed
- The complexity of an expression
In addition to these two factors, there is the complexity of the whole game and the composition of the team. If you have more artists in your team than programmers, you might be using a blueprint that is a lot more than C + + code. Conversely, if there are many programmers on the team, they might prefer to write logic in C + +. And we want people to take a compromise in the middle. In English, the general process is that the content creator creates a particularly complex blueprint, and then the programmer looks at the blueprint and thinks about how to convert a lot of the work into a new blueprint node so that a piece of functionality can be converted into C + + code. A better experience is to use blueprints on a large scale, and then convert them to C + + code when they reach a certain level of complexity that requires an exact description of a function (or when they are too complex for a non-programmer), or when the execution speed indicator is to be converted to C + + code.
Speed
For speed, blueprints are much slower than C + +. This is not to say that performance is very bad, but if you want things that require a lot of computation, or when called at a very large frequency, then you'd better use C + + instead of blueprints. However, it is also possible to use two combinations to meet your team and engineering performance needs. If you have a blueprint with a lot of features, you can put a part of it in C + + code to speed up the run, but keep the rest to ensure flexibility. If the performance analysis results show that one of the actions in the blueprint is time-consuming, then you need to consider porting it to C + + and leaving the rest in the blueprint.
Complexity of
For the complexity of expressions, some things are much easier to do in C + + than in blueprints. Blueprints do a good job in many ways, but some things are not so easy to say with nodes. Manipulating large amounts of data, string manipulation, and mathematical computations of large-scale data are all very complex and not easy to read in a visual system. These things are best done in C + + rather than blueprints, because they are easier to see and easier to understand. Complex expressions are also a reason why a multi-human system is best implemented in C + +.
Example
Because different functions are different in the way they are implemented, some are better in C + + and some are better in blueprint implementations, here are some examples of how C + + programmers and blueprint creators work together to make a game.
- Programmers can create a character class in C + + that defines some custom events, and then blueprints can be used to extend the character class and set the grid and set some default values. The example can see the role control and the enemy's implementation in the Shootergame sample project.
- A base class for a competency system is implemented in C + +, but designers can create specific things by creating blueprints. In the Strategygame example, a turret (turret) base class is defined in C + +, but the flamethrower, cannon, etc. are defined in the blueprint.
- A pick-up, its ' Collect ' and ' respawn ' functions are blueprint-achievable (blueprintimplementableevent) events that can be used by designers to rewrite to generate different particle emitters and sounds. Shootergame and Strategygame have this example of creating a pickup.
Creating a Blueprint API: Tips
There are a few points to note when creating an API that is exposed to blueprints:
- The default parameters are well supported in the blueprint.
1 /**2 * Prints A string to the log, and optionally.3 * If Print to Log is true, it would be visible in the Output Log window. Otherwise It is logged only as ' Verbose ' and so it generally won ' t show up.4 *5 * @param instring the string to log out6 * @param bprinttoscreen Whether or not to print the output to the screen7 * @param bprinttolog Whether or not to print the output to the log8 * @param bprinttoconsole Whether or not-to-print the output to the console9 * @param textcolor Whether or not-to-print the output to the consoleTen */ OneUfunction (blueprintcallable, Meta= (worldcontext="Worldcontextobject", Callablewithoutworldcontext, Keywords ="Log Print", Advanceddisplay ="2"), category="utilities| String") A Static voidPrintstring (uobject* Worldcontextobject,Constfstring& instring = fstring (TEXT ("Hello")),BOOLBprinttoscreen =true,BOOLBprinttolog =true, Flinearcolor textcolor = Flinearcolor (0.0,0.66,1.0));
- Try to write a function that returns a number of parameters and less to return the struct's parameters. Here is a small piece of code to show how to create multiple output pins.
1 " Example Nodes " )2staticvoid multipleoutputs (int32& Outputinteger, fvector& Outputvector);
- It is no problem to add new parameters to an existing function, but if you want to remove or change them, you should discard the original function and add a new one. Make sure to discard this metadata so that information about using the new function is displayed in the blueprint.
1Ufunction (blueprintcallable, category="Collision", Meta= (deprecatedfunction, deprecationmessage ="Use new Capsuleoverlapactors", worldcontext="Worldcontextobject", autocreaterefterm="Actorstoignore"))2 StaticEngine_apiBOOLCapsuleoverlapactors_deprecated (uobject* Worldcontextobject,ConstFvector Capsulepos,floatRadius,floatHalfheight, Eoverlapfilteroption Filter, uclass* Actorclassfilter,Consttarray<aactor*>& Actorstoignore, tarray<classaactor*>& outactors);
- If a function needs to use an enumeration as a parameter, consider using the ' expand enum as execs ' metadata, which makes the node easier to use.
1 " DataTable ", meta = (expandenumasexecs="outresult", datatablepin=" Curvetable"))2staticvoidfloatfloat & Outxy);
- Many time-consuming functions (such as moving to here) should be latent (latent) functions.
1 /** 2 * Perform a latent action with a delay.3 * 4 * @param worldcontext world context.5 * @param Duration length of delay.6 * @param latentinfo the latent action.7 */8Ufunction (blueprintcallable, category="utilities| FlowControl", Meta= (Latent, worldcontext="Worldcontextobject", latentinfo="Latentinfo", duration="0.2"))9 Static voidDelay (uobject* Worldcontextobject,floatDuration,structFlatentactioninfo latentinfo);
- If possible, consider putting the function into a shared library. This makes it easier to use between multiple classes and less than a ' target ' pin.
1 class Public Ublueprintfunctionlibrary
- Remember to mark the nodes as pure (purely) as possible, as this will produce less of an execution pin that needs to be wired.
1 /* */2 ufunction (blueprintpure, category="math| Random")3static int32 Randominteger (Int32 Max);
- Marking a function with a constant function (const) also avoids having this blueprint node produce an execution pin.
1 /* 2 * Get the Actor-to-world transform. 3 * @return The transform that transforms from Actor space to World space. 4 5 ufunction (blueprintcallable, meta= (DisplayName = " getactortransform ), Category=" utilities| Transformation ) 6 ftransform gettransform () const ;
Original address
Blueprint Programming Guide (translator)