[Adonthell-devel] Re: Ancient treasures (?) and more ...

[Kai Sterker]

On Sun, Jun 15, 2008 at 12:12 PM, Kai Sterker <address@hidden> wrote:

> I'll now get to work and try to draw up some kind of class model and a
> sequence diagram that would cover the above (maybe without [2], as I
> think that needs some thoughts yet). In the meantime, comments and
> suggestion are welcome.

Here's a class diagram that basically covers the list from the
previous mail. Green classes would be new. Not sure if I got my UML
100% correct ... I'm kind of still a novice at that.

The ideas behind all that are:

* animation_frame now has a list of images. Each image has an offset
from the top left corner and a flag specifying whether it is
horizontal or vertical. The size of an animation is contained in the
animation class itself (meaning all it's frames will have the same
size).

* sprite is basically the current animation class renamed. It contains
a list of animations that match the shapes of a placeable_model. I.e.
our current character with 12 states (stand, walk and run, each in 4
directions) will need a sprite with 12 animations, one for each state.

* placeable_model will keep a pointer to the representing sprite. This
is NULL initially and will be initialized only when the placeable is
rendered. For now this seems to be the fastest solution. In theory,
the sprite is only required by the map view, but I couldn't think of a
better way to map between placeables and sprites.

* just as with the current code, an area keeps a list of entities that
are part of the map. Each entity has a 1:1 relation to a placeable.
Normally, entities are anonymous (i.e. a ground tile) and there is no
way to retrieve them from the map. There are also unique_entities that
represent characters, doors, items, etc.. They have an Id that
corresponds to an Id of a RPG entity (character, item, etc.). Both
entity and unique_entity have a (virtual) get_id() method, which will
return NULL for entities and the Id for unique_entities. The area
class will also have a get_entity(string id) method to retrieve those
objects (Required for example by the map view schedule to get a
character model by its name).

* The map_view uses render_items to draw the scene. These consist of a
single image and its world coordinates that are determined from the
chunk_info class and the gfx_pos inside the animation_frame. For the
case of non-solid, vertical images that need to be split around solid,
vertical images, the render_item_part class can be used instead of
render_item. It will keep an additional drawing_area specifying the
part of the image to render. Render_item also provides the operator<
for sorting the draw queue, meaning this needs no longer be a part of
chunk_info, which really shouldn't have anything to do with rendering.


This implementation will get rid of the four *_with_gfx classes.
Entity will replace the thing_manager monstrosity inside area.
Animation will be split into multiple classes.

As an aside: In a later step, we should also get rid of the Grid
inside area and switch collision detection over to use information
from the chunk instead. That should eliminate another bunch of classes
(not listed on this diagram): coordinates, square and square_info.


Note that this design isn't optimized for speed or efficiency (there's
some redundancy, but it's mostly multiple pointers to the same
object). It's something that should work and be easy to understand.
Optimizations are for v0.5 :-).


Again, any suggestions are welcome. As is help with the actual
implementation. I am near a point where I can dive back into coding,
though, with a clear idea of what to do, so I should be fine.

Kai

P.S: Tyler, this will involve some changes to the animation class ...
should I take the opportunity and finally include Rians surface_cache
patches? Or should I leave that to you?

P.P.S: The class diagram was created using BOUML:
http://bouml.free.fr/index.html, the fastest, free, cross-platform UML
tool with C++ support I could find in a hurry. Takes some getting used
to, but did a fairly good job at importing the current code base :-).

class-diagram.png
Description: PNG image