I’m rewriting the code that loads and validates the module data files. I’ve switched to a formal JSON schema format. However, in doing so, I’m reconsidering how the system handles module data.

Currently, all module non-media data files must be in YAML format. YAML files require more processing to handle than JSON files, but because the system loads the module files just once at startup, it’s not as much of an issue. However, as the system deals with many modules, each one needing special parsing, checking, and internal expansion, this becomes longer running and more difficult for module authors to test.

I originally standardized on YAML files because their easier to read and maintain for a human. However, I also knew that some aspects of the system would be easier to use if the author wrote the module in an easy to handle form, then use a system to convert that to an internal module format.

Most probably I’ll end up with an compiled-to format that the system uses as the optimized form, while allowing it to also read in the non-compiled format for load-time compiling. I’ll probably make some requirements like needing a “developer mode” flag to allow the program to perform compilation on-the-fly.

This will give module authors the best of both worlds - published, dependent modules are compiled and quick to load, while the in-development modules don’t need to go through an extra compile step.

This will mean that I have an opportunity to split out the text parsing (as seen in previous posts) into the compiler. Those embedded strings would then be stored as a complex data structure where the runtime game doesn’t need heavy parsing. It also puts the validation for those strings earlier in the build cycle, so you don’t need to run tests against the game to see if they all work.