Player Physics in a Platformer

#1 You have checked TDN and the Platform Tutorial first, right? ;)

#2 Sure I have, but although it's an excellent tutorial I find it far from a *good and smooth* platformer movement.

#3 I have a platformer, and it is far from perfect.
At lower frame rates T2D physics gets crazy.
And I was unable to implement a
"bullet" object that doesn't affect the player.
Bullets have physics deactivated even so they affect the
"actors". Before 1.1.2 it was even worse with physics depending
on machine speeds.
And I have only plane platforms... with other tipes seems
things go even worse. Of course it could be my own ignorance,
because a serious physics demo (not only two objects bouncing)
doesn't exists.
I'd like to have a simple physics demo, Melv was kind enough
to answer some inquiries before, now that I have time I'll look
again to this problem.

#4 I plan to do my own physics and just use the nice collision system of TGB. I don't think simulated/accurate physics will give you good results anyway. You need a lot of artificial control over the motion to make it fun to play.

#5 You can find a demo of a jump 'n run with source code here (password: platformerdemo). I got it to work ok mostly but it needed a lot of small tricks and workarounds handling forces and such. But it also uses some of TGB goodies to its advantage. If you press 'g' then the center of gravity will switch to the GG logo in the upper left and you can go round the ball. You will however notice that the walking animation gets kind of wacky then because the character always looses ground for a short time. The can be fixed by typing levelplayer.setMovementCorrectionActive(true); into the console. But with this movement correction turned on some other issues arise.

Unfortunatly I've made some unnecessary modifications to the T2D.exe (this is a Beta2.exe I think) so this cannot be easily dropped into a RC1. But maybe you can get some hints from my script. I am not really satisfied with the whole thing either. Due to the lots of special case fixes the code is a bit crappy at times. Maybe custom physics in script would be a good idea.

-Michael

#6 I think you guys are coming to the right conclusion - the TGB physics engine, or any physics engine for that matter, cannot necessarily get you from point A to point B. You can use the physics, but you need to override & script a lot of it. Here is a quote from a game design book talking about realistic simulations in sports games. I assume the same, even more so, applies to platformers or anything else where physics is part of the design:

Quote:Because a sports game is simulation of the real world, it is a common error to think that the physics in a sports game should be as realistic as possible. They shouldn't be for two reasons.

First, the player is not actually running around on the playing field herself ... [immediate experience, control]
Second, the player is not a professional athlete ... [reaction time, skills]

For both of these reasons it's necessary to fudge the physics to make the game playable. We slow the pitch so that the batter has a reasonable chance of hitting it and we artificially adjust the position of the bat so that it intersects the path of the ball. It doesn't matter whether the physics perfectly copy the real world as much as whether they seem to be producing a reasonable simulation... Even in a highly realistic game, your object is to provide an enjoyable experience, not a mathematical simulation of nature

#7 @Alex is spot on--the generic industry term for this is "smoke and mirrors", meaning that in most cases, "true physics" does not equal "fun gameplay".

--Think about PacMan with accurate physics--it would require incredibly accurate skills to turn a 90 degree corner in the maze (and in fact, is physically not possible given any form of restitution (bounce) off the walls)...yet PacMan makes 90 degree turns flawlessly. This is because they do not in fact in any way use "accurate" physics.

--The average human has a vertical leap of < 25% of their total vertical height. No platformer anywhere would be fun if this were the case!

--what would tetris be like if your blocks bounced when they hit the blocks below them (hmm...that actually sounds interesting, might have to prototype that!)

In general, not as many games as you might think actually will want to use TGB's built in physics without script modification...

#8 I don't think this thread is about real-world physics or not. The question is "How can I use TGBs built-in physics to my advantage for a platformer?".
There are some show stoppers that keep you from just setting collision responses to CLAMP, turn on scenegraph-wide constant force as gravity and off you go. It would be cool if that was possible but it isn't.

#9 @Michael: good point, I didn't tie up my post very well.

As Michael implies, for many game play styles, you in fact do not want to use TGB physics (especially for player movement) at all...instead, you'll want to use the collision callbacks system with physics responses turned off to get the "look and feel" that will be most fun for your game.

#10 Yeah, I ran into those same showstoppers when I was goofing off with the platformer tutorial. But as Stephen and Alex mention, after muttering to myself how crap the movement was with scene wide gravity on, I quickly realized there really isn't a need for it. Sure it's an easy way to do gravity if it worked, but you only need gravity when the player is jumping or falling off a platform. So TGB's physics (in this case gravity) is there and working when I need it; otherwise it's off.

I was quite pleased with the results.

#11 @Stephen: Did I imply that? ;)

Mike is right. Find a way to determine if the player has got ground under his feet (t2dSceneObject::castCollision()!!!) and then turn on/off gravity for him. But there is much more to be done in a more advance platform. Moving platforms for example. You need to handle that to from script (I do that in the demo above). Downward slopes are another thing. It can get quite tricky if you have to handle all those things at once.

#12 Yeah ok, my example was for a very simple platformer. Instead of castCollision though, I used onCollision callbacks and sorted the reactions with the %normal generated (only turn gravity off when %normal is 0, -1 for example). While I didn't deal with slopes, I think that might be a decent way to handle those as well.

#13 Mike,
if you turn off gravity how do you know when your player looses ground under his feet? onCollision() will only be called if the is a collision. But what if the player runs over an edge. How do you know when to turn on gravity again?

#14 I have triggers mounted to the edges of the platforms and I simply use the onLeave callback to turn on gravity. I find t2dTriggers really useful for all sorts of situtations. :)

Edit: I wasn't implying your usage of castCollision is a bad way to handle things (in case you thought that), I think it's pretty cool TGB and Torquescript have so many options and tools to solve problems in multiple ways like this.

#15 I didn't think you meant that. :)

#16 @ Michael Woerister

Hey, man! Nice demo! Maybe YOU should be the one doing the Platformer Tutorial, lol! That demo really had that old-skool feel to it.

I did the TDN Platformer Tut and even though it's a great start, it certainly doesn't have the feel that yours does (which I was lookin' for).

#17 @Chris
The code would have to be cleaned up very much to serve as a tutorial. There are lots of things in it that feel very hacky to me.
I think the platformer tutorial is just meant as a starter, not a full game with "feel to it'. That is mostly a matter of the right timing and physics settings. And I took Super Mario World as a reference (and I am really in awe for the ingenuity of this game) which may be the reason why the controls feel more sophisticated.

#18 Hope it can help :
http://jnrdev.72dpiarmy.com/

Ps: The really big difference that i see with TGB and other game tool like Blitz or Purebasic is that many answers in this forum contain very few script example (please don't pay attention or answer to this fact because it's useless ^^).

#19 I have implemented the platformer tutorial with a bit of my own work arounds.

When the player collides with the platform, I set $player.setConstantForceY(0);. When the player jumps, I set $player.setConstantForceY(10);. This all works fine until I walk off the platform, in which case the ConstantForceY is still 0. How can I set the ConstantForceY when the player stops colliding with the platform?

#20 Test for a collision below the player each update (could possibly use an invisible scene object mounted to the bottom of the player sprite and watch collisions there). If there's no collision from that test, then there's nothing under the player, so you can set the Y force. I'll probably do something like that.