Hey guys. I may not have worded my question right.
I understand the server client relationship and I have working models up and running that all work as should. This is not a question of how to program server or client logic. this is more for understanding best practices on where to place what logic.
So right now I have my game mode and game state and player states all working as needed and containing the correct information ( I think) it all works and no reason to seem anything is off. What I am wondering though is where should I place logic.
For example:
I have components attached to my gamemode. UPooledActorsComponent lets call it.
I have other component attached to my GM that handles spawning actors (players and ai).
this all works fine I have an actor that when the player walks into and “kills” them it will then turn off all settings on the character actor and pool it to the array. It will then depending on spawn condition spawn player as a spectator or new player. When it does this it grabs the correct pawn class from the correct pool and spawns them. everything works nicely.
But then I started thinking if I should have all these components on my game mode or if I should have actors in the world owned by the server to handle different logic.
Maybe I have a UWorldActor class that then holds different components for different reasons such as common server events and pooled actors etc. Is there any benefit from removing this logic from the Gamemode and placing in own actors or is it merely preference for organization.
More actors means the World (simulation, collision, rendering) needs to manage more objects. If the logic is server-side only, there’s no strong reason to put it in Actors rather than in GameMode, unless it gets so big that it’s unwieldy.
That being said – do you actually need the pooling at all? How often do your players die? Have you measured that the simple, “destroy the object, spawn a new object when needed” behavior is at all meaningfully more costly compared to pooling? Have you verified that pooling doesn’t actually keep the object alive on the network, costing more than a dead object would cost?
I’m not trying to imply you have bugs, just making an argument for keeping things simple unless you know for sure that they can’t be simple anymore. (And sometimes we do know, for sure, but sometimes, we end up spending effort on things based only on hunches that might not transfer correctly to the domain…)
Yes, the pooling is needed and has been tested both ways and without it there is performance drops. in both PIE and Packaged.
Everything as far as handling the actors in the pool and network functions are all accounted.
I’ve made multiplayer games before just not sure if they were the most organized. This new project I am trying to force myself for better organization and building more modularly to have scalability.
I guess I will take your advice in the context of using the standard classes (GameMode,GameState,PlayerState) for handling my functions and data until it warrants a reason separate the logic. Just wanted to see what other might have to say on the matter.
That fits well with my “meta-advice” (after 20 years in online game engines) that most of my bad decisions, have been decisions made because I was afraid of changing things later. When I’ve been most successful has always been when I start simple and dumb, and then I’m not afraid to make the necessary changes when they become necessary.