LonelyBond #38 - Unity Physics Are Not Ideal, Let's Rewrite Them!

Hello everyone! How are you all doing?

So I've lately finished rewriting the plot of the first chapter for LonelyBond, and that means that I need to write all the content (well, most of it) again.

That is a good enough reason to address some of the fundamental problems that I've encountered during the making of the prototypes.

For those that don't know, unity physics engine has caused me quite a few problems.

In general, it's a great physics engine, able to run a whole lot of simulations for all kinds of different games really easily thanks to all the feature it has, but it has it's fair share of problems caused by it trying to serve all kinds of physics in all kind of potential games.

You can say that it is a 'Jack of all trades, master of none'.

So I decided to write my own physics.

Here are a few reasons why this is a bad idea:

• For almost every game, this is an overkill.

• It takes time, especially if you need some special physics (and even more so if you have these features in engine).

• When you will have a bug, there are not a lot of resources online to help you out.

But since I've decided to do it anyway, let me list my reasons as to why:

• Almost every game developed in unity (especially platformers) have that same 'unity feel' to them (a tiny bit 'floaty', with a lot of excessive acceleration and deceleration). Writing your own physics allows you to break that feel.

• Unity doesn't calculate the physics precisely the way you want it. It rounds numbers all the time, moves objects when they don't necessarily need to move, and all around does what it want's and not what you want. This causes bugs that are really hard to fix sometimes, and nobody want's that.

So bugs are bad. Now how do we fix them?

Short story, you basically tell unity's physics 'nah, I'm good. I'll run my own physics', and start writing your own code.

If you are more of the programmer type and are looking to learn more on how I've done it - continue reading.

Otherwise, you can skip to the end, no hard feelings (:

When starting to program my own solution, I've went out to the internet to see if there are any good tutorials out there.

First I've found Unity's basic tutorial, which teaches the basics, but is ultimately broken (you can even look at the comment's of the last tutorial to see people complain).

Secondly, I've found a really good tutorial by Sebastian Lague. It goes really in depth on some of the challenges in programming your own kinematic player controller.

So what's the problem? Just use Sebastian's code!

Well, if only it was that simple. Sebastian does a lot of things right, but his code is for Unity 5 and I'm using Unity 2019.

He covers a lot of cool subjects (such as moving platforms that should hold the player and slopes), but I don't need to handle slopes and other such things, so it is a bit of an overkill (and more code means more potential bugs!).

And a big problem was that... he doesn't cover anything regarding pushing other objects, let alone - connecting objects to act as one physical object! (which I really need for the mechanic of my game).

Learning from both of these resources some of the basics on how they do stuff, I decided to take this knowledge and start writing the basics.

I've created a basic PhysicsObject script, and made it so it was able to handle the simple things such as stopping when hitting a wall, and falling down when it's in the air. Simple stuff you will surly learn from the tutorials above.

Adding the ability to push other objects was the big challenge.

This functionality has so many edge cases, that it's unbelievable. I've learned a whole bunch of reasons as to why unity chose the solutions that they did for their physics. You really have to know *exactly* how you want your physics objects to act otherwise.

I could write about ten to twenty pages on these edge cases, but I really don't know if anyone ever is going to want to read all that.

So instead, here is a link to the code that I ended up creating.

If you, for some reason, would like to learn how I've got to this code, feel free to contact me through whatever means you'd like (twitter would be ideal). If enough of you would like to read it, I will write a detailed explanation.

Thank you for reading through all of this, it took me a lot of time to finish working on this, and now I'm able to go on to more challenges I need to tackle, but more on that later (;

See you next week!