Networking dynamic game worlds

Question

I'm working on a 3D massively multiplayer space game in C++ and I'd like some advice from experienced game developers.

Essentially, the world (universe) simulated on the server is absolutely dynamic, which means the location, position, rotation of every single game object in the game is subject to change at any time, as the server is completely authoritive over this. Entire planetary systems can be moved. The server is persistent so movement of everything is simulated in real time. You could log in once, grab a spaceship, fly around a little, and log out again. Upon logging in the next day you log in to find yourself drifting towards a black hole!

So, GameDev, how would you approach sending every game object to the several clients that could be playing? This means loot on the floor, spaceships, space carriers, planets, stars, planetary systems, galaxies! I mean, how could I represent the game objects during travel to a client? As a 3D model name and associated attributes? Or maybe a single id that the client knows about, but then how would it handle users customizing their ships or adding other components to it? I am just unsure how I can replicate the game objects on the clients and allowing support of spaceship custimization and perhaps avoiding updating the game client for every new object added. Maybe it should actually send the model file over, Garrys Mod style?

Tips for network optimisations are welcome too but it isn't urgent this early in development.

Answer 1

After I wrote my first answer, you edited your question and shifted the focus on how to handle the visual information about each object. That's a different aspect I would like to talk about in a separate answer.

It depends on how extensive your customization system is, but unless you go for something extremely flexible, you could certainly express the look of each ship with a bunch of variables (basic hull, list of attachment parts on the hull, color palette...). Sending the whole 3d mesh would certainly be overkill.

You, again, can use information hiding here to both conserve network traffic and to make your game more interesting. When an object is at the edge of sensor coverage, the player shouldn't even know all details about it yet. Just an approximate size and the movement vector would be enough. The client should also get an unique ID for each object, so that the server can refer to further information about this object by providing the ID. When the player gets close enough to realize that it's not a moon but a space station, they would get another message consisting of the same unique ID and the hull type ID so that they can render it with the correct model. When they get much closer, they could get a list of the attachments for that ID and how they look, but not what they actually do (color is red with yellow decorations, some gun on left wing, some gun on right wing, some equipment piece on top). To find out what these attachments actually are, they would have to use an advanced short range scanner on the ship (MK3 positron cannon on left wing, LV-300 heavy pulse laser with Level 2 accuracy upgrade on right wing, Class IV long range scanner on top - powered off).

Answer 2

To minimize network traffic it's important to minimize the number of updates. This has to be done by:

1. minimize the number of updates per object
2. minimize the number of objects a client needs to be updated about

Regarding 1: A common newbie mistake is to update the positions of objects at regular intervals. They send the same position of an object over and over again, even though the object hasn't moved. A much better strategy is to only update positions when they actually changed. When you have a lot of movement, it might be even better to not send changes in position, but only changes in movement vectors. In your case, when a ship is moving around, you would only send an update when it changes its course. No updates are required while it moves with a constant speed in a constant direction, because the clients can extrapolate the position themself. When your game is aiming for a very realistic simulation of space physics, you might even go a step further and only report changes in acceleration, because spacecrafts maneuver in frictionless space by switching accelerating trusters on and off.

Regarding 2: You didn't say much about your gameplay, but I assume that there are events a client doesn't need to know about (or even mustn't know about, like movement of stealthed ships or spawning of treasure which is supposed to be hidden). A fierce battle taking place on one end of the universe certainly doesn't concern someone who is mining for resources on the other. For that reason you should only update clients about events in their vicinity. In the context of your space simulation, "vicinity" might be different depending on the scale of the event. The movement vector of a small asteroid would only be reported to people within visual range. Updates about a ship would be sent to people in the same star system. When a whole star system is moved as you described, it certainly affects everyone in the galaxy, so everyone needs to know the new position of the star system. But do they also need to be informed about all the planets, moons and ships in that system? When they want to know what happened to them, they would have to travel there and find out.

These are only examples, of course. Who needs to know about what depends largely on your gameplay and the role of information hiding in it.