Game Programming Cloud Development Nick Prühs
Objectives • To understand the requirements of backend architectures in general • To learn how to build cloud-based backend architectures 2 / 57
Games Are Online • almost every single game has got an online component ▪ cloud savegames ▪ achievements ▪ friends lists ▪ presence (“… is now playing …”) ▪ online multiplayer gameplay ▪ matchmaking
Frontend vs. Backend Frontend Draws game state Plays audio Input Backend Authorative business logic Data store Game State
Frontend vs. Backend Frontend Desktop PC Mobile Browser Console Input Backend IP address & port Standalone executable? Game State
Request Load ServerClient A Client B Client C Client D … Client Z
Traditional Load Balancing • estimating the maximum amount of load each backend machine can take ▪ e.g. 100 players being logged in simultaneously • setup a number of machines that matches the estimated number of total players of the game • add a world selection or implement automatic load balancing
Traditional Load Balancing
Inefficient Resource Management • Need to always provide enough computing power for maximum amount of possible players ▪ If there is a peak in players wanting to play, there might not be enough capacity to handle all requests. ▪ If there is a low in players wanting to play, we're wasting capacity.
“Just run your backend in the cloud!"
Cloud The cloud provides the combined computation and storage resources of an undetermined number of machines to other devices at arbitrary locations on demand.
Cloud • 120+ Azure Products as of July 2017 ▪ Computing (e.g. virtual machines) ▪ Networking (e.g. load balancers) ▪ Storage (e.g. file storage) ▪ Containers (e.g. service fabric) ▪ Databases (e.g. SQL) ▪ Data (e.g. machine learning) ▪ AI (e.g. cognitive services) ▪ … and more!
Cloud • 120+ Azure Products as of July 2017 ▪ Computing (e.g. virtual machines) ▪ Networking (e.g. load balancers) ▪ Storage (e.g. file storage) ▪ Containers (e.g. service fabric) ▪ Databases (e.g. SQL) ▪ Data (e.g. machine learning) ▪ AI (e.g. cognitive services) ▪ … and more!
Scalable Gaming Backend Architecture Game Client Unreal / Unity Web Service ASP.NET Lobby Azure Service Fabric Actor Database Azure CosmosDB Game Azure Service Fabric Actor
Web Service • acts as interface between the frontend and the actual backend services ▪ protects backend services from direct interaction • just relays requests, no complicated logic ▪ stateless ▪ scaled indefinitely (scale out)
Actors • universal primitives of concurrent computation • concurrently handle passed messages ▪ make local decisions ▪ send messages to other actors ▪ create new actors
Virtual Actors – Project Orleans • improve over previous actor platforms such as Erlang or Akka • straightforward approach to building distributed interactive applications • avoids programming patterns for ▪ concurrency ▪ fault tolerance ▪ (distributed) resource management • scale-up automatically • heavily used first by 343 Industries (Halo 4)
Virtual Actors • Perpetual existence ▪ always exist ▪ cannot be explicitly created or destroyed • Automatic instantiation ▪ if there is no in-memory instance of an actor, a message sent to the actor causes a new instance to be created on an available server (activation) ▪ an unused actor instance is automatically reclaimed as part of runtime resource management ▪ actors never fail: if a server S crashes, the next message sent to an actor A that was running on S causes Orleans to automatically reinstantiate A on another server
Virtual Actors • Location transparency ▪ actor may be instantiated in different locations at different times, and sometimes might not have a physical location at all ▪ location of actor instances are transparent to application code ▪ similar concept to virtual memory • Automatic scale out ▪ create multiple instances of the same stateless actor ▪ seamless scale-out of hot actors
Promises • actors interact by sending asynchronous messages ▪ exposed as method calls ▪ need to return immediately • return a promise for a future result, rather than blocking until the actual result is returned • three-state lifecycle ▪ unresolved: expectation of receiving a result at some future time ▪ fulfilled: result received ▪ broken: error occurred in calculation or in communication
The more, the merrier? • allow us to scale parts of our backend up (and down) ▪ many players trading? create more actors for handling transactions ▪ many players fighting? create more actors for calculating collisions and hit chances • with more different types of actors, we might be required to pass more messages around to get the actual job done
Example: Halo 4 Presence Service
Scalable Gaming Backend Architecture DEMO https://github.com/npruehs/scalable-online-game- sample
References • Nick Prühs. Building a Scalable Online Game with Azure. http://www.gamasutra.com/blogs/NickPruehs/20170214/291318/Buil ding_a_Scalable_Online_Game_with_Azure__Part_1.php, February 2017. • Bernstein, Bykov, Geller, Kliot, Thelin. Orleans: Distributed Virtual Actors for Programmability and Scalability. Microsoft Research, 2010. • Wikipedia. Actor model. https://en.wikipedia.org/wiki/Actor_model, June 2017.
Thank you! http://www.npruehs.de https://github.com/npruehs @npruehs nick.pruehs@daedalic.com
5 Minute Review Session • Name a few typical tasks of frontends and backends in games! • What is load balancing? • Name a few types of services that can benefit from the cloud! • In your own words, describe a simple scalable backend architecture! • What are promises? • What are the four primary properties of virtual actors?

