An often-asked question is how to structure a networked game at the high level: what do you do in the client and in the server, and what do you put into the packets you send?

The basic client loop for this kind of game consists of:

Here is the basic loop for the server:

Here's what the functions do:

service_client_connections():

Read messages from clients, forwarding them to the appropriate objects. Send as much of you can of each clients outgoing queue to each client (to manage bandwidth). Handle log-in and log-out.

update_objects():

Given the current state of the objects, step one step forward (typically, around 20-50 milliseconds per step), doing collision detection, force and velocity integration, setting off triggered scripting events, etc.

queue_object_changes_to_clients():

Figure out what objects changed the most compared to what the client knows about, and queue data for those objects to the clients. Also, send "new object" messages for any new objects that may have entered the world.

read_messages_from_server():

Read the server connection, and dispatch any messages you receive to the appropriate objects.

update_objects():

Same thing as on the server, except you probably don't want to run the scripts etc; just trust that the scripts will run server-side and send appropriate object state changes to the clients.

render_scene():

Traverse the scene from the point of view of the player camera, rendering stuff to the screen.

read_user_input():

Read keyboard/gamepad/whatever. Deal with OS events as necessary.

send_user_input_to_server():

Package up the data you read from the user, and forward it to the user object on the server.

With this basic implementation, the object you control won't start moving on the screen until the user keypress made it to the server and back. Often, that's quite good enough.

• There are many different improvements you can make on this scheme:
• Mask object position updates that put the objects in a different place from where they are currently on the client.
• Apply user input to the user's object immediately when you send it. Figure out some way to account for corrections from the server that you will receive "in the past".
• Forward extrapolate various attributes (position, orientation, etc) when you decide where to draw objects, so that objects are drawn in a predicted position where they might be "now" instead of where the server thought they were "back then."
• Various compression, prioritization and interest management schemes.
• Various control and state information encoding schemes.

I'd suggest you start with the scheme I describe above first, and then improve from there if necessary.