Re: [Adonthell-devel] Source Code reorganisation

[Kai Sterker]

On 08 Dec 2001 18:27:40 +0100 Alexandre Courbot wrote

> I don't know whether we should follow the same development scheme.
> Having totally independant "libraries" doesn't correspond to our goals.
> We want the map engine to be able to draw the stuff, play the sounds,
> and so on. So I think it's right that for instance the "map" module
> needs "audio", "gfx", "ai" and "misc".

Hm. Depends what you define as "map" module. The map on the server
wouldn't need "audio" or "gfx" for example.

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.

On the server you have practically only data (map(-object) and character
data, including inventory and item data, but no gfx or audio). Much, if
not all of the AI would take place on the server and you have network and
"db" ;) code. There is code to turn data into strings, which is used by
both net and db code. And I guess that about is it for the server.

On the client you have all the data as well, together with a graphical
representation for maps, mapobjects, characters and items. The network and
db stuff would also be used by the client. Then you have a GUI that more 
or less sits on top of everything, the window system used by the gui. The
input routines used by the window system. Not to forget the audio code.

If I haven't forgot anything you'd have something like

* ai    - NPC behaviour, pathfinding, battle ai, ...
* audio - mixer, music, sfx
* data  - map, character, quest, item, ...
* db    - loading, saving
* gfx   - mapview, battle-arena, ...
* gui   - dialogue-, inventory-, load/save screen, ...
* input - keyboard, mouse, gamepad, ...
* net   - protocol and client/server connection
* wnd   - widget set, window manager
   
Once the list is complete we should model how those modules interact and
do some corrections. We should also start to break things down some more.
Maybe we can merge some things or have to split some even further.
 

> 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.


> Then, if everything is ok, we
> would move the complete stuff. In this case, maybe it's worth creating a
> new module on the CVS, instead of twiddling again with the old one.

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. 

What do you think?

Kai