Split a room in two when it stops holding together - #23
Conversation
Selling the middle of a bridge leaves two stretches of bridge that are still one room. Everything done to a room is then done to both, and claiming is the one that shows: an enemy worker dancing on one stretch takes the other one too, across the lava it cannot reach. Rooms merge but never split. checkForRoomAbsorbtion() makes one room out of two that come to touch, and nothing does the reverse when tiles are lost, whether sold or destroyed. So Room gains checkForSplit(), which gathers the covered tiles into the groups that hold together, by the same neighbouring rule that decides two rooms are really one, and hands every group but the biggest to a room of its own. It runs after tiles are sold and after Building::doUpkeep() removes the ones whose hit points reached zero, which is the enemy digging through the middle of a room. Handing the tiles over follows absorbRoom(), which does the same thing the other way round. The new room gets a copy of what this one knew about each tile, and what was built on it. This one keeps the original marked destroyed rather than dropping it: a seat remembers which building covers each tile it can see and asks that building about it until told otherwise, so a room that forgets a tile it has handed over is asked about it anyway and reads through a null. Those tiles are not offered for repair, since a tile the other room covers cannot be built upon. What a room keeps for itself rather than per tile is its own business, so splitRoom() lets it give the new room its share. A bridge splits the value an enemy has to dance away, in proportion to the tiles. A treasury has the opposite problem: it counts the gold of every tile it has data for, not only the ones it covers, so the copy left behind has to be emptied or selling the middle tile of a treasury makes gold instead of costing it. It is not only bridges. Any room can be cut in two, and a room in pieces gets its active spots, its creature places and its centre wrong. Traps are claimable and tile based as well and have the same bug, but they build their tiles differently and are left alone here: Building::checkForSplit() does nothing unless a building knows how to split. source/tests/test_RoomSplit.cpp builds a treasury five tiles wide, fills it with 5000 gold and sells the tile in the middle. 4000 is left, the gold of the four tiles that remain. Losing what the moved tiles held would leave 2000, and copying it would make 6000. The test found both of those, and a crash, before this commit was worth making. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 4195cba)
|
Great, will merge it. ODP has functionality I even wasn't aware of ... I am speaking about the dance stuff -- it is possible to claim whole bridge, by enough dancing --even if the drone stands all the time on one of the squares ... Have to consult that with other people, but I prefer the bridge is to be taken square by square ..... |
Isn't this the same behavior as in DK? |
|
I have never played DK only DK2 ... but if my memory serves well ... the second mechanism we are talking about was implemented. |
|
IIRC in DK2 all buildings were claimable, here only bridges. Do you want to make that change? |
|
I will implement it on my own , no worries :D . Actually I would love to have a discussion on discord between users what mechaniscs is desired .... Making rooms claimable or destructible that is the question ! :D anyway Traps should be destructible. The possibility of taking over someones rooms gives handicap to more aggresive/conqueror-style players... Also when you loose something on the behalf of other player, it is still possibile to regain what is lost , when destroying rooms it is not the case..... |
|
Since you'd love a discussion on the mechanics, I've turned the options into concrete PRs you (and the Discord folks) can look at, play-test and pick from — merge what you like, close what you don't, or just use them as reference for your own implementation:
On your handicap point: I'd note claiming is the reversible mechanic — what you lose can be regained, as you said — while destruction is final for the owner and gains the attacker nothing. DK2 shipped both at once (rooms had HP and were claimable), and #33 + #35 together let you test exactly that combination, tuning HP vs claim speed to taste. All four build on |
|
ohh I am so thankful ... :) Many thanks for those proposals .... I will play and choose the best one soon. |
2 participants
Selling the middle of a bridge left two stretches of bridge that were still one room, so everything done to one was done to both — an enemy worker claiming one stretch took the other across lava it cannot reach. Rooms merged but never split:
checkForRoomAbsorbtion()had no reverse.Room::checkForSplit()now gathers covered tiles into connected groups and splits the room when it stops holding together, with per-room-type handling and a unit test (test_RoomSplit).Split out of #16 so each topic can be reviewed on its own. Merging all of the split PRs reproduces the tree of #16 exactly.
🤖 Generated with Claude Code