Left4Dead networking

Here

L4D eats bandwidth and CPU. afaik, it's regular FPS shooter stuff. The server sends game states to the players, that includes zombies.

L4D if pretty conservative on the amount of projectiles. So in fairness, the bandwidth wouldn't be that much greater than in a 32 TF2 game with lots of demo / soldier spam.

One thing to bear in mind is that the Xbox 360 version is P2P, because there is no central server, which was probably one of the limiting factors in making it an 8-player game. However, to contradict this, it does seem like the PC version is clearly a client/server system, but that is not to say that perhaps the in-game entity management is not done P2P as is the case for the Xbox 360. Either way, the question is not so much enquiring about the topological properties of L4D networking, let's just say that it might be either or both.

Although I don't know all of the specifics, we can assume that the rough outline for the network model is the same as is used for other source games. This is a tried and true formula for Valve (and many other companies developing FPS games). Given that, we will assume a client / server model for the purpose of discussion, I think that it might also be safe to assume that for a single zombie entity, some player must assume 'control' of that entity, that is to send updates to his peers in the session with the data required to simulate that entity running on a peer machine. The main entities posing the biggest challenge being zombies (due to their numbers), with the special zombies maybe only requiring simple synchronisation techniques that deviate from the primary formula.

I think it is likely that the game world in L4D can be traversed by the AI using a node network as is common in FPS games. On the most simplistic layer, a zombie that spawns at point A has a target at point B, and may take a path that passes through any number of nodes on the way. Through observation it seems as though the route a zombie will take is precalculated, and this could be done using a fully deterministic algorithm, thus only requiring a start node and an end node to calculate a route using splines, which have several favourable properties useful to network simulation. This would be a good way to exploit existing AI data to save on bandwidth, though zombie behaviour is not quite so simple.

Zombies seem to have the ability to make simple decisions about their target using simple sensory inputs. For example, zombies may change their target temporarily to chase a pipe bomb, or they may prioritise a player based on distance or flashlight on / off status. Changes to the target have to be reflected by sending updates to game participants, and the delta compression algorithm favours less frequent updates.

Zombies also have the ability to perform actions whilst idle. They play various animations and wander around bumping into each other and occasionally fighting one another. These actions could be deterministic or synchronised, but it's probably more likely that it is a balance of both techniques to get an acceptable game experience.

In summary I don't think a single zombie entity requires much data to synchronise.

Quote:

Original post by TheGilb One thing to bear in mind is that the Xbox 360 version is P2P, because there is no central server, which was probably one of the limiting factors in making it an 8-player game. However, to contradict this, it does seem like the PC version is clearly a client/server system, but that is not to say that perhaps the in-game entity management is not done P2P as is the case for the Xbox 360. Either way, the question is not so much enquiring about the topological properties of L4D networking, let's just say that it might be either or both.

You got a source for that? The source engine is a client server model. Where do you get that it's peer to peer on 360? Source engine never had a 'central server' for anything other than finding games, which is the same on the consoles for most multiplayer games.

Quote:

One thing to bear in mind is that the Xbox 360 version is P2P, because there is no central server

I don't understand that, either. Client/Server is a topology; it doesn't need a central server in the sense of a rack of hardware in some data center. There is still a "host" for matchmaking purposes, and that "host" could still bounce incoming traffic to the other participants. The fact that they are all Xbox machines doesn't impact whether the topology is P2P or C/S.

Also, on the Xbox Live! network, there are central servers, in the form of the Live! servers. Those servers keep your gamertag, do leaderboards, do matchmaking, and facilitate UDP punch-through. The are not involved in the actual gameplay mechanics, though -- that's typically done by the hosting Xbox.

It's more likely that the 8 player limit is because an Xbox cannot be expected to have more than about 64 kbps upstream bandwidth (that's the lowest common denominator, and what you have to budget for to pass tech cert AFAIK).

It does not matter if there are 100 or even 1000 zoombies in the gameplay.
the zoombiens actions can be predicted in every side. the zoombies states data is not send from side to side because they are just simple predicted data caused by the user's input.

There is nothing fancy in this game's networking model, a client and server model

err... no, no way L4D is deterministic, if that's what you imply. Zombies state updates need to be sent at regular intervals.

Zombies seem to be regular entities, with ticking updates. What data they are made of is another matter. A* nodes? location target, with path extrapolated on clients? Full position / orientation updates?

