Introduction

In a code-base where the game and mudlib code are intermixed, it can be easy to create coupled systems where the needs of the game unnecessarily influence the design and implementation of the underlying systems. By completely separating where the code for the game and the code for the mudlib are located, implementation of decoupled systems becomes a lot more straightforward.

Details

A core part of this framework is code reloading automatically putting in place the changes you make to the script files that it, and your game, are comprised of. In order to do this, the Python module system is bypassed and the code reloading system is responsible for identifying and loading the mudlib and game scripts.

This is not to say that normal Python scripts are not accessible by the framework, however they are not covered by the code reloading and changes to them may require that the framework is restarted before they come into effect. Normal Python scripts that the framework incorporates are located in the contrib directory. And of course the standard library is available to import from, as usual.

The bootstrap.py script is responsible for instantiating the code reloader and registering with it the different script directories that it is responsible for managing:

    import reloader
    gamePath = os.path.join("games", "room - simple")
    gameScriptPath = os.path.join(dirPath, gamePath)
    mudlibScriptPath = os.path.join(dirPath, "mudlib")

    cr = reloader.CodeReloader()
    cr.AddDirectory("mudlib", mudlibScriptPath)
    cr.AddDirectory("game", gameScriptPath)

The objects defined in script files under each directory are made available hierarchically under the namespace the given script directory is registered with. The following table illustrates how a selection of existing script files have their contents mapped to a namespace location.