I’m working on a game right now that is a 2d platformer where the character controlled by the player is a box - of varying length. I’ve messed around with the scripts/ideas used in the 2D platformer tutorial, but they aren’t really suiting my needs anymore.
I can’t use a CharacterController for this project because my character is really a box, and not just a box that can be approximated by a capsule. The box grows and contracts - the capsule collisions provided by a CharacterController don’t fit. A BoxCollider is perfect.
So now, how do I go about implementing something simple like the CharacterController’s Move function? I want to write some basic scripts that allow me to move the box along a platform with gravity preventing the box from falling through the platform and also with the box sliding along the platform (basically, the two BoxColliders touch and slide against each other but don’t go through each other, like in Move).
This sounds like some really basic stuff - but I don’t understand how collisions work enough to script it. I don’t want to use rigidbodies or anything, there is no realistic physics involved here.
Copy the character controller’s behavior but use a box instead of a capsule.
Yes, there is. You want to move a box (forces are physics), you want gravity to pull down (again, forces are physics), you want the floor to hold the character up and preventing falling (again, physics). Why are you averse to rigid bodies and the character controller as this is all exactly why those items can be so useful (built-in, easy to use, fast)?
Edit: if you must go without physics then using transform.translate will be how you can move the box about. You’ll need to detect whether the control keys are pressed then apply your own “velocity” to move and multiply that by the time elapsed since your last render (vel * time = distance) and translate the object as needed. All while manually keeping the box at a fixed height above your surface.
Whichever method you use to move the the collider, you should have a rigidbody attached to its GameObject - otherwise you’re moving about static colliders which quickly becomes very expensive as it forces PhysX to recalculate its internal static collider states a lot.
If you decide to move the object by modifying its transform, the rigidbody should have IsKinematic ticked or you’ll get physics trailing behind your rendered object.
(Explaining myself from before, but don’t worry; I actually figured out most of my problems! I had to put a rigidbody on the floor and disable gravity on it - and then my box character would stop going through it. Thanks for the help.)
The reason I am averse to physics/the character controller is that the character controller is fixed to using a capsule collider, which I can’t use.
Furthermore, in the tutorials and documentation on the CharacterController, it says it is used because often you don’t want to attach a rigidbody to your character, since people expect that characters in games will have very unrealistic physics (ability to turn instantly, etc.) So in the 2D Platformer tutorial/example, the script that controls the character makes use of the “Move” function on a CharacterController. It also applies its own “physics” by calculating the vertical and horizontal offsets manually, and then moving the character. I figured this was the way you should deal with your character, since you don’t want physics interactions with it.
Right… the point is that the character controller’s behavior is hidden from me - the Move function does a whole lot of stuff. From the documentation:
Move
Attempts to move the controller by motion, the motion will only be constrained by collisions. It will slide along colliders. CollisionFlags is the summary of collisions that occurred during the Move. This function does not apply any gravity.
I have no idea how to figure out all of these collisions, and how to constrain the controller by collisions. (especially since when static colliders collide with static colliders there is no message generated…)
^ That is what I want to do.
So I’ve figured out how to get the box not to go through the floor. Hurray. My next challenge will be to distinguish colliding from different directions: how to determine that I have collided with another object from the top as opposed to from the side.
I think my problem with that is that I am using triggers to get this all working, so I don’t get Collision info.
I attach a rigidbody to the “floor” of my level so that it interacts with the character. But then how do I make it not move? I unchecked “use gravity”. But if the trigger isn’t enabled, then the floor is still affected by my character hitting it, so it moves…
In my setup right now I have my character: which is just a static box collider, then I have the floor, which is a box collider (trigger) with a rigidbody attached, and then I have some other objects in the level which are box colliders (trigger) with a kinematic rigidbody.
I bet that is pretty messed up, but it seems like the only way to get all of the objects to sit still where I want them.
And for some reason with that setup, when the character jumps it still generates OnTriggerStay events every frame with the floor (no matter where it is, after the first frame).
HiggyB, when you say this, do you mean literally (like copy a file) or rewrite it? I’m in the same boat (need character controller with different shape). I’ve rewritten all but stopping characters from moving into walls/floor. Not sure yet how to do that cheaply.
Also, does anybody know where the link jcarpay referenced went? Was it deleted?
HiggyB probably means to copy the character controller’s behavior using the physics (rigidbody) system. While HiggyB’s suggestion is a valid one, in my particular case the physics engine is to unstable and therefore I require the character controller’s capsule collider to be extended with a box collider (I really need that boxed shape).
The link works just fine for me, just register and make your vote
