Slow Rush Games logo,
    depicting an apprehensive-looking snail rushing forward

Slow Rush Games

FAQ for

As you read, please bear in mind that:

I last reviewed this page for accuracy on 2025-12-08.

Gameplay

What is the core gameplay loop?

Under construction! The goal is fast-paced action with regular thinking breaks.

Current plan is roguelite(-lite), inspired by Risk of Rain, Crab Champions, etc:

But again, plans can change!

What does "every pixel is individually simulated" mean?

Every pixel of terrain, liquid or gas in each level has its own behaviors and reacts with other neighbouring pixels.

For example, oil will float on water and be set on fire by explosions, burning wood bridges will be destroyed and collapse, snow melts into water which conducts electricity and will be turned into steam by fire, acid eats terrain to create flammable gas - etc.

How does gun customization and ability crafting work?

Not entirely figured out yet! Currently the system is somewhat similar to Noita's wandcrafting, but I plan to overhaul it to make it more flexible and more approachable - ideally without sacrificing depth. My two goals currently are:

Is there an expansive almost-infinite open 2D world?

Not currently! This is a fast-paced multiplayer game so I want players to stay close together for maximum chaos - and smaller separate levels works well for that.

Moving from level to level also helps counterbalance the fact that it's pretty easy to destroy the world :)

Are the levels handcrafted or procedurally generated?

Currently they are handcrafted because that was easy, but I would like to explore procedurally generating them.

Will this have secrets?

You will have to wait and see :)

Will there be support for modding?

Hopefully! Right now there's support for data tables like physics materials, ability stats, etc to be sourced from config files to tweak stats or add new ones, and of course sprites are swappable too.

Scripting is not currently implemented because the combination of "needs to be fast" and "needs determinism for network multiplayer" and "can work on the web" is tricky - the programming languages that support all three of those things are not scripting languages! But, since the final game won't ship on the Web, I may eventually bite the bullet and integrate a scripting language.

Steam Workshop support would be nice but I haven't looked into exactly what it entails yet.

Multiplayer

Can I play solo?

Yes. A core goal is that the game should be fun in singleplayer too.

Is it a co-op or versus game?

Co-op is the primary game-mode. I'm not ruling out a versus sub-mode, but co-op is the primary focus.

Will there be online multiplayer?

Yes, there will be invite-a-friend online multiplayer. This already roughly works today, but needs a lot more polish (Steam integration etc).

Is there couch co-op (local multiplayer)?

Yes, you can play with 1-4 players locally, including a mix of online & local players.

Currently local players need to stay near each other to stay on-screen; I'm considering whether splitscreen of some kind makes sense or not. Voronoi splitscreen might be cool, but no promises.

Will hot-join be supported for multiplayer?

Yes. It's already implemented for local multiplayer, but isn't for online multiplayer just yet.

Will it be possible to play with more than 4 players?

The balancing (and UI design) will be for 1-4 players.

More than that will not be officially supported, though it may be allowed via a config file hack. (I have tested online play with 8 game clients and it requires a powerful CPU but does work. The tricky part is how to render a HUD for 8 players!)

Technical

What engine is this using?

A custom engine written in Rust. I currently use Macroquad for OpenGL graphics, Rapier for rigid body physics, egui for placeholder UI, and a custom fork of GGRS for netcode (which is itself a variant of GGPO).

What's up with this playable web build?

The playable web build I publish in some devlogs is a worse-performing hacked-up version of the latest game build, sometimes with extra special case hacks applied to get specific feedback on. I publish it to get feedback, and to force myself to keep the game playable, but mostly because I can (it's neat that this is possible at all).

The playable web builds are strictly temporary: performance is too poor (no multithreading) and convincing people to pay would be a hassle.

How does the online multiplayer work?

The netcode approach is based on a peer-to-peer deterministic-networking-with-rollback model, which is the same tech as what good-netcode fighting games use. I have written lots about how it works (check out the updates around November 2024) but the simple version is that game clients:

It is extremely low bandwidth, resistant to packet loss, responsive-by-default and nearly entirely prevents multiplayer-specific glitches - in exchange for using more CPU and being tricky to implement.

It is also possible to turn on some input delay to paper over a friend's weaker CPU (or worse connection), though your character will feel less responsive as a result. (I'm planning to experiment with further client-side prediction to mitigate that, but haven't done so yet!)

Is the pixel physics simulation GPU or CPU-based?

Purely CPU-based right now, so a powerful multi-core CPU is desirable, and your graphics card will only be used for graphical effects. Here's why:

Firstly, the rollback-networking multiplayer netcode requires:

Secondly, in online multiplayer, players can move away from each other, which increases the memory requirements as more simulated pixels need to be kept in-memory; older or lower-end graphics cards may not have enough VRAM for that.

Thirdly, since I am currently publishing browser builds, browsers' WebGPU technology is not widely-deployed enough yet for compute shaders to be a feasible option for the playable web build (and even if it were, the browser WebGPU spec does not support a few highly-desirable-for-performance extensions - like atomics).

A rewrite of (or option for) the pixel physics simulation to be GPU-based instead is not 100% out of the question, but it is fairly unlikely at this point.

Will it natively support ultra-widescreen monitors?

I develop on a 3840x1600 (that's 24:10) monitor, so I will aim to (at least) support that resolution.

You will need a powerful graphics card to support lighting at such high resolutions.

Will it support >60hz monitors?

Maybe. The simulation always runs at 60hz because it is tuned for that (and simulation tick rate must be identical for all multiplayer game clients), but support for high refresh rate monitors ought to be possible using interpolation to provide smoother movement. No promises at this point.

About Caspar

Are you really a solo developer?

Yes! "Slow Rush" is just me (Caspar), and I wrote all the code, wrangled the sound, did the original art, made the website, write all the updates here, etc.

However, I have received some government funding and used that to work with an artist who has polished up or redone a lot of my sprite work, hire a composer to make the announcement trailer music and receive some advice from a marketing pro.


You finished the whole damn FAQ?

Wow, kudos.

But if my ideas are that intriguing to you, you may wish to subscribe to my newsletter: