Search public documentation:


Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 Home > Networking & Replication > Client Server Model

Client Server Model


The client-server model for gaming was first explored with QuakeWorld, and has become ubiquitous now in the various multiplayer games that involve more than a half-dozen people playing together online at once. In this model, there is the big server which maintains connections with each of the clients. Typically a server is hosted on a large internet pipe connection, and the various gamers connect to this server and play with each other. Clients do not communicate with each other, but can only communicate indirectly through the server. It is this model that allows many people to play online with each other at the same time.

Level NetModes

In Unreal Engine 3, there is an enum of net modes (defined in WorldInfo). These net modes define the various role that an instance of the game is performing. In the simplest case, there is the NM_Standalone net mode, which is utilized when a player is playing a single player game involving no network connections. This is the only net mode that has nothing to do with the client/server architecture briefly discussed above. The next net mode is NM_Client, which describes the instance of the game that is connected to the server through the person playing the game. The client receives data about the game's progress from the server, which can be either one of two net modes: Dedicated and Listen. The NM_DedicatedServer net mode is used for a dedicated server. It sits there to serve clients only, and does not display any GUI, have any PlayerPawns associated with it, or handle any of the stuff a NM_Client would have. NM_ListenServer is the weird netmode of the bunch, as it combines the various netmodes. A listen netmode provides a 3d representation of the world to the user playing in that instance of the game, while at the same time acting as a server on behalf of the various clients connected to it. With this setup, the server is typically running at reduced speed due to the server's need to provide 3D acceleration and other visual effects for the client. This net mode has traditionally created some problems when coding as the client in this instance cannot always be treated the same as the others, since it is NM_ListenServer while the others are all NM_Client. For example, every other client has replication and networking to deal with, while the NM_ListenServer instance has the client operating on the same copy of the data as the server. This should make more sense as you become more familiar with the engine.

Server as authority

In the client/server model, the server has full authority. A client cannot cheat and/or corrupt the game state of another client. A client also cannot change their health, give themselves weapons, or change the server's game state, except through mechanism explicitly coded in to allow for the client to change properties, such as an admin mode or keyboard movement to change the player's position (within the constraints of their maximum speed). With the server as the authority, the client is limited in its abilities, and so is a good step to preventing cheating and other such changing of game data.

Clients as dumb terminals

In their simplest form, clients are simply dumb terminals that display data sent to them by the server. With games, it makes sense to send information about changes in the world to the client, and have the client use its 3D card to display the world and provide the user with an online experience. The server sends information about the various clients, projectiles, etc to the client, which then updates its local and inaccurate copy of the data to the latest information sent from the server. However, if one were to send updates as fast as possible to the client, you could probably get updates a few times a second. However, the client is displaying information to the user at a few dozen times a second. If every dozen frames, the position changed to reflect the latest data, you'd notice the horrible, jumpy movement of the actor very easily.

To solve this problem, QuakeWorld introduced simulation, where the client had information about the actor's movement in general. For a bullet flying through the air, one only needs to know it's velocity, and one can make accurate predictions about the bullet's movement at any given time. It can interpolate the position between one update from the server and the next. This enables the client to more fully immerse themselves in the game as they don't readily notice that their game state is continually being updated by a server that is a few hundred milliseconds away.


Cheating is a problem that has plagued every event that has involved one human competing with another, whether it is poker, sports or online gaming. In most cases, you can usually prevent cheating by reducing all forms of privacy and having some guy check every player for cards, drugs or whatever it may be. However, when playing online, one has to inherently trust the client. You can put all the safeguards in the world on the client end, but the human could have hacked the exe/dll to remove every one of those safeguards, allowing themselves to cheat. The server has no way to tell if the client is actually aiming at a particular player, or if some code on the client is doing the aiming for them.

However, with the client/server architecture, one can limit what the client knows to data that is needed for simulation. There's no need to send them information about players they cannot see, stuff that doesn't and shouldn't concern them. This reduces the amount of data the client code has to work with, and reduces the mechanisms through which they can cheat. By the same token, the server should limit what sort of data it will accept from the client. The less data the server trusts of the client, the less ways the client has to manipulate data to it's advantage. One should not have the client specify which player their shot hit, since it would be easy for the client to say he hit a different player with each shot. The server would have no way to determine if this player was legitimately a good aim, or if it was code performing the shots for them. If instead the client sends data about where they are aiming, and when they fire, the server can test to see if the player hit on it's own terms. While the client can adjust the aim with the hope of getting it to hit on the server, it's much less accurate, and it cuts down on hitting people out of range, and other such disasters.