@Marindor Could you please forward this feedback to the developers?
Ok, since I think that no one is going to fix the broken random quests during this event, I have some suggestions for developers how to fix the broken random, so at least we can have it fixed in the next event.
a) Using altered system of last segment of Mermaid's event (it was 10 repeated quests, 8 of them had 2 variants randomly chosen).
Just choose from more than 2 variants for each quest, for example 3 or 4 or 5. With 5 variants for each quest, the whole system would be random enough. This system completely avoids the main problem of current random system (getting the same quests over and over even the same quest several times in a row).
It isn't comletely random, but with 5 variants, it should be random enough. It quarantees, that no one gets the same quest several times in a row.
If you realy insist on random and don't want to use algorithm described in (a), then the only option is to implement more complicated algorithm to avoid too much repeating.
b) Remembering last several quests to avoid repetition (modifies currently used algorithm)
Using this algorithm requires implementation of remembering several (let's say 5 or better 10) last completed event quests, stored for each city individualy (FIFO style).
When algorithm chooses new quest, it also checks if that quests hasn't been completed during last X quests. If so, then repeat until different one is chosen.
This would guarantee that no one gets the same quest several times in a row, and depending how you define X, players are guaranteed to get X different quests in a row.
But this is probably much more complicated to implement than (a) and requires storing additional data.
c) Double layer segments
First layer - segment with all quests from current quest segment (this is already there)
Second layer - segment with quests from first layer minus quests which player already completed (individualy stored to each city)
Would worked like this:
- Player enters segment (f.e. from easy quest segment to mid quest segment). Quests from first layer are copied (or just their IDs) and stored to the city.
- For next X quests, quests are chosen from second layer. Each chosen quest is then removed from the second layer.
- After finishing X quests, second layer is deleted. Then the whole process is repeated (with the same or next quest segment)
Depending how you define X, players are guaranteed to get X different quests in a row. However, there is a low chance that player can get the same quest two times in a row.
More complicated to implement than (a), also uses more memory than (b), small chance to get one quest two times in a row.
There are many other algorithms you can use for this, but without knowledge of Elvenar code it's difficult to guess which is easest to implement and best to fit.
I have also several other suggestions for quests:
24 hrs workshop quests shouldn't have level requirements, they are messing with supplies production too much.
Therefore players should be allowed to complete them with workshops at any level.
Or there should be at least an alternative: (for example: 3 Toolboxes in high level workshops OR 6 Toolboxes in any level workshops)
If you remove level requirement for 24h workshops, you can also add 24/48h quests for manufactories without manufactory level restriction for later segments (finishable with lv1 manufactories)
You can add more 3h or shorter quests for workshops, the main problem with workshop quests was with the 24h one.
Make less radical changes, it usualy ends bad and creates lots of player rage and even quits (especialy changes like cutting rewards by half).
If you need to slow down players from getting too much event currency, make it in higher segments, not from the start. Otherwise many players just gets frustrated and gains almost nothing from the event, or even completely give up of the event(s).