Re: How to continue

[Ingo Ruhnke]

David Philippi <address@hidden> writes:

> To change this I'm forced to do cleanup first to reduce the
> redundant information to a point where I can recognise it as such.
> Beeing a guy who likes to compile often to see wheter a small change
> works as expected, optimizing compile time is very importen too.

'make CXXFLAGS="-s"' was always enough for me, since that speeds up
the final link dramatically. Changing something in WorldObj.hh,
World.hh or globals.hh is of course a problem, but one can workaround
that by 'make -t' and manually touching a few files.

> This certainly doesn't mean that I'm not bored by just doing cleanup. It 
> means that I see no other way if I ever plan to understand Pingus.

One doesn't really needs to understand the whole thing. When you want
to fix an action, you basically just have to go to
src/actions/your_broken_action.cc, to fix a background, goto
src/backgrounds/, etc. There a few issues which needs global tweaking,
but there are also a lot of issues which just involes editing one or
two files.
 
> If you provide a bit more detailed information, I can take a look at
> it. I may know much about C++ but I don't know nothing at all about
> GUI, graphic or game programming. That's one of the main reasons I'm
> interested in pushing Pingus forward: I want to learn by doing
> something usefull.

I don't know much about ClanGUI in generall, but what we need for
Pingus is basically a preferences dialog for each object types where
one can edit the objects properties, like release rate for the
entrance or owner_id for the exit. The dialog might basically just a
varible-value list. Not sure how exactly that should be integrated in
the editor, but something like adding a get_property_dialog() to the
EditorObj class and then adding that property dialog to some dialog
manager class might be working. Rewriting some parts of the Editor to
become a real ClanGUI component would also be possible, but would
involve quite a bit more work.
 
>> for some more issues that need to be resolved. Record/replay
>> features would also be nice to have, but depending on how power
>> full such features should get this could be a bit more complicated.

> Complicated is a word with many meanings. I suppose most people
> would consider writing a Middleware which is a combined CORBA client
> and server, multithreaded and performance critical complicated. For
> me this doesn't really pose a problem since I've got experience with
> this type of programming.
> If you see problems just on the level of C++, I won't fear them.

The complicated part is basically to get the design right and
implemented correctly, since this would involve the ripout and
rewrite/rearange of quite a few classes in Pingus. One could also just
hook the recording up into Server.cc, which would be quite a lot more
easy, but as the whole Client/Server thing isn't really that clean at
the moment one might need to fix a few issues there.

>> There is also the good old pause problem which we currently have. The
>> pause-button is simply too powerfull and makes gameplay rather
>> slow/ugly (most of the time I go pause/forward/pause/forward/...).
>> Solving this without completly removing the ability to pause the game
>> would be good, some things like bullettime, limited pause, a special
>> pause action for a pingu come to mind.

> Well, what is the pause problem? Is there to much that can be done while in 
> pause mode?

Yep, you can do all things in pause mode that you can also do in
non-pause mode. Turning that off isn't a problem, but thats not what I
want. I want something like a limited pause mode, which allows one to
do precise applying of an action to a pingu, but not without going to
a complete freeze of the gameplay at that time.

> Are there parts that don't react correctly so that the game by dump
> core?
 
No, this is a pure gameplay issue, not a code issue.

>> There are also quite a lot other gameplay issues which could need
>> fixing. Pingus getting stuck in walls and other such things.

> Explain me the relations between background, objects and a Pingu and I'll 
> perhaps be able to help you there. ;-)

We have the ColMap, which is used for pingu<->ground collison
(basically PinguAction::rel_get_pixel()). We have the GfxMap, which is
what one sees on the screen. They are seperate so that one can use gfx
effects without influencing the pingus behaviour.

The problem that pingus get stuck results basically from an incorrect
collision checking and from the more complex interaction of actions.
Unifying the collision checking might help, but in the end I guess
this will be pure try and error to get the actions fine tuned against
each other.

An example would be a bridger which walks towards a wall, collides
with the wall and turns back into a walker, but as the bridger as
walked already 'into' the wall, the walker action now gets stuck.

-- 
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