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.

  • 1
    \$\begingroup\$ @TrevorPowell Is that what it comes across as? I'm asking for advice regarding implementing a specific system - the rest of the networking, I can do, it's just the "sending game objects to clients" part. \$\endgroup\$ – jshxe Jan 23 '13 at 8:02
  • 1
    \$\begingroup\$ Sending data about game objects is no different than sending other data. What's the specific question you want to have answered? As written, it sounds like you're asking for a general tutorial on networking, because you haven't narrowed the question down at all. \$\endgroup\$ – Trevor Powell Jan 23 '13 at 8:06
  • 3
    \$\begingroup\$ See? THOSE are your questions. Those should be the text of your question, instead of the nebulous "how do I do networking?" question that's there now. That's exactly what I mean about needing to narrow the question down to the point where it's answerable. \$\endgroup\$ – Trevor Powell Jan 23 '13 at 8:22
  • 5
    \$\begingroup\$ If you have to ask such basic questions, your project will fail. I don't know why such many developers start with MMORPGs in 3D with dynamic world. It's by far one of the most time-consuming and hard topics, which is very unsuitable for a begginer. Anyway, if you want to simplify your networking, use ICE \$\endgroup\$ – Bartek Banachewicz Jan 23 '13 at 13:33
  • 1
    \$\begingroup\$ @BartekBanachewicz That's an unnecessarily de-motivational statement. I am not new to the world of game development OR networking, this game is just the first one I've really tried to put enough effort in it to sell. The reason behind this question is that I would like to see how more experienced game developers would approach this, I'm verifying everything I do step-by-step as I work on this game. I'm sorry if this post came across wrongly. \$\endgroup\$ – jshxe Jan 24 '13 at 18:53

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).

| improve this answer | |
  • \$\begingroup\$ This is a really great answer. The system with IDs is a really clever idea, I like it, I think I will be going for this system, but I was wondering - I do plan on allowing players to actually place some objects where they want on their ship, such as a stool in the cockpit or a chair in the lounge room, or a sensor array on the back of the ship. How would you implement that factor? Perhaps sub-ids for other object alongside with an offset position and location from the center of the ship? \$\endgroup\$ – jshxe Jan 23 '13 at 12:02
  • \$\begingroup\$ When players meet in space, they will certainly not see the interior of each others ships. So this information only becomes relevant when a player is actually walking inside a ship. I would thus send the interior information when a player enters the ship. Whether or not to give each piece of furniture an own ID depends largely on what the pieces of furniture can actually do and how the players can interact with them. \$\endgroup\$ – Philipp Jan 23 '13 at 12:13

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.