[Top][All Lists]

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

[Adonthell-devel] New global framework

From: Alexandre Courbot
Subject: [Adonthell-devel] New global framework
Date: 18 Feb 2002 13:10:08 +0100

Sorry not to answer the previous mail and to break the thread, but I'm
at univ here and haven't the mails backed up.

So, as you might have noticed I've wiped away the game class and
starting writing another one. The principle is very simple: there are
three main directories that Adonthell is aware of:
-The user data directory (~/.adonthell under Unix)
-The global data directory (which is /usr/local/share/adonthell by
-The current game data directory (only used if you are using a game)

What is it usefull for? All these three directories have the classic
hierarchy of an adonthell data directory, that is the gfx and script
directories, etc... They can of course be optionnal.

The static game class is initialised (for now) with the path to the game
you will be using (nothing if none). Then it offers any other class a
way to retrieve the user, global and game directories. But it goes a bit
beyond: it also allows you to find a specific file or directory in these
directories. I'll take an example to be clear.

Say I've just installed the adonthell source, to be able to make new
maps. I'm not interested in playing anything. With the adonthell source
package comes a window theme, which is then put in
/usr/local/share/adonthell/gfx/window/default. So I'll run the map
editor, which inits the game class without any game directory argument.
Then I'll do a window_manager::get_theme ("default"). It will call
win_theme::load ("default"). This is where things become interesting.

The most current behavior when searching such datas is to first search
in the current game directory (if any), then into the global data
directory, and finally in the user directory. win_theme::load will want
to search for themes in this order. It will then call
game::find_directory(string &) or game::find_file(string &) according to
what it is searching. These two methods returns the absolute path to the
file/directory name passed in parameter, searching for it in the game,
global and user directory in this order. So in our case, as there is no
game running, it will directly search into the global directory and will
return the correct file name.

There are plenty of advantages using this system:
-games could be placed in the global data directory, but also in
~/.adonthell/games. In case the user doesn't have access to the global
directory, he could still install games in his directory. When looking
for a game, the game class will search it in the user data directory if
not found in the global data directory.
-we could make editors run without any game package, provided we put the
right things in it. This is the main advantage. This would also give
games creators some default material they could rely on (i.e no need to
copy the default theme in your game package and have several copies of

Of course, sometimes we won't want to use it, and only look for example
for mapobjects in the current game directory. I haven't thought about it
much yet, but it should be easy to make it optionnal in the loading
functions. Or maybe stuff like themes would be looked for in these 3
directories, while real game elements like mapobjects are always only
looked for in the game directory.

Another improvment I haven't made yet: when given an absolute path (i.e
starting with '/'), game::find_file/directory would directly return it
without searching anything. When using editors, you'll certainly want to
be able to load files anywhere on your drive, and not be limited to
these directories.

Pfu! That's about it. Comments?

reply via email to

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