[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Adonthell-devel] Source Code reorganisation
From: |
Alexandre Courbot |
Subject: |
Re: [Adonthell-devel] Source Code reorganisation |
Date: |
09 Dec 2001 18:04:51 +0100 |
> Hm. Depends what you define as "map" module. The map on the server
> wouldn't need "audio" or "gfx" for example.
Exact.
> Maybe we should try to define a pretty much complete module tree before
> putting stuff into CVS. Changing or moving around files and directories
> later is pretty messy. Also, if you design things right, you make sure
> much better that you have "ugly" dependencies.
Right.
> * ai - NPC behaviour, pathfinding, battle ai, ...
> * audio - mixer, music, sfx
> * data - map, character, quest, item, ...
Why not separating the map stuff and future other stuff (like fights)?
If we put everything in a data module it may turn messy.
> > This would mean that you can't manipulate an image from the
> > map module, for example, but I don't think this is a serious problem.
>
> Me too. After all we won't get as many python modules as we had back then,
> so you could easily include both map and gfx if you wanted to do image
> operations on mapobjects.
I meant that, an "image" returned from the "map" module wouldn't be
workable, even if you have the "gfx" module loaded. But I guess there is
a way to workaround this - in last ressort I'll ask the SWIG mailing
list, but anyway such functionnalities may not even be needed)
> That would possibly be best. But as I said, we should get a pretty good
> idea first what modules we'll have. Doing a complete design of the
> framework before wildly moving stuff around might save a lot of work in
> the long run. I can have a look at my Software Engineering papers and see
> which of the methods in there suit us. I remember that there were a few
> dealing with modeling modules and their interactions.
That's a pretty good idea.
Alex.
--
http://www.gnurou.org