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 flux capacitor will be a key component of the engine. Not really, but wouldn't that be cool?!

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?

A human compiler in action.

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?!

Cooler than the "icy" part of "IcyHot"

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's one simple way we can provide hooks into the game engine: we can give "imports" to the Web Assembly environment, such that the Rust code can call Javascript functions in the environment. So there could be something like, I don't know, a function called startQuest that triggers the beginning of a quest...of course, I haven't thought through the API in full, but that's the basic idea. The point is, you can call Javascript functions from WASM, and therefore, Rust code that uses wasm-bindgen and wasm-pack.

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?

Inquisitive baby is curious what we have in mind here...

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...

Yo dawg, I heard you like compilers so I put a compiler in your compiler so you can compile a compiler while you compile!

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: