Blowing up buildings
by Daniel Buckmaster · in Game Design and Creative Issues · 07/24/2007 (10:41 am) · 32 replies
This is a bit of a tricky issue. The short of it is that in my game, I want buildings that you can blow up. Well, not just blow up, but blow to pieces. You can make holes in the wall anywhere you like, that sort of thing. I'm led to believe that this is hard to do. Well, I had an idea, and I want to see if anyone else thinks it's any good.
Basically, each building is made of tiles. This is a good thing anyway, because that way buildings can be procedurally generated and have a lot of variety. Anyway, so you have a tile. This tile represents a bit of wall (2mx3m or some other nice size), floor (2mx2m, ceiling included), or whatever. The tile is made up of several 'locations'. Each location is a separate bit you can damage or destroy. So for example, a two-metre by three-metre tile may be made of six locations. What each location does is keeps track of how much damage it's taken, and when it reaches a certain level, swaps itself for a damaged version. Also, and this is the neat bit, it may damage other locations around it - and that includes locations in other tiles. So then you shoot the location a little more, and the damage passes another threshold. The location is destroyed, and it vanishes, creating particles or debris or whatever.
Code-wise, you'd need a few things. A 'tile' object would be just a placeholder, probably. Its datablock would have fields like its width and height in numbers of locations, and then an array that stores file names for the shapes for each location. When a 'tile' is created, it automatically creates the required locations and locks them in place. When the tile is moved, it moves its locations with it.
Then a leel up, you'd need a similar object to manage a whole building. The datablock would hold values such as how many tiles long and wide, how many storeys high, an array of tile datablocks to randomly choose from, and other random stuff. Then when you create the building manager, it creates a whole lot of tiles in the proper positions and moves them with it.
So, good idea? Bad idea? Got a better idea? I'm envisioning some wicked stuff that could be done with this, especially in the destruction department. You could fire a bazooka at the side of a building, and you'd get a) a big freaking hole; b) the rest of the wall above the hole collapsing; c) rubble coming down on the heads of all the enemies hiding in the building! Perfet.
Basically, each building is made of tiles. This is a good thing anyway, because that way buildings can be procedurally generated and have a lot of variety. Anyway, so you have a tile. This tile represents a bit of wall (2mx3m or some other nice size), floor (2mx2m, ceiling included), or whatever. The tile is made up of several 'locations'. Each location is a separate bit you can damage or destroy. So for example, a two-metre by three-metre tile may be made of six locations. What each location does is keeps track of how much damage it's taken, and when it reaches a certain level, swaps itself for a damaged version. Also, and this is the neat bit, it may damage other locations around it - and that includes locations in other tiles. So then you shoot the location a little more, and the damage passes another threshold. The location is destroyed, and it vanishes, creating particles or debris or whatever.
Code-wise, you'd need a few things. A 'tile' object would be just a placeholder, probably. Its datablock would have fields like its width and height in numbers of locations, and then an array that stores file names for the shapes for each location. When a 'tile' is created, it automatically creates the required locations and locks them in place. When the tile is moved, it moves its locations with it.
Then a leel up, you'd need a similar object to manage a whole building. The datablock would hold values such as how many tiles long and wide, how many storeys high, an array of tile datablocks to randomly choose from, and other random stuff. Then when you create the building manager, it creates a whole lot of tiles in the proper positions and moves them with it.
So, good idea? Bad idea? Got a better idea? I'm envisioning some wicked stuff that could be done with this, especially in the destruction department. You could fire a bazooka at the side of a building, and you'd get a) a big freaking hole; b) the rest of the wall above the hole collapsing; c) rubble coming down on the heads of all the enemies hiding in the building! Perfet.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
07/24/2007 (11:32 pm)
Well, it really depends. I'd like to introduce a strong random factor into damage dealt by one location to another. So if you blow up the bottom locations of a wall, then damage will be added to all the locations round it. There'll be a damage bonus for those locations above it (making it more likely that the wall above will collapse, or at least be visibly weakened). But in every case where damage is passed from one location to another, there will be a random element, meaning the upper locations might not be damaged at all, or they'll come toppling down. 
#3
07/25/2007 (11:26 am)
Id love it either way, being able to shoot a bazooka at a guy and send him and the rocket through the wall, and I literally mean through the wall.
#4
First I got a question to anyone more knowledgeable. How difficult would it be to modify TGE/TGA to support the Agea PhysX PPU (Physics Processing Unit)?
For those not in the know about PhysX, the PPU is to physics calculations as the GPU is to graphics and texture rendering, and the MPU is to mathmatics.
I've seen several demos of what the PPU can do, for example:
Take an airplane object in a game. The model for this plane has not been pre-segmented or 'broken' into pieces for the purpose of damage/destruction. With the PPU enabled, and the right coding of course, the plane can crash and the PPU will dynamically segment the model, render each new object, and apply separate physics to each new chunk. If the pieces are further damaged, they can again be dynamicly disassembled and re-rendered.
How this applies to this thread. If PhysX can work with Torque, then you could simply render a fully intact building/element, write the necessary physics coding, and let the PPU do all the work of blowing it up into little pieces for you.
Granted, going this route would pretty much make your game require a PPU installed in the end-user's computer, but it seems like that's where the next-gen games are heading anyways!
On another aside, if you can find a way to dynamicly take a building/object/element apart (either through PhysX or another method), then it stands to reason that you could do the reverse.
An example of this would be nifty for RTS games, where building a building/vehicle/whatever is more visually interactive, and you can see individual pieces being placed. This would be quite a lot more immersive (to me at least) than where the model is completely replaced with pre-rendered time/progress based 'stages'.
Later all!
07/26/2007 (11:21 pm)
Okay, I'm gonna have to jump on this thread as this basic idea could be useful in my own planned projects down the road.First I got a question to anyone more knowledgeable. How difficult would it be to modify TGE/TGA to support the Agea PhysX PPU (Physics Processing Unit)?
For those not in the know about PhysX, the PPU is to physics calculations as the GPU is to graphics and texture rendering, and the MPU is to mathmatics.
I've seen several demos of what the PPU can do, for example:
Take an airplane object in a game. The model for this plane has not been pre-segmented or 'broken' into pieces for the purpose of damage/destruction. With the PPU enabled, and the right coding of course, the plane can crash and the PPU will dynamically segment the model, render each new object, and apply separate physics to each new chunk. If the pieces are further damaged, they can again be dynamicly disassembled and re-rendered.
How this applies to this thread. If PhysX can work with Torque, then you could simply render a fully intact building/element, write the necessary physics coding, and let the PPU do all the work of blowing it up into little pieces for you.
Granted, going this route would pretty much make your game require a PPU installed in the end-user's computer, but it seems like that's where the next-gen games are heading anyways!
On another aside, if you can find a way to dynamicly take a building/object/element apart (either through PhysX or another method), then it stands to reason that you could do the reverse.
An example of this would be nifty for RTS games, where building a building/vehicle/whatever is more visually interactive, and you can see individual pieces being placed. This would be quite a lot more immersive (to me at least) than where the model is completely replaced with pre-rendered time/progress based 'stages'.
Later all!
#6
EDIT: After looking into PhysX a little more, I've decided that it really isn't suitable for this game. Though awesome, it's not totally integrated into Torque, and it doesn't fit my goal of being able to be played on medium-range computers - I'm even having second thoughts about the modernisation kit for the same reasons.
07/27/2007 (5:29 am)
Whoah. Sounds a whole lot better :P. The only issue would be overlapping damage between tiles, but I'm sure that could be easily solved. And I guess PhysX does cloth sim too? (Not related to buildings, but it's something I want for the game.)EDIT: After looking into PhysX a little more, I've decided that it really isn't suitable for this game. Though awesome, it's not totally integrated into Torque, and it doesn't fit my goal of being able to be played on medium-range computers - I'm even having second thoughts about the modernisation kit for the same reasons.
#7
The building could be in addition be built from physics components, not every tile, but a whole wall as one physics object. When the wall gets a hole or is splits up into 2 meshes, the new mesh would be also a physics object.
08/03/2007 (8:38 am)
I'm planning to do the same thing, destructable buildings. I found some piece of code which deforms a mesh, and adds new vertices where it's deformed, I think that way it would be quite easy to drill a hole into any mesh.The building could be in addition be built from physics components, not every tile, but a whole wall as one physics object. When the wall gets a hole or is splits up into 2 meshes, the new mesh would be also a physics object.
#8
08/03/2007 (9:21 am)
I am also interested in this. I want to be able to have a dif structure be whole and a player comes along with a bazooka and shoots a hole in the wall. I thought this might be possible to use decals. For instance when the projectile hits the wall it leaves this big hole shaped thing. Instead of it being black, make it clear so you can see right through. Of course this probably would need some code changes, but it would be the easiest way to do it imo.
#9
08/03/2007 (10:50 pm)
True, but then you wouldn't be able to walk through it. I doubt it's possible to actually alter a DIF in the game. 
#10
I assume games like Red Faction and Worms use voxels rather than brushes, though.
08/04/2007 (2:57 am)
You still have to network this properly over the network since you're affecting collisions on the DIF/DTS/Whatever and the client needs to know of these changes. I'd say you're in for a painful ride, but I haven't tried to do this either. Single player would be easier.I assume games like Red Faction and Worms use voxels rather than brushes, though.
#11
As for networking, I figured I'd just network them like normal objects that are being altered and destroyed. A BuildingTile takes care of the networking for each location, maybe, and a BuildingManager does the networking for all the tiles that comprise it. They only update ghosted objects when a state is changed - damage is taken or passed on, etc. Otherwise there'd be a shedload of network traffic that doesn't need to be going.
I'm also thinking of doing rubble client-side, but the problem is that I want rubble to damage people it falls on and create piles you can climb on. So I guess rubble would need to be networked as well, or at least the main chunks of it. Particles and other nonlasting stuff on the client, of course.
08/04/2007 (3:52 am)
Ah, Worms! I knew I was missing something. I'd love to know how they did it, even from a 2D point of view. Red Faction, too.As for networking, I figured I'd just network them like normal objects that are being altered and destroyed. A BuildingTile takes care of the networking for each location, maybe, and a BuildingManager does the networking for all the tiles that comprise it. They only update ghosted objects when a state is changed - damage is taken or passed on, etc. Otherwise there'd be a shedload of network traffic that doesn't need to be going.
I'm also thinking of doing rubble client-side, but the problem is that I want rubble to damage people it falls on and create piles you can climb on. So I guess rubble would need to be networked as well, or at least the main chunks of it. Particles and other nonlasting stuff on the client, of course.
#12
08/04/2007 (4:12 am)
I'm not sure, but isn't physics predictable, I mean there are no random parts when someone moves a physics object? If that indeed is so, then you would just need to send the impact or player movement via the network, the other clients could then exactly replicate the physics movements on their side. And doesn't TGE/A have networkable physics (sorry, haven't bought it yet :)? 
#13
08/04/2007 (5:24 am)
Quote:And doesn't TGE/A have networkable physics (sorry, haven't bought it yet :)?Yes, but very basic. There is an ode resource that integrates ode physics into torque. It's supposed to be working quite well. You might check it out.
#15
@Mika, do you think you could post this? I'd be interested in checking it out myself, since destructible parts of the environment are integral to the game I'm trying to do. Thanks.
08/04/2007 (7:24 am)
"I found some piece of code which deforms a mesh, and adds new vertices where it's deformed, I think that way it would be quite easy to drill a hole into any mesh."@Mika, do you think you could post this? I'd be interested in checking it out myself, since destructible parts of the environment are integral to the game I'm trying to do. Thanks.
#16
08/04/2007 (7:28 am)
@Ross, If I remember correctly that piece of code was in the DirectX9.0c SDK as a sample program, or then it was in the Blitz3D demo samples. But I think the Blitz3D version didn't add meshes, it just deformed them.
#17
Anyway, this is probably too advanced stuff to be worrying about yet :P. Gotta get the basics first. Rubble could even just be done by the standard debris system, though they disappear after a certain amount of time. Maybe just spawn a 'rubble' static shape where the debris lands.
08/04/2007 (10:09 am)
RigidShape is networkable though, right? Anyway, while physics is indeed predictable, differences in client-side interpolation of other objects may mess with this prediction - for example, a character moving slightly wrong on the client and bumping into a falling rock would throw it off quite differently to the way it's done on the server, leading to a big discrepancy in the final position of the rock.Anyway, this is probably too advanced stuff to be worrying about yet :P. Gotta get the basics first. Rubble could even just be done by the standard debris system, though they disappear after a certain amount of time. Maybe just spawn a 'rubble' static shape where the debris lands.
#18
08/04/2007 (11:01 am)
Aye, I thought of that too, that there might be also other things happening, resulting that the physics objects would be in different positions on different clients. A quick and dirty solution could be just to warp the objects on the other clients to the same coordinates as the client has which initiated the chain reaction, this could happen after the objects come to a full stop on the initiating client. If the other client's original physics movement matches the initiating client's movement, which should be the case in most cases, there would be no warping at all on the other clients.
#19
08/04/2007 (6:56 pm)
Here is the TDN article that explains it all, and has the links you would need.
#20
08/04/2007 (7:43 pm)
@Mika, awesome, thanks, I'll check those out. 
Ben Immel