Loading Levels

This week, I added support for loading levels on the web build.

So now you can try out some basic levels!

To load a level, just click the Load button in the top left, and choose the level:

Selecting a level using the mouse.

I use this interface a fair bit so I also made it so you can type to select a level:

Selecting a level using the keyboard to type its name.

To be honest, these "levels" are more just scenes I use to test mechanics.

Proper levels - which might even have fancy things like a win condition - are still coming!

A Shaving of Yaks

I already had level-saving and -loading working on the desktop build of the game 6 weeks ago, so surely making it work on the web would be straightforward?

It was not so straightforward. (credit: sketchplanations.com)

A non-exhaustive list of yaks:

Level data is quite large (several MB per level). I had compressed them using zstandard originally¹, but I couldn't get the software library that decompresses them to work on the web build.²
The web build can't read the level files from the filesystem because it's running in your browser.
I needed some kind of user interface for picking levels. I had built one using the filesystem, but of course that wasn't going to work.
I want to be able to "hot reload" levels (change them outside the game, and be able to load them into the game) on the desktop build.

After a lot of fiddling, I ended up with a solution where on desktop files will be read from the filesystem (& support hot reloading - even if the files are zip-compressed), and on web they'll be read from a zip file which is loaded over the internet.

Phew, maybe I should have picked an established game engine after all. ³

The Larger Yak

Originally I was planning to design levels in-game: that makes levels easy to preview and play-test.

Right now, that approach works, but, well, let's try to draw a square:

Tediously drawing a neat square. You don't have to watch it all.

I could make it less fiddly, but I'll also need to be able to place markers like "spawn an enemy here" and "player spawns here".

So maybe integrating the LDTK tiled-based level editor would be better? It supports both drawing squares (gasp!) and placing markers:

A demo video of LDTK, from their website.

But I haven't tried integrating LDTK yet - maybe next week.

Playable web build‎

Now the default level is the more interesting "demo" level:

Click to focus, then play with keyboard and mouse. No mobile support! Give feedback.

Use the Load button on the top left to load new levels.
You can't save your own levels (on the web build⁴), sorry.

I had compressed the levels with zstandard originally because I didn't want to make my source control repository (which keeps backups of my game) too big.

The Rust zstd library wraps the official C implementation. It's straightforward to compile C for the web using emscripten and Rust has official support for it, but everyone is moving away from that to using the Rust compiler's support for compiling to Web Assembly ("wasm") instead - and that's what my game framework (macroquad) uses. You can't (as far as I can tell) compile one library to emscripten and another to wasm - you have to pick. So I stuck with wasm. It sure would be nice if someone would make a pure Rust zstd encoder and decoder!

This type of "assets handling" yak shaving is exactly the sort of thing a good game engine solves for you, so this week I was definitely feeling regret. I did find the assets_manager library for Rust, which got me part of the way there; I had to extend it to support switching between two sources of assets (filesystem or remotely loaded zip) and to support transparently decompressing zip files.

⁴

Saving is implemented on desktop of course, so it would be possible to support saving on the web if people care about it - let me know. Though... it would be quite fiddly, and I might have to break the save format every so often.