As a new developer i want to be able to create microgame meta data in IDE and not have to learn external tools or schemas.
As a git maintainer I want to ensure that devs are able to independently manage their games microdata without it interfering with git and git history. Common pitfalls include master meta game file, and using git-ignored included files
Moving Game Meta Data:
The solution we landed on was creating a 2 part macro that
Checks if a global datastructure exists, and if not creates it
Adds a struct to this global datastructure
Allows the caller to fill out this struct
Closing macro for any macro side logic that needs to be figured out
This logic is required because we have no guarantee of script execution order on boot. Whoever gets there first needs to create the datastructures
Developers would stick this in their microgames/authorname/ folder in a script inside the IDE which is automatically called on game boot.
All jsons would be removed from included files and recreated in new gml files.
Validating the meta data
It is still desired to have the meta data validated. There is already a rule based validation tool FConfigLoader or some shit. This struct knows how to take a directory, recursively find all json files, read them all, validate all their fields with a set of rules and log any warnings found. Finally this is fed into the global data storage for use in the rest of the app.
This validator will still mostly work, but small adjustments need to be made
Changing the input of the struct. Instead of a directory to search we already will have a list or map or something of all the microdata. File calls removed and functions changed to accept a collection
Some asset validating rules are based around name comparisons and are expecting strings. Some fields such as init_room will now be asset references like n8fl_rm_penguin_blast instead of "n8fl_penguin_blast". These rules will need to be updated.
Finally, this now validated collection needs to be assigned as regular to the global app storage to be used in the rest of the app.
As a new developer i want to be able to create microgame meta data in IDE and not have to learn external tools or schemas.
As a git maintainer I want to ensure that devs are able to independently manage their games microdata without it interfering with git and git history. Common pitfalls include master meta game file, and using git-ignored included files
Moving Game Meta Data:
The solution we landed on was creating a 2 part macro that
Checks if a global datastructure exists, and if not creates it
Adds a struct to this global datastructure
Allows the caller to fill out this struct
Closing macro for any macro side logic that needs to be figured out
This logic is required because we have no guarantee of script execution order on boot. Whoever gets there first needs to create the datastructures
Developers would stick this in their microgames/authorname/ folder in a script inside the IDE which is automatically called on game boot.
As an example:
All jsons would be removed from included files and recreated in new gml files.
Validating the meta data
It is still desired to have the meta data validated. There is already a rule based validation tool FConfigLoader or some shit. This struct knows how to take a directory, recursively find all json files, read them all, validate all their fields with a set of rules and log any warnings found. Finally this is fed into the global data storage for use in the rest of the app.
This validator will still mostly work, but small adjustments need to be made
Changing the input of the struct. Instead of a directory to search we already will have a list or map or something of all the microdata. File calls removed and functions changed to accept a collection
Some asset validating rules are based around name comparisons and are expecting strings. Some fields such as
init_room
will now be asset references liken8fl_rm_penguin_blast
instead of "n8fl_penguin_blast". These rules will need to be updated.Finally, this now validated collection needs to be assigned as regular to the global app storage to be used in the rest of the app.