Re: [pygame] Strategies for platformers

[Frank Raiser <crashchaos@gmx.net>]

On Sun, Jan 05, 2003 at 11:35:17PM -0500, Shandy Brown wrote:
> I'd appreciate anyone's opinions or discussion on general ways to do
> platform-type games.

Ok.. here are some random thoughts. Note that I have not written any
platformers yet and so these comments are not to be taken seriously ;)

> 1 - the charactor (mario, shinobi, etc) has a "state" of his movement in
> each direction, x and y.  We're interested in moveStateY.

When you take a little more physical approach an object would have a
speed vector as well as an acceleration vector. The speed vector would
be what your "state" means. However the acceleration vector can be
easily generated by user input. Imagine the user pressing the right button.
You could just add a certain amount to the hero's accelerationX. This gives
you the advantage of not having to handle the input immediately and therefore
'move' the hero twice (once for input, once for 'falling'). Another
advantage is that you can easily specify another acceleration when a hero
gets hit by f.ex. a rocket. You would imagine that if he walks right and
a rocket hits him heading from right to left that it would slow him down.
accelerationX -= amount_inflicted_by_rocket would be all you'd have to do.
Also see answer to point 2

> 2 - before displaying the charactor, subtract a set amount from
> moveStateY.  If the charactor is currently moving up, say jumping, it
> slows him down, if the charactor is at rest (moveStateY == 0) he
> accelerates downwards

I would actually always _add_ (or subtract.. depending on your coordinate
system) to the moveStateY. If your accelerationY always gets closer to
a gravity constant you would only have to add this to your state like
moveStateY += accelerationY. Note that it's easy to implement things like
Mario bouncing off enemies. When you detect that he step ontop of an
enemy you only adjust your accelerationY apropriately. And each frame you
adjust the accelerationY to be closer to your gravity constant. This very
simple physics engine (woo.. kinda overkill to use this word here ;) is
easy to implement and yet gives you tremendous powers at the ease of
one-liners.

> 3 - (still before displaying the charactor) calculate where the
> character WOULD be if he moved by moveStateY on the screen.  See if
> there are any other objects in that new position (pygame gives us some
> handy functions for doing this).  
>
> 4 - If there is a platform in that new position, change the position of
> the charactor so that it just on top of the platform.

That will work as long as you take care that a hero doesn't reach too far
into the platform. Imagine that for some reason in your game the hero moves
very fast downwards (say 20 pixel per frame). In one frame he's 10 pixels
atop the platform. In the next frame he would be 10 pixels inside the
platform. Now what the user will see is his hero flying down (note that
there's no problem when he's flying straight down) and slightly right. Now
if you just calculate the final coordinates and _only_ adjust the Y value
it will appear as if the hero kind of beamed himself a little further right
on the platform than it should be. A pure annoyance if an enemy happens to
be waiting there.
The exact way would be a line intersection between your line of movement
and the top platform line. The intersection point is where your character
should be landing on.
However as mentioned above these problems only occur on higher movement
speeds (they do always occur, but none but the most sophisticated players
would realize a 2 or 3 pixel shift further right)

> This strategy basically makes the charactor always be 'falling', which
> is handy because we don't have to detect when he walks off the end of a
> platform.

Correct. Same applies for the physical approach and I guess it applies to
most other solutions as well. I do not no other approachs but it sounds
sensible to always implement some kind of gravity to get rid of the hazzle
of calculating when a platform is hit _and_ left.

> Are there any other ways people have approached this problem?

There is always more than one way to do it. (tm)

-- 
Raiser, Frank aka CrashChaos
IRC: irc.openprojects.net #pygame

"Your either part of the problem, part of the solution, or part of the
landscape." -Ronin
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org