I'd probably go with the last, you need very good accuracy in shooters, and L4D is good, path prediction would generate some pretty drastic out-of-sync states. Unless they have client-side hit detection.

When a L4D lags behind, you can see the zombies snapping back and forth, which points to the position-orientation updates.

Quote:

Original post by hplus0603 Quote: One thing to bear in mind is that the Xbox 360 version is P2P, because there is no central server I don't understand that, either. Client/Server is a topology; it doesn't need a central server in the sense of a rack of hardware in some data center. There is still a "host" for matchmaking purposes, and that "host" could still bounce incoming traffic to the other participants. The fact that they are all Xbox machines doesn't impact whether the topology is P2P or C/S. Also, on the Xbox Live! network, there are central servers, in the form of the Live! servers. Those servers keep your gamertag, do leaderboards, do matchmaking, and facilitate UDP punch-through. The are not involved in the actual gameplay mechanics, though -- that's typically done by the hosting Xbox.

Hi, on Xbox Live, the servers cannot bounce incoming traffic to the other participants in the manner that you suggest. The Live servers facilitate matchmaking only, once you're in-game it's P2P UDP all the way, unless you know of any Xbox 360 dedicated servers?? Just as a note: It's not impossible that Valve have a battery of Xbox 360 dedicated servers to support all the Xbox 360 gamers in all the world, but a model like that just isn't sustainable in terms of cost, and there's no monthly fee for playing L4D online to pay for those servers. Microsoft certainly wouldn't pay for that, they provide the servers for matchmaking only, and PC L4D dedicated servers aren't compatible with Xbox 360 consoles because the 360 has custom packet headers with encryption.

Quote:

Original post by hplus0603 It's more likely that the 8 player limit is because an Xbox cannot be expected to have more than about 64 kbps upstream bandwidth (that's the lowest common denominator, and what you have to budget for to pass tech cert AFAIK).

Yes you're absolutely correct. What I meant by the 8-player P2P limitation was implying that a 64kbps bandwidth limit would mean a maximum of 8-players. Even then the size of a packet sent to a single peer should average 32 bytes, and at least half that will be used by headers (IP header, UDP header, data header). Considering a single position / orientation uncompressed is around 28 bytes, this is why I'm talking about transmitting node indexes and interpolating the data, because then a single update for a zombie is 4 bytes (uncompressed 32-bit int, might be able to compress more), and the orientation can be derived. With delta compression this would compress down further to a single bit when the client acknowledges the data and it doesn't change.

The real question I am exploring here is not the in-game network topology, because that's not really the topic of the discussion in hand. The real secret to L4D networking is in the compression which enables the synchronisation of all those zombies within the given bandwidth constraints. I was speculating that a client/server model would be simpler because the server is authoritative (and thus, secure from hackers), and Valve know methods (as in other Source games) for compressing huge amounts of data and hiding latency. Extrapolating that idea I was speculating also that in a P2P model you could do a similar thing, except every client is also a server with authoritative control over a subset of the game entities, and also perhaps a simple algorithm for allowing clients to choose which entities they control (and also which entities are controlled by your peers).

P2P usually implies that all players talk directly to each other - there's no reason L4D must use P2P on Xbox 360. They can very well choose a player and have him run the authoritative simulation - that would make the topology Client/Server and not Peer-to-peer. L4D also has plenty of dynamic objects that zombies must navigate around or climb so any precalculating stuff will only go so far.

Afaik they did especially some optimizations for the zombies.
For example they (usually) don't send the height position of a zombie and only the planar coordinates
when they wander around - only if a height change is necessary they send it,
that shaves off one float per update, per zombie..

And I think there are more optimizations for them in place :)

Marc

Quote:

Original post by TheGilb Hi, on Xbox Live, the servers cannot bounce incoming traffic to the other participants in the manner that you suggest. The Live servers facilitate matchmaking only, once you're in-game it's P2P UDP all the way, unless you know of any Xbox 360 dedicated servers??

You don't need a dedicated server for a client-server network structure, one of the players can act as the host. Also one of the features of the source engine is that it supports cross-platform networking which wouldn't make sense if they used different network topologies. Infact P2P is hardly mentioned on the valve developer site - only in reference to cheating.

I'm not trying to say you couldn't make a game such as L4D that uses P2P, just that valve don't.

Quote:

the servers cannot bounce incoming traffic to the other participants in the manner that you suggest

