Repository navigation
Roadmap
[Import database config] 🔴 High
Create a file format which can be loaded to apply all customizations, such as schema, plugins, etc. Will probably be a .zip file with a .json config and desired plugins/resources embedded.
[Plugins in the browser] 🔴 High
This will probably be best accomplished with the above "Import database config" change.
[New export format] 🟠 Medium
Optionally export the database as a .zip containing the .cdb json and all dependent resource files.
[Plugin version compatibility] 🟠 Medium
Define which versions of the app a plugin can work with.
[New plugin format] 🟠 Medium
Create a .zip file format for plugins so that they can embed resources.
[SQL query engine expansion] 🟠 Medium
Right now it is sort of perfunctory, it needs to be made more robust. Though this will probably be dependent on the database engine refactoring.
[Level editor - Redesign Level/Layer Options] 🟠 Medium
Not sure why there is an options.tileSize and a layer.tileSize when you can only place tiles on the options.tileSize grid? Not necessarily opposed to the idea of each layer being able to define its own grid size, but it does seem like a nightmare from an implementation standpoint in the level editor and when being consumed in the final application. All in all, the current state is confusing and needs to be more clear and focused. Will need to investigate.
[Level editor - Toolbar] 🟠 Medium
[More comprehensive unit tests] 🟢 Low
[Massive project refactor] 🟢 Low
[REMOVE data types?] 🟢 Low
It seems like many of the column types in the spreadsheet GUI are superfluous, unnecessary, or just should not be displayed to the user as column options.
[Robust plugin APIs] 🟢 Low
Need to investigate the best ways to expose/gatekeep necessary APIs to plugins.
[Level editor - Shortcut reminder panel] 🟢 Low
[Level editor - Mouse cursor changes for delete/select/move modes] 🟢 Low
[Hard-separate database engine from GUI] 🔴 High
[Main/Model merging] 🟠 Medium
No real reason to have this separation. Implementation differences can be dependency injected.
[Decomposition of god classes (Main.hx, Level.hx, etc)] 🟠 Medium
This will be very nasty work.
[Database.hx and Sheet.hx] 🟠 Medium
These classes are a mess; they will need to be significantly reimagined or outright removed. Ideally, these provide an abstracted access to the underlying data and handle save operations, but right now they do a bunch of weird random stuff and introduce a lot of data syncing issues because they cache multiple versions of the source data.
The spreadsheet GUI seems pretty stable, so the existing smoke tests should be fine for that scope.
[Level editor - Multi-layer operations] 🔴 High
[Level editor - Palette control operations] 🔴 High
[Internal systems - SQL engine] 🟠 Medium
This will probably be dependent on the database engine refactor.
[Internal systems - Code generation] 🟠 Medium
[Level editor - Objects] 🟠 Medium
[Internal systems - Schema generation] 🟢 Low
[Internal systems - Custom types] 🟢 Low