Raylib 15 Game

Showcase
, ,
1

Thank you to @chrboesch, for creating:

It inspired me to create a raylib gui for this game and add additional features.

Play the Game

screenshot000
https://simonlschlee.github.io/zig15game/

qrcode

Wasm

Thank you to everyone in the Zig community that has made wasm/emscripten easier to use, improved Zigs support for it and created examples / projects that compile to wasm.

I especially want to thank @permutationlock for:

This game doesn’t use threads, but this example made wasm and emscripten look a lot less intimidating. Especially the clear and straightforward build.zig.

I looked at these references:

In the future I want to look more into wrapping emscripten as a build dependency.

But while it would be nice to have the emscripten download and install automated, from a practical standpoint, it doesn’t seem absolutely necessary because the resulting wasm files are already portable, so having to generate them manually/locally isn’t that problematic.

This project by @floooh already uses emscripten as a dependency:

It uses emscriptens workflow of downloading and using the prebuilt binaries, it stores those in Zigs cache and then reuses them, it is a bit of a hack, but also useful and a good first step towards something a bit more automated.

I wanted to pull out the code and package it as a emsdk-zig package, however attempting that, I realized that I still have some knowledge gaps concerning the build system and I was wondering what would be the appropriate steps to ziggify emscripten as a zig dependency.

I might revisit that at some later point.

GitHub Pages

For now I found it easier to run the wasm build on my machine and then commit the built version to the pages branch of my repo and use that for the github pages workflow, thank you to @tensorush making it easy for me to figure out my deploy script by looking at:

And specifically liza/src/templates/.github/workflows/cd.yaml at main · tensorush/liza · GitHub here is the modified version: zig15game/.github/workflows/pages.yaml at pages · SimonLSchlee/zig15game · GitHub

Game ideas

I plan to add multiple different board sizes in the future 2, 3, 4, 5 ..., with very big board sizes the current randomization strategy doesn’t scale / fails to provide good results. There are algorithms for calculating whether a random board is solvable based on parity calculations 15 puzzle - Wikipedia, so that in combination with a shuffle might enable better randomization for bigger boards.

However I fear that bigger boards are boring anyway, because it seems like the vast majority of elements can simply be rearranged in an unconstrained manner, until you essentially get back to a 4x4 in the bottom corner again.

The barrier feature I added may add sufficient constraints, to make even these bigger boards interesting, but that is something I still have to play test. Because I still haven’t used bigger boards and barriers at the same time (the bigger boards were in a feature branch I haven’t updated yet).

I thought about adding portals that would allow you to move across further distances, additionally it would allow to move between barrier enclosed regions, I think that could add a lot of potential to make bigger boards both more interesting and less annoying (having to move tiles too far).

It is possible that the parity based solvability checker might not work with certain features, so while adding new features you also have to think about how to generate the initial randomized board.

I think that certain portal configurations might even make every board configuration solvable (just very tedious by having to reorder pieces). All of that are areas for future work / research.

If you have ideas for what could be added to the game, please let me know, but it could take a while before I have time to experiment with the idea and test it out.
(Partially because I want to create other games and have a few other projects I need to finish)

Alternatively you could try adding things yourself. The code is currently relatively minimalist, using math and manual calculations for the layout, that keeps the code relatively compact, but requires some manual effort in calculating offsets and sizes.

11 Likes
2

I’ve never played a variant of this game where there are barriers. That was a lot of fun! Thanks for the small distraction and for sharing so much detail about your process :smile:

2 Likes