Make Deployment Plan
1. Overview
A single game can contain multiple Title Regions, which are mutually isolated and can be deployed in different regions. Therefore, Title Regions can be used to isolate development, testing, and release environments. They can also be used to publish games in different regions. Based on past successful cases, we have summarized typical R&D scenarios in order to provide concrete deployment recommendations.
2. Dev/Test Environment
For games still in the early stages of R&D, a single Dev Region and Test Region should be sufficient. However, if R&D involves cross-region cooperation, you shall set up Title Regions as needed, even for games soon to be launched.
NOTE: The self-help Title Region creation function is not yet available. To create a Title Region, please contact our staff.
2.1 Pre-Production Stage Case 1
Only requires an EU development environment
2.2 Pre-Production Stage Case 2
Requires an EU development and testing environment
2.3 Production Stage Case
The development team is in the EU and conducts an Internal Playtest with China
2.4 Public Test Case 1
The team conducts Alpha, Closed Beta Test, and other test stages in the NA region
2.5 Public Test Case 2
The team conducts Alpha, Closed Beta Test, and other test stages in the NA and EU regions simultaneously
3. Deployment Strategy for Publishing
In Title & Region Isolation, we have already introduced two typical deployment modes: Multi-Region Deployment and Global Shared Deployment. Based on these deployment modes and actual scenarios, we recommend the following practices for deployment planning.
3.1 Global Shared Deployment
This model uses a single Title Region to serve all users worldwide. Therefore, only one Prod Region is required for external distribution. Take the Prod Region deployment in the EU as an example, and its structure is shown in the figure below. For simplicity, we ignore the region used for Playtest.
This deployment model is relatively simple. It is suitable for global distribution when you do not need to consider different needs in different countries/regions. Some players may be located far away from the deployment point. It is crucial to resolve issues and provide a good gaming experience to these players.
There are two main channels of network communication between game clients and the back-end: (1) The game client accesses a DS network connection; (2) The game client uses an SDK to establish a network connection with the PGOS Backend. PGOS provides the following mechanisms to optimize network communication and improve the player experience:
Distributed DS Hosting
PGOS supports distributed DS hosting. This allows you to create multiple DS fleets in different regions (IDCs) within the same Title Region. When allocating DS instances, PGOS will select the nearest fleet based on player latency to minimize the network latency between the player and the DS, thereby improving the game experience.
Global Acceleration for Access Point
PGOS has already deployed distributed access points in main regions around the world. When an SDK connects to the PGOS back-end, it will automatically connect to the nearest access point as well. This means game developers do not have to worry about the underlying communication details. Access points are connected to the PGOS backend by stable and exclusive dedicated network. This ensures that the players from other regions will have a stable connection to the Title Region, improving their game experience.
3.2 Multi-regions Deployment
This model deploys multiple Title Regions in different regions to serve users around the world. As a result, the game needs to select which region to deploy the Title Regions based on their actual target regions.
For deploying your game in Europe, North America, and Southeast Asia regions. We recommend two possible structures:
(1) Use the same content in all regions
When you deploy the same content and configurations (including in-game items, stores, etc.) in all regions, you only need to use one Test Region as the source and synchronize the content to the other regions. This structure is shown below:
NOTE: When using a single Title Region, you may still need to customize the content for different regions. This is done as follows: Configure multiple instances (Matchmaking, DS, Store, etc.) for different regions. Then, use Title Region Config Data to specify the Configuration Keys for the clients in different regions. In the subsequent Typical Use Case, we will provide a detailed description of this solution.
(2) Use different content in different regions
If your game release plans or policy requirements call for different content and configurations for different regions, we recommend you use a separate Test Region as the source of each region. This allows you to better isolate different content provided in different regions. Once the Prod Region is running, we don't recommend modifying the configurations directly except for an emergency. Instead, you should modify configurations in a Test Region and allow the changes to pass QA verification before syncing them to the Prod Region. This structure is shown in the figure below: