Verification

How to quality assurance games using GS2.

Many of today’s server systems present several challenges when it comes to verification.

  • Setting up the environment for verification elements
  • Time verification
  • Server load verification

Set up environment for validation items

The infrastructure used for validation does not provide direct benefits. Therefore, the cost of maintaining the environment tends to be seen as a problem.

The result is a poor validation environment that can lead to inefficient operations. GS2 uses a pay-as-you-go billing model, which means that there is no cost if the environment is not used, even if it is expanded. In addition, the environment can be set up and ready to use with GS2-Deploy.

These features make it possible to increase or decrease the number of environments depending on the validation items. Specifically, if you want to perform the following validations, you need to perform the validation work in series in the conventional development style, but with GS2, you can perform the work in parallel.

  • Verify that the one quest challenge per day limit works properly.
  • Verify that quest drop rewards are appropriate.

The example above shows a situation where a limit on the number of times a quest can be attempted makes it difficult to verify the content of drop rewards. In such a case, a version without the limit can be prepared in a different environment, and the drop rewards can be verified there. If the cost of preparing a separate environment is high, this decision cannot be made, and the time required for validation will increase.

Validating that an event starts at a specific time is another challenging issue. Time-based processing is difficult to detect errors and, if possible, we would like to standardize the GS2 Deploy template applied to the production environment without accelerating the time period of the event in the validation environment.

GS2 provides a mechanism to specify a time offset for time-based processing. If you are using GS2-Account, you can specify a different offset for each account, If you are using GS2-Auth to issue access tokens, you can specify the offset as a parameter when the access token is issued.

time_offset.png

With this feature, an account or access token with an offset of +2 weeks can be used to QA an event that occurs in 2 weeks by validating it with an account or access token with an offset of +2 weeks. This feature allows you to perform validation without changing the GS2-Schedule event period.

Validation of server load

Before inviting players to the server, it is necessary to check the server load to make sure that the service can be provided without problems even if a large number of players come to play. Since many games have server systems that have not been used in the past, this validation must be done carefully.

However, GS2 hosts a large number of games, and GS2’s architecture has been verified to handle over 100,000 API requests per second. Therefore, GS2 users should not be concerned about server load.

However, if you are really concerned, you can request a load test report from GS2 for a fee. The process is very simple.

Play for an hour or so, preferably with 10 or more people, the equivalent of what a typical game player would play. You tell GS2 the GS2 account ID you used for the game, the project name and time of day, and the expected CCUs. GS2 creates a test scenario based on the access history, increases the number of accesses to match the CCU, and generates a report.

If you have ever done load testing, you will understand how simple this process is.