Which Physics Solution?

Hi,

I'm trying to choose which 2d physics solution to use for my platform game (I know - who isn't!?), and I wanted some people's opinions. I've been down this road a few times before, and so this isn't starting from scratch.

For the sake of conciseness, let's say the game is a more tile-based Super Meat Boy clone. It hurts me to describe it like that, but I don't think this post needs a game design document attached to it - it's long enough already!

When I'm talking about a 'solution', I mean any of:
- a home-grown solution for which there is some tutorial, source code, or user-base
- a paid solution, which I can use with Unity hopefully without any plugin-writing of my own
- if nothing else, the knowledge that there is a perfect solution out there, but I'd have to port it or write a Unity plugin.

I imagine my best bet is the first one, and this is where I've been looking. I've started off working with a couple of different tutorials/blogs online, and then realised something like: they suffer from ghosting, they only work with AABBs, or the tutorial is pretty unfinished or illegible.

Just to clarify - I'm dead set on using Unity, and I've used Unity's 2D physics a few times.

Here are some notes on what I'm looking for.


Ghosting Collisions/Edges
This is the main issue I need to overcome. The act of colliding with inner edges that, to the player's eyes, aren't being touched. I've read up on some of the solutions for these so-called ghost collisions, and this has been my main issue when using Box2D in the past. I was using Box2D before edge chains were introduced, but I can't really use edge shapes this time around, because the methods to pre-calculate or re-calculate where these edges must occur, I feel, is a step too far. This is because I absolutely want moving platforms and platforms that toggle (like hazard barriers). I understand that I could recalculate even portions of the edge chain around where moving/switching platforms meet walls and other objects, but this is a restrictive approach that will ramp up in complexity every time I want to arrange a level in a particular way. What if I want a moving platform that doesn't quite line up with other grid-adhering walkways - I then have to split edges exactly where the platform meets.

I'm not happy with using a circle or rounded edges on objects, because from experience, this doesn't even nearly mitigate the issue - instead of being stuck hard on the edge the player is moving into, the player will be launched upward. This can be reduced to a small amount if things are tweaked well, but if the player's moving fast and gravity is low, the player will be launched into the air from what will seem like a flat surface. And I'm not happy with the way the player rolls off the edge of platforms because of a circular bottom. I come to the conclusion that there are far too many games that don't suffer from any of these fairly-minor but very reproducible glitches, that I'm not happy with having them.

For some reference, this video shows increasing levels of work done by someone else to resolve the issue, but I don't feel like even the best solution is really very conclusive.

.

I spotted a discussion on Box2D forums about a method called Conservative Advancement. I didn't look much into it because it seems to just be on the table as a future fix. That also wouldn't mean it'd instantly become part of Unity's 2D physics either, but if I knew it was the ultimate fix, my focus would be on a plugin for the current release of Box2D or something like that.

Because of my desire to avoid this issue, I'm happy to forego any sort of full-on physics engine (which I tend to prefer so that there are more fun tricks in the bag for future game additions - springs, ropes, buoyancy, more complex environment geometry - you know the drill).

The game is fairly tile-based, but I want things to remain polygonal...
The game is quite heavily tile and grid based in terms of its appearance, but this is mainly down to my desire to keep level creation, the overall feel of the game, and the art requirements in line with the tile-based approach. I've seen explanations of the various approaches to collision and response in 2D platform games (mainly classic platform games of the various generations) and there are a few grid-based approaches before settling on polygonal. If I want to introduce some more polygonal elements into the game, I don't want that to require a huge overhaul. This game will probably have sloped surfaces, and the player character will switch between rectangular, circular, and maybe switch to form other primitive geometric shapes. I'd be happy to go with one of these if there was an argument more convincing than just "you pretty much need to", and if there's really sufficient material to help me accurately match the solution.

Speculative/Iterative/Continuous Collision
I can definitely limit the velocities that occur in the game, but it's really meant to be fast, and I want to go with the robustness of speculative contacts/collisions even if it's more work computationally. Also, there isn't loads going on in the way of multiple rigid bodies interacting, but I want to be able to at least have a couple, without the worry that the engine isn't really suited to them and will only usually be fine with it.

I understand enough to perhaps add this manually to the solution I end up with, but that could be messy, so let's say it's a requirement, first of all!



Thanks for reading.

 

Unity has built-in 2D tools, and they're great.

 

I did mention in my post, 'I've used Unity's 2D physics a few times'. I know they're definitely handy, and they satisfy the bottom two of my three main points in the post, but because the physics engine is a conventional one for rigid body simulation (and I'm sure I read that it's based heavily on Box2D), it suffers from the ghosting collisions issue. I know that there's a recognised workaround for this - edge chains - but I explained why this doesn't really suit the game. Moving and alternating platforms make it difficult and impractical. If I had a completely static world, I could either use an algorithm to detect all edges from the level tiles/prefabs that are hidden from view, essentially adjusting all the collider geometry to omit this issue. I've done that already, to an extent - I've foregone the approach of being totally automated/algorithmic and provided toggle options for placeable level pieces, which means that level construction takes longer. This only takes me as far as having the static world safe from this ghosting collisions issue, but I don't want to have to link moving/alternating platforms with the edges or portions of edges of all geometry they come into contact with, and toggling the entire edge chain/chains in that vicinity to open and close these gaps. If nothing else, this means you run the risk of rewriting the geometry of your level at a point where the player's standing right on top of a change - this isn't how the physics engine should be used.

I created a partial workaround for the ghosting collision issue when using Box2D, which was to check the context of the collision in the PreSolve callback, performing a cheap, single-edge check to see whether it's surrounded by other tiles or other geometry. I could then use b2Contact.SetEnabled(false). Does anyone know if the same can be done in Unity? I know of the Physics2D.IgnoreCollision methods, but what I'm talking about is using the manifold information that you can get from OnCollisionEnter2D to prevent the collision response from happening. Again, it was doable with Box2D but that's probably because collision events were split out into 4 smaller events - PreSolve, PostSolve, BeginContact and EndContact.

Edit: This post answers the above. https://feedback.unity3d.com/suggestions/add-presolve-slash-postsolve-for-physics2d-of-unity-4-dot-3