Unreal is a multi purpose engine build for “small” levels (not open world). You can’t produce a engine that does everything perfect. You can’t even provide a single component that does everything perfect (related to what it can do), cause if it can do everything, there are a lots of conditionals that reduce performance.
If you need performance, you need to know the specifics of what you want to do and then can optimize in that direction. E.g. for a 2D game a transform could look like this
struct FTransform2D
{
FVector2D location;
float rotation;
float scale; // Assuming uniform scale
}
With that every transform operation is a lot cheaper than using unreals 3D transform with arbitrary axis scale and 3D rotation.
With all the possible render options unreal provides, you might move much more data around and process it than you actually need.
We develop for VR currently and using a GTX 1080 graphics card. We found that 500 draw calls (like 500 static mesh components with cube that only contains one material) is our draw call limit,
not modifying any render code. Though we dynamically create objects at runtime and depending on the size of the objects (vertex/triangle count) we reached 20.000 objects by merging objects with the same material together (by utilizing a custom version of RuntimeMeshComponent and some additional classes). In case of a city builder like cities skyline, I would do something similar. Like: Subdivide the world into grid tiles, and per grid tile merge buildings together. This might require a special material setup to merge buildings of different type/evolution state.
Already thought about how this conveyer stuff works (Satisfactory, which is build with Unreal). But they definitly have some custom stuff going. Objects on a belt could just be arrays of floats determining the distance on the belt, including a index or something to determin the object type. The belt movement could be processed in parallel using the ParallelFor function of Unreal to run code threaded (belts do not interfer each other, though there should be no problem), but syncronously. In case of Satisfactory you need to handle how much a connected factory consumes and if it can consume (internal item stack full), but should be doable. Would not assume that they actually have collision for the objects on the conveyor belt. Picking stuff from the belt can be done by determining the distance on the spline (belt) the player is looking at and then evaluate the value with the item array for that belt and see if there is a item in range of the look-at-distance (float distance computation in a sorted array -> cheap). Pass the belt arrays to the render thread and batch render the belt items (don’t ask me how that works).
In case of animation you want to look into computing an animation once and use it for multiple skeletal actors. Means multiple actors have the exact same animation. In a battle you might want to split the actors with the same animation across the battlefield to make it look more dynamic. I think Unreal did something in that direction already (never worked with skeletal actors). And if they have the exact same animation state, you might also batch render them like a instanced static mesh component. Meshes for Actors in a game like TotalWar are not so much detailed. If you cut blend weights on vertices and stuff like that, animation computation should be pretty cheap as well. No clue how they deal with damaging the correct unit in case of attack, but probably a spatial grid system to cut of lookup cost. By distributing animation evenly you also split up the number of lookups for what unit needs to be damaged (only units that reach the damage state of the animation need to compute the lookup). Or you define the target before attacking, which would actually be the better case (still using spatial grid to find a suitable target).