Give room tiles configurable hit points per room type - #33
Open
Upabjojr wants to merge 1 commit into
Open
Conversation
Enemy fighters already attack and destroy rooms tile by tile, but every tile of every room had the same flat Building::DEFAULT_TILE_HP = 10 -- a couple of swings from a mid-level creature -- and there was no way to tune it. Room::getTileHP() now reads <RoomName>HP from rooms.cfg (e.g. DormitoryHP, DungeonTempleHP) through a new getRoomConfigDoubleOrDefault that falls back to the old value of 10 when the entry is missing, so older config files keep working. The shipped values make rooms meaningfully sturdier than a creature and the dungeon temple the hardest to bring down; they are meant to be argued about in the config file, not in code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 6, 2026
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 2 of the set following the mechanics discussion in #23 (#23 (comment)) — the "rooms destructible" side of the "claimable or destructible" question.
Rooms are in fact already destructible today: enemy fighters (not workers) target visible enemy rooms, damage them tile by tile, and a tile at 0 HP is removed from the room — with the recently merged room splitting (#23) even cutting a room in two. But every tile of every room has a flat
Building::DEFAULT_TILE_HP = 10.0, which a mid-level creature removes in a couple of swings, and there is no way to tune it. As a mechanic it exists but has no knobs.This PR gives it knobs:
Room::getTileHP()reads<RoomName>HPfromrooms.cfg(e.g.DormitoryHP,TreasuryHP,DungeonTempleHP), falling back to the old 10 when an entry is missing, so older config files keep working. Shipped defaults make rooms meaningfully sturdier than a creature (30–50 HP per tile, 100 for the dungeon temple) — first-guess numbers, meant to be argued about in the config file rather than in code.Notes for the design discussion:
Building::removeCoveredTiledoes not unclaim), so the owner can rebuild on it cheaply, while the attacker would still have to dance the ground afterwards. Destruction is therefore already less "permanent" than it sounds — the owner loses the building and half the gold, not the territory.Room::repairRoom) is currently only ever called by the AI keeper; human players just re-buy tiles. Making repair a player action could be a follow-up if the destructible route is chosen.This proposal is independent of the others in the set: it can be merged alone, together with the traps one (#32), or alongside the claimable-rooms prototype — the mechanics compose (some rooms could be claimable and all of them destructible, DK2-style).
Validated: builds and the full test suite passes via
ctest.🤖 Generated with Claude Code