

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:

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







[ ++ ] Vol. I. CURRENT, available for sale on Amazon [ + ] Preface Motivation behind This Book

Acknowledgements Comments which Helped to Shape the Book

About

What this book is NOT?

What is this book about? On Stateful Distributed Systems in General Genres: From Social Games to MMOFPS, with Stock Exchanges in Between Stock Exchanges are Games. Even worse – they’re Betting Games. Topics: All But Gameplay/AI/Monetization/Physics Too Large to Fit and Therefore Sketchy: 3D Focused on Internet-Based Games which are aiming for millions-of-simultaneous-players, but Some Parts Apply to LAN-based Games Too Game Engines: DIY vs Re-Use vs 3 rd -party

Is this book for You? Prerequisites My Captain Obvious Hat CD NOT included

BYOS (as in “Bring Your Own Salt”)

Recommended Reading Programming in General Game Programming (not really network-related) 3D Programming Network Programming (not game-related) Game Network Programming C++ For those new to C++ For those experienced with C++, but potentially needing an upgrade to C++11/C++14 Security

[ + ] Chapter 1. Game Design Document from an MOG perspective Are you Passionate about Your Game?

3000-word [[TODO/later: double-check size]] Crash Course for First-Time Game Developers On GDD Subject to Change, Seven Days a Week The Over-Generic Fallacy On Project Stakeholders On Focus Testing and Playtesting On Marketing and Monetization On Stakeholder Availability Summary on Project Stakeholders On a Typical non-MOG Team Structure Time-To-Market, MVP, and Planning On Importance of Holding Your Horses

Three All-Important GDD Rules

Limited-Life-Span vs Undefined-Life-Span Games

Client-Driven vs Server-Driven Development Workflow Server-Driven Workflow Client-Driven Workflow Dealing with Client-Driven workflow

On Matchmaking and Social Aspect of your MOG

Technical Issues affecting Marketing and Monetization

Your GDD Requirements List

Additional MOG-Specific Teams Network Team Back-End Team a.k.a. Server Team Both Network Team and Back-End Team MUST be First-Class Citizens

Running Costs Breakdown

Common GDD Pitfall: Just Throw In Multiplayer for Free

Game Entities and Interactions Game Entities: What are You Dealing With? Interactions Between Game Entities What Should You Get? Entities&Interactions Diagram Examples of Entities and Interactions Social Farming and Farming-Like Games Casino Multiplayer Games Stock Exchanges, Sports Betting and Auction Sites Large Virtual World Games (MMOTBS/MMORTS/MMORPG/MMOFPS) Team Competitions / eSports Entities&Interactions Diagram as a Starting Point to Architect Your Game

[ + ] Chapter 2. On Cheating, P2P, and (non-)Authoritative Servers If you’re popular enough, they Will find Reasons to Cheat

The Big Fat Hairy Difference from e-commerce

Dealing with Cheaters Attacks: The Really Big Advantage of the Home Turf Published Attacks: Higher Impact, but Home Turf Advantage is Regained Low-Impact and High-Impact Attacks Legal Stuff and Problems Banning Cheats Game Rule Violations Information Leaks Reflex Augmentation Abuses of Disconnect Handling Grinding Bots Multiple Player Accounts Classical Attacks DB Attacks Stealing Your Source Code Password Phishing Keyloggers/Trojans/Backdoors on Another Player’s Device DDoS MOG Attack Type Summary

Authoritative Client: Pretty Much Hopeless against Cheaters 🙁 Code Signing – Doesn’t Work in Hostile Environment Web of Trust – MIGHT Work in Theory, but There are Several Big Buts for MOGs (and can lead to the Doomsday Scenario too) Cross-Checks – Latencies and More Latencies Consensus (actually, majority vote) – Even More Latencies Homomorphic Encryption – doesn’t even start to fly 🙁 Authoritative Client MOG Summary

Deterministic Lockstep: No Game Rules Violations, but Wide-Open to Information Leaks 🙁

Authoritative Server: As Cheater-Proof As They Go Authoritative Servers: Scalability is Imperfect, But is Workable A Very Example Calculation Summary: Authoritative Server is not ideal, but is The Only Thing Workable

Bottom Line: Yes, It is Going to Be Authoritative Server Think Positive! or Maybe There’s Still Hope… Every Bit Counts. Multi-Layer Protection

