Development and Deployment of Multiplayer Online Games, Vol. II.
Development and Deployment of Multiplayer Online Games, Vol. II.
Minimum price
Suggested price
Development and Deployment of Multiplayer Online Games, Vol. II.

This book is 95% complete

Last updated on 2017-05-03

About the Book

IMPORTANT: currently Vol. II is supposedly text-complete, but formatting (especially EPUB/MOBI formatting) is still going to be done completely from scratch.

What's the Big Idea?

The idea behind this book is to summarize the body of knowledge that already exists on multiplayer games but is not available in one single place. And quite a few of the issues discussed within this series (planned as three nine volumes ~300 pages each), while known in the industry, have not been published at all (except for maybe in discussion forums). 

Programming and deploying an MOG is a daunting task, and having a frame of reference is usually quite helpful — "hey, those guys have already tried this, and it worked for them."

Vol. I-III of the series are about MOG Architecture. In Vol. I, we discussed general issues such as GDD - as well as Communicaton flows. By the end of Vol. II, we'll complete our discussion of the things related to architecting the Client-Side of your MOG, and will be ready to proceed with Server-Side Architecture (Vol. III); Vol. IV-VI will describe issues related to Programming, and Vol. VII-IX will be about Deployment and post-deployment tasks. 

Shameless Plug

The book has got endorsements from quite a few people known in the industry, including people from Amaya, Lloyds Bank, Lionhead Studios, BlueByte (Ubisoft Studio), Lightstreamer, Plarium, and (formerly) Zynga. For the endorsements themselves please see Kickstarter campaign.

And speaking of crowdfunding - the book has already been funded on Kickstarter and Indiegogo - with over 800 backers total (and counting). BTW, here on Leanpub there is a bundle which is exactly the same as an ongoing InDemand campaign on Indiegogo - $20 for Vol. I-III together with an early access (though on Indie there is also an option to pre-order paperback or even hardcover).

Since When Are Rabbits Programming??

I cannot speak for all of rabbitkind, but this particular hare has gone alongside my writings for quite a while now. He was born as "No MT Bugs" Hare in 2010, in an Overload article titled "Single-Threading: Back to the Future?"

Therefore, there is evidence that this particular rabbit has been programming at least since 2010. Yes, he has changed his appearance, but deep inside, he is still the very same bunny with a naïve idea of making programs less buggy. BTW, the character is created by Sergey Gordeev, a guy with many animation awards, known (among other things) for being a director of some of the Animated Mr. Bean series.

Who Is this Book For?

The book is intended for those intermediary developers who want to become senior ones, and for senior developers and up. I expect that the book will also be useful for decision-makers, from PMs all the way up to CEOs — so if you by any chance know one, please make sure to give her a link to this page ;-). 

On the other hand, if you are working on your first programming project, this book will probably be too difficult for you. There will be no explanation on what event-driven programming is all about, what's the difference is between optimistic locking and pessimistic locking, why you need a source control system, and so on. Instead, there will be discussions on how the concept of futures fits into event-driven programming, when the use of optimistic locking makes sense for games, and how to use source control in presence of unmergeable files

In the same spirit, the book is not intended to be a CD to copy-paste your sample MOG from. Instead, the book aims to help you write your own code that is tailored to your own needs, and tries to advise on the available choices at most of the junctions.

What's The Plan?

Vol. II is currently in "3rd beta", with 99% of the content I'm planning, already included. While there still may be some minor changes - the content is almost done.

As I'm working with professional editors (and vast majority of them doesn't know anything but Word :-( ) - I keep and edit my manuscript as a bunch of Word .docx files (I throw myself at the mercy of the court, and assure that it is only because of dire circumstances beyond my control ). I'm using Word to export .docx to PDF, and some_VBA_scripts+Calibre to export to .MOBI and .EPUB.

Please note that current formatting is quite ugly; it will improve after being professionally formatted; it is also expected to pass all the .EPUB validity checks.