Game Programming - Cloud Development

  • 1.
  • 2.
    Objectives • To understandthe requirements of backend architectures in general • To learn how to build cloud-based backend architectures 2 / 57
  • 3.
    Games Are Online •almost every single game has got an online component ▪ cloud savegames ▪ achievements ▪ friends lists ▪ presence (“… is now playing …”) ▪ online multiplayer gameplay ▪ matchmaking
  • 4.
    Frontend vs. Backend Frontend Drawsgame state Plays audio Input Backend Authorative business logic Data store Game State
  • 5.
    Frontend vs. Backend Frontend DesktopPC Mobile Browser Console Input Backend IP address & port Standalone executable? Game State
  • 6.
    Request Load ServerClient A ClientB Client C Client D … Client Z
  • 7.
    Traditional Load Balancing •estimating the maximum amount of load each backend machine can take ▪ e.g. 100 players being logged in simultaneously • setup a number of machines that matches the estimated number of total players of the game • add a world selection or implement automatic load balancing
  • 8.
  • 9.
    Inefficient Resource Management •Need to always provide enough computing power for maximum amount of possible players ▪ If there is a peak in players wanting to play, there might not be enough capacity to handle all requests. ▪ If there is a low in players wanting to play, we're wasting capacity.
  • 10.
    “Just run yourbackend in the cloud!"
  • 11.
    Cloud The cloud providesthe combined computation and storage resources of an undetermined number of machines to other devices at arbitrary locations on demand.
  • 14.
    Cloud • 120+ AzureProducts as of July 2017 ▪ Computing (e.g. virtual machines) ▪ Networking (e.g. load balancers) ▪ Storage (e.g. file storage) ▪ Containers (e.g. service fabric) ▪ Databases (e.g. SQL) ▪ Data (e.g. machine learning) ▪ AI (e.g. cognitive services) ▪ … and more!
  • 15.
    Cloud • 120+ AzureProducts as of July 2017 ▪ Computing (e.g. virtual machines) ▪ Networking (e.g. load balancers) ▪ Storage (e.g. file storage) ▪ Containers (e.g. service fabric) ▪ Databases (e.g. SQL) ▪ Data (e.g. machine learning) ▪ AI (e.g. cognitive services) ▪ … and more!
  • 16.
    Scalable Gaming BackendArchitecture Game Client Unreal / Unity Web Service ASP.NET Lobby Azure Service Fabric Actor Database Azure CosmosDB Game Azure Service Fabric Actor
  • 17.
    Web Service • actsas interface between the frontend and the actual backend services ▪ protects backend services from direct interaction • just relays requests, no complicated logic ▪ stateless ▪ scaled indefinitely (scale out)
  • 18.
    Actors • universal primitivesof concurrent computation • concurrently handle passed messages ▪ make local decisions ▪ send messages to other actors ▪ create new actors
  • 19.
    Virtual Actors –Project Orleans • improve over previous actor platforms such as Erlang or Akka • straightforward approach to building distributed interactive applications • avoids programming patterns for ▪ concurrency ▪ fault tolerance ▪ (distributed) resource management • scale-up automatically • heavily used first by 343 Industries (Halo 4)
  • 20.
    Virtual Actors • Perpetualexistence ▪ always exist ▪ cannot be explicitly created or destroyed • Automatic instantiation ▪ if there is no in-memory instance of an actor, a message sent to the actor causes a new instance to be created on an available server (activation) ▪ an unused actor instance is automatically reclaimed as part of runtime resource management ▪ actors never fail: if a server S crashes, the next message sent to an actor A that was running on S causes Orleans to automatically reinstantiate A on another server
  • 21.
    Virtual Actors • Locationtransparency ▪ actor may be instantiated in different locations at different times, and sometimes might not have a physical location at all ▪ location of actor instances are transparent to application code ▪ similar concept to virtual memory • Automatic scale out ▪ create multiple instances of the same stateless actor ▪ seamless scale-out of hot actors
  • 22.
    Promises • actors interactby sending asynchronous messages ▪ exposed as method calls ▪ need to return immediately • return a promise for a future result, rather than blocking until the actual result is returned • three-state lifecycle ▪ unresolved: expectation of receiving a result at some future time ▪ fulfilled: result received ▪ broken: error occurred in calculation or in communication
  • 23.
    The more, themerrier? • allow us to scale parts of our backend up (and down) ▪ many players trading? create more actors for handling transactions ▪ many players fighting? create more actors for calculating collisions and hit chances • with more different types of actors, we might be required to pass more messages around to get the actual job done
  • 24.
    Example: Halo 4Presence Service
  • 25.
    Scalable Gaming BackendArchitecture DEMO https://github.com/npruehs/scalable-online-game- sample
  • 26.
    References • Nick Prühs.Building a Scalable Online Game with Azure. http://www.gamasutra.com/blogs/NickPruehs/20170214/291318/Buil ding_a_Scalable_Online_Game_with_Azure__Part_1.php, February 2017. • Bernstein, Bykov, Geller, Kliot, Thelin. Orleans: Distributed Virtual Actors for Programmability and Scalability. Microsoft Research, 2010. • Wikipedia. Actor model. https://en.wikipedia.org/wiki/Actor_model, June 2017.
  • 27.
  • 28.
    5 Minute ReviewSession • Name a few typical tasks of frontends and backends in games! • What is load balancing? • Name a few types of services that can benefit from the cloud! • In your own words, describe a simple scalable backend architecture! • What are promises? • What are the four primary properties of virtual actors?