[ + ] Chapter 3. Communications Client-2-Server and Server-2-Client Communications

RTT, Input Lag, and How to Mitigate Them Data Flow Diagram, Take 1 Input Lag: the Worst Nightmare of an MOG developer Input Lag: User Expectations Input Lag: How Much We Have Left for MOG Accounting for Packet Losses and Jitter Internet is Packet-Based, and Packets can be Lost Cutting Overhead Client-Side and Server-Side Buffering on Receipt On TCP TCP buffering TCP retransmits and delays of O(RTT) Input Lag: Taking a Bit Back Data Flow Diagram, Take 2: Fast-Paced Games Specifics RTT LAN RTT vs Internet RTT On CDNs and Geo Server Distribution RTT and Players Back to Input Lag Data Flow Diagram, Take 3: Client-Side Prediction and Interpolation Client-Side Interpolation Client-Side Extrapolation a.k.a. Dead Reckoning Running into the Wall, and Server Reconciliation Client-Side Prediction Client-Side Prediction: Dealing with Discrepancies Take 3 Diagram Lag Compensation – Potential for Cheating vs Player Happiness Server Rewind Subtracting Client RTT on the Server-Side Lag Compensation is Inherently Open to Cheating 🙁 OTOH, Player Happiness is Much More Important There Are So Many Options! Which ones do I need?

Game World States and Reducing Traffic Server-Side, Publishable, and Client-Side Game World States Client-Side State Server-Side State Publishable State Why Not Keep them The Same? Non-Sim Games and Summary Publishable State: Delivery, Updates, Interest Management, and Compression Interest Management: Traffic Optimization AND Preventing Cheating Interest Management as a Way to Prevent Information Leak Cheating On Frustum-based Interest Management Before Compression: Minimizing Data Compression Delta Compression Two flavours of Delta Compression Delta Compression – Generalization to Arbitrary Trees Delta Compression of Arbitrary Trees – Collecting Updates “on the Fly” Dead Reckoning as Compression Dead Reckoning as Compression: Variations Classical Compression Combining Different Compression Mechanisms and Law of Diminishing Returns On Doubles with Lossless Compression On Adaptive Traffic Management Adaptive traffic management – TCP Adaptive traffic management – UDP Traffic Optimization: Recommendations Traffic and Real-Time Strategies

MOG: Architecting for Scalability An Obvious One: Separate NPC/AI Splitting into Areas Seamless Worlds: Overlap! On Server-Side Uncertainty

Broadcasted Messages

Point-to-Point Communications and non-blocking RPCs RPCs Implementing Non-Blocking RPCs Void vs non-Void Non-blocking RPCs Non-void RPCs Client-to-Server and Server-to-Client Point-to-Point communications Inputs Input Timestamping “Macroscopic” Client Actions Server-to-Client Server-to-Server Communications Time Synchronization Synchronization via Server Rewind: “value date” Synchronization without Rewind: CMS/LBTS Seamless Handling of Transient Disconnects Option 1. Separate Caller/Callee Handling Option 2. Two Guaranteed Delivery Streams Going Further: Inter-DB Async Transfer with Transactional Integrity Server-Side Entity Addressing Using Message Queues for Server-to-Server Communications MQs and Transactional Integrity Uses for MQ on the Server-Side Brokered vs Brokerless Server-Side: TCP often wins over UDP

IDL: Encodings, Mappings, and Backward Compatibility IDL Development Flow IDL + Encoding + Mapping Example: IDL Sanitizing Input Data Test Case Generation Example: Mapping Mapping to Existing Classes Example: Encoding Backward Compatibility Implementing IDL and Specific Encodings



[ ++ ] Vol. II. CURRENT (3rd beta), available to backers as an "early draft" on Indiegogo and on Leanpub [ + ] 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 on…

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 Processing and Determinism

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 L 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 performance-wise too 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 About Them? 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 and Flexibility

Summary of Chapter 5

Appendix V.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, Urho3D, 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 subsequent “conversion” Important Clarification: Development Workflow vs Data Flow

Most Popular 3 rd -party Game Engines Unity 5 Event-Driven Programming/Reactors Built-In Communications: HLAPI State Synchronization RPCs (a.k.a. “Remote Actions”) HLAPI summary Built-In Communications: LLAPI 3 rd -party Communications for Unity: Photon Server Photon Server SDK Photon Cloud / PUN 3 rd -party Communications for Unity: SmartFoxServer 3 rd -party Communications for Unity: uLink 3 rd -party Communications for Unity: DarkRift 3 rd -party Communications for Unity: Lower-Level Libraries Unity 5 Summary Option A. Using Client Logic on Server. HLAPI now, probably LLAPI later Option B. Export from Unity and Standalone Server Options – 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: Options A and B Amazon Lumberyard Licensing Technical Urho3D

Comparison Table

Summary





[ ++ ] Vol. III. CURRENT (2nd beta), available to backers as an "early draft" on Indiegogo and on Leanpub [ + ] Chapter 8. Scalability In-Memory States and Multi-Player Games ‘No Bugs’ Rule of Thumb for Multiplayer Games Exception: Stock Exchanges NOT applicable to Single-Player Games In-Memory States: a Natural Fit for ‘No Bugs’ Rule of Thumb On Data Consistency In-Memory State Summary

On Scalability and Load Balancing Scaling Up? No Way, Jose 🙁 . Scaling Out! Scaling Stateful Objects The Myth of Stateless-Only Scalability (kinda)-Stateless Scalability Stateful Scalability 9 Load Balancing Load Balancing of Stateful Objects. Two flavors of Load Balancing

[ + ] Chapter 9. Server-Side MOG Architecture Deployment Architectures, Take 1 Don’t Do It: Naïve Game Deployment Architectures Semi-Naïve Deployment Architecture Web-Based Game Deployment Architecture Web-Based Deployment Architecture (Web Stack): How It Works Caching, More Caching, and Even More Caching Taming DB Load: Write-Back Caches and In-Memory States Write-Back Caches: When to Write Back? Write-Back Caches: Locking Optimistic Locking Pessimistic Locking Caches and Transactions Web-Based Deployment Architecture: Reactors Web Deployment Architecture: Scaling and Load Balancing On Specific Web Servers Web-Based Deployment Architecture: Merits Classical Game Deployment Architecture Game Servers Implementing Game Servers under Reactor-fest architecture Minimal Reactor-fest Logic Reactor Logic Factory Full-Scale Reactor-fest TCP Sockets Reactors and TCP Accept Reactor UDP-related Reactors Websocket-related Reactors and HTTP-related Reactors (not shown) GPGPU Reactor (not shown) Simplifications Reactor-Fest Architecture on the Server Side: Flexibility and Deployment-Time/Run-Time Options Threads and Processes Underlying Communication Protocol as an Implementation Detail Moving Game Worlds Around (at the cost of client reconnect) Online Upgrades with (Almost-)Zero Downtime On Importance of Flexibility Classical Deployment Architecture: Scaling and Load Balancing Scaling Game World Servers – Natural Linear Scalability (except for seamless MMOs) MMOGs and Seamless Game World Servers Moving Objects Around Scaling Matchmaking Server Scaling Other Game Servers Regional Datacenters to Reduce Latencies Load Balancing Once again on hybrid Web-Based+Classical Architectures Classical Game Deployment Architecture: Summary Enter Front-End Servers Front-End Servers as Concentrators Front-End Servers: Benefits Front-End Servers: Drawbacks and Issues to Solve Latencies and Latency Differences Discussion on Scalability of Front-End Servers and Dealing with “N-squared”. Server Groups Game-Server-to-Front-End-Server Affinity Front-End Servers: Implementation Front-End Servers: Reactor-fest Implementation Routing&Data Reactors Routing&Data Factories Routing&Data Reactors in Game Servers and Clients Client Load Balancing DNS Round-Robin Client-Side Random Balancing Client-Side Random Balancing: a Law of Large Numbers, and comparison with DNS Round-Robin Server-Side Load Balancer Appliances Load Balancing Summary Front-End Servers as a kinda-CDN Front-End Servers + Game Servers as a kinda-CDN Front-End Servers Summary

DB Server DB Server API Meanwhile, at the King’s Castle… Implementing DB Server Multi-Connection Basics Multi-Connection DB Server implemented as DB Reactor Single-connection DB Server as DB Reactor Implementing DB Server: Bottom Line DB Server Summary

MOG Server-Side. Eternal Linux-vs-Windows Debate New Generation Chooses Cross-Platform! Well, at least it SHOULD… Eternal Windows-vs-Linux Debate Open-Source Stability/Reliability Security Network Processing Other Technical Differences (scheduler, IPC, file access, etc) C++ Compilers Is it Enough to Decide? Free as in “Free Beer” TCO wars On ISPs and Windows-vs-Linux Cost Time To Market: Familiarity to your Developers It is All about Money 🙁 DB Server Considerations Mixed Bags Linux-vs-Windows: Time to Decide Things to Keep in Mind: Windows Things to Keep in Mind: Linux Things to Keep in Mind: Reactors

MOG Server-Side. Programming Languages Going Cross-Platform Cross-platform C++ Cross-platform Languages Pros (compared to C++) Cons (compared to C++) Personal Preferences and Reactors Scripting Languages On Programming Languages as Such Which Language is the Best? Or On Horses for Courses On Programming Languages and Reactors Supporting Multiple languages/compilers/JITs: Is It Worth the Trouble? Supporting Different Programming Languages within the Same Project Inter-Language Equivalence Testing: Yet Another Reactor Replay Benefit

[ + ] Chapter 10. Fault Tolerance Failure Modes & Effects Communication Failures Game Server Failures Containment of Game World server failures Server Fault Tolerance: King is Dead, Long Live the King! Clusters: HA, not FT Fault-Tolerant Servers: Damn Expensive Fault-Tolerant VMs Virtual Lockstep: Not Available Anymore? Checkpoint-Based Fault Tolerance: Latencies and Even More Latencies 🙁 DIY Fault-Tolerance in Reactor-fest architectures DIY Virtual Lockstep DIY N+1 Reactor-based Redundancy DIY Fault Tolerance – Connections and IPs DIY Fault Tolerance – What to Use DIY Fault Tolerance in case of Almost-Determinism DB Server Failures It’s All about Numbers – and Nothing Else Adding Fault Tolerance Can Make Your Numbers Worse Exception – Stock Exchanges Implementing Fault Tolerance for DBs Fault Tolerance – Failure Detection

[ + ] Chapter 11. Pre-Coding Checklist: Things Everybody Hates, but Everybody Needs Them Too. From Source Control to Coding Guidelines Source Control Git Git and unmergeable files Git and 3rd-party Libraries Git Flow Protecting your Code Reducing Chances: Firewalls & Antiviruses Mitigating Impact from Compromises

Continuous Integration

3rd-party Libraries: Licensing

Development Process

Issue Tracking System Issue Tracking: No Bypassing Allowed

Coding Guidelines Naming Conventions Project Peculiarities Per-Subproject Guidelines Enforcement and Static Analysis Tools

To Be Continued in Part PROG(ramming)…

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





[ ++ ] Vol. IV CURRENT ('1st beta', available online) [ + ] Chapter 12. Things to Keep in Mind Writing for Cross-Platform

Error Handling

Writing for Debugging asserts, and then assert some more Multi-level asserts Post-mortem analysis Text Logging Event-Driven Recording/Replay

Coding for Security DON’T trust the Client! Sanitize, and then sanitize some more Field-Level sanitization Inter-field sanitization Other Develop-for-Security Best Practices

Coding for i18n Translation Implicit Resources Pseudolocalization (into fake language) User-Entered Strings Fonts Currency/number/date formatting On Collating Sequences

Testing as a Part of Development Process On Unit Testing and TDD Regression Testing and Continuous Integration Replay-based Regression Testing Simulation Testing Simulating Players Simulating Network Problems Wireshark Bottom Line on Testing

[ + ] Chapter 13. Network Programming Packet Loss for an App-Level Developer Fundamental Properties of the Internet Each and Every IP Packet is Inherently Unreliable Real-World Issues Router Failures. BGP Convergence Time and Manually Handled Failures Handling Mass Disconnects Router/Link Overload AQM AQM and Latencies Traffic Shaping Last Mile Sudden IP Change Wireless Last Mile Wi-Fi: a Mile beyond the Last One Interference Penetration and Reflection 2.4 GHz vs 5 GHz Wi-Fi Extenders Summary of Packet Loss Mechanisms – and Their Observable Effects

TCP vs UDP IP: just packets, nothing more UDP: datagrams ~= packets TCP: stream != packets TCP: Just the ticket? No so fast 🙁 So, should we always go with UDP? What should we do then? Closing the Gap: Reliable UDP Closing the gap: improving TCP interactivity Keep-Alives and ‘stuck’ connections TCP_NODELAY Out-of-band data Residual Issues Other considerations

UDP from MOG perspective On UDP payload size On UDP broadcast/multicast – Don’t Hold Your Breath UDP: Addressing Lack of Reliability Publishing World States over UDP Fast-paced Updates vs Slow-Paced Ones Fast-paced Updates: Compression without built-in reliability Slow-Paced Updates: State Sync Point-to-Point Communications over UDP Model 1. No Flow Control Model 2. Partial Flow Control: Limiting In-Transit Data Model 3. End-to-End Flow Control: Advertised Receive Window Bottom line about Flow Control Retransmission Policies UDP Connections and KeepAlives: Simplistic Protocol UDP Connections: QUIC UDP and Firewalls UDP Hole Punching Comparison of well-known Reliable UDP implementations

UDP Security Encrypting UDP Why Encrypt? Isn’t Encryption Damn Expensive? Contenders for UDP encryption: DTLS and QUIC Hybrid Implementations Resilience to Crypto-DDoS Attacks An Example crypto-DDoS Attack “Proof of Work” to the Rescue Implementing “Proof of Work” on top of DTLS Similar Protection for QUIC Protection from crypto-DDoS: do you really need it? Common Encryption-Related Notes

TCP and Websockets for Games The Most Popular Bug when using TCP TCP: Reducing Latencies Nagle algorithm and TCP_NODELAY TCP with TCP_NODELAY: minor caveat TCP with TCP_NODELAY: still not a match to UDP with fast-paced sync algorithm, BUT might be necessary at least for TCP fallback “Hanged” TCP connections My First Guess – Exponential Backoff Sudden IP Change – the Curse of Mobile Other Possibilities Dealing with “Hanged” connections – Opportunistic Re-Establish Detecting “Hanged” connection – app-level Keep-Alives Detecting “Hanged” connection – TCP-level Keep-Alives Dealing with “Hanged” Connections – Dual TCP TCP Buffers and Priorities On Multiple TCP Connections for Different Priority Data Bottom line about Single-vs-Multiple-TCP-connections for data with different priority On OOB Detecting Link Saturation. Conflation Terminating connection and SO_LINGER TCP and Compression TCP Checksums and Encryption Encryption for TCP On writing ‘better TCP’ (on top of UDP or via RAW sockets) Dealing with Firewalls Magic Port 443 Web sockets Be ready to Frequent Reconnects Websockets: TCP in Disguise

Socket peculiarities To IPv6 or not to IPv6? Horrors of gethostbyname(): using getaddrinfo() instead, or NOT using anything at all To DNS or Not to DNS? gethostbyname() vs getaddrinfo() Scalability Issues select vs epoll vs kqueue vs Completion Ports on limitations of select() TCP: multiple sockets per thread UDP: Only-One-Socket Problem

TCP Peculiarities for Games TCP Fundamentals TCP is a stream, nothing more, nothing less TCP works over IP Send/Receive Buffers Not-So-Fundamentals Head-of-Line Blocking Retransmit Time-Out (RTO) Exponential Back-Off Nagle’s algorithm Caution when using TCP_NODELAY OOB data (don’t hold your breath) Termination Handshake and SO_LINGER “Hung” TCP Connections and Keep-Alives SACK, Fast Retransmit Buffer Sizes PMTUD Congestion Control/Avoidance (Almost-)Zero-Additional-Latency UDP-over-TCP Why would we want it? The Algorithm Calculating N Disclaimer and Conclusion

Testing Wireshark Wireshark and encryption tcpdump+Wireshark in Production “Soak Testing”, Simulation, and Replay Network Problems Simulation Replay Testing as a Big Helper for “Soak Testing”

[ + ] Chapter 14. Marshalling and Encodings

Encoding Requirements

Some of Existing Encodings XML JSON Google Protocol Buffers Plain C Structures Endianness Endianness these Days: (almost-)exclusively Little-Endian Endianness-agnostic Code Endianness in C/C++ Alignment Flatbuffers (and other Zero-Copy Protocols) ASN.1/PER

not-yet-Existing Encoding: Bit-Oriented Stream Designing BitStream Protocol On Huffman and Huffman-like Codings Optimizing Huffman speed-wise Using Huffman Coding for our Bitstream BitStreams and extensibility

Comparison of different Encodings

On Strings and Encodings String Mapping String Encoding

