I'm making a game some like Terraria. I have a couple of prototypes, but most of them use a "entity-component-system"(ESC) and some custom terrain implementation. Now I've reached the part where I feel like researching some multiplayer-technology. So here I am.

This is what I have so far; * I want to write the server in python, I don't HAVE to but I like python because I feel that I can easily change logic, and the workings of it.

Know, my first question is; the ESC, should run on the server, right? But how do I sync entities and components between the client and the server?

When the client connects to the server, how do I sync the world? The world is randomly generated as it expands. Can someone explain or link some data about how the server entity -> client entity is done? And how to sync the terrain?

  • 5
    \$\begingroup\$ Do you have a specific question, or is this a "teach me the basics of networking" question? \$\endgroup\$ Jan 24, 2013 at 1:56
  • \$\begingroup\$ I'm wondering about what the best way to sync a entity from the server to the client when it comes to identifying the, how to ensure that they have a id that is the same on both server and client. \$\endgroup\$
    – hayer
    Jan 24, 2013 at 7:34
  • \$\begingroup\$ Maybe send the data from the server to the client over a tcp socket? The server should generate the random world and send it to the client. \$\endgroup\$
    – Thomas
    Jan 24, 2013 at 8:22
  • \$\begingroup\$ @Thomas, but isnt it bad to mix TCP and UDP connections togheter like that? Wouldn't it be better to have a "has-to-ack" pack type in the applications protocol on top of UDP? So far the only method I can think of for syncing the terrain is sending a int[][] of the tiles around the player and add some margin to give the server some time to send more when needed. \$\endgroup\$
    – hayer
    Jan 24, 2013 at 8:41
  • \$\begingroup\$ I'm not really sure what's better, TCP or UDP, but I would use a TCP socket. I normally use either C# or Java and in this case you could do it like this: Make an instance of the 'GameWorld' class in a variable. Invoke the 'GenerateRandomMap' method on this object. Serialize the object to either JSON, Bytes or XML. Send the serialized data over the TCP socket to the player(s). On the players side deserialize the data back to the 'GameWorld' object and do whatever you want with it. I would also do this for the rest of the objects the player needs. \$\endgroup\$
    – Thomas
    Jan 24, 2013 at 10:01

1 Answer 1


Whether to choose TCP or UDP often depends on the mechanics and needs of the game. For example, First Person Shooter games often rely on UDP because of the minimal network overhead for exchanging information between two end points.

Using UDP does mean that packets could get lost or received out of order and your protocol and systems need to be prepared to handle this situation. There are UDP software solutions on the market which address these needs. See things like Raknet or ENet for examples.

Using TCP generally implies a bit more network overhead but offers you the reliable stream between the two endpoints. It also makes sure that the order you send data is the same order that it gets received at the remote end point.

Some games exploit the use of both protocols to exchange different data depending on whether the packet is order dependent or needs reliable delivery. Information that is important and should be received in order is sent via TCP and the other information exchanged via UDP that perhaps isn't as important or if it is lost will be resynced when the next UDP packet arrives.

Regarding the Entity Component System, you'll likely have this system running on both the server and client. You'll have the more heavy weight version on the server side where all the rules and logical systems exist. On the client end, its mostly just the rendering aspects of the Entity Component System with some minor logical systems that make sense to delegate to the client such as physics.

There are several ways to keep these entities synchronized. The first thing to keep in mind is that you will often have two types of Entities, Local and Networked. There are also two categories of Components, Local and Networked.

Local Entities are things such as perhaps spawning an object to point the player in a specific direction that wouldn't be necessary on other player screens that could see your avatar. A good example of this is the Archaeology surveyor object in World of Warcraft. It is purely a client side local entity when you use the Survey ability.

Generally you'd have some ID framework in place which allows the server to assign the unique IDs to network managed entities and their networked components. For local entities and components, those are purely managed by the client side only. For example, we use a 32-bit number where one of the bits on the high order end of the number represents local or networked.

Synchronizing the dynamic content from the server to the client is generally based on an concept that the avatar has a Field of Interest (FOI) circumference about them based on their current position. Anything that is within, enters, or leaves this FOI is sent to the client and it responds accordingly. Things like terrain, buildings, and water are all static content, usually delivered when the game gets installed. So this information isn't sent to the client. It's thing slike NPCs, weather changes, other players that get transmitted. Here's an example exchange from our game.

C>S: Account 'crancran' login realm Deep Earth.
S>C: Client connected
S>C: Sending Player Data to client
S>C: Player current location is 1049.0031, 1.984, 75.0494, Map Id 2.
S>C: Game Object Update - Spawn NPC 1234 - Object entered client FOI. 
S>C: Game Object Update - Spawn NPC 1235 - Object entered client FOI.
S>C: Map Id 2 Current Weather is Rain.
/* player begins to move */
C>S: Player has moved.  Present position is currently 1052.948, 1.984, 73.0478.
S>C: Game Object Update - Spawn NPC 99 - Object entered client FOI.
S>C: Game Object Update - Despawn NPC 1234 - Object left client FOI.



You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .