Building a Multiplayer FPS Game on Google Cloud
Question
Mountkirk Games makes online, session-based, multiplayer games for mobile platforms.
They have recently started expanding to other platforms after successfully migrating their on-premises environments to Google Cloud.
Their most recent endeavor is to create a retro-style first-person shooter (FPS) game that allows hundreds of simultaneous players to join a geo-specific digital arena from multiple platforms and locations.
A real-time digital banner will display a global leaderboard of all the top players across every active arena.
Solution concept - Mountkirk Games is building a new multiplayer game that they expect to be very popular.
They plan to deploy the game's backend on Google Kubernetes Engine so they can scale rapidly and use Google's global load balancer to route players to the closest regional game arenas.
In order to keep the global leader board in sync, they plan to use a multi-region Spanner cluster.
Existing technical environment - The existing environment was recently migrated to Google Cloud, and five games came across using lift-and-shift virtual machine migrations, with a few minor exceptions.
Each new game exists in an isolated Google Cloud project nested below a folder that maintains most of the permissions and network policies.
Legacy games with low traffic have been consolidated into a single project.
There are also separate environments for development and testing.
Business requirements -Support multiple gaming platforms.Support multiple regions.Support rapid iteration of game features.Minimize latency.Optimize for dynamic scaling.Use managed services and pooled resources.Minimize costs.
Technical requirements -Dynamically scale based on game activity.Publish scoring data on a near real-time global leaderboard.Store game activity logs in structured files for future analysis.Use GPU processing to render graphics server-side for multi-platform support.Support eventual migration of legacy games to this new platform.
Executive statement - Our last game was the first time we used Google Cloud, and it was a tremendous success.
We were able to analyze player behavior and game telemetry in ways that we never could before.
This success allowed us to bet on a full migration to the cloud and to start building all-new games using cloud-native design principles.
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.A.
The question is asking to identify the appropriate service level indicators (SLIs) for a new multiplayer game that Mountkirk Games plans to deploy on Google Kubernetes Engine (GKE) and manage using managed services and pooled resources, with the goal of supporting multiple platforms, regions, and rapid iteration of game features, minimizing latency, optimizing for dynamic scaling, and minimizing costs. The SLIs are metrics that measure the performance and availability of a service and are used to define service level objectives (SLOs) and service level agreements (SLAs).
Option A suggests creating CPU Utilization and Request Latency as service level indicators. While CPU Utilization measures the percentage of CPU usage by the service, which can be an important metric for capacity planning and resource allocation, it does not necessarily reflect the user experience or the service availability. Request Latency measures the time it takes for a request to be processed, which is a more relevant metric for user experience and can be used to set SLOs and SLAs. However, this option does not cover other important aspects such as error rate, availability, and scalability.
Option B suggests creating GKE CPU Utilization and Memory Utilization as service level indicators. While GKE CPU Utilization and Memory Utilization are important metrics for monitoring and optimizing the performance and efficiency of GKE clusters, they are not necessarily the most relevant metrics for measuring the user experience or the service availability. This option also does not cover other important aspects such as request latency, error rate, availability, and scalability.
Option C suggests creating Request Latency and Error Rate as service level indicators. This option is a better fit for the requirements of the new multiplayer game, as it covers two critical aspects of service performance: user experience (Request Latency) and service availability (Error Rate). Request Latency measures the time it takes for a request to be processed, which directly impacts the user experience. Error Rate measures the percentage of requests that fail or result in errors, which indicates the availability and reliability of the service. This option also aligns with the business requirements of minimizing latency and supporting dynamic scaling, and the technical requirements of storing game activity logs for future analysis and supporting GPU processing for rendering graphics server-side.
Option D suggests creating Server Uptime and Error Rate as service level indicators. While Server Uptime measures the percentage of time that the service is available, it does not necessarily reflect the user experience or the service performance. Error Rate, on the other hand, is a relevant metric for measuring the service availability and reliability, but it does not cover other important aspects such as request latency and scalability. This option also does not align with the business requirements of supporting multiple gaming platforms and regions, and optimizing for dynamic scaling.
Therefore, the most appropriate answer is option C: Create Request Latency and Error Rate as service level indicators.
