Hello, I'm working on a game with destructible and rebuildable environment, which is working great. Fires slowely spread and burn up any material it touches. Now I would like to make the (top-down 2d) map scrollable, but I'm unsure of what to do with things like fire. I can't keep this running these offscreen processes while maintaining performance, but it would be weird if it stops or dissappears after moving offscreen.
Any ideas on how to handle this?
I don't keep track of the fires in an array or something, every fire is it's own little isolated process and checks after a delay wether it is touching material (non transparant pixel) and starts new fires at those locations.
PS: I've been a member of this community for nearly a decade now (Kirl), but I had to re-register because I forgot my password and don't have acces to the mail acount I used at the time I registered.
How to handle offscreen processes like fire?
starts new fires at those locations.
I fear that you need at least some kind of offscreen simulation. Best to break down your simulation effect in level of details and reduce the LOD (=faster) of parts which are not near the visible screen.
"Pixel" sounds scary for checking if fire should spread. I think you should try to simplify it by treating objects as a bunch of boxes or spheres, as fire is kind of chaotic after all so it doesnt need to be perfectly accurate.
The longer a fire is offscreen, the more you can lower the accuracy/take bigger simulation steps for your fire. (if the user looks away for a second, you dont want to throw all the simulation state away and say "BIG FIRE HERE, OK?" and when he returns its completely different...)
Assuming you even need a LoD after making the fire itself fast.
EDIT: crazy optimization idea from the evil volcano of premature optimization!
have time slow down farther from the player, but so that if he walks there, the objects will simulate faster until theyre up to date again before being seen. This will make the computer process a more concentrated chunk of fires at once, instead of all of them. Because its kind of smooth simulation falloff, it wont hopefully cause bad errors because of fire not being able to spread farther because not being simulated there.
This will improve cache coherency by a ridiculously small amount. yay.
The longer a fire is offscreen, the more you can lower the accuracy/take bigger simulation steps for your fire. (if the user looks away for a second, you dont want to throw all the simulation state away and say "BIG FIRE HERE, OK?" and when he returns its completely different...)
Assuming you even need a LoD after making the fire itself fast.
EDIT: crazy optimization idea from the evil volcano of premature optimization!
have time slow down farther from the player, but so that if he walks there, the objects will simulate faster until theyre up to date again before being seen. This will make the computer process a more concentrated chunk of fires at once, instead of all of them. Because its kind of smooth simulation falloff, it wont hopefully cause bad errors because of fire not being able to spread farther because not being simulated there.
This will improve cache coherency by a ridiculously small amount. yay.
The first idea would be to assemble more information and make some rough estimates of what problem we are actually dealing with here.
Hello, I'm working on a game with destructible and rebuildable environment, which is working great. Fires slowely spread and burn up any material it touches. Now I would like to make the (top-down 2d) map scrollable, but I'm unsure of what to do with things like fire. I can't keep this running these offscreen processes while maintaining performance, but it would be weird if it stops or dissappears after moving offscreen.
Any ideas on how to handle this?
I don't keep track of the fires in an array or something, every fire is it's own little isolated process and checks after a delay wether it is touching material (non transparant pixel) and starts new fires at those locations.
What is the structure of your world (continuous, tile-based, ...)?
How large is the world?
How much burning stuff does it contain?
How large is one "unit of fire" (if applicable)?
Do burning things stop burning? If so, how fast, and can they burn again or are they scorched?
I suppose the fires are objects using some kind of timer callback instead of being actual operating system processes?
And it sounds as if a fire always starts a new fire if something flammable is adjacent to it during a game logic tick. No randomness. Correct?
Author
Thanks for the thoughts all, I have included a link to an earlier prototype because a picture says more then a thousand words (not to mention 30.000 words a second). 
You can see it in action here: http://kirl.nl/pixelfunk.html (click screen to set focus)
Controlls:
Arrow keys = move and turn
Ctrl / LMB = shoot
Space = change weapon (gun, fire, water, matter)
Hold Shift = drill mode for when you get stuck
Alt = generate new random walls
What is the structure of your world (continuous, tile-based, ...)?
The world is continuous, I tried adding an underlying grid in an attempt to optimise some stuff, however this hasn't been very succesfull yet...
How large is the world?
I'm not sure yet how big the world will be, for now the map doesn't scroll so it's as big as the screen (400x550);
How much burning stuff does it contain?
Depends, in theory the entire screen can be ablaze.
How large is one "unit of fire" (if applicable)?
One fire unit is a sphere of about 20x20 pixels.
Do burning things stop burning? If so, how fast, and can they burn again or are they scorched?
One fire unit continues until a delay (~1-2 seconds), then it removes the underlying material, checks for neighbouring pixels (starts new fires if there are) and removes itself. So the burning material is basically being chipped away by little sphere shaped bites.
You can see it in action here: http://kirl.nl/pixelfunk.html (click screen to set focus)
Controlls:
Arrow keys = move and turn
Ctrl / LMB = shoot
Space = change weapon (gun, fire, water, matter)
Hold Shift = drill mode for when you get stuck
Alt = generate new random walls
What is the structure of your world (continuous, tile-based, ...)?
The world is continuous, I tried adding an underlying grid in an attempt to optimise some stuff, however this hasn't been very succesfull yet...
How large is the world?
I'm not sure yet how big the world will be, for now the map doesn't scroll so it's as big as the screen (400x550);
How much burning stuff does it contain?
Depends, in theory the entire screen can be ablaze.
How large is one "unit of fire" (if applicable)?
One fire unit is a sphere of about 20x20 pixels.
Do burning things stop burning? If so, how fast, and can they burn again or are they scorched?
One fire unit continues until a delay (~1-2 seconds), then it removes the underlying material, checks for neighbouring pixels (starts new fires if there are) and removes itself. So the burning material is basically being chipped away by little sphere shaped bites.
Cool demo.
I think it's going to depend a lot on how you decide to approach working with a larger area and what the project is to become. If you're thinking you want to unload the portion of the level from memory while the player is off somewhere else, the only thought I have might be to do up some sort of floodfill algorithm that behaves similar to the way the fire behaves. When you return to the area and need to load it up again, run the floodfill from where the fires currently are, spreading outwards a distance appropriate for the time the player has been away.
Also, just a thought if you want to limit how much fire can destroy, you may want to consider having it affected by a constant wind direction and generally have it favor traveling upwards if there's material to burn that way.
I think it's going to depend a lot on how you decide to approach working with a larger area and what the project is to become. If you're thinking you want to unload the portion of the level from memory while the player is off somewhere else, the only thought I have might be to do up some sort of floodfill algorithm that behaves similar to the way the fire behaves. When you return to the area and need to load it up again, run the floodfill from where the fires currently are, spreading outwards a distance appropriate for the time the player has been away.
Also, just a thought if you want to limit how much fire can destroy, you may want to consider having it affected by a constant wind direction and generally have it favor traveling upwards if there's material to burn that way.
The title of this thread made me think of some software engineer in a Dilbert cartoon, who has lost the ability to do anything in the real world and posts here in response to a fire in the building. 
Author
lol @ Álvaro, I love Dilbert! 
Thanks for your thoughts kseh! I had been thinking along those lines, but because the fires spread erratically I can't predict a large area to fill at once. So I'd just have to run the fire function with 0 spread delay a nr of times, if this is fast enough. I fear for larger areas and another tricky problem I foresee is offscreen fires not burning back into view if the material is there.
Thanks for your thoughts kseh! I had been thinking along those lines, but because the fires spread erratically I can't predict a large area to fill at once. So I'd just have to run the fire function with 0 spread delay a nr of times, if this is fast enough. I fear for larger areas and another tricky problem I foresee is offscreen fires not burning back into view if the material is there.
How about keeping your fire alive when offscreen minus the graphics...
By this I mean, you stop aimating them graphically when they are off screen and you implement a routine that calculate the progression of the fire on affected object keeping, say a ratio, of their burned factor over time.
Then when your player scroll back to that portion of the map you use this ratio to draw the affected object. Your computer can crunch number easilly in the background.
By this I mean, you stop aimating them graphically when they are off screen and you implement a routine that calculate the progression of the fire on affected object keeping, say a ratio, of their burned factor over time.
Then when your player scroll back to that portion of the map you use this ratio to draw the affected object. Your computer can crunch number easilly in the background.
Hello. you could try to set all particles up so all you need is to pass the current time and it can calculate the current position based on the time.
I think you need to keep a copy of the direction at origin and a initial position of the particle(fire) .
float t;
float3 Vel = initialDirW * Speed;
float3 position = (0.5f*t*t * Vel + (t*initialDirW)+ initialPosW);
final note. after writiing this I think It may not work, but ill post it anyway.
I think you need to keep a copy of the direction at origin and a initial position of the particle(fire) .
float t;
float3 Vel = initialDirW * Speed;
float3 position = (0.5f*t*t * Vel + (t*initialDirW)+ initialPosW);
final note. after writiing this I think It may not work, but ill post it anyway.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement