Locomotion: Theory Discussion

Hello all. I'd like to discuss the concept of physical locomotion, and how it relates to game engines.

Specifically, Terrestrial Locomotion. This is worth a read if you're not too familiar with the concept: http://en.wikipedia.org/wiki/Terrestrial_locomotion

Some forms of locomotion are very easy to simulate. For example, the way a snake moves can be easily approximated by having that snake slide along the ground as a physics object, with low friction, moving itself with regular pulses of forward motion.

But i'd like to discuss the most common one, Pendulum locomotion with legs. The one we humans use, where you alternately shift weight from one limb to the other, while moving the centre of gravity forward.
This is a form of static locomotion. That is, unlike with the snake, the part that touches the ground (the sole of the foot) does not move in relation to the ground. When you put your foot down, it physically stays where it is in absolute(world relative) terms, and the rest of your body moves around it.

Unlike with the snake case, pendulum locomotion doesn't require a low friction. Infact it requires a high friction, but only high enough to offset the other forces applied and prevent the foot from sliding, beyond that, surface friction is irrelevant.


Anyways, all that scientific information aside, how do we simulate it in games?

I've very, very rarely seen it simulated fully. Usually in games which are entirely focused around that aspect of movement (QWOP and triachnid come to mind). Mostly i think full simulation of pendulum motion is a waste of effort for both the player and developer. But i'd love thoughts on that, maybe modern technology is making it easier and more automated ?


On the opposite end of the scale, there's what i'd like to call programmatic movement. Although if anyone has a more appropriate term, please do tell me. This method seems to be, by far, the most common. Where the player is moved around purely by code in little increments per frame, and has very little interaction with physics at all. In this system the player is basically just a floating object detached from the world, that happens to look like the walking on the ground. To me it seems lazy and inherently limiting, although i can understand why many games use it, due to some combination of budget/time/knowledge constraints. or for games where there simply isn't a physics engine. I however would like to not work like that.

So what is left? what's the third option? Is there some intermediate that offers a balance between utter simulation and reasonable simplicity?



-------------------------------------------------------
In a game i've developed in the past, i implemented the player's movement entirely as a rigid physics object, and i gave the soles of their feet really high friction (rubber soled shoes), but temporarily set that friction to zero when the player is moving via keyboard input. I did this so that when the player stops pressing buttons, their character would slide to a halt over a (very) short distance, rather than having 0 speed suddenly. In general, the player would just slide around everywhere, but have a running animation play that made it look like they were running.

It achieved my objective, but it felt like an ugly hack. And it was a 2D metroidvania style game, so i don't see it working so well in a 3D environment where rotation around the vertical axis also has to be taken into account. in that game i also disabled rotation (around the single axis) and had the player change direction just by flipping 180.

Right now i'm working on one of the unity tutorials which focuses on Player movement, and it seems to be setting some sort of Speed value in the player's animator. What does that even do ? how does it interact with friction? It's also implementing rotation entirely programmatically (little shifts per frame) which feels ugly to me, i'm not comfortable with that

How else can it be done? What possibilities does unity offer? how have you done it in the past ?

 

I'm afraid to tell you that "little shifts per frame" is how everything is done in games, including the physics engine. The physics engine has it's own fixed time step. All the objects are shifted forward a little bit each time. It's basically just using "forward Euler" to solve the dynamic system on the fly.

http://mathworld.wolfram.com/EulerForwardMethod.html

Have you experimented with the "Root motion" options that mecanim provides? It gives a much more realistic and "solid" feeling to the movement.

 

Well, computationally it's not that hard, right? You update the pose of your skeleton, find the relative movement of your traction point compared to your pivot point, then you move the pivot point by the inverse of that. Then all you need to do is appropriately decide when to switch to a different traction point - left to right foot and so on. So we don't not do it because it's technically difficult.

While I can think of cases where it'd be cool and it'd definitely make some things look far more grounded and solid, I think that the added complexity just wouldn't add much to a lot of games. Workflows become more complex and less flexible (there's an animator in the design loop, and characters can't have gameplay until they have animation), AIs that use it have to perform their motion indirectly (instead of "move left" it's "play animation that will result in us moving left"), there are timing issues (ie: it's much harder to know how fast something is moving, so what do you do when a calculation needs to know how long it'll take to get somewhere?), and so on.

But yeah, what you call "programatic movement" is in fact how any movement system will work under the hood. The question isn't how the object is moved, it's how the movement is calculated.

 

It's worth bearing in mind that in a run cycle, the feet spend very little time in contact with the ground. Most of the time is spent with no ground contact at all.

 

I think the reason the simulation of walking has never been adopted by the majority of games is like angrypenguin says, although it's not that difficult, it's not going to add much to the experience.

In many situations I can see it being a huge pain to work with too, how do you get your physics based character to climb a ladder, crawl, crouch etc. Granted a lot of the principles are similar, but it's a lot of extra work for such a simple addition in functionality, and for what benefit?

Simulating the walking movement for instance, I imagine a benefit would be a very solid looking walk cycle, however as pointed out, root motion can achieve this.

Another benefit may be that you can physically affect the movement of a character, however that's also already possible in physics based character controllers (which are more widely adopted in games).

There's also the point that adding this as a simulated system not only increases the computational cost of moving a character, it also introduces the potential for many bugs/unwanted issues.

All in all, I can't think of anything that a simulated system for walking can do that cannot already be suitably approximated.

 

Good point. The algorithm would be a more complex than I stated if supporting running and/or sprinting... though it's not a huge deal, since if there's no contact point you simply maintain existing velocity and add some minute falloff if you really want to pay attention to detail.

This brings up another point, though. No ground contact means no acceleration. So when the player stops pressing forward the character won't stop moving forward until they've got new contact. This raises an issue of responsiveness and, perhaps more importantly, also one of how much additional animation complexity will be required to make it feel right.

 

Oh come on, I'm not stupid. Yes i knew that. That game i was talking about? i WROTE the physics engine for that. never finished or released it though, was mostly a learning experience.
I mean on a higher level, i don't want to have a physics engine and then have characters and players exist outside of it as special cases.

and this root motion system i think is what i'm asking about, still learning that, not done any experimenting yet. I created this thread alongside my own efforts in order to recieve some input and advice as i go

 

So far these answers aren't entirely helpful I definitely agree that full simulation isn't worthwhile, but what i want to find, and want suggestions on, are levels and degrees of simulation that bring meaningful benefit.

What i called programmatic movement, I basically meant doing that with scripting, in the context of either having a physics engine and not using it, or never having one in the first place.

And i still don't have an answer yet, can someone explain exactly how the unity system works? with setting the speed value in an animator? i'll be poking around and experimenting with that myself but advice would be useful

 

I agree entirely with everything you said before this line. What i want to know is, How would you approximate it? What's your preference? How deep can the simulation be taken before the returns diminish too much to be worthwhile ?

 

You’re nailing down two approaches to the locomotion problem - kinematic (aka programmatic) and physics driven.
There’s a spectrum of alternatives “between utter simulation and reasonable simplicity”.

I implemented a physics driven character controller. I used a ball. Since I wasn’t shooting for a physics puzzler - just a reliable controller - I implemented a decent governor and dissociated apparent rotation from the rotation of the ball itself (easy to guess why). The main issue was the lack of friction.

Simple, maybe; still I think it’s a valuable exercise for getting started with physics driven controllers.

I find that physics driven controllers generate more functional bugs (player loose control!), whereas kinematics controllers generate more cosmetic bugs.

"To me it seems lazy and inherently limiting"
Both approaches are inherently limiting. Kinematic controllers are very case based. Works for the player, works for the animator, works for the programmer. Why? Because motor control is meant to be abstracting away the details of how motion is executed.

A good simulation - even with only 2 or 3 rigid bodies; can compliment a modern platform game or an action-oriented piece…

A significant issue with simulations is that integrating the work of animators is difficult.

 

I was writing my previous answer while offline but I think it should give you the basic elements that you're asking for...

- The most simple way to make your character "exist" in the physics world is to use just one rigid body. It may look simplistic but it's actually a good compromise between kinematics and physics. What does it do better than a basic kinematic controller? Out of the box, so many things, like, actors that can push each other around and... well... respond semi-realistically to forces.
- If you're interested in 'locomotion' specifically even a one body system can still provide a starting point, but consider a two body system to simulate feet?
- For anything more complex I'd use governors and some kind of problem solving strategy to parameterise them automatically given constraints (e.g., motion templates ).

