Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 6 down vote favorite

So, I've been working on a project for a while which is basically just a little 2D game. The fun/hard part is that I've been trying to make it work as a multiplayer game. Right now, the game is just a bunch of entities, both players and projectiles shot from players. I have a question about how to keep the entities in sync on both the client and the server.

Is it better to send many many little "update packets" for each entity whenever it is updated? What I mean is, should I send a packet containing an entity's x and y position whenever it moves?

or

Is it better to send larger update packets that contain the updated info for many entities? What I mean here is should I send a bigger packet that has an array of smaller "update packets" that each have updated info on a specific entity?

I'm not sure which will cause less lag and be more scalable. What about if I had a hundred or more entities to update? Which method would work better in that case?

Thanks.

share|improve this question
You can push smaller packets into some queue and then send them at once. This way you can easily change it later if you odnt like it. If you shoot projectile for example, you dont need to send update position to every client, you just need to send projectile start position and speed and clients can simulate the movement - but this depends on what type of game you are doing. – Kikaimaru Apr 18 at 14:02

1 Answer

up vote 4 down vote

The choice to make depends on what your multiplayer architecture is for the game. There are two major architectures for multiplayer games, the first being client based, in which each client is responsible for its own decision making and updating, and the server simply distributes these updates to other players. The other is an authoritative server, and prediction based clients. In this architecture, the clients are basically fancy renderers, that are responsible for simply sending "intentions" to the server. The server is responsible for managing the global game state, and telling the clients what the current state is. In this case, the prediction code is simply used to help mitigate the affects of latency, and smooth gameplay.

To answer your question about more smaller packets, or less larger packets, this would depend on your send/receive architecture, as well as whether or not your game can handle less frequent updates. Stalling an update until you have enough data to reach your desired packet size would lead to less frequent updates, and could make time sharing on the server less effective for asynchronous handling if the number of clients was large enough. This is something that is specific to the architecture of both client and server, but in general I would say "send em when you have em".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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