Show HN: A minimal working Rust / SDL2 / WASM browser game | Hacker News Reader

WASM browser game

github.com

82 pointsawwsmm38 comments

"Game" is a stretch, but I put together this repo containing a pure Rust app which uses SDL2 and compiles to WASM (and can be run in a browser). Older resources were a bit out of date and a bit too verbose for my purposes, so here's a minimal working example.

Open articleView on HN

I'm curious why there's so much interest in using Rust for gamedev. It strikes me as the polar opposite of a minimal-friction maximum-iteration-velocity you'd want for something creative like video games. Is it just a product of the general hipness/hype around the language?

Jon Blow (Braid, The Witness) on rust for games: https://www.youtube.com/watch?v=SodXi2t1mtE

IMO Kyren (the game dev who created a large portion of the Starbound game) covers this well in her Rust 2018 keynote. https://kyren.github.io/2018/09/14/rustconf-talk.html

She is of the opinion Rust is well suited to game dev, and ECS is an excellent choice for a game design. She works off an example from the Starbound code.

Her thesis.

"Rust, by design, makes certain programming patterns more painful than others. This is a GOOD thing! It turns out that, for game development, the patterns that end up being the easiest to deal with in Rust closely mirror the patterns that are easiest for game development in any language.

I unfortunately had to learn this the HARD way!

Rust highly rewards data-oriented design with simple, understandable ownership semantics, and this is great news because this is a really good fit for game development. I suspect this is also true generally, not just for game development! (but what do I know?)"

Unfortunately that story didn't end like one might have hoped, the developer of Starbound did begin their next project using Rust but ended up pivoting back to a conventional C++ stack mid-development. IIRC it was down to a mix of difficulty hiring programmers with relevent experience, an immature ecosystem, and possibly one of the console vendors objecting to using a compiler they haven't certified.

Well... she's not working for Chucklefish anymore, so could also be related to that since she was the lead developer? But I'm not at all familiar with what happened. ... and, well, that was written 6 years ago...

Maybe? I don't think they've done a detailed post-mortem on what happened, it's just fragments of information without a clear timeline.

Embark Studios were the other big player promoting Rust for gamedev and they're still at it, but mostly for tooling and backend infrastructure. Their first game release, The Finals, is plain old C++ on the client side.

ECS can be implemented in any language, it's orthogonal to my comment re: why Rust for gamedev? ECS is such an obvious concept, it's akin to file descriptors and PIDs on *NIX; an indirection table for handles, :slowclap:. There's nothing Rust-unique about it.

The amount of hype I see surrounding ECS like it's some kind of groundbreaking amazing thing, often muddled into "Rust for gamedev" conversations, causes me to question everything said in such pro-Rust discussions.

Blow actually responded to the keynote you linked [0].

What's still unclear to me is what's the advantage that Rust is bringing to the table? Is game development velocity higher than in C++/C/C#? The ecosystem is obviously less mature, and the borrow-checker is an obvious source of friction... How do we separate the hype from the facts?

[0] https://www.youtube.com/watch?v=4t1K66dMhWk&t=1650s

What successful games have been written in Rust?

Well, as she notes in the keynote. "Obviously the advice I give is not as applicable if you decide to use something like Unity or Unreal, which if you do and that’s great and you’re happy, then I’m not trying to convince you to leave that. Obviously if you use one of those, Rust is probably out of the question except for very very peripheral things, but honestly I still think eventually Rust WILL find its way into these sorts commercial mainstream game engine products, it’s just a matter of time. For the moment though, the most likely people to use Rust and find this talk useful are other start-from-scratch indie types, and maybe a few AAA studios that make a lot of their own technology in house (Ready at Dawn!, EA SEED!). "

And yeah, there's a fair # of indie games that have already been written in rust. But if you use the criteria of "successful" (high sales?) that excludes the vast majority of indie games. So getting one of those to a high level of visibility may take a while.

https://itch.io/games/made-with-rust

Random reddit thread claims https://store.steampowered.com/app/808160/UniverCity/ was written in rust. But, yeah, there's the other problem, I doubt anyone is digging around in function signatures on a systematic basis to identify these.

Personally I feel one of the better rust games out there is Veloren, but given it's FOSS, making a ton of $$ is never going to be on their success benchmarks. https://veloren.net/ The veloren folks have been on HN frontpage a few times and attribute some of the successes of their engine to rust.

Not sure why commercial success would influence your choice for a tech stack. A game's commercial success depends entirely on how entertaining it is to users and whether it has a monetizable distribution. It would be better to ask what are some high quality, high complexity games that were built in Rust.

Can you provide objective criteria for "successful"? Without that, any responses could easily be no-true-Scotsman'd.

For a lot of the same reasons people use C++, but I’d argue rust is more approachable.

C++ is definitely more approachable than Rust.

Having programmed in both for years, I respectfully disagree.

