# A different approach on an EvenBetterCharacterControl

As mentioned in the monthly screenshot thread I have finished my character. I’m just joking with the name. It is surely not the best for your game and has its own flaws but I did some things different than the BetterCharacterControl. I hope you can take the ideas you need and do the best possible control for your game. Enough of the boring introduction. Let’s begin:

Firstly my character contains two parts. It is a capsule standing on a ray. You can imagine the ray as the legs. The ray has only one task. It checks the distance between the capsule and the object under the character. If the distance is lower than the leg height (the ray is a bit longer than the leg) the capsule position will be corrected in order that it has at least the leg height between. The correction is done with setLocation no need to use forces or impulses. What effects do this method have? Firstly you can walk over stairs. The capsule slides over the stair because it is flying. Than the ray corrects the position and you are standing on the next step. As another point you need much higher speeds to fly over hills. The reason behind it is that the capsule doesn’t touch the ground. As a result it won’t get an impulse in the y-direction if it moves uphill. The gravity can push the character down to the surface after it is flying and does not have to work against the impulse. Also surface irregularities are handled smoother. You only get corrected up and then fall down due to gravity but no impulse acts on you which pushes you in the air because the capsule doesn’t touch the surface. Because we don’t touch the surface we can set the friction to zero (It doesn’t matter for the movement). Instead we can’t get stuck on walls if a force pushes the character against it.

That was the biggest trick. The remaining part is simple physics:

I move the character by using horizontal forces. I have an acceleration value. To accelerate the character I multiplay it with the mass and then I have the needed force. Now I can accelerate the character to light speed if I want but I don’t. To get a speed limit you need Newton: We need a slow down force with the same length as the acceleration force. The slow down force should depend on the speed squared. Why? Because you know the behaviour from dropping things in liquids and I copied it. I don’t know if other exponents work as good. The force is

``````Fs = m*acc*v^2/vmax^2 = m *acc* = Fa
``````

As you see if v is bigger than the max value we will get slowed down because the slow down force is bigger than the acceleration force. Now you can’t reach light speed any more. We only need to stop the character if it isn’t accelerated any more. I use impulses here because I don’t think of a force which drags the character back. For me this slowing down process is more like running and taking a bit speed out from every step. The impulse in x direction is:

``````-velocity.x*m*0.05f
``````

0.05 is a magic number which produces a nice slow down effect. If you set it to 1 the character will immediately stop.

Jumping is done with impulses too. The rule of energy conservation gives us a term like this:

``````v = sqrt(2gh)
``````

If you want multi-jumps you can use multiple impulses.

As you see the math behind a character control is not difficult. You can manage to use SI units to control your character and don’t need do depend on magic values.

Last but not least I want to write about collision detection. At the moment when you shoot at the legs you won’t hit the capsule. There are two solutions. Either use mesh accurate collision detection for your model or use a ghost object which has the size of the whole character. Don’t listen to hits of the capsule.

What does this character better then others? It does never use setVelocity. As a result it reacts to forces and impulses. This is the most important point for me.

Maybe it is a bit hard to follow without images. Feel free to ask if some paragraphs are unclear or if you need more details. I’m open for any discussion about disadvantage you can think of. I’m sure it is possible to put this all in a control but I do sadly not need it as a control…

7 Likes

For hit detection which includes the legs you should consider using com.jme3.math.Ray

1 Like

You are right. If you want hit detection based on the actual model you can make a ray cast on the scenegraph. I prefer to have a simple shape which approximates the model and lives only in the physics space as a ghost object. Then you can make a ray cast with bullet

2 Likes

I watched the video, you seem to have solved most (or all) the problems I was trying to solve and failing disgracefully (I ended just increasing the problems with new problems…).

The best point in making it a control would be it replacing the BetterCharacterControl I guess, and I think it could be just a composite on your bullet es EvenBetterCharacter (as it is not a physics control :)) so it could work in both ways.

I am not being able to run the TestBetterCharacterControl, found yours while looking for alternatives, i think it is broken, or something is misconfigured here, not sure yet…

EDIT: by not being a physcontrol, when you control it thru keyboard, you just move the model over it right? I think the model geometries could be used as hit spots for shots, and it seems good to keep the capsule only colliding with the terrain walls. But… the whole point on being a capsule is to have roundy edges to get in contact with the terrain, if it is not in contact, it could be anything right? even a box.
Also, did you found advantages on it not being a physcontrol?

1 Like

Yes I tried to cover the issues BetterCharacterControl has. Nevertheless my character logic (I call it logic to not mix it up with Controls) has certainly its own issues. I just haven’t tested it enough. As you see it won’t be a replacement but rather an alternative to the BCC.

This logic needs lots of concepts from my own library. eg. the concrete physics components or the logic manager. Also it is a different concept to a control. In my opinion controls shouldn’t be mixed with physics because controls are only simple tools for altering the view eg. a rotating a windmill. It doesn’t matter for the game state whether the windmill is rotating or not but it is important for the view. This task solves a control. It is a pure view object. I understand that it is comfortable to use a PhysicsCharacterControl because you can get started very fast with it. I could couple my character logic with a control but I’m sure you don’t want that. It brings you a lot dependencies to my style of code and you have to rewrite your whole application.

If you really want my logic as a control you need to copy the concepts and bring it into a form which fits to a control.That’s the reason why I started this thread. I want to give you the ideas to transfer it to your game. I can help you and provide you with code examples but I won’t do it myself at the moment because I have no time and am not convinced that it is right to have a character control.

I hope I have covered you second paragraph with this explanation. I’m not completely sure if I got your question right.

I can’t help you with the TestBCC because I have never used it. I have only watched some videos and read some posts about it. But I think most of the examples should work without problems. The core team made a very good job with the examples. I can give you my example if you like to test one

Response to the EDIT:
Yes and no I have a vector pointing to the feet of the character. The view takes this vector and moves the model to this position. If I want to move the character I apply a force to it - the acceleration force. This force moves the character. I don’t set the position or velocity manually because this would deny the other forces acting on the character.

Yes using the model geometries could make lots of things simpler but you loose some freedom and speed. I will try it out in my next demo.

You are absolutely right the capsule is only for colliding with the terrain. You could technically use any shape and it doesn’t matter for the ground but if you have a slight overhang above you which you might not notice you can’t jump because the edge of your character is blocked by this overhang.

The most important advantage is that you can decouple the view from the game state. You can use the MVC pattern and have your project more structured. As said already a Control is a view object in my opinion but you might think different about it.

To get an example you can clone my repository and run this file:

or the others in the folder. To get an idea of the whole concept you can look at this folder:

And here you find the concrete logic:

I know that this is a lot of code and not much documentation but I will try to improve. It helps me a lot if you continue asking questions because I can get a feeling for the important or complicated parts.

Long post… thanks for reading this far

2 Likes

thx! didnt know that!

like having a server running the physics and a client in playstation showing it, and another gamer using a nostalgic ascii “renderer” hehe

I will take a look at the examples, thx!

1 Like

cool, the essence is the bullet.rayTest(),
if am I not wrong, it works “like” a vehicle? I never used the vehicle things, so I dont really know… but now I am curious if it could be tweaked to be like a character control as a one wheel vehicle hehehe.

I think the core is the torso, everything else may go thru doors and gaps in one way or another, so may be, the best shape could be a diamond

but in some way it must match the visible geometry, otherwise it will just bug the players.

1 Like

I don’t know how the vehicle works but if I would make a vehicle I would do it the same.

I think the best way is to try some shapes and test them.

1 Like

yeah but thinking again the “vehicle-character” (if possible) would be a move against ES …

1 Like