In our previous post we discussed the 4 steps of creating a log system. In this post we will be using the example we gave to optimize the 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
If we take a look at the example below, there is complexity with multiple actions.
[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
Using this example we will be optimizing the log structure we built during our last post.
The Player’s Stage Play
If you organize the details of information of a player playing a stage you can get the following data.
Since the developers know the name of the stage and the monsters that are on the stage, we have removed such data and instead to identify the stage have added the stage ID, an internal in-game stage ID. To identify what characters the player enjoys and is focused on leveling up right now, we’ve added as much detail as possible, and because play time, use of auto battling, and stage play results are all information related to the stage we have added them to the information we are logging.
Player’s Characters EXP Gain and Level Up
If we focus on the part where the characters gained EXP and leveled up we can log the following data.
We can distinguish the fact that all 3 characters received the same amount of EXP, but only 1 character leveled up like this. As there are more than one way for characters to gain EXP, to answer the question of “where” of the 5W1H questions, we have logged the entity category and the entity ID. If, for example, the character gained EXP not by clearing a stage but by an EXP potion, the entity category would be ‘item’ instead of ‘stage’ and the entity ID would be the internal ID of the EXP potion, rather than the stage ID. By utilizing this method, it becomes a simple task of identifying how and where a character gained EXP.
Player Currency Change
When focusing on changes in currency, the data can be logged as following
In total, the player gained two forms of currency and used 1 kind of currency. The currency used was stamina, or activity ability, to enter the stage. As a result of clearing the stage, the player gained gold, and also because the player’s level increased and they cleared a quest, they gained diamonds. If we record where the player gained or used currency as the entity category and category ID we can maintain consistency in recording data.
Once this system of consistently recording data is constructed and maintained, then there is a lot that can be effectively gained. It becomes possible to identify stages which players are failing at high rates. You can verify if planned huddles are operating as planned by checking stage play records. By taking logs where the result is failure, by checking where players are failing you can see whether stage huddles are operating as planned or not.