On Mon, Jul 23, 2012 at 10:24 AM, Josh Glover <jmg...@gmail.com> wrote:
> Ok, makes sense. How would the adonthell program differ from worldtest? Just > by not hard-coding the loading of the player and NPC? I thought a bit about the possible options we have and I see two ways how it could work in principle. The givens are that we have a data directoy that can contain a number of games compatible with the engine. We can either have a single program that can run each game (a global engine executable, like v0.3) or we could allow/require a custom executable specific to each game. In the first case, we'd have the code as part of the engine package (much like worldtest), in latter case it would live in the game package instead (snd a lot of code might have to be duplicated for each game.) In either case, the main loop should be kept inside the engine. Best place for that would be the main package, as that is the one module that has access to all other modules (and inside the adonthell::app class also knows which modules are actually initialized/used). For the main program, this leaves the task of initialization (of course without any hardcoded loading) and a call to a game-specific Python script that can do game-specific setup and will at one point have to start the main loop, at which point control remains within the engine, until the player exits the game. The idea behind the game-specifc init script is also that it sets up global key listeners (to show in-game menus for example) and it needs to have access to adonthell::app to start and stop the main loop. It also has access to any other part of the engine, of course. Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/adonthell-devel