What do you want to see in the API?
Currently, server daily tasks are selected independently with random choice, so with bad luck some task types may appear only once or not at all during a daily reset. We need a scalable generation system where every active daily task type appears more than once, while still keeping the final task list randomized.
How do you think this should work?
Replace pure random selection with a balanced “task bag” system.
Suggested approach:
- Keep all active server daily task definitions in one registry/config.
- Define a minimum occurrence count, for example
MIN_OCCURRENCES_PER_TASK_TYPE = 2.
- Build an initial task bag by adding each active task type to the bag at least that many times.
- Shuffle the bag, for example with a Fisher-Yates shuffle.
- If more task slots are needed, fill the remaining slots randomly from the active task pool, optionally using weights.
- Generate final task values such as
amount, title, coins, and timeLimitMinutes from the selected task definitions.
The generator should validate that:
SERVER_TASKS_PER_CLAN >= activeTaskTypes.length * MIN_OCCURRENCES_PER_TASK_TYPE
If this is not true, task generation should fail clearly, because the guarantee cannot be fulfilled.
The same generator should be used by both scheduled daily resets and startup refresh logic, so the behavior does not drift between code paths.
Any additional info?
The current implementation has duplicated random generation logic in taskGenerator.service.ts and dailyTasksStartupRefresh.service.ts.
This change should make adding or removing daily task types easier: future task changes should happen mainly by updating the active task definition registry, not by editing random selection logic or multiple switch/case blocks.
Completed-task replacement should also be considered. If completed tasks are immediately replaced with a purely random task, the initially balanced distribution may drift during the day. A follow-up or part of this issue should decide whether replacements should prefer currently underrepresented task types.
Extra
Example of Fisher-Yates shuffle:
function shuffle<T>(items: T[]): T[] {
const shuffled = [...items];
for (let i = shuffled.length - 1; i > 0; i--) {
const j = Math.floor(Math.random() * (i + 1));
[shuffled[i], shuffled[j]] = [shuffled[j], shuffled[i]];
}
return shuffled;
}
What do you want to see in the API?
Currently, server daily tasks are selected independently with random choice, so with bad luck some task types may appear only once or not at all during a daily reset. We need a scalable generation system where every active daily task type appears more than once, while still keeping the final task list randomized.
How do you think this should work?
Replace pure random selection with a balanced “task bag” system.
Suggested approach:
MIN_OCCURRENCES_PER_TASK_TYPE = 2.amount,title,coins, andtimeLimitMinutesfrom the selected task definitions.The generator should validate that:
If this is not true, task generation should fail clearly, because the guarantee cannot be fulfilled.
The same generator should be used by both scheduled daily resets and startup refresh logic, so the behavior does not drift between code paths.
Any additional info?
The current implementation has duplicated random generation logic in
taskGenerator.service.tsanddailyTasksStartupRefresh.service.ts.This change should make adding or removing daily task types easier: future task changes should happen mainly by updating the active task definition registry, not by editing random selection logic or multiple switch/case blocks.
Completed-task replacement should also be considered. If completed tasks are immediately replaced with a purely random task, the initially balanced distribution may drift during the day. A follow-up or part of this issue should decide whether replacements should prefer currently underrepresented task types.
Extra
Example of Fisher-Yates shuffle: