What do you think the basic design of the Left4Dead networking code looks like? Normally first person shooting multiplayer games have on average about 32 players on a server playing the same game at the same time. But Left4Dead has 8 players (in versus mode) and tons of zombies – how do they do it?! Each player sends minimal information to the server (e.g. their current speed and orientation etc) to be shared with other players, but in games like Left4Dead, every player also needs to have an update of the zombies position / status. The zombies are all AI driven, so am I right in thinking that a server must be completely authoritative and calculate everything to do with the zombie and constantly keep each player updated? This seems like a huge amount of game calculation on the server, and a high amount of extra networking activity compared to your standard multiplayer game. Does anyone know the specifics of this design?

Here

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.

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

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.