We are currently having some problems creating a 2d worms-style game with destructible terrain and realistic fluid simulation.
We were hoping to leverage the Farseer library to perform most of the game-specific physics collisions for us (player movement, raycast projectiles, thrown/fired projectiles like grenades/missiles + interaction). It seems crazy for us to re-invent the
wheel when farseer can already handle this efficiently and elegantly, so we really dont want to write a cusstom physics solution.
However As far as the destructible terrain and fluid simulation, we currently have a custom working solution (not using farseer). we can click anywhere on the 2d terrain and 'dig' /'grow' it using a brush, and the fluids will act appropriately and flow around
the terrain. (IF anyone has seen 'PixelJunk shooter' a PSN game you will have a VERY good idea of how our current terrain + fluids look + feel).The working code we have uses a clever spatial partitioning system much like a quad tree to allow us to
quickly interact with terrain and store which 'quads' are solid terrain and which are air. We also have working edge detection algorithms to detect which quads border air etc. For now, we are not really worried abotu fluid interaction with farseer, as at this
stage in the prototype, the fluids are more visual candy than gameplay affecting, and so dont need to collide with anything other than terrain (which is complete and functional).
The problem now comes when we come to gel the two solutions (farseer and our custom terrain/fluid sim) together. Essentially we need to take our terrain representation (which reflects any real-time addition + removal that has occured.) and create
a representation that farseer can understand and interact with. We seem to have come up with several possible solutions (each of which have positives and negatives), but we seem to have gotten stuck deciding how to proceed. (we have tried several methods and
1) Create the initial terrain representation using Farseer's Texture to vertices functionality (using a texture accurately representing the starting terrain) Then INDEPENDENTLY upate the farseer terrain representation to our game terrain/fluid representation
when destruction is applied, or new terrain is added and jsut hope they stay in sync.... (dont like this idea!). This would also depend on 'cutting' into a large terrain polygon to create damage (easy enough when a large circular explosion is applied) but
may get more intensive if MANY smaller circular cutouts are applied (e.g. small bullet blasts). We have tried this and seem to run into occasional crashes when cutting / adding terrain, and also have the problem of accurately representing say a circular blast,
when the 'cut' that is made in the terrain may actually 'cut' using a more basic hexagon / simplified cutting shape. Also we arent too sure if having fairly large complex shapes (imagine a high vertex terrain poly after many many bullet impacts etc)
is a good idea, as it may put alot of strain on farseer. We were tempted to split all terrain polys into max size polys (e.g. grid the world into 4*4 grid, and split any terrain polys crossing those boundaries). This again seemed to cause some problems...
2) Since our spatial representation used for the terrain/fluid sim essentially can be analysed to give a list of quad building blocks, we could mirror this data to create many small rectangles for terrain edges and larger rectangles used for the undamaged
'inner' terrain. Our existing solution naturally supports this 'level of detail' system , so only terrain edges are built from small building block to represent detail, whereas large areas of unbroken terrain are represented by larger quads. This would help
prevent us from creating many unecessary farseer rectangle polys. However we then have the problem that we essentially dont have smooth gradient surfaces, we have 'staircased' edges consisting of many horizontal and vertical surfaces. This may affect the bounce
trajectory of say grenades / prevent smooth rolling / player terrain traversal. Theoretically if these staircases were fine enough (e.g. a grenade itself was BIGGER than the staircase blocks and couldnt fit within the gaps) this MAY not matter. However we
attempted this and it could occasionally produce strange results. On a positive note, it woudl be fairly trivial to react to the creation / destruction of the terrain by pairing the quads in the custom terrain representation to their farseer counterparts.Theoretically,
since we can detect edges in our customn solution, we could generate a polygone based on this, but that takes us back to the problems associated with solution (1) above.
3) We have already generated a signed distance field in our custom terrain solution, used to interact with the fluid particles. Is there any way we can convert this into/ inject this in a format Farseer can work with?
4) Another suggestion was to only add physics objects for say, player, projectiles , dynamic objects etc but NOT terrain. Then somehow (please let me know how!!) manually detect collisions with our terrain representation ourselves, and then apply forces
etc to push objects out of terrain (this sounds kinda fudgey....).
Any comments / suggestions PLEASE let me know. We can post screenshots / more info if necessary.