Cracks

Game Mechanics
#1

I’m thinking of how to implement destructability in objects by simulating cracks with a kind of L-system (like the way 2d trees are drawn). Eventually when the cracks reach the other end bits will break off (these bits are determined by the L-system pattern).

I’m new to how physics engines work, but how severly does the size of objects affect performance? And what if the objects are polygons? How many objects can these engines typically handle at a time when they all are moving?

The bits that break off should not be treated as particles from an emitter because these bits should still act as objects that can be moved, but they just won’t be crackable anymore.

All of this will be in 2d platformer type environment, using something like phys2d.

Thanks

#2

Wouldn’t it be a lot easier to implement a ‘net’ of triangles with springs holding them together. The visual triangles will be larger than the physical ones, so that you won’t see gaps, until the springs break due to a tension threshold. I think this is both easiest (nothing to analyze, stuff just breaks) and most realistic (it’s like tearing apart fiber / molecules).

With slightly varying spring-strengths you can have unpredictable cracks.

#3

That’s an idea. But how would I go about predefining the triangles?

The objects that can break will be textured, like a brick wall or a wooden box. Then I would assign a crack pattern to each of those. The patterns are just an L-system string like “AABA[AB]BA”. So when the object gets hit I would draw the “pattern” associated with that substring of letters, onto the object (how would you do this with triangles?). The lengths of the crack lines will be determined by the size of the object so that the crack always goes through after a certain amount of hits.

Then when the object gets broken I use the L-system string to calculate the polygon points and remove the original object and replace it with the broken bits and then the physics engine kicks in to make them fall down and roll and whatever. These bits should still be visible and react to physics, for example when an object below that one gets blown up too.

Using an L-system isn’t very difficult as I’ve used it before. But my issue is how will the physics engine react when 10 crates each blow up into 10 bits each? It now needs to calculate the movements of 100 polygons, and most probably much more when near everything on the screen can be destroyed. If these were done with particle effects then it wouldn’t matter but then these bits won’t act like they should.

Or do you think I’m a bit overoptimistic in what the current physics engines can handle?

#4

Well, my solution was more like dealing with true physics, no L-systems.

Things would simply happen, because they would happen in reality. It’s is pretty much non-deterministic, so if you want to crack an object after N hits, it’s problably not a good solution to rely on a physics-engine that cracks the materials.

Anyway, Verlet-Integration would be a nice fit, if you’d go with a triangle-net, and scales really good (linear).

#5

Your method is to have the object throw off triangle, kind of like when something gets chipped?

What I want is for the object to kind of “explode” once its taken enough damage. The “explosion” will be the bits that are formed from the cracks.

I don’t want the physics engine to handle the cracking. The L-system will determine the crack pattern. The physics engine must handle all the bits that come loose.

Once an object breaks the bits that come loose must be handled by the engine, the same way “rolling a box” would be handled. Once these broken bits come to a standstill they must remain there as smaller objects, not as particle effects. So if something was to happen that disturbed the bits’ rest then they should once more roll along or whatever.

The area in which this destructability occurs could potentially lead to a lot of broken bits. My question is how many such bits can the engine handle before becoming slow?

Maybe I should only have asked how many objects the physics engine can handle at a time. I only mention the cracking to show how the objects will originate and how they will be, ie. smallish polygons.

#6

You’re not going to get an easy answer to that, they’re just too many variables to take into account. What physics engine? What speed CPU? What’s the rest of the physics environment like? What’s the target framerate? What’s the complexity of the shrapnel? You’ll probably just have to knock up a test app and see how it copes to get some actual numbers.

I suspect you’ll largely be limited by the speed of the collision detection, most physics engines are slanted towards geometric primitives (circles, rectangles) rather than poly meshes. Keeping the number of sides of your shards to something low would probably make a big difference. Removing old shards (say, once they’ve been off screen for a while) would be a good optimisation too.

#7

I mentioned phys2d, but I haven’t used it or anything else before. Since this will be in a game it should probably run at 60 fps and not only just on new cpus.

That sort of answers my problem, but how much will polygons affect the speed? Are there some benchmark results for the available engines?

If the polycount was reduced to triangles then the shards won’t look too good when a bunch of triangles are laying around. And there won’t really be any optimization, once the object is broken the shards remain there as new objects.

Mmm, or maybe I should just rethink the effect I want to achieve from this.

#8

If you want some sense what you can get out of a physics engine in Java, see http://www.jbox2d.org/v2demos/ and flip through the demos - there are demos with body counts ranging from one or two all the way up to hundreds and hundreds. The “proxy count” stat roughly correlates to the number of bodies (it’s actually the number of shapes, of which there may be more than one per body).

Those demos use JBox2d, which is not entirely optimized, and it also is slowed down quite a bit by the use of Processing’s software renderer to draw everything, so you could probably squeeze a bit more out of an engine in practice.

That said, a physics engine with a good broadphase (JBox2d has a pretty good one) can happily simulate in the neighborhood of a thousand bodies without too much difficulty, as long as they are not piling up on each other. What slows an engine down is large islands of touching bodies that need to be iterated over as a group to solve interpenetration constraints - the pyramid, circles, and domino tower demos at the above link are examples of worst cases.

BTW, polygons in Box2d (and JBox2d by extension) are pretty fast, I wouldn’t worry too much about that. Triangles are actually sort of a worst case, as a triangle shatter will likely cause a lot more pieces to be generated than a polygonal one, and triangles are just handled as a special case of polygon.

In any case, I doubt if 100 bodies would be a difficult to handle for most engines. Phys2d and JBox2d are based on the “same” engine (Phys2d came from an early Box2d, JBox2d is a port of the newer one), so speed should be similar - any algorithmic improvements made in the newer Box2d are likely made up for by the fact that Phys2d has had more time to get optimized and stable.