Re: How to continue

[Ingo Ruhnke]

David Philippi <address@hidden> writes:

> I'll try to get some sense out of the source. My problem is, that
> I've never ever programmed any GUI - I don't know how they work. All
> I know is some documentation I've read about the Java GUI.

Same for me, beside some one-window java GUI and some guile-gtk I have
never done any GUI development.

> Doing it via mail is a bit difficult, but it shouldn't be
> impossible: [...]

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 got a few books about software patterns and design standing
> just behind me, so you may guess that I've spent some time with
> learning how to do software design. Let's try wheter I can find a
> solution to this problem. Implementing it afterwards should be the
> easy part if the design is done well.

See:

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

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

> Hmmm... not much clearer then before. If you want to allow precise
> applying of an action, you've got to stop every pingu, right? So
> what is there not to be stopped? Animations of other parts?
 
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.

> This means that objects inserted into the GfxMap aren't physical in
> respect to a pingu so one may e.g. have rain in the background or
> suchlike?

The gfxmap is a static bitmap (split into a zillion small tiles),
where one can add and remove parts. Add/removal is a bit slow so in
general, one does only use that every few frames (when a pingu digs,
explodes, etc.) and not every frame. So yes, its completly seperate
from the collision map (which is also a bitmap), it doesn't matter for
the pingu behaviour how the gfx map looks. But in general both gfx and
collision map will have a very similar shape. An example where it
makes sense to apply different add/remove commands is for example when
a pingu explodes, the gfx maps then gets a rough circle, while the
coll.map gets a perfectly clear circle removed. Another example is the
grass, grass is only present at the gfx map, the collmap doesn't
contain grass, since it would be quite difficult to get the collision
right if you have tons of small randomly placed pixels.

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).
 
> You mean that the bridger actually walks "into" the wall while the
> walker would have changed it's direction if a step forward would
> result in a collision? If so, the solution would probably be that if
> the bridger changes back into a walker because of a collision, the
> walker should be initialized with the opposite direction, right?

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.

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.

-- 
Advent:     http://www.freesoftware.fsf.org/advent/
Feuerkraft: http://www.freesoftware.fsf.org/feuerkraft/
Pingus:     http://pingus.seul.org/           || ICQ:      59461927
Home:       http://pingus.seul.org/~grumbel/  || JabberID: address@hidden