Non-Physics Based Player Movement System

After using the UDK for a while, I found that the thing most missing from the BGE is a good, strong template for player movement. Tutorials exist in bulk, but almost always seem to suffer from bouncing and/or sliding, especially on inclines. After looking around a fair bit, I found what is, in my eyes, the best solution (at least as of my writing this): not using physics.

By patching together a modified version of SolarLune’s Mario sidescroller script and Raider’s Mouselook script, I managed to create a suitable, mostly stable first person movement system that does not suffer from sliding or bouncing and can smoothly slide up stairs and over curbs.

Attached is a simple proof-of-concept demo.

Now, the thing is hardly perfect, suffering from a variety of shortcomings that I plan to patch up by way of a series of successive help threads (which will come later). The main point of this thread, however, is if this solution is the easiest, most stable, and/or most controllable one, or whether a physical object aptly represents a character by any means I have not yet tried.

Any comments, criticisms, suggestions, or the like are appreciated.

Edit:Sorry, almost forgot to credit Laser Blaster for his excellent FXAA script, which is also included in the .blend.

Attachments

FPS_Test_1EPacked.blend (666 KB)

Deal one topic in one thread. Otherwise you get the same problems you mention above. Because it is the typical result of unstructured work.

So I take your thread title as topic ( this is what a reader expects).

a good universal shadowing solution

And what do you know! That’s what I’m working on currently.

Instead of using Dloc, the current solution is to use physics, in particular the servo motion actuator. With it you can achieve that non-sliding non-bouncing movement that you want.

Quick tutorial and example script on servo motion.

But as Monster says, please break this thread up into smaller ones that we can deal with individually.

I have a physical walking ragdoll, that walks up stairs etc.

It does not bounce… unless you T him off like a golfclub, with a 300 kg hammer.

He recreates armature actions , it’s jackii’s physical walking rigdoll, itteration 1.
But with some “meat” dampining, and a different set of animations,
And the logic to run it all.

He has a new PID.rigdoll that uses servo motion rotation (thanks sdfGeoff!)
That you may even get better motion from, and if you are coding for the future, you may want to look at what is comming soon in bullet 3 gpu based rigid body simulations.

Yup, I just cleaned it up. This will be the discussion thread, later threads the help ones.

Yeah, I just saw your unlimited point light demo last night. Pretty cool stuff. Screen-space, right?

But does it work on inclines? I’m pretty sure I tried that solution and found myself less than impressed. But eh, I’ll give it another whirl anyway. Perhaps there was some magic there that I didn’t see.

Edit: Okay, gave it another shot. Better than I remember, but while it handled inclines with stride, falling and jumping still didn’t seem quite natural, like the character had no weight. Perhaps putting a constant downward force on the character would help?

I think I tried this, too. It was some impressive tech, but didn’t feel right or look natural, especially for a faster-paced game. It was an older version, though, so a lot may have changed since. I’ll look into it.

I will post a video in a moment,

Why not just use the Character physics type for a camera bound box and set Character movement? That’s what I’ve always done, and I’ve never seen any unrealistic results from it.

Yeah, again, it’s some awesome tech. Given a few years, it could become the open source counterpart to Euphoria. But it’s still too unresponsive and imprecise for what I need. True physical locomotion-based movement is something that almost nobody, AAA included, has ever really succeeded at. And I don’t think I should need to compete with Natural Motion or Wolfire in order to make a decent movement system.

In short, you’re blazing new trails, and you’re doing awesome at it. But I’m just trying to take a humbler road.

My test resulted in the character still slipping on an incline of about 30 degrees. I’m not ruling out that I did something wrong, but even with the material friction values turned up to max on both the character and ramp, the character still continued to slide.

I am the one developing it :smiley:

It can do anything you want almost now,

it follows IK actions, and It’s all adjustable,

too springy?

Adjust text.016 ->Meat dampening,

It uses normal based gravity, and the values are all adjustable, and any armature can be bound to the ragdoll,

I am not a great coder,
I am not a great animator,
I am not a great artist…

This is a system, and this is what I excel at, understanding how a system functions,

I made this walk cycle,

Run = walk cycle at 2x

I need a animator, rigger and pro coder to take this to the next level…

and have you heard anything about bullet 3 rigid body solver on GPU?

Here, try this:
http://en.file-upload.net/download-8876000/Character.blend.html
I’m not going to say there’s no slipping at all, but it’s minimal. I think it was included in the changes in 2.67. I never notice any slipping at all until about a forty-five degree angle, and then that’s still barely noticeable. If it’s still causing problems, you can set up the friction on your ground object.
Just in case you need it.

I’m not sure what I was doing wrong, but this works pretty well. About my only qualm with it is that it seems to resist simultaneous forward/backward and sideways movement, though I’m certain there must be an easy fix for that.

I think the changes came in a pretty recent update, but pretty much everything can be fixed by minor tweaking. I personally don’t like that the character motion can only move in one direction at a time either, but fixing it shouldn’t cause you any problems. I think that I actually did change it in one of my other files, but I’m not sure.

You simply have to disable the force in the other directions (by setting it to zero). So if your servo actuator is applying force/velocity along the Y axis, then set the force in the other directions to 0, and make sure that the force limits are enabled.

Oh, hey, you used my modified Mario script. I’m pretty sure it’s junk now though; it’s pretty old, haha. What I’ve been doing recently is a few things, though not all of these work for everything; I still might have issues with going up ramps causing the character to “hop” at the end, for example.

  1. Handle gravity yourself for objects that need to move on inclines (i.e. characters). You would use applyForce to make the object levitate, and then handle gravity using the object’s linear velocity. Use the rayCast() function to lock characters to the ground.

  2. Shape characters’ physics like: |=> or <=>, but rotated 90 degrees. The sharp point on the bottom should allow characters to climb pretty steep ramps and stay upright, while still having a shape that can collide on the edges, top, and bottom.

  3. Turn off friction on the ground and/or player materials.

  4. Use linear velocity to move objects around, managing friction yourself. That should avoid sliding.

If anyone wants, I can make an example.

@silent1 - Your example’s pretty cool for moving up the steps, though I managed to get trapped in one of the green cubes when I jumped on it.

Yeah, that’s one of the big areas wherein a collision cylinder would help. Not even a physics-active one, just one that would replace the directional rays to detect when the character clips collideable geometry.

I did think of one other major reason why I thought taking physics out of the picture was a good idea: to create a more accurate representation of character strength. With a physics-based solution, a 150-pound character may walk into, and subsequently push/toss, a 2-ton vehicle. Though I imagine there are other ways of solving that one, too.

Yes, if you don’t mind. It’d be interesting to see what techniques everyone here uses for such a fundamental part of game design.

With a physics-based solution, a 150-pound character may walk into, and subsequently push/toss, a 2-ton vehicle. Though I imagine there are other ways of solving that one, too.

Go investigate the mass property under physics, as well as: having friction on the vehicle/ground and having a sensible maximum force the player can apply.

And, for reference, it is perfectly feasible for a single human to move 999999999 tonnes. He simply requires it to be frictionless, and it’ll take ages to accelerate. But he can do it :slight_smile:
Realistically, a person can expect to move at maximum 1.5tonne vehicle on the flat. Or have you never pushed a car into a garage?

Okay, it took a little bit of time, but I think I’ve got it pretty solid.

Attachment removed in favor of Copy link here for easier updating. :>

Use WASD to move and Space to jump. You can use E to jump in the air (aka “flyjump”) as well.

It’s using a single ray to check to see if you’re on the ground and stick to it. When you jump or there’s no ground and you fall (i.e. the player object’s world velocity on the Z-axis is less than 0), it stops “locking” to the ground.

Note that usually you can’t shift direction (at least, not significantly) in the air in normal FPS games, but you can in this because it was kind of annoying to jump around without being able to control your movement. I might need to change how I approach movement and friction.

Anyway, you won’t slide down ramps, and you also can’t climb steep hills, which is cool. Stairs have an invisible ramp (the pink plane) on top that allows you to climb them; I tried to alter the ground locking code to lock the player to where he’s going to step (and so lock him to the next step on the stairway), and while it worked okay for stairs, it didn’t work well for hills. You should be able to perform a separate raycast for stairs if you REALLY wanted unaltered stairs, though.

P.S. A TPS setup would be pretty much this, but the camera’s parented to an object that the player would rotate, rather than the camera itself. That “Camera Node” object would be in the center of the player, but the camera itself would be behind and to a side of that node object. At least, I think that would work okay.

P.P.S. A possible known issue is that it was possible for the player to jump up on a steep incline (like a set of stairs) and get popped up into the air a bit, rather than locking to the ground, since it was still “in a jump” when it would hit the stairs. Although, I think I just fixed this, though I’m not sure.

keypress Jump----and--------apply jump
Ray -z map---------/ --------JumpTime=3
JumpTime=0------/

Ray -z map-----------------and------JumpTime-1
JumpTime min:1 Max:3–/
LinVZ min:-.5 Max:.5—/

always---------------python

python

own[‘LinVZ’]=own.localLinearVelocity.Z

So it removes the jump clock time if your on the ground and not falling, or moving up to fast,

so if your on the map for 3 frames, while LinV.z is between .5 and -.5

Edit:File

Attachments

JumpLimit.blend (442 KB)