I think that sounds difficult enough (and I feel puzzled, is this meant to handle anything better than robot walk on a flat plane?). Honestly wondering how many man-hours you have to put into this to move from a pity proof of concept to something that's production grade, never mind artistically pleasing.
In my opinion, roughly ten times more time consuming than a kinematic capsule.
Also "update the pose of your skeleton" doesn't sound like physical interaction.

 

The speed value in Mecanim is a multiplier for how fast the animation will play, and (if you're using root motion) will directly affect how fast the character moves forward though the world. This is because the character's movement through the world is based on the actual movement of the skeleton in the animation program.

Just to clarify, to use root motion, your animations in your animation program need to have your character actually moving forwards in world space as they walk etc. Not animating on the spot (like how I would consider a traditional approach to work).

Does this help answer that question at all?

 

It's difficult to give a hard and fast answer without a context of use.
It depends on what you're making, where I work, we use pretty simple translations with matched animations. That works for us, because we just have simple scenarios for E-Learning, we don't require any kind of physics.
If we did, I'd imagine we'd implement Inverse Kinematics, which would allow us to blend our animation based approach with physics collisions/forces. That would provide a more reactive character, but keep the stability when performing actions like crouching, picking something up etc. It's worth noting that this is common industry practice even without utilising the physical reaction aspect.

That approach may not satisfy you, as it's still very much a shortcut.
However the fact of the matter is that unless your users are going to notice the effects of your simulation (in most cases this would be unlikely), you are better off not doing the simulation!

If you have a specific case you wish to share, I could probably visualise why this is so important, however if just being applied to any old game with a character, I don't think I see the benefit if the current solution works well enough.

If you aren't already aware of root motion and inverse kinematics, I suggest you should look into them and discover what they can do before trying to simulate everything, you may find they cover what you need them for.

 

http://www.gdcvault.com/play/1020583/Animation-Bootcamp-An-Indie-Approach Rather on point. It's not a physics simulation, but it is about getting character movement to be something that abides by some kind of rules of nature.

 

no, it isn't easy. Please explain

also in general, what's with this constant phenomenon of locking rotation for characters. i understand it makes yourr work easier as a programmer, but it generates a less immersive result. I can't name a single action game that allows the player to be realistically thrown around by forces (explosions, etc) and spin/flip through the air as a result. Even traditionally open games like the GTA series still lock rotation, often leading to silly issues like a man standing calmly in an upright pose as he flies 200ms per second through the sky

I don't like this language. "generate more bugs" is really just a lazy way of saying "it takes more work to implement." That's why everyone keeps going for the kinematic approach, constantly. There are plenty of situations where a physics based system gives the player more control and a deeper level of interaction with the world, but developers eschew it in favour of more overblown set pieces that nobody cares about.

With any technique, and enough time in testing, bugs can be brought down to an acceptable level. Obviously doing it right takes more work

This is the point i'm arguing. it doesn't work for the player. kinematic control is fine for strategy games, and similar situations where direct control isn't an issue. But in almost anything realtime and action oriented, implementing physics gives a better "feel" to things. Players can detect it, even if they don't fully understand what they're experiencing or why.

indeed, which is why i'm interested in the theory of partial simulation, and looking for ideas on that.

 

Good point.

An action game, pretty much any sort of game where someone runs around on the ground and does stuff. Think gears of war, or super metroid, or mario, or GTA, or anything in between. Player input translates to direct movement, is really the only criteria.

IK is a definite interest of mine I've seen it used well in infamous, and assasins creed. And also GTA IV

I wouldn't call IK a shortcut, i rather like it. What you're describing sounds pretty good to me

Totally agreed. Certainly i think that actually implementing physical legs and pendulum locomotion is going too far.

I don't KNOW the current solutions, that is my primary purpose with this thread. Certainly i think it would be naive to expect that i can reinvent the industry alone, but i see a lot of conventions and often-used techniques that i don't like, and i would love a good rundown of ways the industry has so far tried to advance the cause of simulation in this aspect. What kind of solutions have been implemented, and how well have they worked.

 

Oh my god, yes. This is the kind of thing i want to make. thank you immensely for this, watching now.

Four minutes in, you've understood me perfectly. This is really the exact kind of stuff i am looking for. I'm going to watch all of these videos

 

Oh and on the subject of animations. I make my own, have tons of experience with poser. I've always felt that a seperate animator was an odd thing to have, integration is what i care about. in fact i do everything myself, but even so that's not a task i would easily farm out to employees.

 

I agree. I do my own animations too. I think the animations and the character controller code need to work together to the point where they have to be done by the same person.

 

Are you seriously suggesting that we shouldn't participate in a discussion without first advancing our ideas to production value? Besides which, what you quoted all comes down to the last sentence there. I wasn't saying it's easy, I was saying that particular part of it isn't where the difficulty arises.

 

A ball rolling on the ground isn't accurate enough a model of locomotion that its rotation is any use in describing the orientation of a humanoid character. It is a limitation of the model I used.

Generates more bugs isn't a lazy way of saying anything. Now, You are absolutely right that people go with the kinematic approach because it is cheaper. Are we lazy cheapskates ? No; we prioritise.

If you'll have it this way, games don't work for the player. They are full of canned dialogs, photoshopped textures, scripted events and other set pieces that I don't very much care about.
I understand that you're interested in more realistic locomotion, doesn't mean that games are broken, or programmers are lazy.

Where am I even suggesting that anybody should not participate in a discussion?
I guess I was missing your point, sorry.

 

Ha, i found something awesome today that is relevant to this thread:
http://funnyjunk.com/channel/4me/Virtual+evolution/nhGRLau/

That gives a good example of an application of complete simulation.

 

A humanoid character? I think we misunderstood each other.
I thought your character actually WAS a ball. just a sphere of some sort, and then I was confused why you would want to not let the physics engine roll it around.

I understand and agree with this, although i don't think there's anything inherently wrong with those techniques. Just that the industry vastly overuses them, and for some reason believes that's what the players want. (it sells because they throw money at marketing)

The point i was trying to make, is that games with realistic feeling movement are, imo, too few and far between. The ones i've found have been like rare gems, often from smaller developers.

 

Yeah, that was floating around a couple years ago. I don't think there has been any progress on it since then.

 

Doing realistic locomotion in games is very similar to robot locomotion, which I've tinkered with for a while. You can find a lot of research on static and dynamic gaits, learning and adaptation, etc. in the robot literature.

It's hard to do well, though there are certainly builder who do it well (see this for example). And of course in a game, we have the advantage of essentially unlimited speed and torque in the motors.

If you were to take this approach, though, you probably would end up with a gait that looked fairly robotic. So it might be best to start with something where that fits, e.g. a mech game, or something else with robot characters. This could be really interesting — just as World of Tanks is making a highly detailed, physics-based tank simulation, a very detailed, physics-based mech simulation might attract a dedicated audience. You could make the locomotion naturally adapt as the mech takes damage in various places.

If anybody wants to do something like that, and can put together a reasonable budget, PM me — I know how to approach this thing, and it so happens that I'm available for contract work.

 

You have my mentality down pat. I plan to make things across a wide variety of genres, but for each one that i do, i plan on doing it "right" and appealing to the hardcore audience.

The mech idea is a good one. Are you aware of any premade software for figuring out postures and gaits like this, or is that something i'd have to spend time writing myself ? I probably could accomplish it eventually, but i'd have to learn a ton more

 

I think you'll find you have to write code yourself to do this in Unity, though there are a lot of fairly well-developed algorithms you could work from.

Fundamentally, the basic idea is to keep your center of mass over the support polygon. The center of mass is trivial to calculate here (it's much harder in real-world robotics), since you know all the positions and masses of the parts. The support polygon is also pretty easy to find: it's just the convex hull of the of the support points. (It gets a little more complicated on uneven terrain, but I think you could probably ignore that in most cases.) If your COM is above the support polygon, you're statically stable; you can quit moving and not fall over. If it's not, then you're either falling or what they call "dynamically balancing," which means that you have a plan for moving one foot or the other out in front of which way the COM is going and catching yourself before it's too late.

Early humanoid robotics always stayed statically balanced, but modern ones (like in the video I linked to above) use dynamic balancing, just like we do. It's mostly a matter of projecting where your COM is going to be in the time you can swing a foot, and picking a foot position that will be out in front of that, and then using IK to position the limbs accordingly.

One problem with mechs is that a lot of them would be basically incapable of walking at all, in real life, because their legs are too far apart and can't bend inward enough. But some designs would work. And of course your hard-core mech fans might find that really interesting.

 

This is an interesting video I saw a year ago ..

 

That looks like really neat work! This research has really advanced in the last few years.

 

Ah I was looking for this video actually when I remembered the one I posted above all very cool stuff to take in for those who wish to program animations