What do you think?
Rate this book
Multiplayer Game Programming: Architecting Networked Games
The Practical Guide to Building Reliable Networked Multiplayer Games
Networked multiplayer games are a multibillion dollar some games now attract tens of millions of players. In this practical, code-rich guide, Joshua Glazer and Sanjay Madhav guide you through every aspect of engineering them. Drawing on their immense experience as both game developers and instructors, the authors lead you through building a robust multiplayer architecture, and creating every engine-level system. You’ll learn through in-depth working code examples for two complete an action game and a real time strategy (RTS) game.
First, Madhav and Glazer review the essentials of networking and network programming from the standpoint of game developers. Next, they walk through managing game data transmission, updating game objects across the network, and organizing the devices that join your game. You’ll learn how to ensure reliable performance despite the Internet’s inherent inconsistencies, and how to design game code for maximum security and scalability. The authors conclude by addressing two increasingly crucial incorporating gamer services and hosting your games in the cloud.
This guide’s content has been extensively tested through the authors’ multiplayer game programming courses at USC. It is equally valuable both to students and to working game programmers moving into networked games.
Coverage includes
How games have evolved to meet the challenges of networked environments Using Internet communication protocols and standards in game development Working with Berkeley Socket, the most widely used networking construct in multiplayer gaming Formatting game data for efficient Internet transmission Synchronizing states so all players share the same world Organizing networking topologies for large-scale games Overcoming latency and jitter problems that cause delays or lost data Scaling games without compromising performance Combating security vulnerabilities and software cheats Leveraging the networking functionality of the popular Unreal 4 and Unity game engines Integrating gamer services such as matchmaking, achievements, and leaderboards Running game servers in the cloud About the Website C++ source code for all examples is available at github.com/MultiplayerBook . Instructors will also find a full set of PowerPoint slides and a sample syllabus.
Networked multiplayer games are a multibillion dollar some games now attract tens of millions of players. In this practical, code-rich guide, Joshua Glazer and Sanjay Madhav guide you through every aspect of engineering them. Drawing on their immense experience as both game developers and instructors, the authors lead you through building a robust multiplayer architecture, and creating every engine-level system. You’ll learn through in-depth working code examples for two complete an action game and a real time strategy (RTS) game.
First, Madhav and Glazer review the essentials of networking and network programming from the standpoint of game developers. Next, they walk through managing game data transmission, updating game objects across the network, and organizing the devices that join your game. You’ll learn how to ensure reliable performance despite the Internet’s inherent inconsistencies, and how to design game code for maximum security and scalability. The authors conclude by addressing two increasingly crucial incorporating gamer services and hosting your games in the cloud.
This guide’s content has been extensively tested through the authors’ multiplayer game programming courses at USC. It is equally valuable both to students and to working game programmers moving into networked games.
Coverage includes
How games have evolved to meet the challenges of networked environments Using Internet communication protocols and standards in game development Working with Berkeley Socket, the most widely used networking construct in multiplayer gaming Formatting game data for efficient Internet transmission Synchronizing states so all players share the same world Organizing networking topologies for large-scale games Overcoming latency and jitter problems that cause delays or lost data Scaling games without compromising performance Combating security vulnerabilities and software cheats Leveraging the networking functionality of the popular Unreal 4 and Unity game engines Integrating gamer services such as matchmaking, achievements, and leaderboards Running game servers in the cloud About the Website C++ source code for all examples is available at github.com/MultiplayerBook . Instructors will also find a full set of PowerPoint slides and a sample syllabus.
384 pages, Kindle Edition
First published November 1, 2015
43 people are currently reading
265 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 6 of 6 reviews
April 26, 2020
Toying with some collaborative web features, and I thought skimming a book on networking in gaming was likely to teach me something interesting. In particular, I was interested in what techniques games use to deal with latency, reliability, and desync between clients. Chapters exist on low-level network details (what's a socket, what's TCP/IP, what's Ethernet), which I skimmed faster to get to the game-specific content. There's an interesting chapter on UDP vs TCP for games. It boils down to this: if there's any level of quality of service between objects and strong real-time requirements, something based on UDP (which is most games). Otherwise, entertain TCP (turn-based games would do fine here).
It's quite possible for clients to somehow get out of sync. Perhaps a bug placed an object slightly differently in two games. In general, in my experience, when you send a lot of incremental state, at some point, you'll get out of sync unless there's a mechanism to directly prevent this (e.g. log offset). If this is not accounted for, a butterfly effect can easily take form, especially in an RTS game. A rock is placed slightly differently, and players run around it or cover it in one, but not in another. Someone lost 10 health for one player, but not another. To combat this, a hash is continuously exchanged between client and server. If they don't match, some action is taken. In some cases, you're just kicked out of the game, in others, you might get transmitted a known good state.
What about lag? Most games use a generous amount of interpolation (smoothen the transition between two known good states) and extrapolation (try to predict the future based on current events) to deal with lag. Some of the first networked games did none of this, and relied on synchronization with the server on every step (e.g. Quake). Others have a turn-based model, RTS such as Age of Empires or Starcraft, with 100-200ms turns.
What I was more interested in are the ones that are synced in real-time (they seem most complicated), such as shooters (this is more applicable to real-time collaboration). They only receive events every so often (1/2 round-trip time), so between those events they do smoothening of events through interpolation. Otherwise the game would seem 'jumpy.' Clients may also do extrapolation, if someone is running in some direction, at some speed, your client may continue to assume that (and have to correct it if the next event from the server says they stopped before your client animated them to). In this model, the server is the source of truth, and the clients continue to guess what might happen to avoid constantly jumping to a very new frame if the server tells it to. These techniques are very common today, and seem to be supported well by the modern Game Engines.
A technique I found particularly fascinating is "rewinding." If you have another player in your sniper scope, and click, you expect it to hit them. However, in the 20-50ms before it hits the server, the other player may have duck (which you might not have had a chance to see). A technique pioneered by Valve's Source engine is to favour the shooter in this case, and rewind the state on the server to the client's point in time, verify, and then log an event for the shot. This may be frustrating for the victim, as they _may_ have duck in the interim.
The few chapters I read in detail on the tips and tricks were interesting, but I think if I were someone who was about to write a networked game, I'd be disappointed. There's still a lot of questions in my mind about how all this works, and how various edge-cases are addressed. I'd love to see demos of games with and without the various strategies to really understand how they work, and get an intuitive sense for how latency of various values affect the game. The writing style was very approachable, kudos to the author for that.
It's quite possible for clients to somehow get out of sync. Perhaps a bug placed an object slightly differently in two games. In general, in my experience, when you send a lot of incremental state, at some point, you'll get out of sync unless there's a mechanism to directly prevent this (e.g. log offset). If this is not accounted for, a butterfly effect can easily take form, especially in an RTS game. A rock is placed slightly differently, and players run around it or cover it in one, but not in another. Someone lost 10 health for one player, but not another. To combat this, a hash is continuously exchanged between client and server. If they don't match, some action is taken. In some cases, you're just kicked out of the game, in others, you might get transmitted a known good state.
What about lag? Most games use a generous amount of interpolation (smoothen the transition between two known good states) and extrapolation (try to predict the future based on current events) to deal with lag. Some of the first networked games did none of this, and relied on synchronization with the server on every step (e.g. Quake). Others have a turn-based model, RTS such as Age of Empires or Starcraft, with 100-200ms turns.
What I was more interested in are the ones that are synced in real-time (they seem most complicated), such as shooters (this is more applicable to real-time collaboration). They only receive events every so often (1/2 round-trip time), so between those events they do smoothening of events through interpolation. Otherwise the game would seem 'jumpy.' Clients may also do extrapolation, if someone is running in some direction, at some speed, your client may continue to assume that (and have to correct it if the next event from the server says they stopped before your client animated them to). In this model, the server is the source of truth, and the clients continue to guess what might happen to avoid constantly jumping to a very new frame if the server tells it to. These techniques are very common today, and seem to be supported well by the modern Game Engines.
A technique I found particularly fascinating is "rewinding." If you have another player in your sniper scope, and click, you expect it to hit them. However, in the 20-50ms before it hits the server, the other player may have duck (which you might not have had a chance to see). A technique pioneered by Valve's Source engine is to favour the shooter in this case, and rewind the state on the server to the client's point in time, verify, and then log an event for the shot. This may be frustrating for the victim, as they _may_ have duck in the interim.
The few chapters I read in detail on the tips and tricks were interesting, but I think if I were someone who was about to write a networked game, I'd be disappointed. There's still a lot of questions in my mind about how all this works, and how various edge-cases are addressed. I'd love to see demos of games with and without the various strategies to really understand how they work, and get an intuitive sense for how latency of various values affect the game. The writing style was very approachable, kudos to the author for that.
February 5, 2017
Not ideal, but still one of very few books on the subject worth opening
First half of the book is not game-specific, with many barely-relevant details (umptieth repeat of TCP 3-way handshake, anybody?)
And then, just when things are about to become interesting, there are no more pages in the book, and descriptions become sketchy. And while descriptions of Client-side prediction and interpolation are sketchy but bearable, discussion of scalability and security is way too short.
Statement that "[performance] is not an issue on the back-end" is also questionable, to say the least.
Still, given the lack of other even half-decent books on the subject, this one will have to do.
First half of the book is not game-specific, with many barely-relevant details (umptieth repeat of TCP 3-way handshake, anybody?)
And then, just when things are about to become interesting, there are no more pages in the book, and descriptions become sketchy. And while descriptions of Client-side prediction and interpolation are sketchy but bearable, discussion of scalability and security is way too short.
Statement that "[performance] is not an issue on the back-end" is also questionable, to say the least.
Still, given the lack of other even half-decent books on the subject, this one will have to do.
November 18, 2022
Stuff i liked:
Great work explaining the networking OSI model.Probably best material i have read in all my technical years (including the dedicated course in university). The physical, link layer , NAT, NIC , headers all explained so nice with a lot of examples and pictures.
Great at explaining state machines , the lower level of networking in a game , Berkeley sockets , streams, checksums, retry packet strategies bandwidth etc...
Great work on expalining how to reduce traffic by using entropy prediction for the state of the game !
Superb work at explaining strategies to mitigate latency, jitter using interpolation, extrapolation and many other techniques.
Really appreciated that the book included a section on what it means for a game to have intrgrated game services (for example Steam) , anticheat strategies and moving to cloud
The stuff i didn't grok:
Though the book was deep in many aspects it jumped ahead and raced exactly when having to explain how does one manage partitioned world state in a MMORPG like World of Warcraft, how do you provide fallbacks and how do you distribute players across geograhpyically distributed servers.
I get that game programming is done mostly in C++ but i found it many times cumbersome to read the code samples with the pointers and all that stuff. I think pseudocode or any other high level language would have worked, or even more diagrams. Its ok to read a class containing 1-3 mrthods , but when the sample is pages long C++ will be in your way (if you are not a cpp dev)
Some sections included too much code and a too deep dive where i think it wasn't necessary.
I would say this book is great for starters into Networked Games, but beyond that when you have some experience i would use carefully selected chapters of this book as refrences.
Good book all in all !
Great work explaining the networking OSI model.Probably best material i have read in all my technical years (including the dedicated course in university). The physical, link layer , NAT, NIC , headers all explained so nice with a lot of examples and pictures.
Great at explaining state machines , the lower level of networking in a game , Berkeley sockets , streams, checksums, retry packet strategies bandwidth etc...
Great work on expalining how to reduce traffic by using entropy prediction for the state of the game !
Superb work at explaining strategies to mitigate latency, jitter using interpolation, extrapolation and many other techniques.
Really appreciated that the book included a section on what it means for a game to have intrgrated game services (for example Steam) , anticheat strategies and moving to cloud
The stuff i didn't grok:
Though the book was deep in many aspects it jumped ahead and raced exactly when having to explain how does one manage partitioned world state in a MMORPG like World of Warcraft, how do you provide fallbacks and how do you distribute players across geograhpyically distributed servers.
I get that game programming is done mostly in C++ but i found it many times cumbersome to read the code samples with the pointers and all that stuff. I think pseudocode or any other high level language would have worked, or even more diagrams. Its ok to read a class containing 1-3 mrthods , but when the sample is pages long C++ will be in your way (if you are not a cpp dev)
Some sections included too much code and a too deep dive where i think it wasn't necessary.
I would say this book is great for starters into Networked Games, but beyond that when you have some experience i would use carefully selected chapters of this book as refrences.
Good book all in all !
This entire review has been hidden because of spoilers.
June 23, 2024
Very good, really. Just no modern c++.
January 7, 2023
Entra en detalle con implementaciones de ejemplo, considera muchos casos de uso y problemas concretos para reducir latencia, pérdidas de paquetes, etc
December 5, 2021
Fantastic introduction to what goes on "under the hood" in a networked game. I've seen people complaining that this isn't a sufficiently advanced reference, and perhaps that is true...but for someone like me with little experience developing networked applications, I learned A LOT. In particular, the chapters on serialization/deserialization, state replication, and building a custom reliability layer on top of UDP were tremendously useful for me—not necessarily because I will now be using that exact code in my projects, but because I now have much greater awareness of the design challenges faced and approaches for solving them.
The authors are experts at communicating the material in an approachable way. There were a few times where I was reading code snippets and wondering, "huh, why would this edge case ever occur?", only to find that the next paragraph addressed that exact point. Overall, a pleasure to read.
The authors are experts at communicating the material in an approachable way. There were a few times where I was reading code snippets and wondering, "huh, why would this edge case ever occur?", only to find that the next paragraph addressed that exact point. Overall, a pleasure to read.
Displaying 1 - 6 of 6 reviews