The Live! servers absolutely perform NAT punch-through introduction. I did not suggest that they also route between the nodes in the general sense.

And, again, my point is that, just because the Xbox Live! network is "peer to peer" in the sense that the greater Internet is "peer to peer," doesn't mean that you need to use "peer to peer topology" for your networked game structure. In fact, most games are likely client/server, generally with the hosting Xbox also serving as server.

Finally, you can get dedicated server hardware onto the Xbox Live! network. It involves a serious (and expensive) business relationship with Microsoft, but has been done for things like console MMOs (I think Shadowrun did it, for example).

A separate reply: The Zombies in L4D follow the player, and get affected by the player. That means that they cannot be fully deterministic, because where I am on my machine is different from where I am on your machine, unless you introduce a command lag for every movement/command I give on my machine (a la RTS games). In general, what to do with AI characters that need to act on player-modified game state is one of the harder problems when trying to implement input-synchronous non-time-lagged games.

Quote:

Original post by TheGilb Hi, on Xbox Live, the servers cannot bounce incoming traffic to the other participants in the manner that you suggest. The Live servers facilitate matchmaking only

That's irrelevent. These games work the same on PC. You find matches from central match-making servers and end up playing either on a dedicated server or one of the players acts as the host.

Quote:

once you're in-game it's P2P UDP all the way, unless you know of any Xbox 360 dedicated servers??

Unlikely. The players themselves are the servers. Typically the one that created the game in L4D will be the server. On PC, it attempts to find a dedicated server when you start the game, if it can't it ends up using that player as the host. It may or may not do the same thing on Xbox 360, but in either case it's a client server model, not a P2P.

they maybe using p2p for voice comms. That's a hefty chunk of bandwidth that the game host does not have to forward to his clients.

I understand that on Xbox Live you could technically run a client / server setup, that's kids stuff, but what I'm saying is that assuming client / server on Xbox Live seems wrong given the bandwidth constraints. Let's take another Source game with a better known network architecture such as Counterstrike Source. With a tick rate of 33Hz, you need approximately 40kbps per player. That means you need 280kbps of upstream bandwidth to host an 8-player game, which would probably exclude about 30% of all players in the entire world from being able to host a game using that architecture on XBL. Left4Dead has even more data to synchronise, thus even less players could host. However if you use P2P then the load can be shared, thus I speculate that the solution is P2P, but each peer has authority over a subset of entities rather than the simulation as a whole.

The reason I think the architecture varies from XBL to PC is that on PC if player lags then none of the other players are affected. On XBL if a player lags then some of the zombies do not get updated. This leads me to the conclusion that XBL has P2P architecture and the subset of zombies that lag with the player are the ones that the player has authority over. On PC no zombies lag with the player because the server has authority over the entire simulation, and as already pointed out Valve prefer this model because it is safe from hackers. Even though client / server is safer from a hacking point of view, XBL networking is already protected by the XBL platform, which makes P2P a safer option, even if not an ideal solution.

it is possible, P2P complicates the architecture by quite a bit though. I wouldn't know for sure unless you ask the developers, but on PC, it's extremely rare to find a player-hosted game session that is playable. PC version is client-server.

There isn't any reason that they can't be using a hybrid architecture where the clients share the simulation and update load for zombies but still keep a single server for most of the authoritative stuff. Esp on the console where you're unlikely to have hacked machines, where on the PCs you have a very high chance the clients are compromised.

Given the number of zombies they have to update and the nature of the game, it makes good sense to do this ( ie have clients simulate and own local zombies ). The only way to find out if this is the case is to either ask the developers or do systematic tests on the game within a controlled environment.

Pure client server models are rarely used on the consoles these days, since you can trust the clients to a much higher degree than on the PCs, people put authoritative operations on the clients all the time now (ie doing their own forward authoritative extrapolation on physics, dynamic entity migration across peers, server migration, etc.. ) These are just some of the things I've seen.

If anything people aren't pushing the envelope enough, given a trusted network of peers you can do so much more ( ie fully persistent p2p mmos ). Maybe someone will do this with XNA, it would be awesome :D

-ddn

I believe Left4Dead attempts to reduce the load on the server for the PC version by loading fewer zombies in the world and instead clustering them near where the survivors currently are. (You can see this as a zombie by running ahead of the survivors).

This allows them to send less information to the clients as it isn't needed.