Because C++ is a total pain. You want systems performance, but it should never segfault or memleak. Rust fits perfectly into this problem space.

I can't tell you how many times I've had Unreal Engine segfault on me and how much time that's wasted.

Bevy is a fantastic game engine, and with enough velocity, it'll start looking like Godot.

"hipness/hype" is a pretty rude assumption. There are lots of people enthusiastic about the language for the simple reason that they like it better than the alternatives and it solves real problems. It might not be for everyone and that's fine.

I was confused about where/how SDL gets recompiled for WASM, but it looks like Emscripten specifically has built-in support for SDL and a handful of other libraries. That's cool.

Other C dependencies could probably be managed with vcpkg.

If you don't want the portability, you can also write basic drawing code in JS, eg. WebGL, Canvas, WebGPU, whatever other API. Then, you can expose some basic functions to your WASM interface. It's more flexible but not much more complicated if you already are comfortable with JS.

SDL API is used to interface with HTML5 canvas operations so that SDL doesn't need to be compiled: the entire SDL API is literally a primitive in your browser.

That is not true, SDL2 port is written in C and it has to be compiled.

Here's where it's built

https://github.com/emscripten-core/emscripten/blob/main/tool...

Half true. Emscripten implements (much of) the SDL 1.2 (and also SDL_mixer 1.2) API in Javascript here: https://github.com/emscripten-core/emscripten/blob/main/src/.... On the other hand SDL 2 (and SDL_mixer 2) are proper ports (which you linked to).

So there's quite a size penalty to using SDL 2 rather than SDL 1.2, but the reimplemented SDL[_mixer] 1.2 is incomplete and differs from official.

Appreciate the example! I've played around with game dev in JS before, how does this compare?

I'm only just beginning to scratch the surface with gamedev in Rust, but JS and Rust are quite different languages. Rust is compiled, with strong typing. But once you get the mechanics of compiling to WASM figured out (as I have in this repo), it's pretty pleasant to work with.

Having reluctantly hacked up an emulator in Javascript, it was always very fragile. I'm very motivated to reimplement it in Rust and your framework looks like it has almost everything I need. The only thing missing is persistent state (eg. Web Storage API and import/export).

I'm planning on learning Rust and experimenting with game dev so this might help me. Thx.

https://github.com/MeoMix/symbiants Here's my open source game written in Rust and compiled to WASM if you want more reading material :) It uses Bevy not SDL2, though.

Check out Bevy. https://bevyengine.org/ It has the best ECS design I've ever seen for a game engine. Super fun to use. Currently no editor and you need to wrap your head around ECS, but it will definitely push you to improve your rust skills.

Edit: Also it can be compiled for WASM.

I have been having a blast learning macroquad and Rust at the same time by making games. Also compiles to wasm, android, and iOS.

Nice! I literally yesterday started writing wasm support for a Rust project of mine, so this is very topical to me :) I got a hacky PoC running but it definitely needs some design work…

Ebiten (Go package) compiles for all OSes, Switch and web via Wasm as well. The binaries are little fat but it's really nice :)

This is nice. I tried to set up something similar using wasm-pack and npm but the whole thing was kind of a mess. Though I heard the emscripten backend is deprecated/unsupported/WIP? Anyone know if that's still the case?

The Rust Emscripten backend has been on life support for years, all focus has shifted over to the wasm32-unknown-unknown target and associated tooling like wasm-bindgen for generating the JavaScript glue code. I think the only reason you might still want to use the Emscripten backend is if you must link a C or C++ library into your Rust project and compile it to WebAssembly, the newer backend works best with pure-Rust projects.

Does this mean that it would have been better to base hello-rust-sdl2-wasm on wasm32-unknown-unknown target (assuming this is possible)?

EDIT: trying to answer this myself got me down this rathole: https://users.rust-lang.org/t/fixing-rusts-webassembly-targe... and https://github.com/rust-lang/rust/issues/83788

I did find older alternative solutions that uses wasm32-unknown-emscripten, like https://github.com/tanis2000/rust-sdl2-wasm but it's not obvious to me that this is a better solution.

TL;DR: it's currently a mess

Ideally you wouldn't use SDL at all, you would use equivalent native Rust libraries like winit for windowing and wgpu for graphics, which all work with wasm32-unknown-unknown.

It has been a huge pain trying to get SDL2 to play nicely with Android / iOS. Would winit / wgpu make this easier?

Sure. Any suggestions? (I don’t need much, just kbd input and pixel graphics out)

https://github.com/rust-windowing/softbuffer

That gives you a simple software framebuffer, and it builds as a native app or for the web. You'd set up a window (or web canvas) using winit, then pass that to softbuffer so it can render to it.

https://trunkrs.dev

I think Trunk is the most streamlined way of building for the web at the moment, superseding wasm-pack.

A minimal C++ / Windows thing like this would've been right up my alley :)

https://emscripten.org/docs/getting_started/Tutorial.html

Reply on news.ycombinator.com