Awesomeness!!

But I can't really help you at this time in the night (or morning...) so I'll stop writing here (for now).

Moo!

Wish I could help you out. But I'm not too good with that physics stuff :)

I'd just like to say I've been watching your journal for a while now. This game looks like it's going to be awesome! Love your art style :)

A small suggestion for the high friction thing. There's actually a *limit* for friction, and you're not considering it. There's a sort of break-down point when you start having slippage, and after that the friction force stops growing and always stays the same. Actually, immediately after the slippage point, it will decrease a little. Like so: (beware ascii graphics!)

^ Friction
|
| . ./|_________
| ./
|/____________> Force


If you do that, Milkshake will start pushing the wall, but after a certain limit his feet will start slipping on the floor and he can't apply any more force to the wall :)

Looking really good!
What are you using for phyiscs?

Quote:Original post by mightypigeon
I'd just like to say I've been watching your journal for a while now. This game looks like it's going to be awesome! Love your art style :)

Thanks MP - it's surprisingly satisfyling to hear from people who like your creation. It can be a really long slog to actually get something out there on your own (and after following radioactive software's journal - I think I've even underestimated it) - so a little encouragement along the way really helps you keep moving.

Quote:Original post by Aiursrage
Looking really good!
What are you using for phyiscs?

And thank you too =) I'll answer this one first as it'll put Jotaf's comment in context a little better. I wanted to have a "realistic" physics simulation, but I wanted to be able to bend the rules where gameplay needed it - and there's only so far you can bend an existing library - so I wrote a few of my own. Time will tell whether this actually turns out to be a good thing - but if nothing else, it's helped me understand a lot more of what my physics (and collision) options are, how they work, and how I can use them.

I know I'd be experimenting with different physics solutions to get the "feel" i wanted, so I wrote my engine so I could plug in different physics modules really easily (there's a line in the initialisation script which says "new MI6Physics" or whichever solver I want to use right now.

Right now, there are 5 different physics solvers in my code base, all in various stages of usefulness. There's an "accurate" LCP based solver that just tries to be as "real" as it can. There's a more forgiving LCP solver which adds a few concessions to the end gameplay I'm hoping to use - so for example, it allows you to bias how correction forces are balanced between the two bodes in a constraint so you can do entirely inaccurate (but good for the gameplay I want) things like only having friction drive the top-most body. There's similarly an accurate and a gameplay-focused succussive impulse solver. I know in theory, SI and LCP are mathenmatically equivalent - but at least in my implementation they have their own character. The LCP is more even handed, and the SI solver is much easier to understand and add custom behaviour too. And then I've also started an "Isometric" physics solver which just tries to reproduce the feel of the old isometric games (they have no rotation - which feels really weird after playing with the other models).

Which brings me nicely to Jotaf's suggestion:

Quote:Original post by Jotaf
A small suggestion for the high friction thing. There's actually a *limit* for friction, and you're not considering it. There's a sort of break-down point when you start having slippage, and after that the friction force stops growing and always stays the same. Actually, immediately after the slippage point, it will decrease a little. Like so: (beware ascii graphics!)

^ Friction
|
| . ./|_________
| ./
|/____________> Force


If you do that, Milkshake will start pushing the wall, but after a certain limit his feet will start slipping on the floor and he can't apply any more force to the wall :)

Thanks for both the encouragement and the suggestion! No man is an indie coding island ... or at least, not this man, so it's great to get some other ideas.

Adding a friction limit is certainly intriguing. Pardon my rambling, but I'm going to walk myself through this problem out loud - perhaps you can find the hole in my reasoning (and code).

So right now, (like ODE) I have two friction models (well, I think ODE has at least the remenants of several others too): there's a normal force DEpenedent friction limit version, and a normal force INdepedent friction limit version. In the real world, the friction force is roughly proportional to the normal force passing through the contact point - the harder you push two surfaces together, the harder it is the slide them along - and this model also has some very nice gameplay implications too: it means pushing a stack of 2 blocks is twice as hard/slow as pushing a single block; and it means that pushing a block over a single big plane sees the same resistance/push-speed as pushing it over the intersection of 4 tiles. So the following assumes we're using normal force dependent friction.

