Author:	“No Bugs” Hare  Follow:
	Job Title:	Sarcastic Architect
	Hobbies:	Thinking Aloud, Arguing with Managers, Annoying HRs, Calling a Spade a Spade, Keeping Tongue in Cheek

UPDATE: the book has grew soooo large that we decided to split it into 9 volumes (about 300 pages each) instead of three. It means that we plan to print the content which was planned as original Vol.1 as “new” Vol.I-Vol.III, the content planned for original Vol.2 – as “new” Vol. IV-Vol.VI, and the content intended for original Vol. 3 – as “new” Vol. VII-Vol.IX. If you have backed this book on Kickstarter or Indiegogo – please see relevant updates on KS and on Indie. 

The book is WIP

“Development and Deployment of Multiplayer Online Games” (#DDMoG for short), consists of 3 parts: ARCH(itecture), PROG(ramming), and DEPL(oyment). Each part is planned as 3 volumes.

Current status:

• Part ARCH.
  • Vol. I is currently available on Amazon.
  • Vol. II – is in “3rd beta”, and Vol. III – is in “2nd beta”. “1st beta” versions are available on this site. Current versions are available to backers as an “early draft” on Indiegogo and on Leanpub.
• Part PROG. All Vol. IV-Vol. VI are in “1st beta” and are available on this site, see below
• Part DEPL. Vol. VII’s “1st beta” is being written – and Vol. VIII-Vol. IX are still planned.

Table of Contents

Part ARCH. Architecture

OBSOLETE (“1st beta”), available online

Chapter 1(a). Business Requirements
Chapter 1(b). Game Entities and Interactions
Chapter 2. On Cheating, P2P, and [non-]Authoritative Servers
Chapter 3(a). Protocols. RTT, Input Lag, and Mitigation
Chapter 3(b). Protocols. World States and Reducing Traffic
Chapter 3(c). Protocols. Point-to-Point Communications and Non-blocking RPCs
Chapter 3(d). Protocols. IDL: Encodings, Mappings, and Backward CompatibilityChapter 4. DIY vs Re-Use: In Search of Balance
Chapter 6(a). Client-Side. Graphics
Chapter 6(b). Client-Side. Programming Languages
Chapter 6(c). Client-Side. On Debugging Distributed Systems, Deterministic Logic, and Finite State Machines
Chapter 6(d). Client-Side. Client Architecture Diagram, Threads, and Game Loop
Chapter 7. Unity 5 vs UE4 vs Photon vs DIY
Chapter 8a. Scalability for MOGs
Chapter 8b. Scaling Stateful Objects
Chapter 9(a). Server-Side. Naïve, Web-Based, and Classical Deployment Architectures
Chapter 9(b). Server-Side. Front-End Servers and Client-Side Random Load Balancing
Chapter 9(c). Server-Side. Eternal Windows-vs-Linux Debate
Chapter 9(d). Server-Side. Asynchronous Processing for Finite State Machines/Actors: from plain event processing to Futures (with OO and Lambda Call Pyramids in between)
Chapter 9(e). Server-Side. Programming Languages
Chapter 11. Pre-Coding Checklist: Things Everybody Hates, but Everybody Needs Them Too. From Source Control to Coding Guidelines

Stats for CURRENT version of Vol. I-III:

• 270’000 words (~1000 pages)
  • +~150% more content added compared to “1st beta”
  • ~half of content of “1st beta” rewritten (subjective)
  • overall, ~80% of the content in “2nd beta” is new compared to “1st beta”

Part PROG. Programming

Part DEPL. Deployment

[[Now, we will interrupt our beta book, and will ask you a question:

 Loading ...

EDIT: POLL IS CLOSED NOW

Back to the book…]]

About

About the Author. The author of this book is a ‘No Bugs’ Hare from the warren of Bunnylore. He is known for being a columnist for Overload journal (ISSN 1354-3172) and for his significant contributions to software development blog ithare.com. As ‘No Bugs’ is a rabbit with his mother tongue being Lapine, he needed somebody to translate the book into some human language. And of course, as the book is highly technical, to translate technical details with the highest possible fidelity, he needed a translator with substantial development experience.

About the Translator. This book has been translated from Lapine language by Sergey Ignatchenko, a software architect since 1996. He is known for writing for industry journals since 1998, with his articles appearing in CUJ, Overload, C++ Report, and (IN)SECURE Magazine. His knowledge of Lapine is quite extensive, and he is routinely translating the column which ‘No Bugs’ writes for Overload. During Sergey’s software architecting career, he has been leading quite a few projects, including being a co-architect of a G20 stock exchange (the same software has been used by stock exchanges of several other countries too), and a sole original architect of a major gaming site (with hundreds of millions user transactions per day, and processing hundreds of millions of dollars per year). As a kind of paid hobby, he’s also inventing things: he’s an author and co-author of about a dozen of patents (unfortunately, owned by his respective employers 🙁 ).

About the Illustrator. Illustrations for this book are made by Sergey Gordeev from gagltd.eu. He is a professional animator with 10+ awards from various animation festivals, and is known for being a director of some of Animated Mr. Bean series.

Scope

Whenever you open a book for the very first time, you naturally have two questions: “Is this book for me?” and “What is this book about?”. First, let’s see whether this book is for you if you want to use a 3rd-party game engine.

Whether Writing Your Own Engine or Choosing an Existing One, You Do Need This Book

“One thing you should never do, is blindly believing that the engine will be a perfect fit to your specific gameIn many cases it may be very tempting to use an existing (usually 3rd-party) game engine rather than to develop your own one. And quite often it may be a Really Good Idea to do so. However, one thing you should never do when developing anything-more-complicated-than-two-player-tic-tac-toe, is blindly believing that the engine will be a perfect fit to your specific game. Even when the game engine is used by dozens of highly successful games – there is no guarantee that it will work for your specific requirements (unless, of course, you’re making a 100% clone of one of these games).

Instead of assuming “The Engine Will Do Everything Exactly As We Want”, you should try to understand all the relevant implications of the engine-you’re-about-to-choose, and see if its limitations and peculiarities will affect you badly down the road. This is where this book will be useful. It won’t compare existing engines, but it will describe (and explain) principles which are necessary to build a technically successful multi-player game. It means that you will be able to make an informed decision about the game engine (and maybe will decide to write your own parts to complement the existing engine).

So, if you’re going to choose an existing game engine – you need to understand how game engines work (so you can choose the game engine which is suitable for your needs even when you grow to millions of players). And if you’re going to write your own game engine – you certainly need to understand how game engines work. It means that

That’s all what matters for now; we’ll discuss pro- and contra- arguments for DIY over reusing 3rd-party stuff in Chapter [[TODO]].

Focused on Massively Multi-Player Games, but Applies to LAN-based Games Too

“If you're about to write a LAN-based game – most of the this book still applies, but make sure to read AppendixNow let’s try to answer the question “What is this book about?” As the title suggests, this particular book is all about massively multi-player games working over the Internet. It means that single-player games are certainly not our focus; however, for LAN-based multi-player games with only a few players this book is relevant (to a certain extent). While you certainly can build a LAN-based game along the lines described in this book, and it will work, doing it in a way-optimized-for-massively-multiplayer-environments may involve quite a few overkills, which in turn may lead to unnecessary delays with releasing your game. If you’re about to write a LAN-based game – most of the this book still applies, but make sure to read Appendix “Applicability to LAN-based games” for discussion of potential simplifications which you may apply. [[Beta notice: at this point Appendix is tentative and not guaranteed]]

Whenever saying “massively multi-player” game, I mean that the game should be able to reach really massive numbers; if following the advice in this book (including that of in Part D), millions of the players should be perfectly doable; I’ve personally architected a site which has hundreds of thousands of simultaneous players and handled hundreds of millions of user transactions per day.¹

Genres: From Social Games to MMOFPS, with Stock Exchanges in Between

When it comes to the game genres, this book aims to cover all of them (as long as multiple players are involved). While these games vary in terms of requirements imposed on the engine, these requirements are still interrelated; moreover, these requirements represent a more-or-less continuous spectrum, so breaking it at any given point would be quite arbitrary. Let’s take a look at the Latency Tolerance a.k.a. Acceptable Input Lag (which is one of the most important requirements from the multiplayer game engine perspective):²

• Social Games (usually Facebook/Phone). Typical Latency Tolerance: usually minutes are ok
• MMO Turn-Based Strategies. Typical Latency Tolerance: seconds
• Multi-Player Casino Games (bingo, blackjack, poker). Typical Latency Tolerance: single-digit seconds
• Stock Exchanges and Sports Betting. Typical Latency Tolerance: as fast as possible, though most important is “being fair” requirement.
• Massively Multiplayer Online Real-Time Strategies (MMORTSs). Typical Latency Tolerance: low triple-digit milliseconds
• Massively Multiplayer Online Role-Playing Games (MMORPGs). Typical Latency Tolerance: < 200-300 milliseconds
• Massively Multiplayer Online First-Person Shooters (MMOFPSs). Typical Latency Tolerance: high double-digit milliseconds

As you can see, there is a whole spectrum of latency requirements, from minutes for social games to high double-digit milliseconds for MMOFPS, with pretty much everything in between. However, we will see that as soon we take latencies into account, further differences between genres become much less pronounced from the multiplayer engine perspective.

Topics: All But Gameplay/AI/Monetization

“While we're not about to answer the question “WHAT do you want to do?”, we will try to answer the question of “HOW to do whatever-you-want-to-do”Game development and deployment is a huge task, so it is important to realize what exactly we want to cover. This book is very ambitious in this regard: it aims to cover all the aspects of game development and deployment, with one (though all-important) exception. In this book, we won’t try to answer questions such as “What should your game be about?”, “How should your game look?”, and “How to make money out of your game” ; these are all-important business questions which you need to answer yourself. When starting development you should know exactly how you want your game to be played, how you want it to look, how your AI (if applicable) will work, and how you’re going to monetize it.³ These questions are completely out of scope of this book.⁴

On the other hand, as soon as you have answers to these questions – this book has got you covered. We’ll discuss pretty much everything you will need to release your game and keep it running, from overall architecture to deployment and post-deployment issues.

In other words: while we’re not about to answer the question “WHAT do you want to do?”, we will try to answer the question of “HOW to do whatever-you-want-to-do” in as much detail as we can fit into one single book.

Too Large to Fit and Therefore Sketchy: 3D and Physics

While we’re aiming to answer all the questions related to “HOW to do whatever-you-want-to-do”, there are a few issues which are very large on their own, and just wouldn’t fit into one single book. As a result, these issues are admittedly sketchy in this book; while we will have a chapter on 3D graphics and sound (and will discuss physics engines too), please don’t expect this to be as detailed on these topics as those books which are dedicated to 3D engine design.

What is included, should be sufficient to choose your 3D engine (which can often work as a physics engine too). However, if you want to write your own 3D/physics engine, you will need to go beyond this book (I will provide necessary pointers within appropriate chapter).

Prerequisites

“If your game project is your very first programming project – you're likely to have difficulties understanding this bookThis book is targeted towards at least somewhat experienced developers (in other words, it is NOT “how to develop your first program” book with IDE screenshots and copy-paste examples). If your game project is your very first programming project – you’re likely to have difficulties understanding this book⁵. For example, I am not going to explain what the “function” (“database” etc.) is; also I expect you to know what “source control” is and why it is necessary, and why encapsulation is a Good Thing(tm).

On the other hand, this book doesn’t rely on in-depth knowledge in any specific area. You don’t need to be a network guru who knows every tiny detail of RFC 793 by heart, neither you need to have hand-on experience with shaders and/or CUDA; even less I expect you to be a C++ guru who is capable of writing boost-like templates (to be honest, at the moment this last one is beyond my own capabilities too). Of course, 3D graphics experience may be helpful for 3D games, and knowledge of network basics and sockets won’t hurt in any case, but whenever discussing the issues which go beyond “things which every developer out there should know anyway”, I will try to provide pointers “where to read about this specific stuff if you happen to have no idea about it”.

CD NOT included

The book is not going to have an associated CD. First, any attempt to provide CD-with-sample-code almost inevitably ends up in a very platform-specific code, and as one of the main points of the book is that your platform depends on your needs, providing heavily platform-specific code to illustrate this point will be a kind of oxymoron. Second, as mentioned above, this book is not intended as a book-where-you-can-copy-paste-your-very-first-game-from. The reason behind this approach is that in the Internet Age it is easy to find specific information such as “how to write your first Direct3D program”; such tutorials are abundant and can be found (if necessary) elsewhere.

On the other hand, 50’000-feet view with architectural concepts and practical observations such as “what are the advantages of TCP over UDP and vice versa depending on your particular game” or “why exposing multithreading to game logic level is harmful” are relatively difficult to find; this is what this book intends to cover.

BYOS (Bring Your Own Salt)

“In the practical world (especially in game development), for each and every “Do THIS_THING this way” statement there exists a counter-exampleOne last thing I would like to mention before we proceed to more practical matters. There is no one single sentence in this book (or any other book for that matter) which is to be taken as an “absolute truth”. In the practical world (especially in game development), for each and every “Do THIS_THING this way” statement there exists a counter-example, illustrating that sometimes THIS_THING can (or even should) be done in a different manner.

Every advice out there has its own applicability limits, and so does any advice within this book. When I know certain game-related scenarios when these limits are likely to be exceeded (and the advice will become inapplicable) – I will try to mention it. However, it is extremely difficult to predict all the usage scenarios in such a huge industry as game development, so you should be prepared that some of the advice in this book (or any other book) is inapplicable to your game without warning.

Therefore, take everything you read (here or elsewhere) with a good pinch of salt. And as salt is not included with the book, you’ll need to bring your own one. In more practical terms –

[[To be Continued…

First (actually, first, second, or ninth – depending on the poll above) chapter from the book coming soon… Stay tuned!

EDIT: beta Chapter I, Business Requirements, has been published. All the beta chapters will be shown on this page in ToC as they are published.]]

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.