Re: Pingu stuck and collision code

[Ingo Ruhnke]

Gervase Lam <address@hidden> writes:

> This was sort of my initial idea except that, for the time being, it would 
> only be just for Bridgers.  My idea was to "move" Walker::Update() to 
> PinguAction::WalkerUpdate() (or possibly a better name) and make 
> Walker::Update() call Walker::WalkerUpdate().

I think a WalkerUpdate() wouldn't solve the problem, a bridger is not
a walker and walks and behavies quite differently, so do all other
actions. I am more thinking of something like:

bool PinguAction::collide () =0

Status
PinguAction::linear_goto (int x, int y)
{
  while (pos.x < x && pos.y < y)
     if (!collide (x, y)) {
       pos.x += 1
       pos.y += 1
     } else {
       return ABORT_AT (pos);
     }
  return SUCCESSFULL;
}

so in stead of issueing a pos += (4, 2), one would do a goto (x + 4, y
+ 2), which does the needed collision checking for each pixel between
these 4,2 increment and returns if a collision happens.


There could also be a generic terrain traversal code which one could
tell:

"Walk from X to Y, tollerate at most MAX_HIGH pixel else reverse,
walk with speed 0.5, on no_ground -> fall, on_lava -> burn, ..."

                                |
                              __|
    X   _....,------.    Y    |
__,-----             ------___|


The traverse code should also be generic enough to handle walls for
the climber and walking up-site down, but well I have no idea on how
to implement that cleanly, so I would stay with the current code,
which is not the nicest, but works mostly.
                            
-- 
WWW:      http://pingus.seul.org/~grumbel/ 
Games:    http://pingus.seul.org/~grumbel/gamedesigns/
JabberID: address@hidden 
ICQ:      59461927