#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# "Forest fire" algorithm?

Apologies in advance for not being clear. I'm still trying to define this problem.

I'd like help with a "forest fire" algorithm to support sandbox generation. Suppose you have a large hex-in-hex map. These hexes are numbered (let's say 1 to 100) and they are adjacent to others based on their placement on the map.

Now let's suppose one of these hexes is on fire. You'd like the generator to create a larger area of fire, based say on strength of the initial fire. I'm thinking perhaps Hex A has a chance to set adjacent hexes on fire, which then may spread (but not forever). How might you do this?

Forest fires are one application: a working algorithm could also be used for things like area of influence around an orc nest, direction and length of streams or small rivers or roads in a 1-hex-per-mile map, etc.

Any thoughts?

• edited July 2018

So, I'm thinking that you need to have a numerical standard for the relative position of each adjacent hex. For instance if the fire (or peasant revolt, plague, giant rat epidemic) started in hex 26, it easy to figure the the hex to the left is 25, and the hex to the right is 27. But, by knowing the overall grid dimensions, you might determine that the adjacent hex above-left is (n-12) or 14, which makes above-right 15, and (probably) below-left 38 and below-right 39. I'm guessing that there is a constant for hex grids that given rows of 24/25 across, the above-left is always n-25, or something like that, where by gaining user input of the number of rows across, this could be made universal for any size of grid.

So, if that's the way the grid is laid out, then the code would be something like:

1. Start with 1d100 to determine origin hex for event (or prompt the user to enter the hex ID number).
2. Set a variable (origin) = to that number.
3. Check the 6 adjacent hexes with some kind of die roll: If 1d100 < 20 then hex (origin-12) is affected; repeat for hexes n-11, n-1, n+1, n+12, n+14. Display these results. I'd put in a user prompt asking for the "contagion" rate and use this value instead of the static "20" in my example (as in, user enters how likely is it to spread).
4. I'd think you need to assign more variables to those hexes that it spreads to.
5. Then (here's the tricky part, I'm sure this will take more thought...) something like "if hex n-1 is affected, then set n-1 as origin2, and call the table checking 6 adjacent hexes for spread, but sending origin2 as the source point. Loop this over and over again. (I know, easier said than programmed).
6. Might want to send % chance of spreading to the table as a variable too. First table call from origin spreads at {\$prompt1} percentage; each subsequent cycle of checking the next ring of hexes is maybe round({prompt1} * 0.7). This will give it a dampening effect as the spread gets further and further from origin. You could also prompt for dampening constant, but I think that just complicates things. Here, if the first ring has 20% chance to spread, the second ring has 14% chance, and the third ring has 10% chance. With a higher beginning contagion, say 70% change to spread, the second ring would be 49% and the third ring would be 35%.

I think the practical way to do this, is to loop it until spreading stops, and display all affected hexes on the screen with a note of the origin (or let the user enter the origin from the prompt). Then the GM just has to layout the full spread, and explain to players where it spreads each turn/day/month, as the reality is that the spread won't be instantaneous.

Another easier way (programming wise) would be to just run the 6 adjacent hex... no big deal. That is epidemic interval 1. Then rerun the generator again, once for each "positive spread" hex, setting a user defined origin of the new affected hex. and do this manually until extinguished, manually changing the % chance to spread during each interval check (to simulate dampening or intensifying), until extinguished. Much easier to program, but not too much more helpful than picking up a couple dice and manually rolling.

Very interesting concept you have. I'd love to play around with it a bit in IPP, but I'm wrapped up for the next week or so. Good luck!