Skip to content
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

Make monstergroups work the way one would expect #52284

Closed
I-am-Erk opened this issue Oct 14, 2021 · 6 comments · Fixed by #52323
Closed

Make monstergroups work the way one would expect #52284

I-am-Erk opened this issue Oct 14, 2021 · 6 comments · Fixed by #52323
Labels
[C++] Changes (can be) made in C++. Previously named `Code` Code: Infrastructure / Style / Static Analysis Code internal infrastructure and style Good First Issue This is a good first issue for a new contributor [JSON] Changes (can be) made in JSON (P3 - Medium) Medium (normal) priority Spawn Creatures, items, vehicles, locations appearing on map <Suggestion / Discussion> Talk it out before implementing

Comments

@I-am-Erk
Copy link
Member

I-am-Erk commented Oct 14, 2021

Is your feature request related to a problem? Please describe.

The monstergroup JSON object is quite difficult to use, and as a result we have a lot of poorly made monstergroup entries that are basically duplicates of each other. They're also very difficult for humans to read.

Describe the solution you'd like

I have four core suggestions that would deeply enhance human-readability of monstergroups. I have set these up in order of what I believe is easiest to hardest, but also the later entries are at least partially dependent on some of the earlier ones. The first two should be quite easy. Each should definitely be a separate PR.

  1. Change "starts" and "ends" to use standard time units instead of hours, so where they are currently 1440, it would instead be "30 days". I assume for backwards compatibility if just an int was entered, we'd still read that as hours. Note that if standard time units are used, they should still be affected by monster evolution speed as the hours measurement is.
  2. Make the cost_multiplier field optional and have it default to 1. It's something we rarely need at all, yet it's required, creating a ton of clutter. Run a find and replace and remove every instance of "cost_multiplier": 1. Ideally, remove all cost_multiplier entries in upgrade-only zombie lists, since they do nothing there.
  3. Change "freq", which is currently a number out of an implied 1000, to instead use a weighted list like itemgroups do. It would no longer be a required field - assumed to be 1 if not entered. The chance of a given monster being selected from the list is equal to (freq of this entry) / (sum of all freq in the list). If you wanted to change the name from freq to weight at this point I would not object. This would also remove the need for the current "default" field. Warning: as the default field can include mon_null, this will probably result in some big glitches to monster spawning that will need shaking out later. This might be allayed by adding mon_null as a possible spawn to those lists.
  4. The big one: allow monstergroups to nest within each other, like itemgroups do. See Allow nesting monster groups #49392 for more detailed thoughts on how this should be implemented.

Describe alternatives you've considered

Things technically work in their current form, but I think all these changes are actually quite necessary to make monstergroup auditing a sane task. Number 4 in particular will allow us to condense a huge number of redundant groups into much smaller entries.

I wouldn't mind an option for some functional metadata in monstergroups, such as flagging upgrade lists with "upgrades" and throwing an error if they are used elsewhere.

Additional context

In the future, we may want to consider replacing start, end, and cost_multiplier with difficulty. We'd have a difficulty value of the game that slowly increases over time, a rate which can be adjusted in settings, and perhaps in the distant future have that rate change dynamically based on how the game is going. That is not within the scope of fixing monster groups.

@I-am-Erk I-am-Erk added <Suggestion / Discussion> Talk it out before implementing [JSON] Changes (can be) made in JSON Spawn Creatures, items, vehicles, locations appearing on map [C++] Changes (can be) made in C++. Previously named `Code` (P3 - Medium) Medium (normal) priority Code: Infrastructure / Style / Static Analysis Code internal infrastructure and style Good First Issue This is a good first issue for a new contributor labels Oct 14, 2021
@Venera3
Copy link
Member

Venera3 commented Oct 14, 2021

For nested monstergroups specifying a pack size in the upmost array, and taking that number of entries (with their own pack size) from the lower-level groups would be extremely useful - see #49392.

Start/end dates are also multiplied by the evolution factor, for the record.

I'd adore if cost_multiplier did anything, as it stands it's only relevant to the radius-based monster spawns but it could be a useful balancing factor if it played a role in the "normal" OMT-based spawns.

@I-am-Erk
Copy link
Member Author

For nested monstergroups specifying a pack size in the upmost array, and taking that number of entries (with their own pack size) from the lower-level groups would be extremely useful - see #49392.

Start/end dates are also multiplied by the evolution factor, for the record.

I'd adore if cost_multiplier did anything, as it stands it's only relevant to the radius-based monster spawns but it could be a useful balancing factor if it played a role in the "normal" OMT-based spawns.

I changed 4 to link to your issue, and I'll add a comment about start/end dates.

What would cost_multiplier do, if we had weighted lists? I can't think what it would apply to individual monster spawns. it might be nice to have some kind of "spawn zone" option where we could define in mapgen something like a 20x20 region where monsters can be found at a given density, and then cost_multiplier could be used.

@Venera3
Copy link
Member

Venera3 commented Oct 14, 2021

The way I thought cost_multiplier worked (for longer than I care to admit) was when a set population is rolled from e.g. the overmap definition the cost_multiplier of the entry gets deduced - if a swamp rolls four pops and predators take up two, that means this tile can either roll two predators, four prey or a 1/3 split.

@I-am-Erk
Copy link
Member Author

That is how it works afaik. I mean I'm not sure what it would do in other situations that isn't handled by a weighted list.

@Venera3
Copy link
Member

Venera3 commented Oct 15, 2021

That's how it works in the context of radius spawns. Otherwise ot does jack - put it at 3000 and behold stuff spawning all the same.

@I-am-Erk
Copy link
Member Author

Ah yeah, that definitely needs fixing then

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C++] Changes (can be) made in C++. Previously named `Code` Code: Infrastructure / Style / Static Analysis Code internal infrastructure and style Good First Issue This is a good first issue for a new contributor [JSON] Changes (can be) made in JSON (P3 - Medium) Medium (normal) priority Spawn Creatures, items, vehicles, locations appearing on map <Suggestion / Discussion> Talk it out before implementing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants