Platformer Problems

[hockeygoalie5]

I'm kind of back and with more alliterations in my thread titles! Anyway, I'm getting back into ActionScript and I'm working on a platformer game. I've got it all down: the player, gravity, the objective, etc. but there's a problem. The platforms themselves are giving me a headache. Two problems: the way I made them (just a testing design) and actually programming them to work.

Okay, this is on the player:

if(this.hitTest(_root.platform)) {
        mainJumping = false;
        this._y = this._y - yspeed;
}

For some explanation of what's going on, if the player hits the platform, it stops jumping and moving upward the same speed as the gravity is pushing down so it doesn't fall through. But this causes the character to move slowly up and then immediately come back down. This can be fixed by setting the player's y to on the platform. Two problems: because it is a hitTest it starts doing this as it's on the platform. That causes the character to bounce up and down quickly. And, if it walk up to the platform (even though it's on top of walls that prevent the character from walking on it) the design still makes you able to hit the platform and go up without jumping. So, in conclusion of this long explanation of my problem, I need a different way to detect the player on the platform without hitTest and using if(this._y == _root.platform._y) doesn't work. Thanks in advanced!

EDIT: Forgot to add another thing, any ideas on making the platform itself?

 

[hockeygoalie5]

Bump.

(Don't yell at me, it's been two days and no one really looked at it.)

 

[berry120]

I've never really done much with actionscript, nor do I ever plan to do so! That said, your problem isn't so much of a language specific one (so it seems anyway) but a logic error, one I quite commonly see over on the Greenfoot mailing list.

I'm not sure exactly how you calculate gravity or at what point in your code you apply it, but in general it's likely to be the "move up at the same speed as moving down to normalise gravity" approach that causes such bugs. It's a bit of a flawed model and even if you get it to work in this circumstance it's not very extensible or efficient.

Instead, I'd adopt a new model where gravity is only applied in the first place if you're not on a platform - otherwise you stay stationary (in the y axis at least!) The only gotcha is when you come to stop on a platform you can't just check whether they're intersecting and then freeze the character since the character will probably move more than one pixel at a time. Most common scenario would be he ends up embedded in the platform, worst scenario he travels straight through it! Instead you'll need to "look ahead" the number of pixels the character is about to travel, check whether any of these intersect the platform, and if so only move the character that number of pixels until he stops.

I'm sure you're starting to appreciate how difficult game physics gets quite quickly...!

 

[hockeygoalie5]

Thank you for your help, to make sure I understand, you're suggesting that instead of making gravity a constant force, it is only applied when the player is not on a platform or the ground? Sounds like we're rewriting the laws of physics. Thank you again for your help.

For those who are looking to this thread for a reference to complete a similar problem, I'll put some code I plan on using to fix this.

if(mainJumping) { // character is jumping
    this._y+=yspeed; // change the character's y position based on gravity which is defined as: yspeed = 3*drag+gravity where drag is .98 and gravity is 2
}

If you need more of the code or an explaintion, PM me.

 

[berry120]

Thank you for your help, to make sure I understand, you're suggesting that instead of making gravity a constant force, it is only applied when the player is not on a platform or the ground? Sounds like we're rewriting the laws of physics.

Yup, that's exactly what I'm saying.

You're correct in that this isn't how things work in the real world - but when modelling physics in games you have to make such compromises. Very few (if any) major physics engines model things exactly the way they happen. Sure, people have tried but you run into all sorts of problems - even the simplest of things turn into absolute nightmares.

The classic example is the stacking problem with rigid body physics - quite simply, the problem is realistically modelling a few rigid blocks stacked on top of one another. Seems simple enough? It's really not - use conventional techniques and your stack that should be stable in the real world will start to vibrate more and more until the blocks bounce around and the stack falls over.

I won't go into the details of why here, suffice to say it hasn't yet been solved in the "real" sense. Methods like shock propagation have the effect of solving the problem, but in pure physics term it's a complete fudge and not at all how things work in the real world (it just looks like it is!)