Re: [Adonthell-devel] Global framework redesign

[Alexandre Courbot]

> These are just random ideas, the only thing I'm certain about is that we
> need to redo our framework. Currently everything is fixed at init time
> and remains static. We must turn it into something more dynamic. I'll
> try to come with more ideas later, but I let you know what I think so
> you can give it a thought too ;)

Here is a bit more stuff to think about:

First, the game class go to trash. It has only two awfull methods, init
and cleanup, to respectively initialise and cleanup the game. Every app
that links to it must include the entire game. Instead, we'll make sure
that each subsystem (Python, audio, gfx, etc...) has init() and
cleanup() methods and we'll call the one our app needs instead. As for
the game, it has to init/cleanup everything, but there are only 5-6
systems to init like this, not a big deal.

The gamedata class should be split. It currently contains methods for
saving/loading games, which is fine. But it also has a bunch of static
methods to get the game data directory, load all the characters/quests,
etc... which is not right. I propose we re-create a static game class
which only provides central information about the game, for example:
-user_data_dir -> ~/.adonthell (the user data directory)
-global_data_dir -> /usr/share/adonthell (the global game directory)
-game_data_dir -> /usr/share/adonthell/games/wastesedge (the current
game data dir, with the others datas. Only relevant if we are actually
playing a game, of course)

It would start with these three ones for now. Note that it doesn't
depend on anything - it's just a global class to centralise information
others systems will need.

The dynamic game saving stuff stay into gamedata, while the static stuff
would go in another class. We have to consider the game saving stuff as
an actual subsystem amongst others - not as something that is mandatory
to include. Anyway, if we start serialising things, we'd certainly need
to rewrite/cleanup the game saving system, which is not a big deal
anyway. So I propose we isolate it for now, and decide later a better
way to handle saved games.

After doing these first cleanups, the others systems would be able to
get their data at three places:
-the global data directory, where stuff provided with the engine are
(like the default theme/font)
-the current game data directory, for game-related data
-the user data directory, for custom stuff. We could maybe allow the
user to place his games in this directory too, in case he doesn't have
access to the global data directory.

As a consequence, we would stop chdir()'ing into the game directory and
use relative names when loading our data files. On the contrary, the
subsystems will be responsible for concatening their files names to the
right data directory. Which means you won't need a game to be the root
of everything once you want to run a simple editor - and files you load
doesn't necessarily need to be a part of a game.

Give me your green light, and I'll start messing with that. At first I
wanted to start making some editors and continue the map system, but
better to cleanup the base first.

Alex.
-- 
http://www.gnurou.org