Re: How to continue

[David Philippi]

On Tuesday 11 June 2002 19:30, Ingo Ruhnke wrote:
> Same for me, beside some one-window java GUI and some guile-gtk I have
> never done any GUI development.

I'd say you know a bit more about it than I still. I'm hard pressed to 
understand how the map works at all.

> Beside mail we have also #pingus at irc.openprojects.net, I also have
> jabber and icq running here which might be more appropriat sometimes.

I've never used jabber, but are you using icq under Linux? I've got the 
problem that using licq I may receive messages without problems, but if I 
sent messages it's more like random wheter they arrive or not (I get an ACK 
package every time).

>  * http://www.gamasutra.com/features/20010713/dickinson_01.htm

I'll take a look.

> for the basic concept (disable java-script to get to that page without
> a login).

Is this an intended feature or a stupid webmaster?

> As said, its not a code issue, but a pure gameplay issue. Games aren't
> normaly played in pause-mode, while pingus currently can be played in
> pause mode and I tend to play it in pause-mode only most of the time.
> The solution is to make the pause a real pause mode, disallowing any
> actions to happen and add a bullet-time or slow-motion mode which
> allows precise action applyage without leading to a complete stop of
> the game.

Changing the pause mode to a real pause mode shouldn't be that much work 
IMHO. Using pause quite often to solve the game isn't something I'd consider 
a bug on the other hand. If you still have fun while you "cheat", it's ok 
for me.

> Things like rain, snow and other effects are done in another layer and
> don't influence either map directly (snow gets put onto the gfxmap
> when it has fallen to ground).

How many layers are there actually?

> Yep, something like that. Not 100% sure what the current situation is,
> but unifing the collision code, might help in a lot of cases. Since it
> might happen that the bridgers collision code is different from the
> walkers one, the bridger would walks into a wall, while the walker
> would have already detected a collision, so the bridger detects the
> collions at a moment where the walker can't do anything about it.

Unfying the collision code could prove a bit hard. A climber for example 
won't collide at places where other pingus do. But I suppose that most of 
the code will be common for each, so it could prove usefull to have a common 
collision implementation which can be either overriden for a special action 
or wrapped with some specific code.

> A generic unstuck-method for pingus would also be interesting, so that
> we don't need to avoid each and every stuckiness, but simply wrap to
> pingu to the next free pixel.

This sounds like a very good idea. But I guess really implementing those 
changes is a bit harder then talking about them. ;-)

Bye David