This shows you the differences between two versions of the page.
|
dcss:brainstorm:dungeon:branch:tartarus [2014-09-30 21:24] infiniplex [Ongoing Decay] Added mumra's original note |
dcss:brainstorm:dungeon:branch:tartarus [2014-09-30 21:51] (current) infiniplex [Internal Representation] moved to seperate section |
||
|---|---|---|---|
| Line 20: | Line 20: | ||
| The starting map is like the decayed map, but with special walls added. (Or the decayed map is like the start map with some walls removed.) These would behave and appear exactly like normal walls in-game, except that they would eventually convert to floor. They would need to be placed intelligently (not just with e.g. ''SUBST:''), so that they did not disconnect the map and do not change its basic style (e.g. city, passages, etc.). | The starting map is like the decayed map, but with special walls added. (Or the decayed map is like the start map with some walls removed.) These would behave and appear exactly like normal walls in-game, except that they would eventually convert to floor. They would need to be placed intelligently (not just with e.g. ''SUBST:''), so that they did not disconnect the map and do not change its basic style (e.g. city, passages, etc.). | ||
| - | |||
| - | My guess is that the best way to represent these walls internally would be using a special feature type (e.g. ''DNGN_DECAYING_WALL''). It would look and act like a rock wall, and would be placed by layouts. Vaults could also place it using ''KFEAT'' (like they place iron grates now). The disadvantages I see to this are that I don't know how many places in the code this new constant would have to be added to (it could be a lot), and that it might break save compatibility. Some other options would be a) to reserve a special certain character for this (I think the ''char''-based maps are stored), b) to place markers on each cell that set some new property, or c) to keep a bid table of all the decaying cells in LUA persistent data. None of these seem as good as a new feature-type to me. | ||
| The map would still start connected (with at least one down stair reachable from every spot. As long as the decaying walls never disconnect areas, this will be easy to achieve. | The map would still start connected (with at least one down stair reachable from every spot. As long as the decaying walls never disconnect areas, this will be easy to achieve. | ||
| Line 34: | Line 32: | ||
| * Special layouts would be needed. Depending on exactly how the decaying walls are placed, they could get quite complex. | * Special layouts would be needed. Depending on exactly how the decaying walls are placed, they could get quite complex. | ||
| * This would lead to trouble with end vaults. Either they would have to be redesigned with appropriate decaying walls, of the decay would mysteriously stop at the end vault. | * This would lead to trouble with end vaults. Either they would have to be redesigned with appropriate decaying walls, of the decay would mysteriously stop at the end vault. | ||
| + | |||
| + | ==== Internal Representation ==== | ||
| + | |||
| + | My guess is that the best way to represent these walls internally would be using a special feature type (e.g. ''DNGN_DECAYING_WALL''). It would look and act like a rock wall, and would be placed by layouts. Vaults could also place it using ''KFEAT'' (like they place iron grates now). | ||
| + | |||
| + | The disadvantages I see to this are: | ||
| + | * I don't know how many places in the code this new constant would have to be added to (it could be a lot) | ||
| + | * It might break save compatibility. | ||
| + | |||
| + | Some other options would be to: | ||
| + | * Reserve a special certain character for this (I think the ''char''-based maps are stored) | ||
| + | * Place markers on each cell that set some new property | ||
| + | * Keep a bid table of all the decaying cells in LUA persistent data. | ||
| + | None of these seem as good as a new feature-type to me. | ||
| ==== Decay Methods ==== | ==== Decay Methods ==== | ||