Development and Deployment of Multiplayer Online Games, Vol. II.
Development and Deployment of Multiplayer Online Games, Vol. II.
DIY, (Re)Actors, Client Arch, Unity/UE4/Lumberyard
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).
Comments
All the comments are extremely welcome - and they DO help making the book better.
About the Author
Bundles that include this book
About the Contributors
Illustrator
Sergey Gordeev (currently from gagltd.eu) 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.
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
Summary
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
Timers
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 (
Exceptions
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
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
Determinism
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
PRNG
Logging/Tracing
Caching
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
Stack-of-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-Simulate
Validate-Calculate-Modify Summary
Scaling Reactors
Splitting and Offloading
Reactor-with-Mirrored-State – Limited Relief
Reactor-with-Extractors
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
Variations
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
Summary
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
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
