I am creating levels at runtime (game startup) by spawning a bunch of blueprints which are basically rooms that I place so they connect together. The level contains of static geometry (well movable as they need to be placed at runtime), and spawn points that will spawn replicated actors on the server. For a networked game, I would like for the server to only send the seed needed to generate the level on the clients rather than needing to replicate all the static actors over network.
Is there any way to get my level actors to generate the same network id on all networked game instances, so that they can be synced even though they are spawned both on server and client?
If not, do you have any other ideas on how to achieve this? I have been thinking about saving my generated levels and then loading them, but then I would still need to make sure the actors get the same name/id, so that the game thinks it’s loading the same package (even though it’s generated separately on a specific server/client).
So for clarity, everything works with replicating the actors to the client. I set the bNetTemporary flag so it should only replicate when spawned and then close the network channel for that object. Right now I am generating 20-40 rooms to build the level.
Still, it is unnecessary as I can use the seed to deterministically load the rooms on both server and clients. So any ideas would be appreciated.
It sounds like your current approach with replicated Actors using bNetTemporary=True is probably best. You only have network load whenever a client joins (which is very common) and then after that your strategy should work just fine. I feel it’s probably best to just stick with the simple solution for now, and just re-visit it later if you find that the network performance is unacceptable.
I don’t know what the best approach would be. I’m a newbie to network multiplayer.
If the generated actors do not need to move or change in any way after they’re generated, then you can use the random seed approach to optimize. So if you’re only replicating once in order to get it to everyone, then it sounds like the seed is enough and you could just do that instead.
However, if anything at all about the generated actors needs to be able to change and have that change show up on clients at any time (whether they joined before or after it happened, then you probably need continuous replication of at least the variables that are changing, if not the entire actor.