Greg Murphy is the COO of Gamesparks, a cloud-based platform providing and a rich mobile back-end service for game developers to engage with their users. Greg takes us inside Gamesparks discussing the architecture, machine learning and what it’s like to launch in the China market.
Key Takeaways
- One powerful way to keep players engaged is to use game analytics and real data about how players are behaving
- Once a player is gone it’s really difficult to get them back, this is where tuning is key.
- We Apply Machine Learning to user behaviors to identify trends across players
- We deploy across AWS, Microsoft Azure and Google Cloud Platform
Subscribe on:
Show Notes
Gamesparks
- 1m:23s - When Gamesparks started we saw ourselves as a back-end provider, but as we’ve developed, we’ve realised we offer much more: we’re an engagement engine
- 1m:44s - What’s important for developers is to keep the players engaged in their games and enable monetization of the game
- 1m:56s - The power offered is the ability for developers to get started quickly and have all the benefits with out of the box functionality, without having to build the backend themselves
- 2m:11s - We have a lot of behavioral data about how players are interacting with the game, and can control games from the server side,
- 2m:24s - Using the data we can tune games - pressing all of those behavioral and social science buttons with players to keep them engaged and keeping their experiences as good as possible.
Engagement Engine
- 2m:44s - One powerful way to keep players engaged is to use game analytics and real data about how players are behaving
- 2m:55s - The ideal game that uses Gamesparks is one that’s really server authoritative; such as a level-based game
- 3m:02s - The client can be relatively dumb in this respect, asking the server for parameters at the start of a level for example
- 3m:19s - The server might respond it should have X level of difficulty, X number of enemies, and it should take X time to complete
- 3m:25s - Where this is powerful is if you see in the analytics that 50% of players are dropping out at this level, you can then tune the difficulty down to decrease drop out
- 3m:41s - Once a player is gone it’s really difficult to get them back, this is where tuning is key.
Tuning the Gaming Experience
- 4m:04s - Functionality is out of the box API, presenting around 180 different calls covering anything from authentication with social platforms, adding multiplayer, virtual economies and player challenges
- 4m:25s - A developer gets that functionality without having to write any code
- 4m:35s - Developers can extend that functionality with their own server side Java Script or their own customer API’s, customer data stores
- 4m:55s - We Apply Machine Learning to user behaviors to identify trends across players
- 5m:15s - Catches people cheating easily using Machine Learning.
The Architecture
- 5m:55s - We present a couple of different interfaces into the platform for customers and game players
- 6m:04s - Starting point is our management services - our interface to our customers (game devs, game studio) take the form of a web portal and management API
- 6m:19s - We’ve gone for an API first approach - meaning our portal is now a consumer of our management API - removing the usual issue of keeping them both in sync
- 6m:39s - The developer portable is a consumer of the API, if a customer wants to integrate Gamesparks with their own CI they can
- 7m:22s - Regardless of device: console, mobile, PC - they connect into our runtime services
- 7m:30s - Our run-time services are connected to via our SDK - we have SDK’s for a number of platforms.
SDK’s and Real-time Data Transfers
- 7m:38s - Most popular are Unity and the Unreal Engine
- 7m:50s - More specific SDK’s for iOS and Android, or even down to C++ and C#, as well as action scripted SDK’s
- 8m:17s - Our Unity SDK is just a package that’s installed into Unity, and gives the developer a Gamesparks dropdown within the IDE
- 8m:55s - The runtime services have to massively scale - we have around 35M monthly active players, we handled 15 billion API calls in the month
- 9m:15s - We offer real time multiplayer gaming, our standard runtime API is JSON over websockets
- 9m:45s - Our real-time services offer interfaces that are a custom protocol that we’ve written
- 9m:51s - It uses protocol buffers over UDP, falling back TCP if UDP isn’t available to ensure very rapid transfer of data between players
- 10m:38s - We have some racing games that use that service
- 10m:55s - Developers want in game statistics like which players have crossed the finish line.
Server-side Scripts
- 11m:37s - Act as a fundamental extension mechanism of the platform. What we understand is, we try not to make developers decisions for them. We provide a toolbox of services, not a prescriptive service.
Managing Noisy neighbours and Security
- 13m:02s Server side code is written in Java, so when any request is handled, every request is managed within a Java security manager which is proxy object to any of the data stores is needs to interact with
- 13m:17s - Each customer has their own data store - there’s no possibility of that request being able to step outside of those boundaries and get to any other customers data
- 13m:26s - Noisy neighbour point of view, we implement throttling on the platform so if the script is consuming more resources than it should and we will cut it off
- 13m:44s - We’re constantly getting call backs during its execution - if too many resources are being consumed, we terminate it.
The Developer Experience
- 14m:34s - When you install a Gamespark system SDK package into Unity - you get a dropdown that allows you add basic information
- 14m:51s - We have developer sandbox for developers to test any of their games
- 14m:47s - Then there’s lie-then point that the real players connect to - functionally there’s no difference between the two, the only difference being real players only connect to one end-point and there's no cross-pollination of data between development and live
- 15m:14s - Once Unity is set up, the developer has access to Gamesparks API
- 15m:54s - We take an identifier from the device that is provided by the SDK, creating a specific player
- 16m:11s - A player can choose to authenticate with Facebook, Twitter etc. that ID is then tied to the same record as the previously identified device
- 16m:54s - We deploy across AWS, Microsoft Dujour and Google Cloud Platform
- 17m:13s - Reason we did this was twofold: we wanted the largest geographical reach and we wanted these providers to bring customers to us
Deploying Across Three Cloud Providers
- 18m:31s - We designed our run-time services as a deployable unit called the run-time cluster
- 18m:56s - The deployable unit consists of API and server-side code engine plus the data stores that sit behind those engines
- 19m:16s - We chose those two is because our server side code is Javascript
- 21m:00s - We are on the journey to containers, some of our services we have built as containerized from the ground upwards
- 21m:18s - We take a couple of approaches to abstract the underlying cloud provider from the equation - we use a project called Packer JavaScript to build our images which is manifest driven, so we tell them we want all our ios images like this and it will go off and build them on all the respective clouds
- 21m:46s - We’ve built our own abstraction layer to perform the deployments above the three cloud providers API’s - so when we deploy our services in the platform - we send a message to our deployment manager
Elasticity
- 22m:47s - We’ve written our own auto scaler which raises some eyebrows. We decided not to use the cloud providers auto scalers, as we wanted a consistent experience across all three clouds.
Machine Learning
- 24m:03s - We get a really valuable stream of behavioral data
- 24m:18s - We analyse this as it’s passing through the platform and make rapid decisions about player behavior
- 24m:30s - We want to be able to close the loop between insight and action.
Identifying Churn
- 25m:40s - We want to identify what disengagement is - looking at the profile of how players play the game, when the play, frequency and what they to etc. and if that patterns starts to change, then maybe that’s not so good
- 26m:12s - Our nirvana here is to be able to get to auto-tuning - fundamental feature in the platform is segmentation by attributes of players by their traits.
The China Market
- 27m:45s - The firewall was the obvious inhibitor - so we deployed one of our run-time pluses in mainland China to meet that demand also a Government certification needed
- 29m:13s - It includes explicitly the IP addresses you’re allowed to use, so in an environment like ours where we dynamically scale and ordinarily cycle through IP quickly, that becomes a complication - so in this case we provisioned the number of elastic IP’s we have and then make sure we never give them up.
Technology
Companies Mentioned
