Who are you?
I’m the creator of a new unreleased 2d physics plugin, as well as creator of many 2d physics systems in other engines. I also make 3d games with unique features.
What kind of game are you trying to build or would like to build?
As it stands, I create all manner of games, both 2d and 3d, hi-res and low-res imagery and geometry, but there are 2 types of games I am aiming to create above all – heavy emphasis on player-generated 3d content, and player-generated physics/states (that can be executed in-game and not just through the editor).
Additionally, I create many 2d platform-based games with old-school console-style physics recreations.
How does Physics fit into that? What use-cases do you have?
2D – I want the common problems with characters on slopes eliminated, particularly in platform games, where jumpthrough/one-way slopes are involved (as well as slope handling in general!), making it easy to simulate ‘retro-style’ 2d movement. I also want to be able to easily create destructible terrain (i.e. destructible tiles included! – not just Worms-like destruction with alpha-masking, etc.)
3D – I do many things with physics, but I focus particularly on Mario 64-styled movement that takes into account walls and floors as well as slope angles (and jumpthrough floors!). A character controller that does this level of precision is something that should, imho, be included in Unity. Additionally, I enjoy making player-destructible/editable 3d geometry, and would really love something like the Digital Molecular Matter (DMM) engine such as that in “Star Wars: The Force Unleashed” to be included in Unity. I’m aiming to create some added realism to my character physics as well, so the Euphoria engine for ragdoll physics (used in SW:TFU and GTA V also) would be very welcome, though, for now, I’d settle for just a better cloth/hair editor and simulator in Unity that doesn’t require any fancy shaders/etc. to be used.
What are the GOOD things about Physics that you like?
So, I’m loving the direction 2d physics are taking with the new 2d graphical features Unity is about to offer us. That being said, I’m glad Unity is supporting 2D a lot better nowadays than it used to. It’s becoming a game-making beast.
What are the BAD things about Physics that you dislike?
Other than what’s already been said about access to the lower-levels of physics (I also feel we wouldn’t need this as much if we had fully-featured 2d and 3d character controllers from the start~!), I don’t dislike much about the physics system – though check out my “How can we make it BETTER” section below to get more of the specifics that I feel Unity sorely lacks in the Physics department.
2D Horizontal Edge Colliders + Horizontal Raycasts/Linecast = ???
So, yeah, they should register a collision. Maybe we need a fatter ray or something, but if the ray’s technically on the exact line with the edge-collider, a hit should be registered. 'Nuff said.
Next Up:
Other than the above-mentioned, I do have a few issues not mentioned in my next section. These are not necessarily Physics directly, but they’re relevant, to say the least, and I don’t know where else to address these issues, so here goes:
-
LAYER MASK function arguments – these are extremely inconsistent at best. IgnoreLayerCollision, for example, is a huge offender when combined by something like Linecast imo. I do understand somewhat why you need a layer mask vs. a layer index, but making people put a 1 >> LayerMask.NameToLayer() in some places and simply LayerMask.NameToLayer in others is just confusing and unnecessary.
-
Additionally, having Physics options tucked away waaay under Project Settings AND having the options appear differently in the Inspector area when it’s in Debug Mode is highly confusing. I once spent days trying to figure this stuff out. I thought it was a Unity bug that my Layer checkboxes were somehow not appearing there.
-
Finally, many physics functions don’t really have much in the way of explanations to help users understand them anyway. I’d suggest offering graphics in the manual/scripting areas to illustrate these functions a lot more clearly to users.
3D**) One thing I do have to mention about 3D physics though – they are becoming stagnant imo. Stuff like Digital Molecular Matter and Euphoria is becoming the norm these days, but even something as common as cloth/hair simulation is really rudimentary in Unity, despite it being highly standardized features in games these days. I only wish there was something we could do, at the very least, about the latter. Cloth/hair is very important to go with the nice new GI feature we have nowadays. Stiff hair/clothes just doesn’t look nice with otherwise hyper-realistic environments. 
2D**) Also, very little support for on-the-fly skinned-mesh renderers with generated animations of its individual vertexes (such as stuff like the “Edge” section with the guy’s nose being stretched: Mesh attachments - Spine User Guide
How can we make it BETTER?
2D:
Two problems usually come to mind with my 2D use-cases – first, a separate (user-made) physics engine is generally required, regardless of whether the actual “physics” are required to be custom. It is FALSE to think that every game must have a separate custom-programmed physics engine to suit the needs of their game, when in-reality, all they’re really looking for is simply custom-values on particular physics features/properties to suit their 2d platforming game.
Second problem is that slopes, in-general, are poorly handled in Unity for 2d games, and that probably has a lot to do with how lateral movement is dealt with (i.e. rather than an hspeed variable that takes slope normals into account to keep a constant movement speed up the slope [and an option to do otherwise], we are forced to do these calculations ourselves and rather than, say, simply moving to the right – we must check for a slope angle / tagged object / normal angle relative to our collider / etc. etc. and this pain is further compounded by the need for moving one-way slopes and platforms with multiple edge colliders on them, simulating bumpy-ness (even with the new platform effector 2d help, one must use multiple gameobjects to use the surface arc property across multiple 2d edge colliders, rather than taking each vertex of the edge collider into account to calculate its surface arc individually).
Finally, the ability to stretch and animate individual vertexes for skinned mesh renderers, doing something like the following for animated 2d meshes generated for body parts of a multi-part character (that, of course, can also be made physics-responsive) that may be swapped out at runtime with other meshes (i.e. an arm with stretchy fingers/forearm swapped into an arm with foreshortening with little need to be stretched): Mesh attachments - Spine User Guide
3D:
-
For movement – A Mario 64-styled movement controller that takes into account walls and floors as well as slope angles (and even jumpthrough/one-way 3d floors!). A character controller that does this level of precision is something that should, imho, be included in Unity, allowing users to modify it as they see fit, with most of the basic basic work being done already for them, just letting them set parameters for most other stuff.
-
For environments – destructible 3d – something like the Digital Molecular Matter (DMM) engine such as that in “Star Wars: The Force Unleashed” to be included in Unity for destructible 3D objects. Additionally, native support for any 3d voxels would be awesome.
-
For characters – the Euphoria engine for ragdoll physics (used in SW:TFU and GTA V also) would be very welcome**,** and also a more user-friendly cloth/hair editor (check out iclone if you want a rudimentary texture-based approach to allow people to import at first, but I’d prefer to also eventually have a soft-brush style approach that lets you either manually select or stroke hair/cloth into soft/rigid states).
Both 2D and 3D:
More universal functions – This is only a loose suggestion, but I can’t tell you the number of times I’ve forgotten to put a 2D behind the function name / collider / raycast / etc., so consider making the physics systems recognize whether you’re aiming for the 3d version or 2d version by letting them automatically recognize that you’re passing something like a Vector 2 or Vector 3, and change them from 2D or 3D versions accordingly (automatically) from behind the scenes. For those that don’t have Vector coordinate arguments, if you can, potentially just use the most recently used coordinate system (or the number/arrangement of arguments in the function, as 3d functions generally require different ones than the 2d version of the functions). To ensure you have the right coord system for certain, you can always add an (optional) argument to the function/name/etc. to specify the system you need.
