I have been continuing studying Godot and I stumbled upon https://youtu.be/ExuzWQ077n4 . At about 10:47 onward, I can see the movement_state_machine has lots of nodes as its children.
If I am to create an enemy which has tons of movesets, these number of nodes will start to grow linearly. Ex. If an enemy scene has 10 states. 100 enemies would mean 1000 nodes.
My questions:
Although performance testing is definitely a must, before I implement anything, is this normal in Godot design-wise?
Those different state nodes should only take up extremely tiny amount of memory on RAM, but the number of instances of the enemy scene will grow linearly with respect to number of state nodes, yes? (Should still be quite minimal anyway)
For these state nodes, do they in any way being called upon internally in the game loop if they just exist in the scene but not the active states? Suppose I have 100 enemies and they combine up to 1000 nodes , compare this with another design that has the same 100 enemies but each enemy only uses 1 node, resulting in just 100 nodes. In that single enemy node, we have a state machine in a dictionary of functions instead and we use enum for the key to each function in the dictionary, will the performance be the same as having 1000 nodes?
Can those state machine state nodes which will be identical for all enemies be shared by all enemies? Ex. All 100 enemies share the same 10 nodes but keep track of their own variables and which state they are using. Or is this completely unnecessary or irrelevant?
Creating the nodes will be the most impactful on performance, once spawned they shouldn’t matter much. If it becomes a big issue maybe extending Resources or Objects instead of Nodes for state will instantiate quicker, I think Nodes as a state machine is pushed because it visually looks nice and can easily track what states a given character has, Objects would be a better fit for splitting up files by state.
I theory, having more nodes will obviously consume more memory as you are adding more information…
On the other hand, the point is how much more memory this will consume, and if this will have an noticeable impact or not…
I stumbled on a video a couple of months ago where the guy was building a RTS game and he was having performance issues with multiple soldiers on screen… And the problem was that each soldier was doing the path finder calculation individually and it was consuming a lot of memory. I don’t remember how he fixed it , and I can’t find the video anymore… but in the end if a tradeoff. You use a little bit of more memory for a better design pattern, but don’t overuse the memory.
I think if you only watch video 27, which is the one I added, might be enough…
I don’t think the quantity of nodes is a real performance issue, but what’s inside the nodes…
If you have 1000 nodes with 5 children each and all children have a “process” and “physics” to do, then you have 5000 processes to handle every single frame.
But if you have only 1 node with 5000 children, you still have the same amount of workload.
Obviously, you are saving 999 nodes in the memory, but the point is if those 999 nodes removed had their own logic to process or not. If they were there only for structure, and debug easiness, then the amount of memory should be minimal.
So if you watch the video, you will see how he basically had a huge amount of performance gain, even increasing the number of units, thus, more nodes(probably)