Week Three: Roadblock

Alright, this post isn't going to be much- but at the same time, it will be going over everything I accomplished this past week D:

I just barely made my breakthrough so I'm going to post this out and relax, so I can recharge mah batteries.

The issue:

Not to throw shade or anything, but Unity's default rigidbody solution always gives me grief when developing character controllers. Anytime I use it, I always need to make a bunch of custom script crutches just to get it to feel somewhat normal. This is especially noticeable for characters that need to move quickly and slide across different angled surfaces without canceling all their momentum.

I am really trying to avoid rewriting as much built in functionality as possible, but because this issue related to something as fundamental as the way the character moves around (which affects one of the key components of gameplay I have mapped out) something needed to change.

The default controller as of the last update sure did move the character around, but featured classic signs of defaultism: sticking to walls, canceling momentum, and bouncing around a lot more than I wanted it to.

The solution(s):

Could I have just added a bunch of physics materials to everything to make the character slide more and bounce less? Sure, I could have. But one of the main mechanics of the game relies upon giving the character dynamic drag and friction, and being able to control all of that in one place seemed like a better long term goal. (plus who knows how well that would have worked, I felt it wasn't worth the effort to invest the time in)

My first attempt at custom character collision resolution was pretty fast and sloppy, and I would love to share the gif I prepared especially for this, but apparently my video editing program makes exclusively huge gifs, and itch only allows 3mb. So next time I want to show something I'll have to upload it to youtube probably.

Attempt 1:

My first attempt was to move on the X axis first, and depending on if it was positive or negative check the right or left wall, and then move back the overlapping distance, and blah blah blah. Overall, just typing the code out made me realize that I didn't go to university for four years to individually program every edge case collision scenario.

Attempt 2:

My next try was a more general approach: Move the current velocity amount, predict a certain distance in that direction, and if I'm about to collide, change my velocity. The only problem with this is that it predicted the new position, and immediately redirected the character, resulting in really jumpy behaviour. (and phasing through walls)

Attempt 3:

The next attempt built off the last one, basically attempting to move the player to that predicted collided position, and THEN change the velocity based off whatever surface it was hitting. This worked the best overall, and there was no wall phasing. The issue is that this was only slightly better than just using the built in rigidbody. There was still a lot of too-eager colliding going on, and the transition between different angled surfaces was really jittery.

FINALLY solution:

Just rapid firing off attempt 1 2 and 3 without going over too much of the process may make it seem like they were simple logical steps, but I was getting extremely frusturated. I started working on this right after the last dev log, and it took until about 10pm today to get the working product. I started over on my custom rigid body solution at least twice, and had no idea why my ideas just weren't working how I thought they should. I began adding random coefficients to different functions just to see if it would make a difference, because I was so sure I was headed in the right direction.

And then I stopped trying, and just started thinking.

I was headed in the right direction. The character is headed in the right direction- but I was too focused on where they were going, and didn't focus enough on where they should be landing.

I re-approached the issue with a new mindset: I need to figure out where the character should be after the frame was over.

In real life, there are no frames. Motion is constant, and collisions occur in real time. So, then I thought, what if I cut real life into frames? I imagined what a frictionless rectangle would do in real life when faced with walls and slopes, and then imagined it's position at the end of different slices of time. The key was that in most cases, the collision doesn't occur when the frame begins or when it ends, it happens inbetween frames, and as such, I should calculate it's full translation between frames. I'm sure there is no remarkable ingenuity in this, but it really was what ended up solving my buggy movement and turning it into something that looks and feels really smooth.

Essentially, the idea is as such:

1. Predict if character is about to collide
2. If about to collide, see where they will hit, and move them to that position
3. Now, after moving to the collision position, see how much movement potential is left over after being cut short by an intermediate wall
4. Redirect the characters' velocity by projecting their velocity onto the normal of the collided surface, and then move them in that direction the remaining amount

So that's the meat and potatoes of the collision solver I made for the player character. One side note I must add is that I found it necessary to displace the character every frame by a tiny amount (found by using Collider2D.Distance), as by the end of all the operations, the character had become slightly buried beneath the ground, and left unchecked, the floor would eventually swallow them.

So that's all for today, I should really probably stop releasing these close to midnight if I want people to notice this game by the time it is ready to be released, so I might start compiling information to share on Sunday and actually post mid-day Mondays.

Additionally, I saw that my first post got about 30 views, so if you are one of those views for this post, feel free to leave a comment about how there was this much easier thing I could have done all along that would have saved me my whole week's worth of effort so I can kick myself while I shift into maximum overdrive this next week to catch up with my original timeline lol.