Generated maps are created at runtime using a
mod-defined trait. They are embedded directly
into replays and save games as they exist in
memory only, and disappear after the game exits.
Exposes the TilingPath code used by the map generator as a map editor
tool to help automate the process of tiling sequences of templates
together.
No additional template stitching definitions are added as part of this
commit. As such, the tool currently only supports the same auto tiling
as the map generator does. This includes:
- RA and CnC support.
- Beaches, land cliffs, and roads.
Support for additional mods and templates can be added in follow-ups
by adding the necessary MultiBrush definitions.
Related changes included in this commit to support this work include:
- Add support for sparse EditorBlits.
- Add support for MultiBrush to EditorBlitSource conversion.
- Add support for EditorBlitSource previewing.
- Adjust the "Road" types used in segmented MultiBrush definitions.
The default path weight of 125% allows paths up to 25% longer than the optimal path to be returned, which improves the performance of path searches.
Over short distances, players are likely to be sensitive to suboptimal paths this can produce, so instead use a weight of 100% over short distances to ensure these paths are optimal. As the search area is limited, the additional performance impact is also capped. The hierarchical path finder already has a speculative check for short paths within a 20 cell area (twice the grid size of 10 cells), which allows it to skip a hierarchical search if a path within that area can be found. We can piggy back on this short path logic and use a weight of 100%.
Over longer distances, players are less likely to notice the suboptimal paths, and the performance benefit is more noticeable, so continue to use the 125% weight in these scenarios.
The editor's resource value calculation logic was fixed in #21820 to
match actual gameplay. The map generator logic originally copied the
editor logic from EditorResourceLayer rather than ResourceLayer and
associated game logic. As such, it inherited incorrect calculations.
This change updates the map generator logic to match the now
consistent logic in both ResourceLayer classes. Map generator resource
settings are also adjusted -25% to continue roughly matching the
previous resource output.
For awkward symmetries (where there is mirroring and/or non-grid
aligned rotations), road planning now runs an extra filtering step so
that only sufficiently symmetric road plans make it to the tiling
stage.
Road planning also now extends out-of-map-bounds to more accurately
accommodate awkward rotations, improving the symmetry of pre-filtered
road plans.
A previous filter, which removes nearly horizontal or vertical roads
is now removed, as this is not fair to all rotations. This step is
less importance since the introduction of relaxed tiling.
Note that roads may be dropped entirely if the plans come out highly
asymmetric. This is not uncommon for awkward rotations. This is
preferred over presenting a map with asymmetric roads.
CnC map generation previously only supported maps with water/beaches
for the DESERT tileset, as it is the only tileset with a complete set
of beach tiles. This change adds support for the other tilesets
(TEMPERAT, SNOW, WINTER) by adding fake beach templates constructed
from actors and other templates' tiles that look reasonable in both
original and remastered graphics.
This means all CnC tilesets have feature parity in the map generator.
This generalizes TilingPath to accept MultiBrushes instead of templates
and makes the output also a MultiBrush. As a result:
- Composite or faked templates can be used in tiling. This will (in a
later change) be used to support CnC beaches outside of the desert
tileset.
- The tiling result can be previewed without committing it onto the map,
making it more viable for adoption as an editor tool.
- The full shape of the tiling result can be inspected without messily
reading it back off of the map, simplifying some map generator logic.
- Separates map generation-specific segment definitions from the core
template definitions.
- As MultiBrushes can be many-to-one with templates, there is no need to
have a one-to-many template-segment relationship. Multi-segment
templates, such as roads, now use multiple brushes instead. This
simplifies the logic of segment consumers.
Previously, MultiBrushes which contained no offset information in their
definitions were automatically aligned such that the first tile was
under 0,0. This is no longer the case. This was previously done for use
in MultiBrush.PaintArea to improve tile packing success, but the
alignment is now handled automatically by PaintArea instead.
Due to some impure refactoring which changes the randomization of
tiling choices, map generation results may change.
