Client-Server Game

First-person Shooter, not Ego shooter.

you can call them like

CEntityClient_Terrain
CEntityServer_Terrain

it''s more typing, but at least, you know it''s an entity, needing both client and server counterparts.

Client entities don''t need to send data to the server. Only the player entity, which can send input packets (all the inputs from a player, bundled into one packet). Separating the PlayerEntity (which manages the inputs) from the client/sever is a good idea, well, that''s what we do.

the server entity obviously need to send updates, for positions, states, current animations (death, and other specific animation overwrites), explosion messages, synchronisation messages, and others. Also, when a client receives an update message from an unknown entity (all entities have a unique ID number) the client requests from the server a creation message. For some objects, that''s not necessary, like explosions, and other ephemeron objects. For that, an Entity Factory system is a good idea.

A client machine should not need a server entity, but a server machine might need a corresponding client entity on the same machine, even if it is a dedicated server. If you use skeletal animations for example, you need the bones positions and other things for bullet hits. This is usually calculated on the client, using update packets from the server.

that should be enough for LAN play.

for internet play, you need to think of prediction on the clients.

the way we do it, a client entity receives updates from the server, at, say 20 fps, and the data from the updates is stored into an interpolator, that you can use to predict positions in the near future (up to a reasonable time). The current position is calculated from the interpolator, and used to render the object at the current time on the client.

For the player entity, it''s a lot more complicated. You need to make the lag as transparent as possible to the user, and it can get quite tricky, when you collect pickups, switch weapons, fire bullets, change a clip... The server should ultimately control the client weapon system (another good candidate for the Client/server architecture), but at the same time, a player wants to be able to switch weapons instantly, and fire instantly, ect... bullet hits, and predicting kills can be tricky too.

Predicting the player movement is another problem. For that, we have collision objects on the client entities on the client machine, and we run a physical simulation on PlayerEntity only. The client runs the simulation, and along with the commands, sends the predicted position to the server. The server receives the packet, run the commands, calcualte the new position, see if the calculated position is the same as the predicted position sent by the client, if not, sends a correction message. The PlayerEntity receives the correction message, and update the PlayerEntity (and corresponding ClientEntity_Human) position accordingly. It''s tricky, but it works OK so far. Most of the time, the predicted position will be correct, until the player bumps into another player, then you could see a slight jerk on the client due to the correction.

Another important thing, it''s good to have a good synchronisation system, so the timers on the client and server run concurrently.

Another thing we implemented, is a compression system. Basically, only modified data from a server entity gets physcally sent to the clients. That also requires to send a heartbeat messages (a message with no data, every 5 seconds), for creating unknown entities on the clients. That reduces the data sent dramatically. It''s clever, but quite complex to implement. But once it''s setup, it''s transparent to the programer. It''s a good candidate for scripting and other automatic clever data processing methods.

Hope all that information can help.