Implement mechanics for different branches.

[malcolmriley]

Ideally, this will be implemented as a number of prefabs, wherein common behavior is implemented in a scripts for the simple type, and specific behavior is implemented via a script inheriting from that base type.

• [x] Solid Branch: A large, sturdy branch. This is the base type.
• [x] Slippery Branch: A branch that the squirrel slides around on.
• [x] Bouncy Branch: A branch that causes the squirrel to bounce.
• [x] Breaky Branch: A branch that breaks after a few landings. It's cheaper than the others.

[malcolmriley]

We've got a bit of an issue on our hands regarding the current Squirrel player movement implementation. Here's the breakdown:

• If we want different behaviors for different branches, we have to use collision detection of some variety.
• In Unity, there's two different "flavors" of collision detection: Collider and Trigger.
• Collider events only occur if one of the two colliders has a non-kinematic Rigidbody attached to its parent object. See documentation here.
• Trigger events only occur if one of the two colliders has a Rigidbody attached to its parent object. See documentation here.
• There is a secret third flavor of collision detection using the CharacterController. These collision events only fire on scripts attached to a parent object with a CharacterController attached. Theoretically we could do all our different branch logic in PlayerController but I'd personally be against it; in my opinion branch behavior should be attached to the branch prefab and not scattered wherever it fits.
• We can attach a Rigidbody to the Squirrel, but the Squirrel's movement is controlled by the script directly, and not by physics as seen here, and some other places in PlayerController. Thus we cannot currently enable physics on the Squirrel without making some internal changes to the way player motion is handled.
• Trigger colliders don't interact physically with any other collider (including the CharacterController) so we can't just turn our existing colliders into Triggers, because we need them to interact physically.

The fundamental issue is that the current Squirrel movement implementation is incompatible with physics.

The current workaround is to attach a second capsule collider to the Squirrel, and a kinematic Rigidbody that doesn't respond to gravity (Since we can't use physics on the Squirrel), as well as secondary trigger-only colliders on the branches. Thus, the branches can respond to Trigger collision events without interfering with the way the Squirrel's movement works currently. Only time will tell if this is ends up being an effective long-term solution, so I'm documenting my reasoning for it now so that when we all forget why everything was the way it was we can look back and hopefully piece it all together again.

[NicolaeChristof]

Thank you for looking into this.

First: I would like to use your "secret third flavor" of collision detection because it means we can keep our existing character controller code. All of my playtesters said that the player controls feel very solid and I dont want to backtrack and lose that.

Second: when I was building the character controls I looked into and tried using a ridgidbody but it didnt "feel" right and I ended up using the character controller because of this.

Therefore I think there are two ways we can go about this.

1) I think an alternative would be to create a new script and attach it to the player and access the character controller through this to do our physics. It would be using your "secret third flavor" but also keep branch logic in its own file without interfering with the player controller script.

2) alternatively if you want to keep the scripts attached to the branch prefabs you could theoretically access the player from the scripts on the prefabs

if you have questions or wish to discuss this you know how to reach me :)

[malcolmriley]

Well, I think it would probably be possible to recapture whatever magic we have using the CharacterController with a physics-based approach but then again I haven't actually tried it, so maybe not.

Compromise counterproposal:

• Keep CharacterController, don't use Rigidbody, etc.
• On the Squirrel, attach a script that receives the CharacterController's collision events. This script then calls some as-yet-unimplemented methods on the Branch the squirrel collided with.
• These methods on Branch receive Squirrel GameObject as parameter and maybe some other things too, they can then affect the Squirrel
• These methods are overridden in subclass scripts for particular branch types

Pros:

• This keeps the behavior of individual branches encapsulated (somewhat).
• Squirrel is agnostic of what branch they landed on (same method call in script), but can still be affected by branch-specific logic

Cons:

• We'll have to mess with PlayerController internals anyways, particularly all the Vector3s we're using to track motion
• AFAIK we can't use Physic materials, because no physics, so somebody'll have to approximate those behaviors themselves in the new script

Not ideal in my opinion, but then again, is anything ever?