More random events
Sometimes random events (RE and RIE) repeat week after week, even, random individual events (RIE) triggering twice in a row in the same week with different slaves. There are many events that are rare to see because they have few slaves that meet the requirements. This merge request attempts to adjust this behavior with an experimental feature.
- Creates a new object,
V.eventControl, containing both new and current variables and objects to control random events. - Adds a new counter attribute for slaves,
counter.events, for the number of RIE the slave has starred. - Tracks RE and RIE played in the last 2, 4 or 8 weeks (for soft, medium or high control level).
- Reduces the weight of the RIEs already played in the control period.
- The slaves that have appeared the least in RIEs have the most possibilities.
- Some rare events are more likely to be triggered.
- The player can choose to control RIE events with a soft, medium or high level, or not control them at all.
- If the player chooses to control RIE, there is also the option to control RE.
When the control is activated, at any level:
- Slaves who starred fewer events are more likely to appear.
- A slave who starred in one event the current week is prohibited from starring in another (current behavior).
- An event that appeared the current week cannot be played again.
- An event played within the control time has fewer chances of being played again.
- If RE control is active, a random event can't be played two weeks in a row.
Soft level
It only tracks events for 2 weeks.
Medium level
- Tracks events for 4 weeks.
- Reduces the number of elegible slaves.
- Events played in the last two weeks have even fewer chances of being played again.
High level
- Tracks events for 8 weeks.
- Further reduces the number of eligible slaves.
- Events played in the last five weeks have even fewer chances of being played again.
- An event played within the control time has even fewer chances of being played again.
- If RE control is active, a random event will not be playable after two weeks.
Up to 9 attempts to pick a RIE are made, softening the control demands in each of them. If there are no events that can be played yet, one is chosen as usual. Only in certain circumstances, with few eligible slaves with very specific characteristics, does the routine have to resort to the traditional way of selecting events, but this does not have a significant impact, nor does it prevent it from continuing to control the events.
This new feature has been tested intensively, with different numbers of slaves, with different assignments, and with different characteristics. Always works as expected.
Merge request reports
Activity
added 51 commits
-
c315d672...6dd407b3 - 51 commits from branch
pregmodfan:pregmod-master
-
c315d672...6dd407b3 - 51 commits from branch
I don't know what I did wrong with !11532 (merged), but I messed it. I've done the MR again. Solved the suggestions made by @svornost
added 43 commits
-
33a357e3...9fb1c151 - 41 commits from branch
pregmodfan:pregmod-master - 76ccc21f - modified: src/events/randomEvent.js
- cba7357d - Merge branch 'pregmod-master' of https://gitgud.io/pregmodfan/fc-pregmod into moreRandomEvents
-
33a357e3...9fb1c151 - 41 commits from branch
added 44 commits
-
302bd2e9...22bd46c2 - 43 commits from branch
pregmodfan:pregmod-master - ff4b64a1 - Merge branch 'pregmod-master' into 'moreRandomEvents'
-
302bd2e9...22bd46c2 - 43 commits from branch
I LOVE least recently used code for random generation in video games. I'm not sure I have the skill to write it myself.
But I have written the code for a LRU method in python, where it uses a list of possible events and then uses the absolute value (to fold the results in half) of a gaussian randomly generated number (this is a function in python import math) set with a standard deviation of length/2 or length/3 and this results in half of a natural curve. This makes it so that the least recently seen item in the list is most common, but the most recently used still has a tiny chance to repeat instead of the zero chance to repeat I see in some LRU methods.
No clue how such code would work in this game, which is 10000 times more complicated than the coding exercise I was working on.
