Rewards. Opening mechanism.

   Hello everyone. I work as a server developer for a gaming company. And I needed to implement a new server for our game. It was necessary to enforce chests in it. Anyone who plays games loves opening chests. Waiting with bated breath for an epic artifact or collectible. How is this implemented? Where does the gold in the chest come from? How does the artifact appear? In fact, the mechanism of rewards and chests is not something new and unique, so I started asking a lot and looking for suitable options. I was interested in absolutely everything, from how game designers create a chest to how a player opens a chest and receives specific or not certain items. Perhaps I did not make enough effort to find the correct answer and the finished architecture, but I could not find the information that suits me. Have you implemented such mechanics? Where did you get the information from?

   To understand what we want to get from the chests, I had to spend a lot of time clarifying all the requirements from our game designers. The following picture emerged - game designers want to create a chest and fill it with various awards, such as gold, artifacts, gems. Prizes may or may not be required. There may be several gold rewards in the chest, but they will drop out with different chances. These were the minimum requirements. Certain deposits can have a minimum and maximum value.

   With such requirements, the chests have faded into the background. And it was necessary to understand how to create rewards, how game designers will create and start rewards in the system, how the server will be able to save the bonus, how the server will calculate the compensation later. As you can see, there were much more questions than knowledge in my head. I wanted to make an expandable system so that it would be possible to add new rewards over time. The first idea was to create a separate table for each award. Not bad. This is a working idea. For each table, there is a repository that retrieves data from the database. There is a service that processes the parameters of the reward and a benefit for applying the prize to the player when he took it. And everything works fine until it becomes necessary to collect the chest from the rewards. It turns out that the Chest entity must know about all the awards in the system. Adding a new bonus causes a change like a chest and the services that open this chest. Unfortunately, the open-close principle tells us that the plan should be open for expansion but closed for change.

   This circuit looks overwhelmed and too complex, which tells us that most likely we did what. That's wrong.

  How can we improve this circuit? Let's try to put all the awards in one table and add an enum to define the types of awards. Then we have the opportunity to make an array with various awards and handlers for them, depending on the style. In this case, we will get, over time, a massive enum with all types of rewards. A working option that again leads to system changes.

   In this case, you will have to change only one enum and, most likely, the reward service, to which you will have to add a switch/case. I had a great desire to implement this option because it looked correct and straightforward, but common sense prevailed over me, and Timleader said to think again, giving me more time to study the issue.

   The main question was, is it possible to get away from a massive class with constants? In ORM models, inheritance is present. In my experience, this is an underestimated mechanism that you don't often see in use. By the way, we are using hibernate. Hibernate gives us the ability to implement a base reward class with standard fields. Artifact rewards and currency rewards, for example, will inherit the base reward class. Each of these rewards can have special/unique areas. These fields will only be used to calculate this reward. Hibernate gives us a choice between the implementation options for child classes. It is possible to create a separate table for each child's class. Specific fields will be retrieved from individual tables, and base fields will be retrieved from the base table. And you can also put all the fields in one table, and the reward, which does not need any lots, will simply be filled with null values. These options allow you to add new prizes to the system without changing the current code. Unfortunately, we will have to change the database structure, but we cannot do without this in any of the options described above. Also, each award will return its own unique type, which we will need in the future.

   We were able to place all the awards in the database. Since each reward has a unique calculation mechanism, we will need to implement such a mechanism for each type of reward. For example, an artifact reward may have a drop rate, a gold bonus has a drop time limit. How to calculate everything flexibly enough? You can try to inherit the base class reward from the Interface, in which we will place the method for calculating the compensation. It turns out that each award will be able to figure itself based on its parameters. Sounds interesting, but how do you do it?

Java

public interface GameItem {

    List<?> rewardFor(Profile profile, ContentGenerator contentGenerator);
}

 @Override
 public List<?> rewardFor(Profile profile, ContentGenerator contentGenerator) {
     int count = contentGenerator.generateCount("some params");
     return List.of(new GoldCurrency(profile, count));
}

   At this stage, we have saved awards in the database and a mechanism for calculating the award. The following articles will describe how it turned out to receive recognition from the database and calculate them for the "client." The current implementation turned out to be quite flexible and convenient for expanding and adding new types of rewards.

  It would be advantageous for me to hear your opinion on what happened to me. How did you sell rewards and chests?