Module / Driver system
Create a module interface that will have init procedure and will be able to output it's own information at startup. Most modules will also be command libraries, in fact, the class commandlibrary could be renamed as module making the rulebox a module itself.
Each each module is passed as an individual parameter at start up BB.init(), they should each print their own information.
Now the main problem is the dependency system which will require testing. If I pass a series of IModule or IDriver in parameters, there should be no dependency to a JSON or SQL class. But will a game that does not any of them still be dependent on them even if never used. If I don't need SQl, can I have classes that required SQL in the library, but not have the dependency at all. Maybe the depend classes needs to be put into another package, or maybe if it's never called, it won't complain.
Else I'll have to create a sub-project for each classes that requires dependencies to make sure they are completely isolated.
Here is the schema I want to use:
- Interface IModule (which could be ICommandLibrary renamed)
- Class DataModule, CartographyModule, ScriptingModule, RuleBox will implement IModule
- Interface IDataDriver, ICartographyDriver, IScriptingDriver
- Class SQLDataDriver, JSONDataDriver will implement IDataDriver
- Class LUAScriptingDriver will implement IScriptingDriver
CHANGES: Data modules and driver will be only sql module and driver. There will be no other data structure. I am not sure yet if the scripting module could also be reused for rulebox implementations.
Note: can use something else than the word module to avoid confusion with NOOP module. Could try something related to books: Chapter?, volume, section, cahier? Might not be a good idea. I am already using datadocks. Maybe try something like plug-in, which will then use a driver.
Note: Maybe drivers are only defined when an external library is required like SQL, JSON and LUA. There should not be any cartography driver as everything is inside the library.
From a priority point of view JSON might be rerely used as small games that would required it might not need to save their game. It could only remain there for compatibility and learning purpose. But the priority seems more the SQL data storage. So maybe focus on that while keeping the JSON door open.
CHOICE: NO JSON.
NOTE: I will postpone this issue to complement the SQL database implementation.
TODO
- Restructure the module system, command library and rule box. Clean up some methods, and classes.
- Implement the Sqlite for java driver. Make some dependency tests. Might need to make a separate project for each driver. Test a game with and without driver for dependencies.
- BB.init will require the various driver passed in parameter for each module. An init call could look like : Init ( new SQLModule ( new SQL Driver), etc ); . Then it will display the various plug in identification, initialise them.
ISSUES
- From what I remembered it was pretty complex to handle all those drivers without any real benefits. So I decided to streamline stuff and use a few classes as possible. It's a bit the idea of the NOOP paradigm.
- I am not sure if I want to keep the connection inside the database class which will break noop, or pass the connection in parameter for each SQL call. I might want to try this approach to test the benefits and flaws of the NOOP approach.