Reflections on Running Bevy Workshops After GPN

2026-06-12

By Caitlin Sar Campbell

Setup

Some time ago, I signed up to run a workshop at GPN24 in 2026.

Before doing so, I had the opportunity to volunteer at the Bevy workshop at RustWeek 2025.

Long story short, I very much liked the "here is a working game; improve it as much as your Rust and Bevy know-how allows" approach the RustWeek workshop took, and created a workshop modeled on the same approach.

While the workshop eventually went swimmingly, thanks to Jade, who volunteered to help as we were randomly talking, there were some differences at GPN that I would take into consideration. These differences aren't necessarily GPN-specific as much as they are specific to non-industry-centric, hacker/maker-centric events.

I wanted to document these here such that future Bevy workshop runners might be able to consider these points in advance.

Hardware Considerations

Situation

I think a major factor to consider when running Bevy workshops at GPN is that there is a lot more diversity in hardware compared to more industry-centric conferences.

While at RustWeek, the majority of the hardware consisted of M3/M4 Macs, several of the latest Framework laptops featuring dedicated GPUs, or other quite powerful modern hardware.

The story was very different at GPN. Here I saw people working on Steam Decks, self-built Cyberdecks, many older laptops, and a few newer machines. Notably, though not strictly related, there wasn't a single MacBook to be seen.

Part of this might be a result of relative socioeconomic diversity at GPN compared to RustWeek, for sure, but a large part of this comes from hacker conference culture in general. Better to have self-expressive, open-source, self-made hardware than not.

As a result, the initial compile times were horrendous, shining a worse light on Rust and Bevy than I would have liked. They ranged from 10 minutes to 40 minutes, depending on the machine, with an average around 20 minutes.

People were literally SSH-ing into remote machines to compile it there, only to find that the debug builds were too big to scp back in a reasonable time.

In the end, though, everyone did get the code running after the initial compile, including one participant who did the initial 40-minute compile twice after reading online that cargo clean could address compile bugs.

This being said, I think we can do better.

Possible Improvements

I have two possible improvements that could help, one of which is uniquely enabled by hacker-centric events.

1 - Bevy Feature Optimization

The workshop I ran just used the default Bevy features without any manual selection at all. I had considered trimming it down, but opted against it because I didn't want users to be confused if they added Bevy ecosystem crates that suddenly didn't work due to said missing features.

Looking back, I should have done this. I could have eliminated many of the image formats, audio formats, system-specific features like Android, custom cursor, zstd, and many more.

Having a slimmed-down build, I suspect, would have made many people happier with the workshop. While this isn't technically an accessibility issue in the strictest sense, it feels that way when you see people not able to work because of older hardware while others get a 10-30 minute "head start".

At the very least, it feels privileged not to try to make things better. Something I can improve on.

2 - Shared Compile Caches

This one is more unique. Hacker-centric conferences, in my experience at least in Europe, allow people to host and run servers on the conference network.

This enables the potential for a locally hosted shared compile cache.

Personally, I use sccache in my own CI/CD pipeline and in my Docker build environment for Steam targets with a locally hosted S3-compatible endpoint.

I think this could be used to speed up the workshop at conferences that allow for local hosting.

The workshop participant could run this single command and start compiling right away, transferring binaries to their machine and bootstrapping themselves past the pain point.

AWS_ACCESS_KEY_ID="ReadOnlyId" \
AWS_SECRET_ACCESS_KEY="ReadOnlyKey" \
SCCACHE_BUCKET="workshop" \
SCCACHE_ENDPOINT="OnLanIpOrDns" \
RUSTC_WRAPPER=sccache \
cargo build

One could pre-populate it with x86_64 and aarch64 artifacts, and people would be on their way MUCH faster.

Software Considerations

Situation

Like with hardware, GPN-like conferences provide a very unique and diverse software environment. No macOS, no Windows, but a ton of Linux. Not just your Ubuntu, Debian, and Fedora either. The workshop featured many Arch and NixOS machines, several Fedora and Debian machines, a Void Linux machine, and a SteamOS machine.

While it was really cool to see Bevy running on such a diverse series of ecosystems, this led to several issues with setting things up to compile properly.

Particularly with NixOS and SteamOS.

Possible Improvements

While this is a hard one to address outside of the existing Bevy Linux-specific guides, I do think there is more to be done.

At the very least, workshops should aim to provide a NixOS flake. It was pretty simple, and Jade ended up distributing it to the NixOS participants.

I do think there is a better general solution though that should at least be considered, this being distrobox.

Distrobox is, in essence, scaffolding around OCI images (think Docker or Podman images) that lets users do things inside of those OCI images. You could distribute the workshop as a small (6 to 60 MB) image hosted on Docker Hub or GHCR.

The workshop participant could get Bevy running in a pre-set-up environment with literally two commands.

distrobox enter --name mybox --image ghcr.io/orgLocation/workshop:eventTag
cargo run

Distrobox works virtually anywhere, including VERY out-there environments like SteamOS or Void Linux and is trivial to install.

Location Considerations

This one was simpler but is still worth considering. If you are organizing a workshop, make sure there are plenty of power outlets. Compiling Rust is a battery killer, and participants can focus more on creativity if they don't have to worry about their 2023 laptop battery dying mid-recompile.

Conclusion

I hope future workshop runners can learn from my thoughts and experiences here. I know I will be changing things quite a bit to make things as nice as I can going forward.

This all being said, no one is entitled to more free labor than a volunteer workshop runner is willing to give. No judgment should be made if people go a different route.