Was thinking about the longstanding issue of fire acting oddly when the player isn’t there to interact with it, and realized there’s a solution to the problem of keeping the map data loaded to handle the spread of fire when the player isn’t there. Jotting down the details for reference when I have time, or in case someone else decides to add it.
- Store a bitmap of whether each tile is flamable or not in the overmap. This would take about 2MB of memory if every map tile is loaded, but there are several measures we can take to mitigate this overhead.
- Only load bitmaps for map tiles that have been generated.
- This requires us to generate map tiles if fire spreads near them, but this should generally be pretty infrequent.
- Only load bitmaps for tiles that have flamable components, air, rock, river, roads, etc, as well as burned tiles don’t need to be tracked.
1.a. Actually we only need to track bitmaps of map squares with flammable borders, if a fire can’t enter a square, we can just count the whole thing as non-flammable.
- Only load bitmaps for map tiles that have been generated.
- Store timestamps of active fires to track the spread. For each square a fire spreads to, we just need the turn on which it caught fire.
- Possibly just store the timestamp of the first square that the fire spread to caught, and the bitmp of the rest.
- Each tick (not necessarally turn), process active fires with adjacent flammable squares and check for spread.
- Ideally this won’t be random, it’ll just spread to adjacent flammable tiles after a delay.
- When a map with a burned tile is loaded, any tiles that were on fire have the fire effect applied as of the timestamp recorded in the overmap, then fuel is consumed at the ordinary rate until the current time is reached. The expectation is that it will usually be burned out, which is really cheap to calculate.
Risks:
Memory utilization might get out of control if the player explores too much. This is bounded by the number of overmaps that are loaded, probably never more than 10MB.
Processing the active fires in the background might get too expensive. This should be mitigated by only processing active fires on their appropriate tick, and fires going passive once they’ve spread to all adjacent squares.
Active and reactive entites like explosions and fire monsters will not be represented. For these to work properly they need to load the nearby map, process, then unload the map. This is possible but tricky.