[Adonthell-devel] Remaining map tasks

[Kai Sterker]

There's still too much stuff open, making it hard for me to decide
what to do next. Better to first make a lil' list :-).

* Character shadow:

That's very specific, and I think it can only be implemented in
context of the character class. It needs to be a separate entity on
the map and move along as the character moves along. It should always
rest on the ground beneath the character. The question is, should it
be created dynamically, based on the characters bounding box, or do we
want to use a special image for it?

A possible place for the implementation would be character::update().
If we change moving::update to only return true if a change to the
position did occur, we can use that to change the shadow position if
necessary.


* Map saving / loading

That is twofold. For one, we have to store which entities exist on the
map, possibly together with an index or in a way that their order
remains the same. This needs to be done in the area class. Then we
need to save the position of each entity, preferably by using the
index as a reference. This is going to happen in the chunk class.
There is no need to save the tree structure, as it will be regenerated
dynamically when loading again.

One change that should go hand in hand with this is changing the
area::put / remove methods from using grid-based coordinates to use
pixel-based coordinates. This will ease loading the chunk and it will
be a first step in getting rid of grid-based map storage altogether.


* Rendering

This includes getting the drawing order correct again and adding a
scan over the render queue in order to split non-solid objects as
detailed as part of this email:
http://lists.nongnu.org/archive/html/adonthell-devel/2008-04/msg00014.html

As part of the rendering, we should also consider if we want to have
composite entities on the map or not. Having them would mean less
individual entities on a map and therefore some speed improvements in
collision and render parts. OTOH, even with the simplified structure
of the map stuff, I don't see where they would fit nicely.


* Removing the Grid

That basically requires to change the moving class to use chunk in
order to find the objects we need to test of collisions. In fact, this
will help to get rid of a good deal of code, as moving will only have
to calculate a bounding box of the area that will be covered by the
moving entity. The chunk class will then return the list of objects
intersecting with that box and therefore need to be tested for
possible collision.

It also means that put/remove methods of area become obsolete, as we
can directly use put/remove of the chunk class. Also obsolete are the
square, square_info and probably coordinates classes. Moving
coordinates could be represented by a vector instead.


* Integrating schedules

Not sure if that is something to do now, or if it could wait. But the
idea here is of course to activate the schedule system and implement
the player character movement in terms of a Python schedule script.
The problem to solve here is that the character schedule stuff lives
in the RPG module. While it is simple to write a schedule that simply
registers callbacks with the input system, the question is how it can
control the player entity on the world map? Makes one wonder whether
schedules should rather be part of the world instead of the rpg
module. Seeing that NPC schedules will require path finding (which
would also take place in the world module), it seems to make sense.


Looking at the list, rendering seems to have the highest priority
(although it's also one of the more complicated parts). I do want to
wait with the character shadow (I'll post something about that to the
artwork list ... want to know what our artist thinks ;-)). Integrating
schedules could also wait. Removing the grid could have some of its
prerequisites done as part of loading / saving, so it might make sense
to do it afterwards. That would result in the following order:

1. Rendering
2. Saving / Loading of Map
3. Removing the Grid
4. Character shadow
5. Integrating schedules

I would leave #2 to somebody that wants to get into Adonthell
(although #5 might also make sense). So I'll have a look at the
rendering. Not sure how many of my previous ideas still hold true, but
I'll come up with something.

If there is interest in #2 or #5, I can post more details as to what
needs to be done (and how to go about it). It'll be a nice way to get
deeper into the current code. We could also discuss on IRC
(freenode.net, #adonthell) although I probably won't be around
tonight.

Kai