Now, the next strand of the problem comes from trying to walk around on a moving platform. When you're walking on a mooving platform, and either you or the platform makes an instantaneous change of direction, the engine needs to be able to apply an impulse large enough to enact the change across a single physics timestep, or else the character slips around (something I don't want - if I allow some character slip, the solution is totally stable, but it's sloppy). The problem comes from the fact that the acceleration of said impulse far exceeds the acceleration of gravity (as in most fantasy universes like Mario, you actually have an amazingly low gravity relative to the real world to stop things plunging at frightening speeds towards the ground. So, the friction constant used to calculate the friction limit from the normal force is noticeably larger than 1.

Which brings us to the final piece of the problem: restitution force. Both of my solutions are so-called "discrete collision" systems. This means that they let intersections happen, then they try and fix it (and interestingly, for stable systems, they usually try and leave a small bit of inter-penetration around, usually referred to as the surface thickness or something). So, when you're character is standing on (or falling into) the ground, the solver doesn't actually "fix" the whole penetration every time step - because if it did, your character would actually bounce off the ground. Instead, it fixes some constantly-defined proportion of the penetration, usually around 50%. If you make this constant too low, things just smoosh through each other. Make it too high and things bounce off.

So, looking at the combined effect of applying all these rules to the situation where your character is walking full-pelt into a wall, you get the horrible net-effect that, to avoid bounciness, the solver only tries to apply around half of the force necessary to correct the character's incursion into the wall. But to give you a totally sticky "run around on a moving platform" behaviour, it's also been told it can use a force at least as big as the acceleration of the character in the first place (as anything smaller means slip on a moving platform). So the friction force is 100% of the incursion force (or more) - meaning it slowly but surely forces you through the wall.

Does all that make sense?

So even if I added a friction cutoff for the force-dependent friction, won't setting it low enough to stop you overpowering the wall mean it's insufficient to apply an impulse large enough to have the character stick to a moving platform changing direction?

The closest I've come so far is the play around with some low slip values - trading off a tiny amount of slop in th

The problem is that if you let the friction force grow uncontrolled, it will in some situations overpower everything else. You should have a cutoff, even if it's set really high, because it's sensible that if something is applying too much force, friction shouldn't back it up, there should be some slippage.

Your point is valid, and it happens in real life; if you're standing on something that's moving and it changes direction abruptly (with an impulse force greater than the cutoff), you will probably slip and fall down! Unless your soles can grab the floor really well. But consider the alternative, if the cutoff is set too high, and you try to push a wall, *all* of the force you're applying will be transfered to the wall. Overpowering the reaction force of a wall in real life usually means tearing it apart. The cutoff acts as negative feedback on the system and counters this. You would still have to tune some values to make it stable (like with all other negative-feedback control systems) but it isn't so bad :)

BTW, what should the engine do when you're pushing a heavy stack of crates? It should slow you down to reflect the weight. What about the limit situation, when the stack of crates you're pushing is too heavy to be pushed? Ideally, the poor cow's feet should slip. Otherwise something would have to break to release all that energy! This is the same as with a wall, something that should not be pushed.

Absolutely astounding progress and cute to boot :-).

Quote:Original post by Jotaf
The problem is that if you let the friction force grow uncontrolled, it will in some situations overpower everything else. You should have a cutoff, even if it's set really high, because it's sensible that if something is applying too much force, friction shouldn't back it up, there should be some slippage.

Your point is valid, and it happens in real life; if you're standing on something that's moving and it changes direction abruptly (with an impulse force greater than the cutoff), you will probably slip and fall down! Unless your soles can grab the floor really well. But consider the alternative, if the cutoff is set too high, and you try to push a wall, *all* of the force you're applying will be transfered to the wall. Overpowering the reaction force of a wall in real life usually means tearing it apart. The cutoff acts as negative feedback on the system and counters this. You would still have to tune some values to make it stable (like with all other negative-feedback control systems) but it isn't so bad :)

BTW, what should the engine do when you're pushing a heavy stack of crates? It should slow you down to reflect the weight. What about the limit situation, when the stack of crates you're pushing is too heavy to be pushed? Ideally, the poor cow's feet should slip. Otherwise something would have to break to release all that energy! This is the same as with a wall, something that should not be pushed.

Great to have someone to bounce this stuff off Jotaf - thanks!

So I totally agree with you - I do see the value of a friction limit. But I think there might still be a scenario where this breaks down. Imagine the 'X's in the horrible ascii art below represent your character, and you're trying to make him walk under a ceiling that is angling down toward the ground (creating a recess that is not high enough for the character). [EDIT - the diagram below is totally hosed by the proportional font - I guess you'll have to use your imagination]

*--.__
X *--.__
X ->
X
------------

Let's say the friction force limit is Mu. And, in order to get nice high friction response, Mu is significantly greater than gravity. So, at the ground contact point, your walking character will exert the full force Mu along his direction of motion (right) because the ground normal is totally perpendicular. But at the ceiling, the normal is not quite perpedicular because of the angle of the roof - so Mu gets applied up and to the left (to try and stop the motion). Now if we ignore the normal force from the roof given that Mu is significantly larger than gravity, won't the friction force from the ground still "win", driving the character into the gap that he really shouldn't fit into? This is what happens when I run the simulation at any rate.

Quote:Original post by Milkshake
Great to have someone to bounce this stuff off Jotaf - thanks!

So I totally agree with you - I do see the value of a friction limit. But I think there might still be a scenario where this breaks down. Imagine the 'X's in the horrible ascii art below represent your character, and you're trying to make him walk under a ceiling that is angling down toward the ground (creating a recess that is not high enough for the character). [EDIT - the diagram below is totally hosed by the proportional font - I guess you'll have to use your imagination]

*--.__
X *--.__
X ->
X
------------

Let's say the friction force limit is Mu. And, in order to get nice high friction response, Mu is significantly greater than gravity. So, at the ground contact point, your walking character will exert the full force Mu along his direction of motion (right) because the ground normal is totally perpendicular. But at the ceiling, the normal is not quite perpedicular because of the angle of the roof - so Mu gets applied up and to the left (to try and stop the motion). Now if we ignore the normal force from the roof given that Mu is significantly larger than gravity, won't the friction force from the ground still "win", driving the character into the gap that he really shouldn't fit into? This is what happens when I run the simulation at any rate.

Well, I can see where you're going, but from a gameplay perspective this is a bit contrived and shouldn't be seen as a total failure. That's the engineer in me talking :) As a last resort you can just not have that kind of geometry in the game.

Of course the perfectionist in me is intrigued by the challenge :P To be honest I don't quite understand your explanation. This is how I would probably analyze the situation: Milkshake exerts a (unnatural) force on the ground and gets a friction as a response, driving it onwards. There's an intersection with the ground so there will be a normal force to counter the sum of all other forces (friction + gravity, projected on the normal => countering just gravity).

As soon as the roof is hit, there's another normal force in play. The problem is that if they're defined in this way they become mutually dependent; computing one changes the sum of all forces which influences the other one, which in turn... you get the idea. How would you handle that? Simple accumulators don't seem to work. Is there an obvious answer I missed? Perhaps in your earlier explanation which my tired brain could not defuse :)

Given that interactions between different normal forces acting on the same rigid body can become quite complicated, I thought of a different solution: what about if your character (and maybe objects in general) is defined by a set of springs? Arranged as the edges of a cube or similar. Any object caught between 2 or more normals would "squish", absorbing the energy in question (a rigid body would be subject to a lot of stress if it's forced in an inverted wedge like this).

I just noticed that I didn't even mention the friction limit at all. I don't think it would fill a big role in the situation that you describe... except as the initial force, but then, inertia could do the same (throw the object in the air into the same geometry).

Glad to discuss some old-school physics too, from my 1nd year onward the most physics I had was about wave and electromagnetic fields :)

Do the platforms really need to change direction suddenly? If they moved more smoothly it wouldn't be an issue.

Quote:Original post by RAZORUNREAL
Do the platforms really need to change direction suddenly? If they moved more smoothly it wouldn't be an issue.

I thought about that a bit - but in the end, I decided there were just too many different ways I'd need them to be able to change direction relatively quickly (e.g. you start or stop moving on a platform - which is the same problem, you use a switch to turn a platform on or off, someone bumps the platform you're standing on, etc).

Definitely would have been nice if I could have "game-designed" my way out of this hole =)

So it's not perfect - but I think I've got something good enough to go on with. It's using one-way LCP constraints (which are quite cool). I'll write it up in my next journal entry.

Thanks to all for your great suggestions!