Next steps:

  • The manuscript is already with "line editor" (that's what that Kickstarter money was for :-)).
  • Then - it will be sent to the typesetter
  • Then - it will be finalized here on Leanpub (and rewards for Kickstarter and Indiegogo backers will be sent out too)
  • And finally, it will be published on Kindle (and on Amazon via CS). At this point, price of the book may go higher here on Leanpub (to match Kindle price).


All the comments are extremely welcome - and they DO help making the book better.

Table of Contents

Chapter 4. DIY vs Re-Use: In Search of Balance

     Business Perspective: DIY Your Added Value

     Engine-Centric Approach: an Absolute Dependency a.k.a. Vendor Lock-In

           Implications of Vendor Lock-In

           Engine-Centric Approach: Pretty Much Inevitable for Indie MMORPG/MMOFPS

           Engine-Centric Approach: You Still Need to Understand How It Works

           Engine-Centric Approach: on “Temporary” dependencies

     “Re-Use Everything in Sight” Approach: An Integration Nightmare

     “DIY Everything”: The Risk of Never-Ending Story

     "Responsible Re-Use" Approach: In Search of Balance

           “Responsible Re-Use” Examples

           “Responsible Re-Use”: on "Temporary" dependencies


Chapter 5. Reactor-fest Architecture. I got Event Loop. I got Event Loop. I got All Event Loop

     On Terminology: Reactor, Event-Driven Program, Game Loop, ad-hoc Final State Machine, and so

     What NOT to use - “OO” RPC Frameworks

     Game Loop: Game Programming Classic

     Event Loop as a Generalization of Game Loop

           To React or Not to React?

                 Reactors or Not – Stay Away from Thread Sync in your Game Logic

           Other Event-Driven Systems: GUI, Erlang, Node.js, and Java Reactor

           On Separating Infrastructure Code from Logic Code

           Advantages of Reactors

           Reactors in Game Engines

     Two All-Important Improvements to Classical Event-Driven Programming: Mostly-Non-Blocking Pro

     Non-Blocking Processing

           To Block, or Not to Block, That is THE Question. Mostly-non-blocking Reactors

                 Case 1. Processing while Call is in Progress, is Required at Logic Level

                 Case 2. No Processing at Logic level while Call is In Progress

                 Blocking or Non-Blocking? - Mostly-non-Blocking

           Implementing Non-Blocking Processing for Games


                 Non-Blocking State Publishing

                 Point-to-Point Communications and other Non-Blocking Stuff

                 Handling non-blocking returns in Reactors

                       Take 1. Naïve Approach: Plain Messages (will work, but is Plain Ugly)

                       Take 2. Void-only RPCs (a tiny bit better, still Really Ugly)

                       Take 3. OO-Style: Less Error-Prone, but Still Way Too Much Boilerplate (


                             Cascading Exception Handlers

                       Take 4. Lambda Continuations and Callback Pyramid

                             On Continuations

                             Cascaded Exception Handling for Lambda Style

                       Take 5. Basic Futures

                             Differences from std::future<>, boost::future<>, folly::Future<>, etc.

                             Take 5 Summary

                       Take 6. Code Builder

                             Take 6a. Enter C++ Preprocessor


                                   Offloading Caveat: Keeping portions Large

                                   DON’T offload unless Proven Necessary

                                   Another Offloading Caveat: Flow Control

                       Take 7. Fibers/Coroutines

                             On boost:: coroutines and boost::context

                             On goroutines: BEWARE THREAD SYNC!

                       Take 8. async/await (.NET and JS proposal)

                       Surprise: All the different takes are functionally equivalent, and very close performan

                       Similarities to Node.js

                       Handling Non-Blocking Returns in Different Programming Languages

                       Serializing Reactor State

                             On serializable lambda closures in C++

                       Why so much discussion of this one thing?

                       TL;DR for Non-Blocking Communications in Reactors


           Distributed Systems: Debugging Nightmare

                 Non-Deterministic Tests are Pointless

                 The Holy Grail of Post Mortem

           Portability: Platform-Independent Logic as “Nothing But Moving Bits Around”

           Stronger than Platform-Independent: Determinism

           Deterministic Logic: Benefits

           On Replay-based Regression Testing and Patches

           On Fuzz Testing

           Deterministic Logic: On User Replay

           Implementing Deterministic Logic

                 Deterministic Logic: Modes

                 Implementing Inputs-Log

                       Going Circular

                 Recordable/Replayable InfrastructureEventHandler

                 Implementing Deterministic Logic: Dealing with non-Determinism due to System Calls

                       Dealing with System Calls: Original Non-Deterministic Code

                       Dealing with System Calls: “wrapping”

                       Dealing with System Calls: “Pure Logic”

                       Dealing with System Calls: Input Parameters as Reactor Data Members

                       Dealing with System Calls: TLS-based Compromise

                       Dealing with System Calls: Pool of On-Demand Data

                       Dealing with System Calls: On-Demand Data via Exceptions

                       Dealing with System Calls: Which System Functions We're Speaking About and What to do A

                 Implementing Deterministic Logic: Other Sources of Non-Determinism

                       No Access to non-const Globals and TLS

                       On Pointers

                       On Threads

                 Implementing Deterministic Logic: non-Issues




                             On Isolation Perimeters

                 Implementing Deterministic Logic: Cross-Platform Determinism

                       Achieving Cross-Platform Determinism

                 Implementing Deterministic Logic: Summary

           Types of Determinism vs Deterministic Goodies

           Relation of Deterministic Reactor to Deterministic Finite Automata

                 Deterministic Finite State Machines: Nothing too New But...

           TL;DR for Determinism Section

     Divide et Impera, or How to Split the Hare the Hair the Reactor

           Composition: Reactor-within-Reactor

           State Pattern

                 Getting Rid of Big Ugly Switch

                       Common Data Members

                       Potentially Expensive Allocations

                 Hierarchical States


     Reactors, Exceptions, and VALIDATE-CALCULATE-MODIFY Pattern

           Validate-Calculate-Modify Pattern

                 Exceptions before Modification Stage are Safe, including CPU exceptions

                 RAII equivalents in Different Programming Languages

                 Posting Messages (calling RPCs, etc.) within Validate/Calculate

                 Exception Safety for Modify stage


                 Validate-Calculate-Modify Summary

     Scaling Reactors

           Splitting and Offloading

           Reactor-with-Mirrored-State – Limited Relief


     Reactor-fest Architecture

           Reactor Factories

           Reactors and Programming Languages

           Relation of Reactor-Fest to Other Systems

                 Relation to Actor Concurrency

                 Relation to Erlang Concurrency, Akka Actors, and Node.js

                 Reactors and Microservices as Close Cousins

                       Physical Server – VM - Docker – Reactor as a Spectrum of Tradeoffs between Isolation an

     Summary of Chapter 5

     Appendix 5.A. C++-Specific Examples and Comments for Chapter 5

                       Avoiding Expensive Allocations

                 C++: Enforcing const-ness for Validate-Calculate-Modify

Chapter 6. Client-Side Architecture.

     Graphics 101

           On Developers, Game Designers, and Artists

           On Using Game Engines as Pure Graphics Engines, and Vendor Lock-In

           Types of Graphics

                 Games with Rudimentary Graphics

                 Games with 2D Graphics

                 On pre-rendered 3D

                 Games with 3D Graphics

     Very Generic Architecture

           Logic-to-Graphics API

                 Dual Graphics, including 2D+3D Graphics

           Modules and Their Relationships

                 Game Logic Module

                       Game Logic Module & Graphics

                       Game Logic Module: Client-Side Prediction and Simulation

                       Game Logic Module: Game Loop

                       Game Logic Module: Keeping it Cross-Platform

                 Animation&Rendering Module

                 Communications Module

                 Sound Module

           Relation to MVC

           Differences from Classical 3D Single-Player Game

                 Interaction Examples in 3D World: Single-Player vs MOG

                       MMOFPS interaction example (shooting).

                       MMORPG interaction example (ragdoll).

                       UI interaction example.

     Reactor-fest Client-Side Architecture

           Reactor-fest Client Architecture

           Reactor Specifics

                 Animation&Rendering Reactor and Game Loop

                 Communications Reactor and Blocking/Non-Blocking Sockets

                 Other Reactors

           On Reactors and Latencies


           On Code Bases for Different Platforms

           Scaling Reactor-fest Architecture on the Client

                 Parallelizing Client-Side Reactors

           Summary of Reactor-fest Architecture on the Client-Side

     Programming Language for Game Client

           One Language for Programmers, Another for Game Designers (MMORPG/MMOFPS etc.)

           A word on CUDA and OpenCL

           Different Languages Provide Different Protection from Bot Writers

                 Resilience to Reverse Engineering of Different Programming Languages

                       Compiled Languages

                       Languages which compile to Byte-Code

                       Interpreted Languages

                       On Compilers-with-Unusual-Targets


           Language Availability for Game Client-Side Platforms

           On Garbage Collection

                 On “Stop-the-World” problem

                 To GC or Not to GC?

           On Consistency between Client-Side and Server-Side languages

           Sprinkle with All The Usual Considerations

           C++ as a Default Game Programming Language

                 On C++ and Cross-Platform Libraries

           Big Fat Browser Problem

                 Line-to-Line Translations: “1.5 code bases”

                       Line-to-Line Translations: Are They Practical?

                 Client-on-Server Trick

     Bottom Line for Chapter 6

Chapter 7. Client-Driven Development: Unity, UE, Lumberyard, and 3rd-party Network Libraries

On Client-Driven vs Server-Driven Development Workflows

On Server-Driven Development Workflow

Client-Driven Development Flow

Implementing Client-Driven Workflows

Single-player prototype and “continuous conversion”

Engine-Provided Server vs Standalone Server

Important Clarification: Development Workflow vs Data Flow

Three Most Popular 3rd-party Game Engines

Unity 5

Event-Driven Programming/Reactors

Built-In Communications: HLAPI (for Engine-Provided Server)

State Synchronization

RPCs (a.k.a. “Remote Actions”)

HLAPI Summary

Built-In Communications: LLAPI (both for Engine-Provided Server and Standalone Server)

3rd-party Communications for Unity: Photon Server

Photon Server SDK

Photon Cloud/PUN

3rd-party Communications for Unity: SmartFoxServer

3rd-party Communications for Unity: uLink

3rd-party Communications for Unity: DarkRift

3rd-party Communications for Unity: Lower-Level Libraries

Unity 5 Summary

Engine-Provided Server. HLAPI now, probably LLAPI later

Standalone Server with Export from Unity

Engine-Provided vs Standalone: Which One is Better?

Unreal Engine 4

Event-driven Programming/Reactors

UE for MOG

UE Communications: very close to Unity 5 HLAPI

UE Communications: Lower-Level C/C++ Libraries

Reliable UDP Libraries

Event Handling Libraries

Socket Wrapper Libraries

UE4 Summary: Engine-Provided and Standalone Servers

Amazon Lumberyard

A choice between Amazon-Only Hosting – and (hopefully) Co-Location

Amazon Lumberyard Communications: GridMate

Amazon Lumberyard: Summary and Engine-Provided/Standalone Servers

The engine that didn’t make it - Source

Comparison Table

Summary for Chapter 7

Bundles that include this book

Development & Deployment of Multiplayer Online Games Vol. I
Development and Deployment of Multiplayer Online Games, Vol. II.
Development and Deployment of Multiplayer Online Games, Vol. III.
3 Books
Suggested Price
Bundle Price

About the Author

'No Bugs' Hare
'No Bugs' Hare

20 years ago (damn, I am getting old) I was a co-architect for an electronic stock exchange of a G20 country, and for all practical intents and purposes stock exchanges are just another game genre. The project was fun and, among other things, allowed for real-time trading over the cellphones of that time (those with 9600 baud connection).

A few years later, I became a chief software architect working for a start-up that quickly grew into a rather large online game with half a million simultaneous players that processed half a billion user transactions per day. The project taught me a damn lot about such different issues as scalability, DB physical layout, server farms, attackers and cheaters of all kinds, and bot fighting — just to name a few.

Since then, I have consulted and performed due diligence on several game-related projects. In addition, I've spent quite some time researching the field and discussing related problems and their respective solutions with people from the industry.

I feel that this puts me in quite a unique position of knowing not only one single game, but a bunch of them, and being able to summarize and generalize my real-world experiences. Oh, and I have been writing for industry journals (and am especially proud of articles in CUJ and C++ Report) since 1998, so the process of typing sentences is not something new for me either.

If you really want further details, you can dig them out of my LinkedIn page

About the Contributors

Sergey Gordeev
Sergey Gordeev


Sergey Gordeev (currently from is an animator with a dozen of awards from different festivals. He is most known for his work as a director of Animated Mr Bean series.

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub