Master data management
definition of terms
term | meaning |
---|---|
Model Master | data that does not change for each game player that is temporarily registered by the Master Data Editor |
model | data that does not change for each game player that is used from within the game |
Properties | Data that is different for each game player created based on the model |
Game elements include item parameters, quest composition data, and other data that does not change from player to player. There is data that does not change from one player to another, such as item parameters and quest composition data. Such data is called a model in GS2. The data that is transformed from models into data possessed by players is called properties.
General master data corresponds to a model in GS2, and there is a concept of a model master in GS2. The difference between a model and a model master is that the content of the data is the same, but the difference is whether or not the data is actually accessible by the game.
Data that can be edited on the GS2 administration screen is a model master, and when it is converted to a state that can actually be used in the game, it becomes a model. The reason this conversion process is necessary is so that all changes to the model master are reflected in the game at once. Without this process, data updated in the administration screen will be reflected in the game.
Create master data
This conversion process is a mechanism for exporting all model masters to JSON format files and uploading the JSON files to reflect them as models all at once. You can use the model masters by manipulating them on the GS2 Administration screen and exporting them to JSON format files, or you can create your own management tool, such as Excel, and reflect the data in models without registering any model masters on GS2.
You can also manage master data in GS2 Deploy templates. In this case, it will be easier to use version control tools such as git, so please consider this option as well.
Please manage master data in a way that is convenient for your organization.
GS2TemplateFormatVersion: "2019-05-01"
Description: GS2 master data template Version 2010-06-26
Globals:
Alias:
NamespaceName: inventory
Resources:
Namespace:
Type: GS2::Inventory::Namespace
Properties:
Name: ${NamespaceName}
NamespaceSettings:
Type: GS2::Inventory::CurrentItemModelMaster
Properties:
NamespaceName: ${NamespaceName}
Settings: # The data from here down is originally specified in JSON, but can be written as yaml and reflected
version: 2019-02-05
inventoryModels:
- name: item
metadata: ITEM
initialCapacity: 40
maxCapacity: 60
itemModels:
- name: item-0001
metadata: ITEM_0001
maxCount: 99
sortValue: 1
- name: item-0002
metadata: ITEM_0002
maxCount: 99
sortValue: 2
- name: item-0003
metadata: ITEM_0003
maxCount: 99
sortValue: 3
- name: character
metadata: CHARACTER
initialCapacity: 30
maxCapacity: 50
itemModels:
- name: character-0001
metadata: CHARACTER_0001
maxCount: 1
sortValue: 1
DependsOn:
- Namespace
Freeze master data
To avoid inconsistencies when a player updates his master data while logged in, a mechanism is provided to fix the master data used by the player as of a certain date and time.
gs2 = await gs2.Distributor.Namespace(
"namespace-0001"
).Me(
_gameSession
).FreezeMasterDataAsync();
Thus, by calling GS2-Distributor’s FreezeMasterData, it is possible to process subsequent APIs with the contents of the master data at the time this API is called. However, it is possible to fix the master data within 24 hours and up to 10 generations ago for each microservice. If this limit is exceeded, the latest master data will be used.
Since WebSocketSession can be connected continuously for 2 hours, it is recommended to remobilize the connection when reconnecting when OnDisconnect of WebSocketSession is called. When re-fixing, check GS2-Version, etc., to see if the master data has been updated, and if so, consider returning to the title screen.
Tip
Recommended implementation for GS2-Version to determine if master data has been updated
Register the master data version as warningVersion in the VersionModel in the format YYYY.MMDD.HHMM at the time of master data update. When the client reconnects to the WebSocketSession, it performs a version check using the date and time when the master data was fixed. If the warning is caught, it means that the master data has been updated, so the client should re-fix the master data at the current time while maintaining consistency by returning to the title, etc.