pingus-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pingu stuck and collision code


From: Gervase Lam
Subject: Re: Pingu stuck and collision code
Date: Thu, 26 Sep 2002 00:27:16 +0100

On Wednesday 25 September 2002 09:22 am, you wrote:
> Ok, patch commited. Seems to work, but I am not really sure that I
> like that behaviour completly. Its ok for and bridge that is already
> half build, but I would probally like to keep a way to add a final
> last brick to the bridge so that pingus can no longer pass that way. I
> mean add a special case handling for the placement of the first brick.
> So two bridges could actually work as a blocker.
>
> ############
>               <- here bridger stops, path is still walkable
>     __--
> __--
> ##########
>
> Another bridger is started at the top of the bridge and places a last
> brick:
>
> ############
>         __      <- patch would now be blocked due to head_collision
>     __--
> __--
> ##########

Well, I don't completely like that behaviour of the fix either.  But it is 
the simplest solution to the problem.

As to the above idea.  It still would not work fully.  Even if it did, I 
would allow the Bridger to build the above Bridge in one go rather than 
two.  That is, make a Bridger behave like what it was before the fix.

The problem is that Walkers are still going to get stuck as per my 
previous example.

Here is another much simplified version of another situation I came across 
while I was finding out about the fix.  The following diagrams show a 4 
pixel high Pingu walking up a bridge.

              _________
(1)  ________|         |_____

            >
            >
            >bbbbbbbbbbbbbbbb
            >bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb

              _________
(3)  ________|         |_____
             >
             >
             >
             >bbbbbbbbbbbbbbb
             bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb


              _________
(3)  ________|>        |_____
              >
              >
              >
             bbbbbbbbbbbbbbbb
             bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
         bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb
     bbbbbbbbbbbbbbbb


We now have a stuck Walker.  With the Bridger fix, the situation would not 
happen as the top brick would not be placed because of head collision 
along the placed brick.

I suppose you could have the Walker check along the brick to see if there 
are going to be any head collisions.  However, this is at best complicated.

There could an absolute _mess_ (and mass!) of bricks there from a player 
attempting to one bridge on top of another many times.  You do not know 
how the bridges/bricks are going to be positioned or arranged.

And the bridges can start at the nearest 1-pixel vertically with many 
bridges, not 2-pixels with just one bridge.  See the Walker positions in 
the above example to see how this can happen.

Oh.  And another thing I have thought of.  What if the Pingu in (3) were 
to place a brick in its current position...

Thanks,
Gervase.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]