I’m doing an RTS project and for now, all my project is pure C++ (except HUD things where I use UMG).
That being said, I slowly realize that doing complexes Actors using multiples other Actors is going to be one hell of a run with C++, same for particle effects, etc, where you have to use ObjectFinder and every other ConstructorHelper kind of stuff, without any visual feedback (no viewport ><).
Right now I’m hesitating to do a BP child of all my classes to have an easier control over my meshes. Let me give you an example. I have a C++ class called “HQ” which, has you can guess, is the HQ for the player. For now, it’s just a static mesh so everything is fine. But I started to think about adding child components such as rotating lights and door opening for when a unit is built. The rotating lights are themselves an actor composed of a static mesh and 2 lights. I have the feeling that doing all that purely in C++ is going to be cumbersome, but maybe I’m wrong.
So my question is, should I derive my classes to BP to have a more visual approch of my classes and add particle effects and child components, or should I keep my game full C++ ? I’m looking for performance, and I prefer coding.
What bother me is that I’m going to have a full mirrored project hierarchy between BP and C++. Every single folder for factions, buildings, units etc will be duplicated for the BP.
Any suggestion ? Have you guys already met this problem ? Thanks !
The general workflow that I use, and that Unreal heavily encourages, is to do any performance intensive things in C++ and do the less important busy-work type of stuff in Blueprints. Often it’s useful to write base classes in C++ that can then be extended or modified in BPs as you suggested.
But you should be able to build your game either way so if you’d rather code the entire thing in C++ then you can; it will certainly have performance advantages, but you’re right that it will likely take longer and be fairly cumbersome. In the end it’s mostly a question of preference so you’ll have to decide for yourself.
Personally I’m doing most of my development in Blueprints and only really doing coding when I need specific optimization.
Use both if you can, aspecially if you have a artist in team (think of it as you make tools for him), make base in C++ and specific actors in blueprint, using C++ components is also good idea. To avoid ObjectFinder and ConstructorHelper, use property editor to set those in editor, for example you make door component insted of staticly getting it in C++, make UStaticMesh* property and se mesh in editor, no need ot tieing asset with C++. You can also override UWorldSettings for level wide class and asset selection.
If you have heavy tick work to do, it is always recommanded to do it in C++.
The first thing I should note, is that if you ever find yourself doing something in an actor which is complex enough that you’re saying to yourself “gee, I should do this in C++” then you should probably be making a C++ component to do that work and not an Actor at all.
In those cases where you do actually need a new actor type, it is useful to have an abstract C++ parent class which you then create a blueprint actor out of. Just minimize what you are doing in blueprint. The faster prototyping time is often offset by the amount of time it takes to push your blueprint work back down into code land.
However, you can’t really do this with components. Components really shouldn’t be created in blueprint. Though in theory you could, in practice blueprint components will really screw you over down the road since C++ doesn’t know about them, so you can’t do much with them in code without it being a giant headache.
Thanks for all your answers ! So the bottom line is that all abstact classes should be C++, which is already my case, and “spawnable” classes can be BP for artistic purposes. It makes sense, and follow what I thought in the first place.