/ Recent content in Welcome to the Game Server Services User Guide on Game Server Services | Docs Hugo en /overview/workflow/architect/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/architect/ Once the game specifications have been determined, it is necessary to consider how to implement them. GS2 provides microservices that can be used to implement various game specifications. Please refer to the following document for a description of the types of microservices provided by GS2 and the role of each microservice. Introduction to Microservices Game Server Services offers paid support to help you with your design. When you sign up for paid support, GS2 staff will work with you to understand your game specifications and how best to apply GS2’s microservices. /microservices/account/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/account/ The account system provided by Game Server Services is an “anonymous account” type of account system. This is a major system in Japan, but may be unfamiliar in other regions. However, this account system makes a lot of sense for games. What is an anonymous account? When you think of account management, you usually think of having a login ID and a password. Anonymous accounts are no different. However, the most important feature is that both the login ID and password are randomly generated by the system. /microservices/ad_reward/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/ad_reward/ It has become common practice to have players view ads and earn rewards from ad platforms as a monetization method for mobile games. When an ad is viewed correctly, the ad platform notifies GS2 via server-to-server coordination, and rewards are granted by GS2, thereby preventing cheating. In designs where rewards are granted solely via client-side callbacks, there is a risk of cheating using a tampered SDK. GS2-AdReward provides a mechanism that issues rewards based on trusted viewing-completion events delivered via direct Server-to-Server (S2S) notifications from the ad platform to GS2. /microservices/buff/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/buff/ GS2-Buff provides a centralized function to manage compensation and rewards for microservices provided by GS2, as well as corrections to the maximum value of user data. It can be used to realize features such as increasing rewards for a limited period of time or raising the maximum value of user data while a subscription is active. Rather than directly rewriting other microservices, GS2-Buff propagates correction values to each microservice via meta information called a “context stack” passed in API calls. /microservices/chat/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/chat/ GS2-Chat allows you to add text chat to your game. Text chat requires an always-on session to detect new messages and has complex server requirements. Game Server Services frees you from the hassle of managing these always-on sessions. Room To start using GS2-Chat, you must first create a room. Rooms can be created freely by the player, or you can have a room created for you by the developer. You can also set a whitelist of user IDs that are allowed to post, enabling you to build rooms exclusive to specific members. /microservices/datastore/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/datastore/ GS2-Datastore allows you to store arbitrary binary data on the server. Uploaded data can have access permissions set: choose from public (open to everyone), protected (visible only to specified user IDs: up to 100), or private (yourself only). GS2-Datastore is primarily intended for uploading data such as UGC or racing-game ghost data, and is not necessarily suitable for storing player user data. This is because storing the quantity of possessions as binary data would allow item duplication via tampering of the save data or the application binary, or play with modded applications that illegally inflate acquired quantities. /microservices/deploy/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/deploy/ GS2-Deploy provides the ability to manage namespaces and master data of GS2 microservices as code, and to provision them declaratively. Designed with a philosophy similar to AWS CloudFormation, it allows you to build, update, and delete resources spanning multiple microservices as a single unit (a stack) based on resource definitions described in a template file. In game development, adjustments to master data and changes to namespace configurations occur frequently. By using GS2-Deploy, you can manage these changes in Git, and run CI/CD pipelines linked with repositories such as GitHub to deploy them automatically. /microservices/dictionary/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/dictionary/ GS2-Dictionary provides a dictionary (compendium) function for items and characters acquired in the game. Basically, you can think of it as a simple-implementation version of GS2-Inventory, which manages a two-state (acquired / not acquired) ownership status. It can also be used for purposes other than a dictionary. For example, the ownership status of avatar parts is a good example. Whether you own a particular avatar part is sufficient to manage as a two-state per part, so GS2-Dictionary is well suited for this. /microservices/distributor/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/distributor/ GS2-Distributor is the core service for executing transactions that span across multiple GS2 microservices. It provides the foundation for safely executing a sequence of operations that span multiple microservices, such as “consume an item to receive a reward” or “consume stamina to start a quest”. In GS2, operations that are disadvantageous to the player are called “consume actions”, and operations that are advantageous are called “acquire actions”. GS2-Distributor receives a “transaction” that bundles these actions together, then forwards and executes them against the appropriate microservices, allowing all of the processing that makes up the game cycle to be handled in a consistent manner. /microservices/enchant/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/enchant/ This service provides a feature for adding unique random parameters to equipment and characters. It can be used to implement expressions such as additional stats on weapons in an RPG, individual values granted to cards obtained from gacha, or additional effects on equipment in hack-and-slash games — i.e., representations where “even the same item has different performance for each individual instance”. Two types of random parameters are available: Balance parameter Rarity parameter graph TD Item["Equipment, character, etc. /microservices/enhance/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/enhance/ This feature may be completely incomprehensible to some developers. However, it is a feature that is always present in the de facto standard game systems of mobile games, starting with those in Japan. This game mechanic itself should be useful knowledge for realizing Game as a Service, so for developers who do not understand it we add an explanation of the game mechanism. If you already have sufficient knowledge of the game mechanics of the enhancement feature, you can safely skip the rest of this explanation section. /microservices/exchange/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/exchange/ This is one of the most widely used microservices provided by GS2. It is responsible for converting the resources of any microservice into the resources of a completely different microservice. There are many game specifications related to resource exchange, and GS2-Exchange comes into play each time. Examples of resource exchange Conversion of enhancement materials Exchange 10 ★1 enhancement materials managed by GS2-Inventory for 1 ★2 enhancement material also managed by GS2-Inventory. /microservices/experience/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/experience/ In Game as a Service, growth elements are indispensable. GS2-Experience provides experience and rank features for implementing a game cycle in which players grow their characters and use those grown characters to take on more challenging content. GS2-Experience has a flexible design that lets you centrally manage not only the level of a single character but also the growth of multiple properties (characters, weapons, parties, guilds, etc.) within a single microservice. /microservices/formation/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/formation/ It is a common specification to combine the resources you own into a single composition. This is the case when organizing multiple characters into a party, or organizing items such as weapons and armor as an equipment set. GS2-Formation is a microservice that defines “what slots exist”, “what can be attached to each slot”, and “how many of the same type of formation can be held” as master data, and manages each player’s formation contents. /microservices/freeze/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/freeze/ GS2-Freeze is a feature that allows you to freeze the version of GS2 microservices used by your game at an arbitrary time, and to update the version on a schedule managed by the operator. Normally, GS2 microservices are continuously upgraded, and games always use the latest version of the API. While most titles operate without issue under this model, there are situations such as right after the release of a large-scale title, or when stability is to be prioritized for a long period of time, where the operator wants to control the timing of service-side updates. /microservices/friend/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/friend/ Provides the ability to create a game-specific social graph. While social graphs are a feature that platforms also offer, there is also value in creating your own in-game social graph. Players tend to be reluctant to register platform-wide friend relationships. This is because there is a case of “I want to play the game I’m playing with this person, but I don’t want to play other games with them”. If we treat the social graph provided by the platform as reflecting a relationship closer to real life, and the game-specific social graph as reflecting a relationship within that game, players will feel more comfortable using the friend feature. /microservices/gateway/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/gateway/ GS2-Gateway provides the ability to maintain a persistent WebSocket connection between the game client and the server, and to deliver notifications from the server at any time. Normal communication with a game server is a request-response model where the server responds to client requests, but GS2-Gateway enables server-initiated notifications (incoming messages, friend requests, guild invitations, etc.) to be delivered to the client in real time. sequenceDiagram participant Client participant Gateway as GS2-Gateway participant Service as Each Microservice Client->>Gateway: WebSocket Connect Client->>Gateway: SetUserId (authenticate) Service->>Gateway: SendNotification Gateway->>Client: Deliver notification payload Main features Persistent WebSocket connection GS2-Gateway accepts connections from clients using the WebSocket protocol and maintains connection information per user. /microservices/grade/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/grade/ A common specification for character and equipment development is to provide grade-up in addition to level-up as a short-term growth goal. Grading up can raise the level cap and make it possible to develop characters and equipment more powerfully. There are several possible methods of upgrading: some can be done by consuming growth materials, while others involve synthesizing characters or equipment of the same kind. GS2-Grade does not care about the method. /microservices/guard/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/guard/ GS2-Guard provides the ability to protect access to GS2 API endpoints. It allows you to determine the request source by various conditions such as country or region, IP address, anonymous IP, IP of hosting providers, and IPs with bad reputation, and to allow or deny API requests accordingly. It functions as a kind of lightweight WAF (Web Application Firewall) for games, protecting the game server from misuse, cheating, and abusive traffic. /microservices/guild/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/guild/ The guild function is a feature that allows multiple players to create a team and work together toward some goal. GS2-Guild is a microservice that manages guild members and the privileges that guild members have. In GS2-Guild, a “guild” is treated as a single player and referred to as a guild user. Guild members are federated to be able to retrieve and update information as guild users, so that guild members can manipulate common properties. /microservices/identifier/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/identifier/ GS2-Identifier is a service that manages credentials for accessing the GS2 management console and GS2 APIs. It issues and manages users associated with a GS2 owner account, the permissions (security policies) granted to each user, and the client ID / client secret actually used to call APIs. GS2-Identifier is a service that is not intended to be called directly from game clients; it is used for operator-side setup, deployment automation, and CI/CD pipelines. /microservices/idle/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/idle/ Implements a mechanism that grants rewards based on how long the game has not been played. For smartphone games, a design where “you launch the app after a while and obtain a large amount of rewards” strongly contributes to encouraging players to return. GS2-Idle is a microservice that makes it easy to incorporate such idle rewards. graph LR Start["Start waiting"] --> Idle["Idle time elapses"] Idle --> Prediction["Retrieve scheduled rewards"] Prediction --> Receive["Receive rewards"] Receive --> Start Categories Multiple idle rewards can be provided. /microservices/inbox/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/inbox/ Implements a mechanism for delivering messages and gifts from the system or operators to players. In games, situations frequently arise where rewards are delivered asynchronously to players, such as “apology distributions”, “login bonuses”, “purchase bonuses”, and “event rewards”. GS2-Inbox provides message queuing, unread/read management, reward attachment, and automatic deletion by expiration date, serving as the present box feature throughout the lifecycle of the game. sequenceDiagram participant Ops as Operator / Server participant Inbox as GS2-Inbox participant Player as Player Ops->>Inbox: Send message (with reward) Inbox-->>Player: receiveNotification Player->>Inbox: Get message list Player->>Inbox: Open message (Read) Inbox->>Player: Grant attached reward (transaction) Player->>Inbox: Delete read message Messages Read management Messages have a read status. /microservices/inventory/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/inventory/ Manage information about the items a player owns. There are three methods for managing items. The first is standard inventory and the second is simple inventory and the third is big inventory. Standard inventory has the following features. Limit inventory capacity Splitting the same item into multiple stacks of a certain quantity Setting an expiration date on items Simple inventory, on the other hand, does not have the features of standard inventory. /microservices/job_queue/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/job_queue/ GS2-JobQueue provides a job queue feature for stacking up processes to be executed asynchronously on the game server. Game processing includes operations that do not need to return a result immediately, and operations that should progress gradually over time on the server side. Such processing can be registered as a “job” in the queue, and executed later either at the timing when the player accesses the server or by an explicit API call. /microservices/key/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/key/ GS2-Key is a service that manages encryption keys (symmetric keys) used within GS2, and provides AES-based encryption and decryption APIs. In addition to use cases such as server-side encryption and decryption of sensitive data, it is also used as the key management foundation for various signing and encryption processes used internally by GS2 itself. Encryption key management In GS2-Key, encryption keys are created and managed under a namespace. A key can hold the following information. /microservices/limit/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/limit/ This is a mechanism for limiting the number of times a player can act. You can centrally manage frequently-occurring count limits in games, such as “you can draw the gacha up to 5 times a day” or “a reward you can receive only once a week”. graph LR Action["Player action"] --> CountUp["Count up (with maxValue specified)"] CountUp -- Limit not reached --> Success["Allow processing"] CountUp -- Limit reached --> Failure["Reject processing"] Reset["Reset cycle"] --> Counter["Reset counter to 0"] Counter An entity used to represent the number of times a player has acted. /microservices/lock/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/lock/ GS2-Lock is a distributed mutual exclusion service that provides a mutex operating on a per-resource basis, preventing multiple server processes and multiple execution environments from accessing the same resource simultaneously. In game operations, problems such as “performing the same process twice on the same player” or “different backend servers writing to the same data concurrently” can easily occur. GS2-Lock prevents these problems through a shared mutex provided as a microservice. /microservices/log/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/log/ GS2-Log provides a feature for aggregating and storing API access logs of all Game Server Services microservices embedded in your game. In game operation, it is very important to be able to later trace “when, who, which API was called, with what arguments, and what result was returned”. GS2-Log data can be leveraged as the foundation for various operational tasks such as investigating fraudulent players, checking game balance, handling user inquiries, and aggregating KPIs. /microservices/login_reward/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/login_reward/ This is a mechanism that distributes rewards to players who log in to the game every day. It provides a generic version of patterns frequently used in operations, such as distributing items that change daily, login bonuses that loop on a 7- or 30-day cycle, and the ability to retroactively compensate for missed days. Mode There are two ways to provide login bonuses: 《Scheduled Mode》 and 《Streaming Mode》. graph LR Mode{Bonus mode} --> Schedule["Scheduled Mode<br/>(mode: schedule)"] Mode --> Streaming["Streaming Mode<br/>(mode: streaming)"] Schedule -- Fixed to date --> SchEx["Day 1=Gold, Day 2=Silver. /microservices/lottery/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/lottery/ This is a mechanism for implementing gachas. GS2-Lottery supports both normal gachas and box gachas. graph TD Trigger["Lottery trigger<br/>(GS2-Showcase purchase reward / quest clear reward, etc.)"] --> LotteryModel["LotteryModel<br/>(lottery model)"] LotteryModel -- "mode = normal" --> Normal["Normal mode lottery"] LotteryModel -- "mode = box" --> Box["Box mode lottery"] Normal --> PrizeTable["Prize table<br/>(PrizeTable)"] Box --> BoxData["Player-exclusive box"] PrizeTable --> Prize["Prize<br/>(acquireActions)"] BoxData --> Prize Prize --> Acquire["GS2-Distributor<br/>reward distribution"] Normal Gacha A normal gacha performs a pure lottery with the specified probability. /microservices/matchmaking/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/matchmaking/ A feature that groups players based on conditions. It can be used to find opponents. Script Triggers By configuring createGatheringTriggerScriptId, completeMatchmakingTriggerScriptId, and changeRatingScript on the namespace, you can execute custom scripts when a gathering is created, when matchmaking completes, and when ratings change. The main configurable event triggers and the script setting names are as follows. createGatheringTriggerScriptId: When a gathering is created completeMatchmakingTriggerScriptId: When matchmaking completes changeRatingScript: When a rating changes Push Notifications The main push notifications you can configure and their setting names are as follows. /microservices/mega_field/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/mega_field/ GS2-MegaField provides the ability to efficiently share and synchronize the position information of a large number of players in a huge 3D space. In titles such as MMORPGs, open worlds, and metaverse-style services where a large number of players log in to the same world simultaneously, distributing every player’s position to every player would overwhelm both network bandwidth and CPU. GS2-MegaField solves this problem by efficiently retrieving “only the players near you”. /microservices/mission/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/mission/ A mechanism for rewarding players based on actions they have accumulated in the game. It is used to implement features generally referred to as achievements, trophies, and missions. graph TD Action["In-game action<br/>(quest clear / gacha draw, etc.)"] -- "Increase counter<br/>(IncreaseCounterByUserId)" --> Counter["Mission counter<br/>(Counter / Scope)"] Counter -- "Target value reached" --> Task["Mission task<br/>(MissionTaskModel)"] Task -- "ReceiveRewards" --> Reward["completeAcquireActions"] Reward --> Distributor["GS2-Distributor<br/>reward distribution"] Task --> Group["Mission group<br/>(MissionGroupModel)"] Group -- "Reset receipt flag<br/>based on resetType" --> Task Mission Counter An entity for counting the number of times based on a player’s actions. /microservices/money/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/money/ Warning GS2-Money2 has been released. Unless there is a special reason, please use GS2-Money2 for new use cases. A feature that handles in-game resources whose value is equivalent to cash. Be sure to use this feature when handling assets that fall under prepaid payment instruments (self-issued type) as defined by the Japanese Payment Services Act. Balance GS2-Money does not manage a player’s billing currency balance as a simple quantity; instead, it manages quantities per the value at the time of purchase. /microservices/money2/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/money2/ Tip GS2-Money2 is, as its name suggests, a microservice that corresponds to version 2. For documentation on the previous version, see GS2-Money. A feature for handling in-game resources that have a value equivalent to cash. Be sure to use this feature when handling assets that fall under prepaid payment instruments (self-issued type) as defined by the Japanese Payment Services Act. GS2-Money2 is not merely a service that handles “billing currency balances”; it is a microservice that takes on the following accounting and legal-compliance requirements as a whole. /microservices/news/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/news/ A mechanism for delivering in-game announcements in HTML format. The HTML content to be delivered must be generated by hugo (https://gohugo.io/). When you upload article data to GS2-News, GS2 builds it with hugo and hosts it as static web content. Game clients can view the announcements by accessing the temporary URLs delivered by GS2. graph LR Author["Operator"] -- "ZIP upload" --> GS2["GS2-News"] GS2 -- "hugo build (pre-generates all<br/>public/non-public patterns)" --> CDN["CDN (HTML / ZIP)"] Player["Player"] -- "GetContentsUrl" --> GS2 GS2 -- "URL + Cookie<br/>(valid for 1 hour)" --> Player Player -- "WebView or ZIP DL" --> CDN hugo hugo is a generator for producing static web pages. /microservices/quest/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/quest/ Manages game progression and quest progress. GS2-Quest is a microservice that manages on the server only the “entry” and “exit” of the in-game portion of the game (battles, stages, etc.). It is not involved in the internal logic of the in-game; it is responsible for processing that should be trusted by the server, such as cost consumption at start, granting rewards on clear, and evaluation of prerequisites. graph LR Start["Quest start<br/>StartAsync"] --> Battle["Run the in-game<br/>(client / dedicated server)"] Battle -- Success --> End1["Report quest end<br/>EndAsync(isComplete:true)"] Battle -- Failure --> End2["Report quest end<br/>EndAsync(isComplete:false)"] End1 --> Reward["Grant clear rewards"] End2 --> FailedReward["Grant failure rewards"] Quests A quest is the basic unit of in-game play and is the entity you select when starting the in-game portion. /microservices/ranking/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/ranking/ Warning GS2-Ranking2 has been released. Unless there is a special reason, please use GS2-Ranking2 for new use cases. Implements a ranking feature for competing on game scores and clear times. There are two types of rankings: “those where all participants compete on the same board” and “those where players compete against the scores of players they have subscribed to.” The former is called a global ranking, and the latter is called a scope ranking. /microservices/ranking2/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/ranking2/ Tip GS2-Ranking2 is, as its name suggests, a microservice that corresponds to version 2. For documentation on the previous version, see GS2-Ranking. Implements a ranking feature for competing on game scores and clear times. GS2-Ranking2 provides the following three modes. Global ranking Cluster ranking Subscription ranking Most of the ranking requirements a game needs should be satisfiable by one of these modes. Ranking Modes Global Ranking Global ranking provides a ranking feature for competing against all players. /microservices/realtime/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/realtime/ This feature can be used for low-latency, high-frequency communication to allow game players to play against each other. GS2 typically charges by the number of API requests, but for this service, once the game server is up and running, a fee is charged for the time the game server is running and for communication capacity. There is no charge per number of communications. graph TD Match["Lobby established<br/>by GS2-Matchmaking"] --> Want["Request a room with RoomWant"] Want -- Allocated from hot standby --> Warm["Warm Start (1 to 3 seconds)"] Want -- New launch --> Cold["Cold Start (40 to 60 seconds)"] Warm --> Connect["Player connects"] Cold --> Connect Connect --> Play["In-game communication via packet relay"] Play -- No communication for 1 minute or 3 hours elapsed --> Shutdown["Room terminated"] Server Type Currently, GS2-Realtime only provides packet relay functionality. /microservices/schedule/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/schedule/ Provides functionality to manage schedules for in-game events and similar activities. On its own, GS2-Schedule only manages event duration information; reward granting, purchase restrictions, and similar processing are realized by combining it with other microservices. Nearly all game-element microservices such as GS2-Showcase / GS2-Exchange / GS2-LoginReward / GS2-Mission are designed on the premise of cooperating with event durations, making it the core microservice when conducting limited-time operations. Event Duration There are two types of event duration. /microservices/script/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/script/ GS2-Script is a Lua-based script execution environment that runs custom logic on the server side in response to events from GS2 microservices. Each GS2 microservice provides a mechanism called “script triggers” that runs a script before or after a specific API call. By linking scripts written with GS2-Script to these triggers, you can execute on the server side game-specific validation logic, data processing, and external system integration that cannot be achieved with the standard features of each service. /microservices/season_rating/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/season_rating/ This feature classifies players by player skill and enables matchmaking with players of similar skill. GS2-Matchmaking has a matchmaking function based on rating values, but it does not support the recently increasing system of ranking players over the course of a season, which can last from a few weeks to a few months in real time. This microservice can be used to realize a game cycle in which players repeatedly play against each other to achieve a high tier during a season, considering a defined period of time as a season. /microservices/serial_key/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/serial_key/ This feature can be used when you want to distribute in-game items through out-of-game merchandising, real events, SNS campaigns, collaboration campaigns, and so on. The same mechanism can handle codes printed on paper packaging or QR codes, as well as strings distributed via email/SNS. However, some platformers do not allow the implementation of this feature, so please check the platformer’s guidelines before adoption. Types of Serial Codes There are two types of serial codes: /microservices/showcase/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/showcase/ This feature is used to sell products in the game. The difference from GS2-Exchange is the existence of a showcase. DisplayItems can be placed on a showcase, and you can configure the cost required to purchase a DisplayItem and the reward obtained when purchasing it. There are two types of showcases: the “Standard Showcase,” on which fixed DisplayItems are placed, and the “Random Showcase,” on which the displayed contents are randomly drawn at regular intervals. /microservices/skill_tree/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/skill_tree/ This microservice realizes the skill tree functionality commonly used as a growth element for characters and other objects. A skill tree is a feature with a tree structure such as the one shown below, in which releasing nodes improves a character’s parameters. Releasing a node requires a cost, and GS2-SkillTree allows you to set the consume actions provided by each microservice. flowchart TD Base --> Node1[STR+5] Node1 --> Node2[DEF+5] Node2 --> Node3[SPD+5] Node3 --> Node4[STR+5] Node4 --> Node5[DEF+5] Node5 --> Node6[STR+5] Node6 --> Node7[DEF+5] Node3 --> Node10[SPD+5] Node10 --> Node11[DEF+5] Node11 --> Node12[SPD+5] Node12 --> Node13[DEF+5] Node11 --> Node30[SPD+5] Node30 --> Node31[STR+5] Node31 --> Node32[SPD+5] Node7 --> Node20[STR+5] Node13 --> Node20 Node20 --> Node21[STR+5] Node21 --> Node22[STR+5] Node Definition (NodeModel) Nodes that make up the skill tree are defined as the master data NodeModel. /microservices/stamina/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/stamina/ Stamina is a feature that realizes in-game limits on the number of times something can be done. GS2-Limit expresses limits like “3 times a day,” but GS2-Stamina expresses limits with a combination of time progression and consume actions, such as “use stamina that recovers 1 point every 8 hours to enforce a limit of 3 times per day.” In the case of stamina, by varying the points consumed, you can realize specifications such as “action A is 3 times per day, action B is 5 times per day. /microservices/state_machine/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/state_machine/ GS2-Quest provided a mechanism to manage the start and end of quests and to receive rewards on completion according to the quest started. However, GS2-Quest had a problem handling game specifications where in-game randomness is strong and rewards are difficult to determine in advance. GS2-StateMachine was developed to manage in-game state at a finer granularity. State Machine The state machine is what is used to manage in-game state. flowchart TD Start ----> MainStateMachine_Initialize MainStateMachine_Pass ----> Exit subgraph MainStateMachine MainStateMachine_Initialize[[Initialize]] -->|Pass| MainStateMachine_ChoiceSkill MainStateMachine_ChoiceSkill[/ChoiceSkill/] MainStateMachine_InGame([InGame]) -->|Pass| MainStateMachine_NextTurn MainStateMachine_InGame([InGame]) -->|Fail| MainStateMachine_Pass MainStateMachine_NextTurn[[NextTurn]] -->|Next| MainStateMachine_ChoiceSkill MainStateMachine_NextTurn[[NextTurn]] -->|Exit| MainStateMachine_Pass MainStateMachine_Pass[\Pass/] subgraph ChoiceSkill ChoiceSkill_Initialize[[Initialize]] -->|Pass| ChoiceSkill_LotterySkills ChoiceSkill_LotterySkills[[LotterySkills]] -->|Pass| ChoiceSkill_WaitChoiceSkill ChoiceSkill_WaitChoiceSkill([WaitChoiceSkill]) -->|ChoiceSkill| ChoiceSkill_ChoiceSkill ChoiceSkill_WaitChoiceSkill([WaitChoiceSkill]) -->|ReLotterySkill| ChoiceSkill_ReLotterySkill ChoiceSkill_ReLotterySkill[[ReLotterySkill]] -->|Pass| ChoiceSkill_LotterySkills ChoiceSkill_ReLotterySkill[[ReLotterySkill]] -->|AlreadyReLottery| ChoiceSkill_WaitChoiceSkill ChoiceSkill_ChoiceSkill[[ChoiceSkill]] -->|Pass| ChoiceSkill_Pass ChoiceSkill_ChoiceSkill[[ChoiceSkill]] -->|InvalidSkillIndex| ChoiceSkill_WaitChoiceSkill ChoiceSkill_Pass[\Pass/] end end MainStateMachine_ChoiceSkill --> ChoiceSkill_Initialize ChoiceSkill_Pass -->|Pass| MainStateMachine_InGame Player ----->|Interaction| MainStateMachine_InGame Player ----->|Interaction| ChoiceSkill_WaitChoiceSkill If you are a programmer, you have probably received a flowchart like the one above from your planner. /microservices/version/ Mon, 01 Jan 0001 00:00:00 +0000 /microservices/version/ Provides the ability to determine the version of the application, the version of any additional assets, and the version of the terms of service the player has agreed to. If the version check passes, a new temporary GS2 client ID/secret can be issued. By using this feature, the GS2 client ID/secret embedded in the application only has the authority to call the APIs that perform login and version check, and only after passing the version check can it receive a client ID/secret with the privileges sufficient to actually play the game. /api_reference/state_machine/format/ Mon, 01 Jan 0001 00:00:00 +0000 /api_reference/state_machine/format/ Introduction GS2 States Language (GSL) is a state machine definition language with a unique structure. A state machine is generally composed of Tasks, which represent multiple states, and Transitions, which represent transitions between tasks. When a message is sent from the outside, the “running Task” transitions based on the rules defined by the Transition to manage the state. In addition to “running Tasks,” a state machine also has “state variables. There are several different types of Tasks, but in general, the process can be described by executing a GS2-Script. /overview/workflow/setup_gs2/create_account/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/setup_gs2/create_account/ To start using Game Server Services, you must first register an account. Account registration can be done from the bottom of the page at https://gs2.io. During this phase, you will need to discuss the operational policy for the accounts that developers will use. Each developer creates a dedicated account for development Developing with a shared account Each developer creates a dedicated account for development GS2 recommends this method. By having each developer create a dedicated account and develop in a dedicated environment, development can proceed smoothly without being affected by other developers’ changes to GS2 settings. /overview/workflow/setup_gs2_resources/manual_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/setup_gs2_resources/manual_setup/ The first thing a developer should do in the Management Console is to create a namespace and register master data. These can be created in the Management Console. Select Region Below the side menu, there is a region menu. From here you can select the region in which you want to operate microservices. Create a namespace Log in to the Management Console and select Microservices. When the list of namespaces appears, create a new namespace. /overview/workflow/setup_gs2/create_project/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/setup_gs2/create_project/ Once you have created an account, create a project. A project can have a fee plan and a billing address. This means that you can set up different billing addresses for different projects, even within a single account. This should be a useful structure for developers who have publishers who pay GS2 usage fees. Once you have finished creating your project, you are ready to start using GS2. /articles/tech/error/pattern/ Mon, 01 Jan 0001 00:00:00 +0000 /articles/tech/error/pattern/ In network feature implementation using GS2, error handling directly impacts game stability and user experience (UX). Here are some practical implementation patterns that go beyond simple exception catching. 1. Error Classification and Handling Policy GS2 exceptions can be broadly classified into three categories based on their nature. Category Applicable Exceptions (Example) Handling Policy Transient Errors InternalServerError, ServiceUnavailable, RequestTimeout Automatic Retry. If it fails after several attempts, display an error dialog. Logic/Configuration Errors BadRequest, NotFound Errors to be resolved during development. /overview/workflow/setup_gs2_resources/automation_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/setup_gs2_resources/automation_setup/ Setup using the management console is attractive because it is easy to perform. However, you must despair when you receive an order to “create another of the same environment”. Game development typically requires multiple server environments: a development environment, a test environment, and a production environment. It is impossible to configure GS2 in each of them by repeating the same operation in the management console without making mistakes. GS2-Deploy GS2 provides GS2-Deploy, a microservice for creating environments. /overview/workflow/setup_gs2_resources/cdk_setup/ Mon, 01 Jan 0001 00:00:00 +0000 /overview/workflow/setup_gs2_resources/cdk_setup/ GS2-Deploy did a great job of setting up the environment. However, there was still a challenge in writing templates. That is, you cannot get any input help to write a template file. I have already explained that I used AWS’ Cloud Formation as a reference to design GS2-Deploy, but In 2019, AWS announced the AWS CDK (Cloud Development Kit). This was the result of an effort to enable template writing in various programming languages, as a solution to the problem of not getting input support for writing template files in traditional JSON or YAML. /articles/master_data/cicd/ Mon, 01 Jan 0001 00:00:00 +0000 /articles/master_data/cicd/ Automating master data updates can reduce human error and speed up the development cycle. Automation Flow The general automation flow is as follows: Data Creation: Create master data using Excel, Google Sheets, CSV, etc. Conversion: Convert from spreadsheets to GS2 master data format (JSON). Commit: Commit the converted JSON or GS2-Deploy template to a Git repository. Deployment: CI tools (GitHub Actions, CircleCI, etc.) detect changes and reflect them in GS2. Automating Deployment Using GS2-Deploy If you embed master data in a GS2-Deploy template, you can reflect changes by updating the GS2-Deploy stack from your CI. /api_reference/state_machine/deploy/extention/ Mon, 01 Jan 0001 00:00:00 +0000 /api_reference/state_machine/deploy/extention/ GSL is a state machine definition language with excellent readability and descriptiveness, but it is not superior in terms of IDE input support and learning cost. CDK can be used to define GSL using various programming languages. CDK details Start defining a state machine Use the following syntax to start a state machine definition Language: Java PHP Python TypeScript C# class TestStateMachine extends io.gs2.cdk.stateMachine.integration.StateMachineDefinition { public TestStateMachine() { // write state definition here } } class TestStateMachine extends \Gs2Cdk\StateMachine\Integration\StateMachineDefinition { public function __construct() { parent::__construct(); // write state definition here } } class TestStateMachine(gs2_cdk.