-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better map event distribution #113
Conversation
…pe when creating map
… rooms before boss
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few things to change, but it's mainly details
The comments explain well what you are doing, that's great
Would it be possible to add a test to check the time it takes to generate a map ? Ran multiple times, to know the distribution of times, maybe 100 times ?
…r.EVENTS_CLASSIFICATION to match GlobalEnums.EventType
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generation and the rules seem good. I had to take time with some of them (3rd one specifically) but then realized it's probably because they are made for the specific map layout we decided on.
If the distributions look good (which is being discussed in other message from turtyo) then it should be good
…se_event_from_type in Global_enums
…ums.choose_event_from_type instead
This reverts commit 99e8ce1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems clear, will just test it before approving
What happens if we can't generate the map because of rules ? I don't see a retry of the generation |
Once we have the map re-generation in case we it gets blocked, I think it'll be good for approval |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good, will just test that tomorrow, a thing to change regarding code structure I think, the double break with a flag is a bit strange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Left one small comment but if you think it's okay to keep it there then we don't have to move it.
If the distributions appear good enough, then I think we are good to go with this.
Description
Changes Map Event generation based on set probabilities instead of just randomness.
There are also rules to prevent cases such as consecutive shop rooms, and floors where events are fixed (heal rooms before boss room).
Related issue(s)
Issue: #108
List of changes
Room events are generated with the following probabilities:
The probabilities are set in
GLOBAL_VAR.gd
, and the implementation is inMapManager.gd
We then apply some generation rules that are inspired by this blog:
Also some fixed rooms:
Tests
Tests are written in
test_map.gd
, they test that the 4 rules described earlier are applied correctly to the test map.Additional notes
Code in
MapManager.gd
that counts and prints the number of rooms for each event to verify if we get the number of rooms we want, with randomness. SetDEBUG_PRINT_EVENT_COUNT
inDEBUG_VAR.gd
toTrue
.