Feature: Create a bundler for the gamercade ecosystem

[Cardosaum]

Currently, the developer experience when creating games or contributing to the source code of the project is quite laborious.

For example, to generate a working version of a custom game first one need to open the editor, select the generated wasm for its game, then export it as gcrom.

We could automate this exporting process by creating a bundler that takes the wasm and any relevant assets file and automatically produces a gcrom as output.

An idea of such working bundler could be:

cargo run --bin editor my_game.wasm my_game.gce my_game

Where my_game.wasm is the game code itself, my_game.gce is the assets file and my_game is the gcrom output file.

---

Disclaimer: The original idea was from @RobDavenport, I'm just creating the tracking issue for the feature.

[RobDavenport]

This could be related to #30 and #12 but I'm open to any kind of suggestions here.

I think this could either be added to the editor as optional command line arguments, or possibly as a combination new binary & related crate... like gamercade_bundler tool and gamercade_fs crate or something.

New Crate & Additional CLI Tool

Pros

• it would open up the possibility of importing, bundling, exporting as a separate crate instead of requiring it to be a part of the editor.
• we could then maybe allow some fast, "developer mode" for console which speeds up testing, since the console could now be able to load raw .gce files and raw .wasm, and combine it into a .gcrom in memory temporarily.
• could hook this up to CI/CD to auto-publish new builds of the example projects posted around and keep them up to date, and also let us know if we somehow broke compatability somewhere.

Cons

• need to move around a lot of the logic, types, and code, around from different projects. For example, the editor_data and related types EditorPalette, EditorRom etc.

Overall, I think this is a better approach - what do you think @Cardosaum ?

[RobDavenport]

After our short discussion on Discord, I think the correct steps to do this will be something like follows...

1. Create a new crate, lets say gamercade_fs which is to handle saving/loading from disk. This would need to include both the .gce, and .gcrom files. The code to do this already exists in parts of the editor and console.
2. Modify the console and editor to now use this crate for saving and loading.
3. Create another new crate, lets say gamercade_bunder (or whatever name makes sense), and then just hook it up to use gamercade_fs.

I'm not too picky on the names, and it might be worth it to split this up into two separate PRs, one for steps 1 & 2, and a second one for step 3.

I can definitely help with this issue since there's actually some big changes needed, but not necessarily compelx ones.

[RobDavenport]

Comment from Andre_LA on Discord:

Just read now, I think using CLI args on the editor executable is better (like gamercade_editor bundle -i build/game.wasm -o build/game.gcrom) than making a new application just for that, and maybe this combined with a gamercade_console build/game.wasm --watch command would make it better, however, I generally use the terminal a lot.

For instance, on wasm-4, there is the w4 watch command, with it just saving the code will recompile and re-run the game automatically, which makes the development much more practical.

Finally, I think it's pretty important to not depend on cargo or rust, I actually don't have Rust or Cargo installed (nothing against rust btw :v), and this non-requirement it's a good thing.

[RobDavenport]

These are definitely fair points! I think the end goal here is to not make the bundler application a requirement, but only an alternative. And the first step for that would be to add the saving/loading/exporting logic into it's own library. Then, we can add the saving/loading/exporting logic to whatever other applications we need in the future. The bundler would just be a streamlined one, which could be invoked either by users or by CI/CD instances to keep things up to date.

If we can get the bundler to work using arguments, then it should be easy to add that additional logic to the console later.

I really like the idea of the gamercade_console build/game.wasm --watch. It might need to be adjusted to also include the path to the .gce file so it knows which assets to pull in each time, but alternatively it could actually just load up an already-exported .gcrom for assets, and then just pull in the new .wasm code whenever its ready.

Perhaps the command should look something like this? With an -assets flag and -code flag? We can then read the file extension. Or should another flag exist? like -ae and -ar for editor and rom?

• gamercade_console -assets my_game.gcrom -code my_game.wasm pulls assets from the .gcrom directly
• gamercade_console -assets my_game.gce -code my_game.wasm pulls assets from the .gce and bundles them in-memory