What I am wondering is, what information do you put in the client and what do you put in the server. For instance, an MORPG, what information would be in the client and what information would be included in the server? I don''t know if this is too general a question or not since I have no experience with Winsock and client/server coding. Thanks.

Yeah, it''s a pretty general question. In _general_, you would keep the authoritative state on the server (each players position, name, class, items, spells, etc.) and what''s often called a proxy state on each client. The proxy state will have a lot of the same information as the server, and it will periodically request that the server change its state (whenever a button is clicked or a key is pressed). The client will say, "hey server, move my character forward 3 units". The server will check the request for validity, and then either ignore it or, if it''s accepted, eventually rebroadcast it back down to all the clients who will update their corresponding proxy state.

Generally, maps, models, textures and other things relating to drawing the virtual world are kept on the client. Often they are checked against a hash to ensure that they haven''t been modified or updated. Ideally you would keep these on the server, too, but they tend to be too large to pass back and forth across the net.

Obviously things get much more complicated when you start having to deal with latency and other network "inconveniences" and each implementation is different (some more than others). Hopefully I answered your question. If you''re interested in learning more about it, I found the book Massively Multiplayer Game Development very helpful.

bpopp - My Gamedev Journal

I concur

in general, the client keeps render/sound parts of the code (animations, models, textures, ect...), while the server keeps the physical part of the code (collision meshes, collision objects on players, AI paths, sound positions for AI), and the game logic (game flow, client inventories, weapons...).

The clients get positions of entities in the world from the server, and their state (including the player managed by the client), and render things ''blindly''.

So in short, you''d have client entities, which take care of the rendering / sounds, and server entities, which take care of the physics, and game state changes. for example, the client entity positions are calculated from packets received from the server (the positions received are either interpolated, or not, and used to render objects, calculate speed of the client entity to perform animation blends and speeds).

Server passes position, orientation, states to the client (overwriting animations, if the player is dead, crouching/standing/prone state posture, which weapon they have in hand, ammo, ect...), and mostly, only the client player entity on each machine sends input packets to the server, which process them and calculate the position of the player, and sends the position of the player back to every clients.

but that''s general. Clients can also perform predictions (so in that case, they also need a physical representation of the world, for collisions and physics), by doing a physics simulation on some objects (the client''s local player, mostly), sends the predicted position to the server (along with predicted states, like posture, weapons in hands, ammo), which the server, in turn, aknowledges it, or sends a corrected position or state. Clients can use the positions received from the server, and perform forward interpolation (prediction, along a spline built from previous received positions).

it quite complicated A book is your friend.

quote:

---

Original post by bpopp
The proxy state will have a lot of the same information as the server, and it will periodically request that the server change its state (whenever a button is clicked or a key is pressed).

---

Great explainations so far. Let me define Proxy for you (specifically remote proxy):

A remote proxy provides a local representation for an object in a different address space:
1. It provides an interface identical to the subjects
2. controls access to the real subject and also may be responsible for creating and deleting it.
3. A remote proxy is responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space. (other players)
4. It may also responsible for transmuting a response from the real subject back to the client. (your player)(http://www.ccs.neu.edu/home/salil/section3_3.html)

Basically, you could start with a regular engine that isn't server aware. However, your engine would reference your entities through a control class. Originally, the main player would accept input from the keyboard and move its entity and animations based on the input (processed through physics). The AI would accept its command from an AI class that would move it around. Each AI would have its own class to represent it.

Now the proxy wrappers act just like the classes they derive from. The engine knows no difference (nor does it care) where it gets its data from. It would be prudent to maintain a local state chart that is updated from the servers' datagrams. (which help with prediction as Oliii pointed out)

[edited by - natasdm on January 26, 2004 9:01:40 AM]