adonthell-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Adonthell-devel] Framework ideas


From: Alexandre Courbot
Subject: [Adonthell-devel] Framework ideas
Date: 01 Dec 2001 14:49:08 +0100

Hello everybody,
Maybe it's a bit prematurate to expose these fresh ideas here, but that
way we could have a discussion about them this evening.

I think that 0.3 is a big improvement in terms of design compared to the
earlier releases. Actually, it's the first that starts looking like
organized. Still, there is still some progresses to be made in that
respect. It appears that since we correctly design our code, serious
bugs appears less often, things are more reusuable, etc...

What we should try to do is to improve our framework, actually redesign
it completely, so 0.4 can be to 0.3 what 0.3 has been to 0.2.

We have several solutions from there. I think we can get inspiration
from the NeL engine which is being developped at Nevrax
(http://www.nevrax.org). As you know, it's GPL'd, they use Doxygen (doc
available on their website) and it's quite well documented. Moreover
they are making great progresses and it seems they will actually succeed
(would be so great, to see a GPL'd game success!) You can have a quick
look at how they organize their stuff. One interesting thing
is that the different "modules" (rendering, network, AI, sound, ...)
seems to be completely independant. They are also all assigned a
namespace. I don't know whether the latest SWIG likes namespaces, but I
like the idea. We could (physically) separate the different parts of the
engine as follow (just an idea):
-addraw, basic image/animation manipulation classes
-adgui, the current window system
-adaudio, the future audio system ;)
-adnet, the future network layer
-admap, the map engine
-adai, the AI stuff we have (including dialogs?)

The thing to watch out are dependencies. For example, it is ok if admap
requires addraw, adgui and adnet, but in this case neither addraw, adgui
and adnet would require admap. Cross-dependencies are a pain, as we
experienced with 0.3, and the signs of a bad design. And unfortunately I
think we still have some.

Of course, you'll quickly see the limitations of the upper scheme:
-what about (for example) the characters? Where are they defined? admap
would use characters, but also other parts, so where to put them?
-should we also use a subsystem for the inventory stuff, team managment,
etc..?

Also, inside the modules there is a bit of work to allow them to be
flexible enough: for example using admap to make a map run wouldn't mean
having all the gfxs in memory: for a server, which doesn't display
anything, this is totally useless. The current mapengine doesn't allow
this at all, as graphical datas are always loaded along with the rest.

Well, you got the idea. I'd like we discuss about how to
organize all our code, using namespaces, and why not libraries, or even
subdirectories. As most of the code will be blown away soon, it's the
good time to do so, I think. If we can get a nice discussion this
evening I think we should quickly come with a complete document
describing the framework, and we could finally start development again!
:)

But please all consider releasing 0.3 first, so we can hire new
developers. I know I'm boring, but this is really important!

See you this evening!
Alex.

-- 
http://www.gnurou.org




reply via email to

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