![]() Since there are different pieces of functionality that are best handled in C++ or in Blueprints, here are some examples of how C++ programmers and Blueprint authors can work Complexity of expression is another reason a crowd system wouldīe better to implement in C++ code than in Blueprints. Those things are better kept in C++ than in Blueprints, just because they're easier to look at and figure out what's going on. are all very complex, and aren't easy to follow in a visual system. Operating on large sets of data, doing string manipulation, complex math over large data sets, etc. Blueprints do a lot of things well, but some things are just not veryĮasy to express in nodes. ![]() To handle decision making, pathing, and other crowd functionality in C++, and then maybe expose some tweaking parameters and controlling functions to Blueprints.įor complexity of expression, there are just some things that are easier to do in C++ than in Blueprints. If your profiling shows that one operation is taking a lot of time in Blueprints, consider moving just that section into C++, while keeping the rest in Blueprints.Īn example of a system that would take a lot of time to execute if done with Blueprint visual scripting is a crowd system that controls a thousand Actors In this case, it would be better for performance If you have a Blueprint that has a lot of functionality, you can push some of that functionality into C++ to speed it up, but keep the rest in Blueprints to retain the flexibility. However, it is possible to combine the two in the way that works best for your team and your project's performance. That's not to say performance is bad, but if you're doing something that requires a lot of calculations, or operatesĪt a high frequency, it might be better to use C++ instead of Blueprints. Where that would enable a more concise expression of the functionality (or it becomes too complex for a non-programmer), or speed of execution dictates a move to C++.įor speed, the fact is that Blueprint execution is slower than C++ execution. A good practice to follow would be to use Blueprints extensively, and then push things into C++ as they reach a complexity So they move that chunk of functionality into a new C++ function. ![]() At Epic,Ī lot of the workflow is that content creators will make a very complex Blueprint, and a programmer can see how they can compress a lot of that work into C++ by coding a new Blueprint node, We expect people to fall somewhere in the middle. In contrast, if you have a lot of programmers, they're probably keen to keep things in C++. If you have many more artists than programmers, you'll probably have significantly There are two driving considerations when deciding to use C++ or Blueprints:īeyond those two factors, a lot of it comes down to the complexity of the game, and the composition of the team.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |