adonthell-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]