Let enemy workers claim room tiles (DK2-style), behind a config switch - #35
Open
Upabjojr wants to merge 2 commits into
Open
Let enemy workers claim room tiles (DK2-style), behind a config switch#35Upabjojr wants to merge 2 commits into
Upabjojr wants to merge 2 commits into
Conversation
A bridge held a single claim pool for the whole room: an enemy worker dancing on any one square drained the shared pool and, the tick it hit zero, every tile of the bridge changed hands at once -- however long the bridge and wherever the worker stood. The claim progress now lives per tile (BridgeTileData, mirroring how traps already track per-tile claims). A worker dances one square down and only that square changes hands: it moves into a bridge owned by the claimer, merging with an adjacent bridge of theirs through the existing checkForRoomAbsorbtion, and if the loss cuts the victim's bridge in two the room splitting takes care of the halves. The tile stays a bridge tile throughout, so pathing is never interrupted and flood fill does not change. The stream format still carries one claim value per bridge (the sum of the per-tile values, shared out evenly on load), so existing level files and saves load unchanged. Portals keep their whole-room claim. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The DK2-style side of the claimable-or-destructible question: when RoomsClaimableByEnemies is set to 1 in rooms.cfg, enemy workers can dance room tiles down one at a time, the way they already claim ground, bridges and traps. A claimed tile moves into a room of the same type owned by the claimer, merging with an adjacent room of theirs, and the victim's room splits when it is cut in two. Room-level state travels through the existing splitRoom hook, so a treasury tile takes its share of the stored gold with it. What was lost can be danced back. The switch ships as 0: default behaviour is exactly as before, rooms can only be destroyed. The dungeon temple is never claimable since losing it means defeat and that path expects destruction. Portals keep their whole-room claim, bridges their per-tile claim. The per-tile claim progress moves from BridgeTileData into the base TileData so every room type shares it; TrapTileData keeps its own field of the same name until trap serialization can move too. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposal 4 of the set following the mechanics discussion in #23 — the "rooms claimable" (DK2-style) side of the "claimable or destructible" question, as a prototype to play-test, off by default.
Builds on top of the square-by-square bridge PR (#34) and generalizes its tile-transfer machinery: enemy workers can dance enemy room tiles down one at a time, exactly like ground tiles and (now) bridge tiles. When a room tile falls it moves into a room of the same type owned by the claimer — merging with an adjacent room of theirs when there is one — and the victim's room splits if it was cut in two. Room-level state is shared out through the existing
splitRoomhook, so e.g. a treasury tile takes its share of the stored gold with it (and merges it back into the claimer's treasury on absorption).Because Tom explicitly wanted a community discussion on this one, the whole mechanic is gated behind a config switch in
rooms.cfg:0(shipped default) keeps today's behaviour: rooms cannot be claimed, only destroyed. Set it to1to try the DK2-ish mode where conquest is possible and reversible — you can dance your dormitory back after driving the enemy out. Workers still only reach tiles at the border of fully-claimed ground, so a room deep in enemy territory erodes from the edge inward, which in practice makes claiming slower than destruction unless the area is secured.Portals keep their own whole-room claiming, bridges their per-tile claiming; the dungeon temple is excluded from claiming (losing it means defeat and that path expects destruction).
Points for the Discord/community discussion this is meant to feed:
<RoomName>ClaimValue) if the flat 1.0-per-tile feels wrong.Validated: builds, full test suite passes via
ctest, both with the switch off (default behaviour unchanged) and on.🤖 Generated with Claude Code