Due to multiple requests, I’ve built a GitHub repository for the Super Character Controller project. It can be accessed here.
This thing gives me nightmares
The project currently on the repo is extremely similar to the 2.0 release from several weeks ago, with the only main differences being that the demo models are now in the .FBX format, as opposed to the .max format. This is to ensure that users without 3ds Max will be able to download and contribute to the project without any errors.
This is the first open source project I’ve created, so please bear with me while I iron out any details I’ve missed and get the hang of this. As always, any contributions, comments or tips and tricks are appreciated.
Roystan Ross 
Hi, sorry to be a bother but I’m having some trouble with the Super Character Controller, not so much the controller itself but implementing something using the controller. I’m trying to modify the example project to get an effect like in Mario 64, where for example if the player holds either all the way to the left or all the way to the right, they start running in a circle and the camera just rotates to face the player. Another example would be if the player turns around the camera just turns around to stay to the back. I’d imagine I need to change the lookDirection variable but unfortunately I’m a novice at best when it comes to calculations using Vectors.
I completely understand if you’re not able to help but I’ve been stuck on this for quite a while and any help at all would be appreciated.
If you’re new to Unity or Vector math in general, I’d recommend sticking with the built-in Character Controller, since it’s far less complex to use than the custom one I made. I’d suggest searching for tutorials focusing on using the character controller for character movement and rotation.
With help from the Unity3D subreddit I’ve managed to get everything working as expected. It was a pretty small issue on my behalf, thanks for the controller it works really well.
Glad you figured it out! Best of luck on your project.
In case you aren’t aware of it, I thought you might want to know that they are releasing a function for OverlapBox and OverlapCapsule in 5.3.
The only catch from what I can see is that OverlapCapsule is really OverlapCapsuleNonAlloc, which means you need to provide your own buffer for the function, not sure why they didn’t add a plain old OverlapCapsule while doing this, but I asked one of the Unity physics programmers on twitter and they said they would add it since I asked for it, which probably means the allocating version for OverlapCapsule won’t be out with 5.3 (seems silly to not provide both versions if you’re going to do one, no?).
At least the non-allocating version will be out, and that probably has better performance anyways, thus a superior choice when creating a character controller that uses the function frequently, since there won’t be memory allocations each time you call the function.
Oh my god that is so goddamn boss. I had actually been planning to implement my own OverlapX methods, using OverlapSphere as an initial prune and then using custom Box->Sphere Box->Box Box->Capsule and so on intersection tests, but this is obviously way simpler. This is super useful even beyond the character controller, since I am currently working an a multiplayer game that uses lag compensation for hit detection…and since the only exposed physics tests you can run at will was OverlapSphere, it kind of limited the shapes of objects I could use.
The NonAlloc only is kind of bizarre, but I would take anything at this point. Thanks very much for the heads up!
Hey, I just wanted to say great work! I recently downloaded the super character controller to make a little platformer in Unity, to possibly port onto the Wii U. Everything has been working great, and I’ve mostly been able to debug things, but there’s one issue that I cannot seem to solve that has to do with ground clamping. Occasionally, my character will clamp to the ground when stepping off a ledge, no matter how high up the ledge is. Not all ledges do this, but those that do do so consistently. I would greatly appreciate any help in figuring this out, as it is the last bug I need to squash before getting my hands dirty with design!
I run into this same problem on seemingly random occasions. I’m not sure what the deal is but once I can find a way to reproduce it reliably I’ll push up a fix. Glad to hear it’s (mostly) working out for you!
Thanks for the quick response! You are an awesome person. Keep us updated!
Hey Hedley,
Were you able to reproduce this bug reliably? I was only able to do so once after a bit of effort in the main scene of the sample project and was wondering if you were able to get more consistent results.
Yes, I have it occurring reliably, and I think it might have to do with the angle of my surfaces. It happens unreliably on cubes, but always on weird shapes. Is there a way I can send you the scene?
You can export it (and necessary files) as a .unitypackage and email it to me (my email is on the About page).
Alright mystery solved. I’ve narrowed it down to the SimulateSphereCast method. I’m not sure if you’ve looked into the source/theory behind the controller (ideally it’s not required!), but if not: essentially to avoid weird clipping issues when detecting ground, the SphereCast that does the main ground detection has a slightly smaller radius than the controller. Doing this causes some minor accuracy errors that are ‘repaired’ by the SimulateSphereCast method (which basically just adjusts the RaycastHit.point of the original SphereCast to make it align with the proper radius of the controller).
I pushed a change just now to the repo which is exactly…one line long. I swapped out a Raycast for a very thin SphereCast, which will eliminate inaccuracy problems. In the future, I’ll probably look into Moodie’s SimulateSphereCast method to see if it’s most robust. Thanks again for the bug report, always appreciated.
Hi Erik, thank you for all these great posts and information on making your super character controller. It’s very very interesting reading and very generous of you to share all your research, and very much appreciated! I was wondering if it would be possible to get a version of the super character controller that doesn’t need the super state machine to run? I know that using a FSM is a fine way to setup your player movement and have no doubt that the super state machine works great. That being said I am currently exploring making a player controller that uses a behavior tree for getting all the inputs and making the calculations for various player movements (using node canvas from the asset store to do this). It’s not so much that I think this is better than using state machines, but more just that using a behavior tree for a controller is something I am interested in exploring and trying out because it forces you to look at your code and player movement in a slightly different and interesting way, whether it be better or not in the end. My current setup works well with Unity’s character controller but I am now running into some of the character controller’s limitations, mainly the moving platforms thing. I’d also like to explore making a test level similar to the planet level demo in the SCC package where gravity’s direction changes based on the angle of the ground you’re standing on. So basically I’m trying to integrate the SCC with my current setup instead of using the super state machine. Maybe you could just provide some insight on how to best go about this?
Hey Florent,
The SCC doesn’t currently require the SSM. Any script you attach to the object with the SCC script attached will receive SuperUpdate messages, sent from the controller. The SSM just receives the SuperUpdate messages and then calls the correct state Update methods. This should let you do what you want.
Hey so, I’m testing out the Terrain version of the SCC and it seems to ignore certain colliders; such as the Unity terrain trees.
http://i.imgur.com/bTb0GnQ.png Here’s an example with some of your debugging turned on; those push back messages get spammed like that each time I cross over a tree.
Gotta be real with you Blayne, I legit basically never use the Unity terrain system, and mostly added the terrain colliders at the request of others…so I’ll have to look into it a bit to give you an informed answer! According to what I’ve looked up in the last 5 minutes, they seem to use generated Capsule Colliders. Capsule Colliders ARE natively supported by the SCC, so I’m not sure what the deal is. I’ll look into it more tomorrow and give you an update then.
Thank you sir! It would be hugely convenient to use the native terrain trees instead of having to figure out how to place our own optimized billboarded trees, so you doing this for us would be a great assistance. 🙂
Hey, so I did some testing this morning and found some interesting data. It seems that although Unity uses Capsule Colliders to represent Tree Colliders, when you actually collide with one Unity registers it as a collision against the main Terrain Collider. This is unfortunate as it does not actually return any useful information for the SCC—as far as the SCC is concerned, it just collided with the terrain.
This is where all the pushback messages are coming from. When the SCC hits a tree, it checks to see where on the surface of the terrain it collided with. After doing some logic it determines the closest point, and then realizes it’s not actually touching that point and ignores it. Nowhere in this process is a capsule collider passed back to us. Unity’s terrain does have data on each TreeInstance, which we could access and find the nearest set of trees to us, and then determine which we collided with, but that wouldn’t be too trivial to do.
As far as most convenient solutions go, you could either write your own tree script, switch back to the Unity built in CC, or at the start of your game iterate through every TreeInstance on the terrain and spawn a Collider at their location that the SCC can detect.
Hey, I just wanted to say great work!
Glad to see you enjoyed it!
Is it work in Unity 5.5?
I imported the project and i had this error:
Assets/Scripts/Moodie/CustomController.cs(221,43): error CS1502: The best overloaded method match for `SuperCollider.ClosestPointOnSurface(UnityEngine.TerrainCollider, UnityEngine.Vector3, float, bool)’ has some invalid arguments
Assets/Scripts/Moodie/CustomController.cs(221,85): error CS1503: Argument `#1′ cannot convert `UnityEngine.Collider’ expression to type `UnityEngine.TerrainCollider’
Any solution?
This pull request has updated the project to 5.5.