Lately, I've been thinking a lot about how Foxie's compiler will look. Which language will it be written in? What will it compile to? How will it interface with the game engine itself? Here, we will answer those questions.
First, the game engine.
The game engine itself will be largely pre-built, configurable via scripting in the Foxie langauge. I'm calling it, tentatively, "Lyger" (like a liger, but it's got a "y" in it, so it looks cooler). This engine needs to talk to the compiled output of the Foxie program, somehow.
Let's back up. How will Foxie be compiled in the first place?
I'm using Rust to build the compiler. To paraphrase Hank Hill, now, I know it's an awesome language and it makes you look cool, but it's also safe. Rust prevents a ton of errors, memory access bugs, and generally keeps things nice and tidy when it comes to systems programming. In short, I'd much rather be using Rust to compile to WASM, than C++ (though I do want to learn it soon!).
So: Rust is the language the compiler will be written in. But...since the compiled Foxie code has to interface with Lyger, written in JS, how will the two talk to one another?
There is a tool called
wasm-bindgen, which allows you to pull functions from JS, and export functions and data structures to JS. So, we could conceivably make a package, combining
wasm-bindgen with a power tool called
wasm-pack, which lets you export a package from Rust to a JS-consumable WASM package – how freaking cool is that?!
This only begs the question: what are we compiling Foxie to? Obviously, the result will be a Web Assembly library, given the tools at our disposal. However, we don't yet know how this compiled Foxie code will interface with Lyger, the game engine.
There should also be hooks in the other direction. For example, you should be able to declare a basic data structure for the RPG world (map, spritesheet, etc.) which is parsed by the Lyger engine as a sort of guide for how to configure everything. Again, the API is far from finalized here, but that's the basic concept.
This raises an interesting question: should the compiler be written in Rust, and export pure game engine interface code in WASM? Or should it merely translate the compiler into WASM, and let the compilation happen on the frontend?
The latter possibility raises some interesting implications. For one, it could mean that the compilation process is more interactive. It means I can write a compiler in Rust, translate it to WASM, then allow the user to compile their Foxie code to WASM on the fly – this is obviously the superior approach, to encourage interactive development. Interactive development beats stilted, stunted development 100% of the time.
This approach makes more and more sense to me, but also introduces a fair amount of complication. Rust's WASM integration tools are meant to translate a Rust executable or library into a WASM equivalent. What I'm suggesting here is compiling a compiler...
This is getting too complicated. Let's simplify.
What I want is to define the compiler in Rust. This compiler can live in the world of WASM, and can also generate WASM. It's more complicated, to be sure, but it's what's best for the game creator using these tools.
I've got some thinking (and sleeping) to do, so I'll consider this structure over the coming week...in the meantime, I'll leave you with a classic in indecision: