In our previous post, we explained the basic rule of data logging, the 5W1H method. While in isolation, logging data in this fashion doesn’t seem difficult but the reality is not as simple. In many games, a single action such as beating a stage can create various situations which make it difficult to log everything at once.

[Example]

Player XXX’s brings character AAA, BBB, and CCC to stage 1-10 Senmai Field Ruins, paying 20 stamina, and defeats 2 Goblin Warriors and 1 Goblin Chief after 3 minutes of auto battling, resulting in clearing the stage and gaining 1000 gold and 500 EXP.

With this EXP gain, character AAA leveled up from level 5 to level 6.

Also, the player’s level rose from 4 to 5.

Because the player is now level 5 they also finished the Reach Player Level 5 quest, meaning they receive 20 Diamonds.

and...

etc, etc

These kinds of situations become too large to simply divide and log following the 5W1H rule. If one does attempt to log them as such, it becomes difficult to interpret and understand the logs while trying to analyze them later down the road. In order to facilitate efficient analysis, it is critical to design your logs after considering the log units or the uses of the log.

Every game has different types and amounts of content, thus meaning that from the perspective of analysis, every game is different in what will be central to analysis. In other words, there is no one size fits all solution for designing and constructing a log which will apply to any and every game. However, we will try to explain the 4 steps to designing and constructing a log system.

The 4 Steps For Designing a Log System

Step 1: Categorize by Entity

Step 2: Categorize by Action

Step 3: Add or Delete Action by Importance

Step 4: Deciding On a Log System Structure

‍

Step 1: Categorize by Entity

  • Player
  • Character
  • Currency
  • Item
  • Equipment
  • Stage
  • …

First, you can list and categorize your data following in-game entities such as above. These entities are the smallest unit of information available to meaningfully categorize your data. Drawing a chart of the relationship between entities can be helpful in designing and developing a data log. Below is a relationship chart that we drew in the early stages of TENTUPLAY of a hypothetical game. Now it has become even more complicated.

data logging

‍

Step 2: Categorize by Action

  • Player: Join, Login, Level Up…
  • Character: Get, Delete, Gain EXP, Level Up, Rank Up….
  • Currency: Get, Use
  • Item: Get, Use, Delete, Purchase, Sell….
  • Equipment: Equip, Unequip, Sell, Break Down, Upgrade…
  • Stage: Enter, Clear, Fail
  • …

The next step is to take your entity categories and create subcategories of the actions, values, or changes that can be created by the entities. For example the actions a player can take are joining, logging in, or leveling up. Besides these actions, they can also sell items, or play a stage. In the case of currency, players can gain or use currency, and the amount of currency they have will continually change over time.

‍

Step 3: Add or Delete Data By Importance

  • Character/Experience/Level Up: Place of Gain / EXP Gain Amount / Previous EXP amount / EXP after Gain / Previous Level / Level After Gain
  • Currency: Place of Gain or Use / Amount / Previous Amount of Currency/ Currency Amount After Change
  • Stage Play: Characters Used / Opponent Characters

After creating subcategories of actions, the next step is to consider details about the action and judge what data is important and what data is nonessential, adding or deleting data accordingly.

As a general rule, it is more beneficial to leave as detailed data logs as possible as it provides more data to look through while trying to fix an issue or if there is a point of curiosity.

However, there are many limitations to logging every action with the maximum amount of detail, such as database server performance. It is recommended that you consider what data will be used a lot in the future and what data you can live without when designing and constructing a log system. For example, when recording a stage play, what enemies were featured and in what formation is information developers already know. There is no need to leave such data within the log. On the other hand, what characters players take to a stage is a variable that changes by player, and becomes important data to tell which characters a player favors and which characters they are trying to level up the most, meaning that it is beneficial to record this data with as much detail as possible.

‍

Step 4: Deciding On a Log Structure System:

Once you have finished deciding on what data to add and what data to delete, the overall structure of your log structure system should be in place. Once what data will be recorded in which entity is decided, it is possible to apply this structure in logging data from the previously discussed examples.

In our next post, we’ll discuss how to optimize our data log system structures using the example we talked about before.

‍