The web service has regulated resources. Their presence / absence / value is what they charge for. You can buy a separate chip, or raise a separate parameter for a while. You can buy a "tariff plan", which includes a set of advanced parameters and the current month.

Question: how best to describe / manage these resources within the application? Probably, for game developers, hosting or mobile operators, the topic is hackneyed and solved long ago.

It is interesting to hear the opinion of those who implemented something similar in their projects.

Difficulties arose when considering collisions. For example, I bought the TA tariff, in which the P1 parameter rises to 100. This TA is valid for 1 calendar month. But the user took it, and in two weeks bought a separate P1 upgrade to 200, for a period of 2 weeks.

Addition is possible for some parameters: i.e. for two weeks the user will have P1 = 100+200 = 300 . For some, the addition is impossible, and you need to keep P1 = 200 consistently, and after the upgrade expires, continue at the tariff level P1 = 100 . And another question is whether to extend it for 2 weeks, or to disconnect as soon as the month of the tariff’s validity passes? (To be honest, it is necessary to extend, perhaps.)

The system is growing, and there will be new “items for bargaining” and a new business logic. How is it more or less reasonable to foresee the possible complications of marketing?

While each Parameter is entered into the database, along with a description of its properties: it is added or sequential, etc. When buying, the user acquires the Product, which consists of one or more Parameters, and has a validity period. And the purchased Parameters are listed in the Table of Activations: today with a plus sign, and at the end of the action, with a minus. When several identical parameters appear for one User, their dates are adjusted.

    1 answer 1

    To begin with: I have never implemented the game logic in my code. Therefore, take these recommendations not as a final word, but as an assumption.

    So, I would do the following logic:

    1. We have a set of objects providing upgrades (and, possibly, downgrade). The objects themselves are more or less passive. For example, they can get the impact force / wound healing rate / percent discount on goods at the input, calculate the same parameter after applying the upgrade. Or, having received a set of participant properties, issue a new set with the applied upgrades. But they do not do this themselves, they must be called by another piece of code for this. Plus, perhaps, we need additional parameters like cumulativeness (two upgrades of the impact force by 100% increase the amount by 100%? 200%? 400%?) And the limits of applicability (only the magician can enhance its magical properties).
    2. The next entity is the purchase. It represents an upgrade and a period of its validity. Having a participant and a shopping list, you can determine the currently active list of upgrades.
    3. The user has a basic set of properties (impact force, chance to find an artifact, etc.) that change over time (weapon, number of victories, ...). When applying currently active upgrades, you get an effective (currently active) set of properties. The transformation of the basic set into the current one is handled by a separate part of business logic - the combinator of upgrades. It is this part that follows the rules and recalculates the current set of properties when necessary (for example, every time).

    How are problems resolved?

    The TA tariff and P1 upgrade are part of the active list of upgrades. If the first of them is an upgrade to 50 units, and the second is an upgrade to 150 units, and they are cumulated, you get a total upgrade to 200 units. If the first of them is an upgrade to 100 units, the second is an upgrade to 200 units, then it probably makes sense to make them non-cumulative , and, according to business logic, the best option will be taken. Or the worst.

    If not all upgrades are added to each other, then the choice is again coded by the business logic of the upgrade combinator. For example, you can try all the combinations (the first is combined with the second - we take it as one possible option, etc., the second with the third, but then not with the first - another option), and choose the best among them.

    This way you can code arbitrarily complex business logic.

    Adding a new type of upgrade comes down to

    • creating a new class describing the upgrade, and
    • adding, if necessary, custom business logic to the upgrade combinator.

    It seems that there is no need to keep the existing set of properties in a separate table, since this interferes with other logic of the program. For example, if a user had 50 health units, he bought an upgrade that multiplies health by 2, and then he was injured, which took 10 basic health units from him, his current health indicator would be 80, and after the upgrade period expired - 40. This The logic is easily coded if you have separated the basic and operational parameters, and it is rather difficult if everything is mixed up.

    • “Turning a basic set into a valid one” is practically event sourcing :). - andreycha
    • @andreycha: Yeah, we kind of lose the shopping history every time. - VladD