Cloud Gaming Architecture–A walkthrough of how to get started

Architecture

The architecture has a logical layout (below). It looks complex, but the blog will hopefully explain it.

The Pieces of the Puzzle for a great cloud gaming experience.

When architecting our game your need to consider what the  components, described below. Some are apps (the clients), and the rest are cloud services.

Clients

The clients are the apps that game players download to their devices. Each app must be developed for the particular device, but they must all have behave the same. The game is the same, just the UI changes.

When building a game today you want it to be played on the most number of devices so, ideally it should be capable of being  played on Windows Phone 7 and 8, Windows 8.0 and 8.1, iOS, Android, and Kindle.

To enable maximum platform support communication is enabled using REST APIs. The experience of playing the game should be smooth and seamless. A key factor is to ensure that the client app makes the minimal number of calls (after authentication).

When developing your client its key to ensure that each of the client has a thin hardware abstraction layer (HAL). the HAL must contains the code necessary to display and process the UI controls, along with the code that initiates contact with the Visitor Center and the code that interacts with a Game Room.

Visitor Center (VC)

The first stop for a player is the Visitor Center. So think of the Visitor Center as the landing page for your game i,e.  you’ll find the leaderboard results and a directory of the gamer IDs. You can also find a friend on the system through the leaderboard.

Identify Yourself

When the player starts the game, the client app authenticates the player with either Facebook or another authentication services (using a username and password). The client app then sends the Visitor Center the identity of the player (via a token). The Visitor center confirms the identity by contacting Facebook or other authentication services to verify the token (and thus the player). Once confirmed, the Visitor Center sends the client app a new URL that goes to the Game Room where the user will be playing.

Note that if the user does not sign I, you may want them to allow them to play as a Guest (guests may be simply unranked or wouldn't be issued persistent stats or friends).

Game Room (GR)

The Game Room consists of 3 APIs that interact with the client.

1) Game: Sends the current puzzle to the client.

2) Post: Receives the user’s individual results from the client.

3) Results: Sends the leader scores and relative ranking of user to the client, along with the next puzzle.

Game Room Services and Locations

You may want to geo locate each of your games rooms, best practice is to locate each Game Room on the continent with the greatest player base – so European languages are housed in European data centers, for example. The hard cases are English, Spanish, and Portuguese, which have broad, world-wide audiences. English is played from everywhere, but is most concentrated in the US, UK, India, and Australia. Spanish is split between Spain and Latin America. Portuguese is most heavily played from Brazil, but there are still plenty of players from Portugal and other parts of the world.

The Aggregator

When a game ends, each client sends the player’s results to the Game Room. The Game Room has an Azure load balancer in front of it that distributes the results to one of its three web roles. Because the results are randomly scattered, they must be gathered into one central spot—the aggregator.

The inner working of the aggregator is an Azure Cache. Caches are used in computing because they take the pressure off a system by holding recently stored data in memory and letting many operations access the data. Because the data is in memory, it can be instantaneously returned to any operation. The cache operates instead of a database engine that would otherwise query for a particular result. Multiply the queries and the database quickly reaches its capacity to respond. Caches are tried and true time savers.

Here’s what happens between the GR and the aggregator.

After a game ends, each Game Room web role receives the individual client results. The web role then sends all of its accumulated results to the aggregator. Note that due to retries, there may be duplicate client results received by the Game Room and received by the aggregator. (Two people sharing the same Gamertag while simultaneously playing using different devices also causes duplicate client results to be received.) Then, the aggregator sends all of the Game Room web role results back to each Game Room web role, as shown in Panel 3 of the diagram above.

Each Game Room web role removes duplicates and sorts the results, and sends the top results and individual results with peer ranking back to the client. After the next round starts, each Game Room writes its buffer of unsorted results to blob storage. Each blob is named in the form <puzzle language id>-<game id>-<instance number>.txt, and consists of Comma Separated Values (CSV) data.

Leader Board Orchestrator (LBO)

The LBO does the heavy lifting for the app. It works in close partnership with the two database stores that conceptually flank it to create the “best of” lists (best of right now, best of the hour, best of the day, best of the week).

When the Game Room and the aggregator have finished the results reporting work, the LOB starts.

It first gets the results of the game from the newly written blob storage. It then processes the data to create in-memory tables that are inserted into an instance of Azure SQL Database. Once the data is inserted into the database, a large number of queries, in the form of stored procedures can be run against the data. To preserve the integrity of the data, stored procedures are the only way used to determine stats. The integrity of the data can also be checked during the process. The LBO can use more than one worker role to process the data. The results can also be compared. If any discrepancies arise, then the worker can be immediately stopped, and a new worker started to retry the processing.

Headquarters

There is another component, although it is more of an infrastructure piece. The “Headquarters” service is used to run tests against the various other parts of the game. For example, it runs the test-bot that makes sure the game rooms (in all languages) are working. It also checks the integrity of the database operations. If a worker role running an operation creates a result that is different from others, the worker is terminated and a new one started. The headquarters handles those administrative and quality assurance duties.

Deployment

And finally, a server that is on-premises builds and deploys the whole system, every night. The build system is automated, and Azure REST APIs enable deployment. The function is key in protecting the integrity of the system by only allowing only the build scripts to perform the tasks. No one physically should have the permission rights to build and deploy manually.

References