GS2-Idle

Implement a system that grants rewards based on the length of time a game has not been played.

Categories

Multiple idle rewards can be provided. Players can have one waiting time per category.

Idle time

The category can have an initial value of how many minutes of idle time is rewarded and a maximum value of idle time. The maximum idle time can be increased by each player. Whether to reset unused idle time after receiving rewards or carry it over to the next time can be selected via rewardResetMode.

Idle Reward

Define the list of items obtainable after a set idle time has elapsed for idle rewards. Multiple rewards to be granted can be set up to a maximum of 10 items, such as “experience + items”.

In addition, multiple lists of rewards can be set up so that there can be variations in the content of rewards within the waiting time.

For example, “Experience +10” and “Enhancement Material Lv.1 x 1” can be obtained for every 10 minutes of waiting. However, at every 60-minute timing, instead of the above rewards, “Experience +20” and “Enhancement Material Lv. 2 x 1” can be obtained. Consider the above example.

In this case, the following table is set up for the idle rewards.

The content of the reward item can now be changed according to the elapsed time. The content of the reward loops, so after 2 hours, you will have the items “1,2,3,4,5,6,1,2,3,4,5,6”.

Random drawings for idle rewards

Sometimes we want to have more randomness in the rewards. In such cases, you can set up GS2-Lottery’s lottery process for the rewards.

In the conventional GS2-Lottery, the result is not determined until the lottery is drawn, but when GS2-Idle is used, a random number seed is generated at the start of the waiting period. By using this seed for lottery draws when calculating rewards, the randomly drawn item contents can be presented to the player even during the waiting period, and the contents remain unchanged. (Changing the GS2-Lottery prize table will destroy this assumption.)

Scheduling of standby time

Each category can be associated with an event in GS2-Schedule so that idle rewards can be implemented in conjunction with the event.

Suppose the event duration is 2023-01-01 00:00 ~ 2023-02-01 00:00, and the wait begins at 2023-01-31 23:00. In this case, the count of the idle time stops when 2023-02-01 00:00 is reached.

Therefore, the content of the reward will be the same whether you receive it on 2023-02-01 01:00 or on 2023-02-01 09:00.

If an event has a recurring setting, the idle time resets when the recurrence interval changes. For example, if an event repeats every Monday 00:00 ~ Tuesday 00:00, the waiting time will be reset even if you did not receive the previous week’s reward at the moment it reaches 00:00 the following Monday.

Apart from the waiting time schedule, you can set the period during which rewards can be received.

Example implementation

Start of Waiting Time

Waiting is started when the waiting time information is retrieved for the first time.

    var item = await gs2.Idle.Namespace(
        namespaceName: "namespace-0001"
    ).Me(
        gameSession: GameSession
    ).Status(
        category: "category-0001"
    ).ModelAsync();

    const auto Future = Gs2->Idle->Namespace(
        "namespace-0001" // namespaceName
    )->Me(
        AccessToken
    )->Status(
        "category-0001" // categoryName
    )->ModelAsync();
    Future->StartSynchronousTask();
    if (Future->GetTask().IsError()) return false;

Retrieve the list of statuses (idle information)

    var items = await gs2.Idle.Namespace(
        namespaceName: "namespace-0001"
    ).Me(
        gameSession: GameSession
    ).StatusesAsync(
    ).ToListAsync();

    const auto It = Gs2->Idle->Namespace(
        "namespace-0001" // namespaceName
    )->Me(
        AccessToken
    )->Statuses(
    );
    TArray<Gs2::UE5::Idle::Model::FEzStatusPtr> Result;
    for (auto Item : *It)
    {
        if (Item.IsError())
        {
            return false;
        }
        Result.Add(Item.Current());
    }

Check the reward

    var items = await gs2.Idle.Namespace(
        namespaceName: "namespace-0001"
    ).Me(
        gameSession: GameSession
    ).Status(
        category: "category-0001"
    ).PredictionAsync();

    const auto Domain = Gs2->Idle->Namespace(
        "namespace-0001" // namespaceName
    )->Me(
        AccessToken
    )->Status(
        "category-0001" // categoryName
    );
    const auto Future = Domain->Prediction(
    );
    Future->StartSynchronousTask();
    if (Future->GetTask().IsError())
    {
        return false;
    }

    // obtain changed values / result values
    const auto Future2 = Future->GetTask().Result()->Model();
    Future2->StartSynchronousTask();
    if (Future2->GetTask().IsError()) return false;
    const auto Result = Future2->GetTask().Result();

Receiving Rewards

When a reward is received, the waiting time is reset. Also, any remaining idle time that has not yet reached the next reward interval will also be reset to 0.

    await gs2.Idle.Namespace(
        namespaceName: "namespace-0001"
    ).Me(
        gameSession: GameSession
    ).Status(
        category: "category-0001"
    ).ReceiveAsync();

    const auto Future = Gs2->Idle->Namespace(
        "namespace-0001" // namespaceName
    )->Me(
        AccessToken
    )->Status(
        "category-0001" // categoryName
    )->ReceiveAsync();
    Future->StartSynchronousTask();
    if (Future->GetTask().IsError()) return false;

Script Triggers

By configuring overrideAcquireActionsScriptId or receiveScript in the namespace, you can execute custom scripts before and after reward calculation and receiving processes.

• overrideAcquireActionsScriptId: A synchronous script executed during reward calculation. It allows you to dynamically override the reward list.
• receiveScript (completion notification: receiveDone): Executed before and after reward receiving. Synchronous execution allows for permitting/denying the receipt or applying multipliers, while asynchronous execution enables external integration via Amazon EventBridge.

Transaction Actions

GS2-Idle provides the following transaction actions:

• Consume Action: Subtract maximum idle time
• Acquire Action: Add maximum idle time, set maximum idle time, receive rewards

By using “Add maximum idle time” as an acquire action, it is possible to perform processes such as automatically expanding the maximum time rewards can be accumulated when a specific item is acquired or when a player’s rank increases. This allows players to accumulate more idle rewards as they grow, leading to an improved player experience.

Buff-Based Adjustments

When integrated with GS2-Buff, buffs can adjust the category model’s acquireActions and per-player maximumIdleMinutes. This enables dynamic adjustments to idle reward contents and maximum idle time according to events and campaigns.

Master Data Management

Registering master data allows you to configure data and behavior that can be used by the microservice.

Available master data types:

• CategoryModel: settings for idle time and reward tables

Master data can be registered through the management console, imported from GitHub, or registered from CI using GS2-Deploy.

Detailed Reference