Devblog - Character Controller II

Okay I was wrong, I take it all back, ignore everything I did last week.

18 May 2018 by Garry Newman (6 Comments)

With a heavy heart, I decided to move the character controller back to a Kinematic one. This meant I'd basically wasted a week fucking about with it.

I originally switched to the rigidbody version because I found myself implementing a ton of physics stuff, that I thought the physics system should take care for me.

The reality was that I found myself fighting the physics system to get it working, and in the end had basically implemented a rigidbody version of Unity's built in Character Controller. And by doing that, by getting it all working how I wanted, I'd removed any ability for the rigidbody to behave like a rigidbody.

So at that point I gave myself a reality check. This was meant to be easy. This isn't adding anything significant. Take the easy path and get shit done.


With the rigidbody setup I had it so the player could walk into and push things like cowboy style doors. That was pretty cool. But as far as I can remember that was the only significant thing that we've lost (and I would imagine it's relatively easy to fake).

Bright Side

On the bright side, the character controller code is clean and modular now. Its boundaries are clearly defined, it's configurable, and can be ripped out and placed in any other prototype.

The character controller code went from a single class, where changing one thing broke 4 other things, to a simple and easy to understand modular peice of code. Probably not worth spending a week on though.

Fully implemented the pushing.

I coded it so it works in multiplayer, so if there's more of you pushing, the faster it'll push.

It's a bit werid at the moment though because the guy who's pushing with you will be lagging a ping time behind the pushable, so they'll be hover-pushing. I think I need to kind of hack it and force them to be next to the object they're pushing.

I updated to the latest citizen model that Paul and Alex have been working on cleaning up and setting up. So we got LODs now and a rig we think we probably will never have to change.

We decided to get rid of the winky. We decided that these guys don't have gender. It seems that ultimately being genderless, meaning they can be dressed as anything, has more scope than having a little winky and big fat tits.

Heres some boring shit for unity nerds. I've been working on a skeleton system over the past few weeks to solve a bunch of problems we've had with Unity in Rust. It's in use now, in the first person clothing stuff in Rust. Here's the low down.


The skeleton holds a list of bone names in a rig.

In basic terms it converts a bone to a number for us.


So then something that uses that rig, like an NPC or Player Model can have a skeleton component, which carrys an array of transforms - which match up with that skeleton definition.

This means we don't have to look up bones by name, and we don't have to build this at runtime by looking at bone names. You should never really access GameObject.Name in Unity because it's slow and allocates memory every time.


Here's where things make your cock rock hard, so undo your belt. On everything with a SkinnedMeshRenderer we add a SkeletonSkin. This keeps an array of bones used by the skinned mesh, and an index of the corresponding bone in the skeleton.

The massive benefit of this is retargeting.

Changed Skinning

So you built your player model, it's all cool. But then an artist comes along and changes the skinning on the mesh. So now your SkinnedMeshRenderer in your prefab has the wrong bone information. Your model is all bent up and fucked. Not with SkeletonSkin. It looks at the SkinnedMeshRenderer on the imported model and fixes the bones on your implemented SkinnedMeshRenderer.

Adding SkinnedMeshRenderers

Sometimes you want to add another SkinnedMeshRenderer to an existing prefab or simply change the mesh. This can be tricky. In Rust I remember methodically recreating prefabs by dragging the model into the scene, copying shit over from the old prefab, then dropping that new one over the existing prefab. What a fucking mess. With SkeletonSkin, you chose the new mesh - and it automatically works.


So your character dies in the world, you want to turn him into a ragdoll. If your character is always wearing the same clothes you can create a ragdoll prefab using the imported model, and spawn that, copy bone positions. SkeletonRagdoll helps you out in a few ways here.

Ragdoll Creation

Ragdoll creation is a pain in the ass and I hate it. So I made some tools.

It tries to create the ragdoll for you, and give everything the unity recommended values from everything I could dig up.

Ragdoll Transition

So transitioning a regular model is really easy. Here's all of the code.

This is as allocation free as possible. No looking up bones via name, because everything has an array of transforms already filled.

I found some editor widget stuff I never knew about in a teardown I did of some Unity stuff, so I implemented it. Now the MovePattern thing - which was only really previewable when selected, is always playing in the scene view.

I added handles to the keyframes too. I'll expand this with rotation and shift dragging in the future I think.

One of the things I always loved doing in GMod (and Rust) is flying around taking screenshots. To take screenshots for the blog headers I've been hacking pausing and manually placing the camera in the editor. That sucks.

So I added a screenshot camera to Tub. Pressing 2 when no-one else is in the game will pause the game and put you in the mode. E to focus, R/F changes aperture, right mouse hold to zoom.

I just threw it together in an hour, it's relatively self contained, the code might be useful to someone so here it is. You just want create the class and call .Update to update your camera in a LateUpdate or something, and OnGUI from something elses OnGUI.

I've got myself into a state of enjoying the programming too much over the last couple of weeks and haven't made much progress pushing the actual game forward. While refactoring and improving editor tools is all good work, it shouldn't be taking up 100% of development time in a given week.

I'm looking forward to getting back into the game design now. It's getting clearer what I want the game to be, how I want certain things to work, so I'm going to try to flesh some of those things out.

The art and style is still a bit of a question mark so I'm starting to explore that area too.

Mailing List

If you want to follow this project you can sign up to the mailing list.

We'll only update you about this project, we won't spam you about other stuff or sell your email address.

* By subscribing you agree to the Terms Of Service and Privacy Policy