Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was going through the Tribes network model and the network model used in Quake3. What I understand is that Tribes is more of an event based model where as the Quake model uses game states and delta game states to sync clients. Is my understanding right?

What kind of games do these models favor? Also what are the drawbacks of one model compared to the other. I am currently developing a two player First Person maze solver game and trying to choose between the two models.

share|improve this question
up vote 1 down vote accepted

Note that I'm not knowledgeable about those games specifically, so I can only answer in the general sense.

A lot of modern games do both game state synchronization and event delivery to some degree. Each approach has a different use-case, as Anomalous Underdog pointed out.

One advantage of the sync-the-world model is that you can reuse the general state sync code to allow new clients to jump into the game and know what's going on; the server just notes that the state delta is "everything" and sends the whole state down. With an event model, new clients must be specially handled to ensure that all necessary object-creation events are sent on connection in order to get the client up to the current game state.

Another advantage is that creation messages are less important and for some games destruction is unimportant. You don't need to send an explicit "create object X" message and ensure it is handled before any movement messages since I can just create the object when I get a movement message for it. Destruction is still a little complicated, since you need to know the difference between "object X is gone" and "object X has no more updates." Some games's gameplay requires a relatively small set of always-around synced objects so destruction is unimportant.

A pure event model is how many games are implemented at the low-level but some of those events are "here's some new state." Some sync individual object states rather than a whole game state. The advantage of this model is that it's just easier to do with partial ordering of states, non-state-based messages (like chat), control flow, and so on. With the game state model, it's important to have an additional means to send reliable events, so you're still implementing the entire event model anyway.

You can combine both methods, using state sync to handle objects that the server and client both know about, and using events for object creation, destruction, and non-state updates. This tends to be where many higher-end games go, as sending an individual state event for each object uses more bandwidth in event framing/headers, but events are needed no matter what. That rarely matters for smaller games or games that don't try really hard to fit into lower bandwidth requirements.

Note that pure state deltas in either model is a huge chore unless every update is ordererd and reliable (e.g. via TCP). The server needs to know which state the client has in order to calculate deltas appropriately. That gets hard because even if the client ACKs a packet a new state delta might be sent before the ACK is received so the client sees extra movement (once from the first packet and then that movement reapplied in the second). The server could keep a state sequence number that is sent with each update and the client can keep recent states for each sequence; the server sends which state sequence it thinks the client has and the client ignores updates if its state sequence doesn't match the packet but then you might needlessly drop some state updates that are accumulated together (eg if a packet has updates from state 5 to 7 but the client is on state 6 from a previous update whose ACK is delayed/lost then the new packet must be thrown away and the update to state 7 from 6 must be resent in another packet). That approach works for lock-step games but is still not ideal.

Using current state updates rather than deltas makes it so that missing intermediary states or duplicated state updates are irrelevant whether they come in the form of state syncs or individual events (you'll still need a proper retry and ordering mechanism for some events but not entire packets).

For a simple two-player game that has little going on besides maze navigation state sync might be easier. Just send the player's positions/orientations and the positions of any movable maze elements with each packet, append any reliable events like chat, and resend those events if their packet doesn't get ACK'd. With a pure event model you'll need to handle a lot more resend and flow-control logic for events and, if things are moving a lot, you'll just be sending an event for each object anyway so you're still doing a game state sync.

Or just use TCP; honesty for most hobbyist/student games or even AAA games that don't have a lot of real-timey requirements for action TCP is easier and works just fine (if you turn off Nagle). An increasing number of network-centric games these days use TCP (MMOs, RTSes, RPGs, etc.) but very twitchy/action-y games should still usually aim for UDP to have better latency control. Your game may will work perfectly fine with TCP which simplifies everything by making all messages reliable and ordered.

share|improve this answer

When you say state synchronization, it just always fires the latest values for those variables. For things that you don't care about their previous values, this is preferable.

Like 3d position for example, you don't care about dropped packets of old position values. You're more interested in where a character really should be right now, as opposed to where the client computer thought it should be. Usually you'd smooth out the difference (so-called "interpolation") so the effect won't be jarring.

For things that require being in order, events are preferable as they can be queued to clients in the proper order. Like chat messages for example. You wouldn't want it that you're hearing conversations backwards (e.g. see someone's answer before the question)!

Also stuff that don't need to be sent every so and so seconds, are preferable as events. Like an event where you accept a quest, or pick something up to put in your inventory.

Disclaimer: I'm no expert. Feel free to correct me if I'm wrong on anything.

share|improve this answer

The tribes and Q3 models are very similar, the core idea is exactly the same (unreliable delta sync), they only differ in implementation quite a bit.

share|improve this answer
Can you please elaborate on how the core idea is the same, what that similarity is? Events are much more than just deltas. – congusbongus Apr 3 '13 at 12:22

Your Answer


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.