For anyone who doesn’t know, Quicksilver is my 2D game framework that targets desktop and web. It is a pure-Rust library that focuses on ergonomics and simplicity.
Quicksilver is part of a small (but growing) set of Rust game engines. Notable are the Amethyst project, an open-source game engine, and ggez, a LOVE-inspired 2D game framework. Increasingly it is practical to build an entire game with only the Rust toolchain: winit provides windowing, a variety of crates allow access to platform graphics APIs, rodio provides sound, rusttype for font rendering, etc. A pure-Rust game framework is getting easier to make all the time.
However, very few libraries support WASM out of the box. This means Quicksilver and Rust WASM games in general essentially have small implementations of windowing, event handling, sounds, graphics, and input for the web that have not been contributed upstream.
The Framework Problem
Opting to use Quicksilver for some feature (web support, API design, automatic batching) requires opting into all of Quicksilver’s features. This isn’t necessarily great! Even with compile-time feature flags available, it’s hard to do any Quicksilver code without buying into the State trait. This boils down to the vision of Quicksilver as a framework: if you can just plug in Quicksilver and start making a game right away, it needs to be everything to everyone.
Largely, Quicksilver’s API is approaching a state of stability. It accomplishes most of what I want it to, in a way I’m largely satisfied with. For end users, the Quicksilver project has been more or less stable for a few months, and no substantial breaking changes are planned for the future.
However, Quicksilver still has quite a few systems implemented by a dependency and an ad-hoc web clone of that dependency. This is what I hope to change, by contributing web backends across the ecosystem. My ideal outcome is that the fundamental multimedia crates (winit, rodio, gilrs, etc.) can run on WASM out-of-the-box.
If it sounds like my current goal is to make Quicksilver obsolete, that wouldn’t be too far off. Quicksilver’s raison d’etre is packaging up a bundle of functionality and to provide a single API for both web and native. Moving the ecosystem to support web and native makes this less important. Parts of Quicksilver that I think are particularly useful will probably become their own crates (re-exported in Quicksilver) to allow their use outside the framework. Some future version of Quicksilver may just be entirely a re-export of various crates and types with a consistent organization.
In essence, I want seamless desktop and WASM development to move from a selling point of developing games in Quicksilver to a selling point of developing games in Rust.