Support for mutable overmap specials and unhardcode anthills #51317
Conversation
jbytheway
force-pushed
the
overmap_mutable
branch
from
dd3f945 to
5928eb2
Compare
actual-nh
added
[C++]
|
Well, that looks way too difficult (for me) to comprehend at glance. It would require thorough examination for proper use. |
|
This pull request introduces 3 alerts when merging e577f98 into acde44f - view on LGTM.com new alerts:
|
jbytheway
force-pushed
the
overmap_mutable
branch
2 times, most recently
from
8b9adae to
2a65b1f
Compare
|
I believe the LGTM warning is resolved. |
|
Remaining CI failure appears to be unrelated. |
Correct; see #51377. |
jbytheway
force-pushed
the
overmap_mutable
branch
from
2a65b1f to
04def7f
Compare
I am trying to add a new variant of overmap special. As a precursor to that, I wanted to refactor a bunch of the overmap_special code so that more of it is contained within the overmap_special class rather than other code messing with its internals directly. Thus, made most of its member variables private and moved various chunks of code to member functions.
This feature already existed for some specific enums, but we can implement a generic version.
Mutable overmap specials are a new type of special where you do not define a specific layout, but rather a collection of rules about what OMTs are permissible and how they link together. Add this as a new subtype of overmap special, with all the associated code to support it. This is only an initial, limited, implementation.
A first step towards un-hardcoding anthills, make a mutable overmap special to represent them. In this first iteration, it's nothing more than a single crossroads with some variable-length straight tunnels extending in each compass direction.
When growing a mutable overmap special, actually respect the location restrictions set by the JSON.
The JSON anthill now spawns food, larvae, and queen rooms in addition to just tunnels.
When placing an OMT as part of a mutable overmap special, previously it was possible for it to be placed in such a way that it had a connection into some terrain that could not permit that connection. For example, a tunnel that would have to lead into another tunnel. Now, when satisfying a constraint, we also verify that the adjacent terrains fall into the into_locations member of the respective connections. If not otherwise set, those locations are the default locations of the special.
Allow a mutable overmap special to specify some location constraints for its initial placement. This prevents some types of placement errors (such as an anthill over a sewer tunnel that prevents the underground part being placed).
The term 'connection' already had a meaning in the context of overmap generation, so I should not have reused it. Switch to 'join' instead.
Fix LGTM warnings.
jbytheway
force-pushed
the
overmap_mutable
branch
from
04def7f to
88d9a40
Compare
|
Note that I've opened a follow-up PR #51474 that includes this one with further changes (in particular, it adds the ant spawns back to the ant tunnels that were missing in this version). |
|
There's a CI error in "GCC, Ubuntu cross-compile to MinGW-Win64, Tiles, Sound". It doesn't like the |
|
It isn't just the cross-compile, looks like - GCC is objecting on Linux also. Ping: @jbytheway? |
|
In case it helps, here is another anthill spawn failure on Ubuntu Clang: |
Thanks, but it looks like that log has already vanished. |
Summary
Infrastructure "Support for mutable overmap specials"
Purpose of change
We still have several hardcoded overmap specials which we would like to unhardcode, such as anthills and classic labs. One of the reasons these have been difficult to convert to JSON is that their layout on the overmap is randomized. Currently JSON special definitions must have a fixed layout.
Describe the solution
Split overmap specials into two subtypes: fixed and mutable.
Fixed specials are what we already had. Mutable specials are a new concept that allows randomized layout on the overmap.
In short, mutable overmaps specials work like a jigsaw puzzle, where each OMT is a piece, and you define how the pieces can fit together.
Use this to define a mutable special for anthills. Note that I haven't actually removed hardcoded anthills yet because this only works for regular ants, not acid ants (so far).
Document the new feature in
OVERMAP.md, using the anthill as an example.Describe alternatives you've considered
This is a minimal viable initial implementation. I can already see various refinements that will be needed, but this was sufficient to allow anthills to be reliably generated, so I stopped here to make the initial PR as small as possible with a meaningful proof of concept.
My new anthills are smaller than the old ones, but I think that's reasonable. They are really rather boring mostly-empty tunnels (in both cases), so I don't think they should take up too much overmap space.
A bigger issue is that the new anthills don't have any ants in them (except for queens and larvae). This is not really fixable until we also un-hardcode the lower-level anthill mapgen, because those spawns ought to be linked to the OMT definitions, which are hardcoded. I plan to do that in a follow-up PR. This one was already adding a lot of stuff and I didn't want it to grow further.
Testing
The new docs can be viewed here.
Generated a lot of anthills.
Here's what old-style hardcoded anthills tend to look like:
Here's an example of the new-style JSON anthill, as it naturally spawns:
Here's the result of me debug-spawning many anthills close to each other to verify that they can spawn without error even in constrained situations:
Additional context
It seems like there are issues with the regular (non-overmap) generation of anthills, because none of them spawn with a way to get out to the surface. But this is a problem with old and new anthills, so out of scope for this PR.