[ + ] Chapter 15. Basic Security Logins and Passwords On Back-End Logins vs Player Logins Player Logins: 3rd-party Social Logins Players: Internal IDs, Visible IDs, and Login IDs Visible IDs and censorship Avatar Censorship DIY Player Logins DIY Player Logins: Registration Form DIY Player Logins: On Client+Web Logins DIY Player Logins: “Remember me” Scrambling DIY Logins (both player and back-end) DIY Logins: Weak Passwords DIY Logins: Rate Limits and Lockout Account Lockout DIY Logins: Forced Password Changes DIY Logins: Password Hashing DIY Logins: Password Recovery Back-End Logins: On Access Permissions Player Logins: On Loginless Spectators

War on Clones. IP-based (non-)Identification. Identifying PCs and Macs False Negatives and False Positives IPv4: NOT an Identification Identifying Devices Hidden Crypto-ID On MAC addresses On “Too Good” Identifiers and unbans Identifying PCs WMI WMI Caveats System fingerprinting Identifying Apple Macs On Virtual Machines Identifying Mobile Devices Identification under iOS Identifying iOS Devices Accessing user social data from iOS Identification under Android Identifying Browsers Not-Really-Technical Identification Social Identification On E-mails Payment-Based Identification Putting it All Together Nothing is 100% Reliable Use Everything You Can Get Your Hands On That being said – DON’T play with fire Everybody make Small Mistakes once in a While Log Everything and a bit More Real-World Inter-People Relationships Auto-Bans

TODO: Key Management

TODO: Heresy: Security by Obscurity is NOT Necessarily Bad





[ ++ ] Vol. V CURRENT ('1st beta', available online) [ + ] Chapter 16. C++ Programming for Games C++ Guidelines – Made-to-Measure vs One-Size-Fits-All On One-Size-Fits-All Guidelines Popular Sets of C++ Guidelines My Own One-Size-Fits-All Set Principles Enforcing Your Own Guidelines Naming Conventions and Indentation Style Dealing with C Legacy and Correctness General C++ Self-Documenting Code On Comments On Error Handling On Cross-Platform C++ C++11 On Libraries Sub-Project Guidelines Infrastructure Code Logic/Reactor Code

C++ Performance On Performance in General On “noisy neighbor” code and “Resource Hogs” On Server Performance Allocations are Evil. Even More So Because of Locality Allocations and Data Locality Lack of Locality. How Bad Can it be In Practice? Almost-Natural Locality: Reactors Mitigation: Reducing number of Allocations Mitigation: Flattening Flattening as an Intermediate Stage: Client-Side Flattening as an Intermediate Stage: Server-Side Flattening using FlatBuffers On Data Locality and Hyperthreading On Prefetch and _mm_prefetch() On Locality within the Cloud On writing Your Own Allocator Performance Wisdoms and Performance “Wisdoms” “No C++, just plain C” – not for app-level programming On “C++ as C-with-Classes” C++ Exceptions – (Almost-)Zero-Cost until Thrown Smart Pointers and STL: Allocations are Still Evil Using boost:: – Case by Case and Only If You Do Need It Polymorphism – Two-Fold Impact RTTI – Can be Easily Avoided Most of the Time On Branch (mis)-Predictions and Pipeline Stalls On inline asm and SSE Quite Simple One: Server-Side On inlines and force-inlines On templates On compiler flags On Manual Loop Unrolling “For-free” Optimizations a.k.a. Avoiding Premature Pessimization

Implementing Queues for Event-Driven Programs Simple MWSR Queue Fixed-Size Queues Flow Control Dropping Packets Full Queues are Abnormal. Size. Tracking Implementing Fixed-Size Queue with Flow Control Implementing Fixed-Size Queue with a Drop Policy Performance Issues Reduce Time Under Lock Removing Allocations from Under the Lock Removing locks completely Waiting for Other Stuff On libuv

Summarizing Chapter 16 [ + ] Chapter 17. Graphics 101 Asset Pipeline Simple Asset Pipeline Enter Game Editor Enter 3D: Pre-rendering Pipeline Full 3D Asset Pipeline and Source Control Asset Pipeline Summary On Specific Tools Further Reading

2D 2D Basics Static 2D Vectors vs Raster for Games On RGB and Colors On Gamma Correction On Transparency and “Alpha Channel” On Aliasing Naïve aliased rasterization Simple anti-aliased rasterization Aliasing and transparency Raster formats: On JPEG vs PNG (vs GIF) PNG and JPEG compression technicalities Static 2D – is it any good for games? TODO: Physics (sort of) TODO: UI 2D Animation Sprites and Z-order Sprite Sheets Animation Double Buffering “Screen Tearing” and V-Sync Triple Buffering Minimal DIY 2D Engine Rendering 2D Using 3D Engine Why 3D Rendering is Important for 2D? Graceful Degradation and Backup non-3D Engine Sprites as Polygons Shaders for 2D What is Shader? GPU: DirectX/OpenGL Language to describe shaders: HLSL vs GLSL vs Cg Pixel Shaders Vertex Shaders Impact of shaders on a MOG data flow 3D Very Basics 3D Maths Bits and Pieces Floating-Point Implications Meshes The Curse of 3D Games: Polygon Counts and Low-Poly Meshes Server-Side Models: Ultra-Low Poly Textures UV Mapping Normal Maps Texture Filtering Anti-Aliasing Lights!.. Camera!.. Frustum?! Lighting Light Sources Reflection model Lighting and MOG Camera & Frustum Perspective projection Orthographic Projection Frustums and MOGs Rendering Pipeline and Shaders Highly Parallel Nature of Rendering Pipeline Fixed-Function Pipeline vs Programmable Pipeline. Shaders What should you use? Fixed-pipeline vs Shaders Rendering Pipeline and MOGs TODO: 3D Animation TODO: Post-Processing TODO: 3D Physics TODO: 3D UI

[ + ] Chapter 18. Client Updates Client Updates Installing Making your Client Installer- and Player-Friendly Signing Installer Auto-Updates Compatibility Issues Compatibility of Local Data Stale Clients Stale Clients on Client machines Stale Clients on download Servers Differential (Delta) Updates Implementation Different Environments Version Numbers are Evil Hash-based Updates to the Rescue! Differential/Delta Hash-Based Updates Implementation: Transactional Updates Windows: Vista-and-later UAC Craziness Update-of-Updater



Part DEPL. Deployment

[ ++ ] Vol. VII. '1st beta' IN PROGRESS [ + ] Chapter 23. Preparing for Launch Once again on MVP

To Cloud or Not to Cloud? No Way to Run Servers from Office To Cloud or Not to Cloud? On hosting ISP and CSPs On “Cloud Gaming” Video streaming Progressive downloading IaaS vs PaaS vs SaaS Pros and Cons of the IaaS Cloud Bare-Metal Clouds Economics of Cloud What About those Big-Name Games?? Beyond Intra-Day Variations – Cloud rulezz? Hybrid (Rented+Cloud) Deployments Summary on Rented-Servers-vs-Cloud

TODO: Choosing Cloud Provider/ISP

TODO: DNS provider

Services Provided: Co-Location vs Rented/Dedicated Servers vs Cloud On Co-Location Services You Need All Providers Rented Servers Co-Location Cloud

Server-Side Hardware for MOGs RENTING our Hardware Typical Server-Side Network Diagram Hardware Switch Firewall Servers On Out-of-Band Management “Workhorse” Expendable Servers – 2S/1U Caveat Emptor (=”Buyer Beware”) On Blade Servers In-Between/Storage Servers – 2S/2U Mission-Critical Servers – 4S/4U On Storage: Internal/DAS/SAN/NAS On Disk Latencies, BBWC RAID, and NVMe Choosing Storage On Vendors TODO: Web Server, E-mail Server

TODO: CDNs

Configuring Hardware for MOG Network Equipment Ethernet Switch Firewall Servers Game Servers Linux (with FreeBSD on the side) Choosing Linux Distro Configuring Network Configuring RAID Disabling Swap Disabling Unnecessary Stuff Restricting Permissions for your App Further Hardening Windows Databases and RAIDs RAID 101 RAID Levels BBWC RAID SSD and NVMe Hot Spare Drives Database Servers OLTP DB “Hot Spare” OLTP DB Server DIY Hot-Spare (online backup + ongoing rollforward) Replica-Based Hot Spare On Handling DB Data Growth

[ + ] Chapter 24. Launch! Seating Idle? Forget it!

Bugs, bugs, and more bugs…

Fighting Backlog From Both Ends

Prioritization

Release Cycle Deployment without Stopping the World On Continuous Delivery

[ + ] Chapter 25. DevOps for MOG DevOps Continuous Delivery/Continuous Deployment

Docker Encapsulated Environment – A Real Saver (for Really Poorly Written Programs, That Is) Other Benefits of Docker Docker Costs Docker with an In-Memory State (Immutable but non-Ephemeral) Docker Swarm and In-Memory State Summary

Monitoring Requirements What to Monitor? On Storage: to SQL or not to SQL? Which Monitoring System to Use? What to Do with All This Data? Bottom Line

[ + ] Chapter 26. Back-End Tools and Help Desk Back-End Tools Control Monitoring Reporting

Help Desk Support as a Damn Important Part of player experience e-mail Chat+VoIP Forums

[ + ] Chapter 27. DB Optimizations, Take 1 Prepared Statements (if you didn’t do it per Vol. VI)

EXPLAIN understanding stats, RUNSTATS on importance of hints (stale stats typical Bad Example(tm))

Stupid things JOIN-ing nested queries (SELECT-based-on-SELECT) only needed fields temporary tables (No-No for OLTP)

Indexes, and more indexes Multi-field indexes (not the same as N single ones) Too many indexes (OLTP) DON’T trust automated advisors (too many indexes) index with data(!)

BLOBs

When to Violate 3NF

Caching DB Caching OLTP: fit whole DB into RAM Caching only once App-Level Caching







[ ++ ] Vol. VIII. PLANNED [ + ] Chapter 28. Bot Fighting Security by Obscurity

Difference Between Programming Languages

Passive Methods No Sensitive Text as Windows Controls

Server-Side Statistics

Client-Side Detection

Captcha and Others [ + ] Chapter 29. Other Player Abuses Rules: Enforceable vs Non-enforceable

Attacks Brute Force DDoS App-Specific

Disconnect Abuses

Payment Abuses

Multiple Accounts Identifying Computer/User

Promotions and Promotion Abuses

Chat Abuses

Items Traded on Secondary Markets (eBay etc.) [ + ] Chapter 30. Protecting from Internal Abuses Being Active vs Reactive

Attack Vectors

Need-to-Know/Need-to-Do

Logging Everything and More

Roles and Hierarchy: Limited-Depth Trees





[ ++ ] Vol. IX. PLANNED [ + ] Chapter 31. i18n & Multi-Currency i18n Phrase-Level Translation Translation Engine Separating Translators from Developers Dealing with Layouts

Multi-Currency Multi-Currency Payments Casinos and Stock Exchanges: Multi-Currency Accounts To Margin or Not To Margin Currency-Exchange Abuses

[ + ] Chapter 32. Optimizations and Scaling Other-than-DB Optimizations & Scaling

DB Optimization & Scaling Physical DB Layout Async Replicas App-level implementation Aggregates Scaling Federated Databases Split Databases Inter-DB transactions

[ + ] Chapter 33. Deployment, Take 2 “Money is no Object”: A Curse in Disguise

On Clusters

On SANs

DDoS protection BGP-based one

On Reserve Datacenters Remote Backups

[ + ] Chapter 34. Security, Take 2 Two-Factor Authentication Login Recovery for 2FA

The Big Problem of Remote Admin’s Laptop

BYOD for Internal People in General

Hardening

Security Perimeters

IDS [ + ] Chapter 35. Themes, Modding and 3rd-Party Tools Intentional/Unintentional Abuses

Advantages of Explicit Support for Modding/3rd-Party Tools

DLLs vs Processes [ + ] Conclusion Good Development & Deployment practices cannot make your game successful, but bad ones can easily kill it

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

How do you want this book to be posted on this site during Beta-Testing? Start from the very beginning (Chapter I) (67%, 43 Votes)

Skip all the preliminaries in Part A, start right from coding (Part B, Chapter IX) (20%, 13 Votes)

I don't care about Business Requirements! Skip Chapter I, start from Chapter II (11%, 7 Votes)

Forget it, I won't read it anyway (2%, 1 Votes) Total Voters: 64

Loading ... 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

Whatever you do while developing your own Massively Multi-player Game,

You DO Need This Book

🙂

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.1

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):2

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.3 These questions are completely out of scope of this book.4

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 book5. 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 –

For each and every decision you make based on advice in this book, ask yourself:

Does This Advice Really Apply to My Specific Case?

[[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.]]

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.