Sign in to follow this  

Character Controllers - what do YOU use?

This topic is 468 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I naively thought implementing a character controller with the Bullet Physics would be quick, simple, and there'd be a "one size, fit all" approach.

 

Boy was I wrong...

 

I have been scouring the web for details of tried and true implementations, but am quickly seeing its something that needs to be tested and calibrated per game. I think people just apply a lot of experimental tweaks and don't always share the details. So I just wanted to see what other people are doing to give me some baseline approaches. 

 

My main questions are the following but you can provide as much detail as you wish:

 

1. How do you model your collision objects for your character?

2. Do you use a dynamic rigid body, or a kinematic object?

3. How do you apply force/velocity/position updates and resolve collisions?

4. How do you drive the motion of the character with scripted animation? (For example, if there is a dash forward and strike animation, make sure the physical object moves forward, and follows the slope of the ground)

5. What do you think are the strength and weaknesses of your approach?

 

Right now I am particularly curious about how some people use a capsule that is "sitting" on one, or several ray casts, as this seems to be the most common approach. My understanding is that a ray cast is just a means of measuring distance (and getting collision info) so I don't know exactly how height is maintained (setting position, velocity, force? etc.). Do you use a kinematic object for this? How do you handle collisions? Etc. and so forth..

 

Any details or insight in this matter would be appreciated. From what I gather, this is quite a "black art" and it can consume a lot of time. Trying to avoid this problem eating my life. 

Share this post


Link to post
Share on other sites

I am not familiar with Bullet, but here's my scenario.

 

I went ahead and rolled my own system. It is rather undeveloped and has only been tested in a limited working environment, but the logic still stands for what I need and has shown to be sufficient for the current progress of my overall game engine.

 

The philosophy behind my home grown engine is to keep all systems decoupled for maximum portability. Most systems communicate using an event handling system that couples everything together.

 

In a nutshell, without knowing type information, but clients conforming to expected types, a physics participant in my physics environment takes a pointer to a position, world matrix and a copy of the mesh information. Using these variables, you can construct multiple types of bounding information for bodies to interact, apply gravity, ect... to the draw location. Their are different types of physics participants to accommodate different theoretical object types and their necessary sub-routines.

 

A LWPhysicsBody for standard, dynamic, intractable objects in the game world.

A LWPhysicsTerrain for static terrain.

A LWProjectile for short lived, "bullet" or "shooting" type objects.

 

1. Using mesh information passed in from the client application.

 

2. My own implementation is a simple rigid body system.

 

3. force is applied to a stored pointer variable for the objects draw location. Collisions are resolved using mesh information that is compiled as the physics object is created, and updated using the objects world matrix.

 

4. I will be using physically based movement for all animations. Meaning if their is a dash, you actually apply a set amount of force in the direction that is required for that "attack". I don't plan to support absolute position changes from an animation.

 

5. I have not put my system through the ringer yet to really get a good sense of the upside/pitfalls of my approach. It is, how ever, fast.

 

Their is a lot more for me to do with my own system, but I guess the answer you are looking for is probably just an ambiguous "what fits your scenario best" as per standard programming protocol.

 

Edit:

As for your capsule question, I am assuming you mean how to keep the object "standing" on the ground? If that is your question, I use a bounding box. After applying gravity or any other force, you cast a ray down from the draw location(which is the object origin) to the ground, if the distance is less than half the object height, set its Y component to half its height. That keeps it from going through the ground.

Edited by ExErvus

Share this post


Link to post
Share on other sites

1. How do you model your collision objects for your character? 2. Do you use a dynamic rigid body, or a kinematic object? 3. How do you apply force/velocity/position updates and resolve collisions? 4. How do you drive the motion of the character with scripted animation? (For example, if there is a dash forward and strike animation, make sure the physical object moves forward, and follows the slope of the ground) 5. What do you think are the strength and weaknesses of your approach?

 

1. bbox range checks

 

2. these seem to be engine specific references for an engine i don't use (perhaps unity?) . 

 

3. x+=vx,  y+=vy. stepped movement for fast objects. sliding collisions. avians and falling characters are more complex. collisions with the ground are also modeled in depth (bouncing off angled surfaces), and impulse and momentum for ground collision damage. missiles use true 3d rectilinear kinematics with gravity, aerodynamic drag, wind effects, etc.

 

4. with code. animations only control the pose of the model. code controls the location and rotation of the model.

 

5. it was easy for me to write. i've been doing this stuff a long time, and physics has always been my best subject.

Share this post


Link to post
Share on other sites

I'm working a 2d platformer, so the finer details would be different for other types, but I generally end up using a similar controller for everything I've done.

Generally I have a PlayerInput object which controls ActorController on an Actor, which drives animation and physics. The ActorController applies physics to Actor and sets bools that drive the animation in the Sprite. 

For the hierarchy, It's basically this:

PlayerObject
->Actor
--->Interactive Triggers (for triggering interactive things like buttons, alerting enemies, etc)
--->Raycasters
->Character Sprite
--->Muzzle Flash Position
--->Weapon Position
--->Effect Emitters

Raycasters are used to detect grounded/not grounded (for jumping/landing). The Sprite is set to follow the Actor very closely - basically overlapping. This is just to avoid physics jitters and jerkiness. The PlayerObject is there as the top of the hierarchy, which allows the different parts to communicate and be spawned/destroyed together.

Share this post


Link to post
Share on other sites

I wrote my own. I recently ported it into Bullet so I use Bullet's GJK implementation manually to do the collision checking and to get the minimum separating vector, then I model a capsule sitting on a ray manually to get the character controller behaviour I require.

 

In my experience, it is not possible to get a character controller working right if you model it as a rigid body and apply normal physics to it.

Share this post


Link to post
Share on other sites

This topic is 468 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this