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 _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
