Why no audio files?

Files mean downloads, loading screens and a pile of licenses to check. Code sounds are a few lines each and load instantly. The game is small, so this fits.

1. Layer a few oscillators

One oscillator sounds like a beep. Two or three sound like a thing. A coin jingle is two square waves, one high note and then a higher one about 80 ms later. A level-up fanfare is just a quick climb of four notes.

Give every note a tiny volume envelope. Start at zero, ramp up in 5 ms, then drop to zero. Without that you get nasty clicks.

2. Add a noise burst

Swords and hits need noise. Make a short buffer of random numbers and play it once. A sword clang is noise plus a high ringing wave. A crit crunch is a longer, lower noise burst with a quick drop.

3. Filters shape everything

Run the noise through a filter:

• low-pass makes a dull thud (great for boss hits)
• band-pass makes a swish
• high-pass makes a bright clink

Sweeping the filter cutoff down while the sound plays makes it feel like it has weight. We change the clang a bit for each weapon by moving the pitch and the filter, so a dagger sounds different from a big sword.

4. Limit how often a sound can repeat

This one matters a lot. If you click fast, 30 sword clangs can fire at once and it turns into a loud buzz. Give every sound its own repeat limit. Store the time each sound last played and skip it if it was too soon. Quick hits get something like 60 ms. Big sounds like boss horns get much longer.

const last = {};
function play(name, minGap) {
const now = ctx.currentTime;
if (last[name] && now - last[name] < minGap) return;
last[name] = now;
sounds[name]();
}

5. Split music and effects

Make two gain nodes, one for music and one for effects, and send both into a master gain. Then sliders are easy. Players can turn music down and keep the clangs. Rare drops get a little extra volume so the chime cuts through.

Browsers also block audio until the first click or tap. Make the audio context after that first tap, or call resume() on it.

Bonus: the 20 second auto-pick

In the same update we added a "Recommended" bonus. It's highlighted, and if you don't choose in 20 seconds, the game picks it for you. Keep the countdown on the real clock, not on frames, so it still works if the tab lags. Show the seconds left so nobody feels tricked.

Try it

That's the whole trick. Small sounds, layered, filtered, rate limited. If you want to hear it, the free 8-bit browser version of SnowRSPS (Snow317's custom RSPS, online since 2012) is here: https://snowrsps.com/io

Here's how we structured it, at a level any small server can copy.

The hub: one URL that never changes

Everything starts at snowrsps.com/live. It's a single page that links to every place the stream lives:

• Kick: kick.com/snowrsps, the main 24/7 channel ("24/7 CUSTOM GRIND! FREE MYSTERY BOXES")
• Twitch: twitch.tv/snow_rsps
• YouTube: @playsnowrsps, with daily Shorts
• Rumble: rumble.com/c/c-7904496

Why a hub instead of linking platforms directly? Platforms change. Channels get renamed, and a new site becomes popular. Posts and forum signatures that point to /live never go stale. You update one page, not 200 old posts.

The general architecture

Without going into our exact stack, a self-broadcasting server usually has these pieces:

1. A capture source. A game client logged in on a dedicated machine or VM, rendering the world (a busy area, a camera that cycles between locations, or a fixed view).
2. An encoder. Something like OBS or ffmpeg that turns the capture into an RTMP stream.
3. Multi-destination output. Either the encoder pushes to several RTMP endpoints at once, or a relay service fans one stream out to Kick, Twitch, YouTube and Rumble.
4. A watchdog. Streams drop. A script that checks "is the encoder running, and is the ingest accepting?" and restarts it is what makes it 24/7 rather than "mostly on".
5. Short-form clipping. Long streams make poor discovery content, so a daily Short on YouTube gives search and recommendations something bite-sized.

Tying the stream to the game

A stream is only useful if it pulls viewers into the game. Our page does that with a referral prompt right next to the stream links: new players type ::ref SNOW-CYU0 in-game for a starter bonus. Players who want to recruit can generate their own code with ::ref gen (details at snowrsps.com/ref).

Pair that with in-game events that are fun to watch, like global drop events and automated key-opening events that also post to Discord, and the stream has something happening even when nobody is commentating.

Lessons (generic, but hard-earned)

• Pick one canonical link and use it everywhere.
• Expect disconnects. Automate restarts before you automate anything else.
• Check each platform's rules on unattended or 24/7 streams. They differ and they change.
• Don't chase viewer counts. An always-on stream is a storefront window, not a TV show. Its job is to show the world is alive.

If you run a small server and want to try this, start with the hub page. It costs nothing and makes every later change painless.

👉 Watch the 24/7 stream: snowrsps.com/live · Play: snowrsps.com

The starting point

Our desktop client is a classic 317-style Java client: software rasterizer drawing into an AWT canvas, Swing chrome around it, a large cache, and a raw TCP socket to the game server. Players want "play in browser, no download."

The plan: ports, not a wrapper

Instead of trying to run the whole AWT jar in a tab, we're porting the core pieces one at a time and testing each one:

1. Buffers & crypto: the packet stream reader/writer and ISAAC cipher, ported to TypeScript and checked against the Java output.
2. Login: the RSA/ISAAC login handshake, matched to our server's keys.
3. Cache & decompression: reading the existing cache in the browser.
4. Rendering: the client already draws into a CPU pixel buffer, so we blit that buffer into an HTML Canvas2D each frame.
5. Networking: browsers can't open raw TCP, so a small WebSocket (WSS) bridge sits in front of the game port.

Why this order

Each piece can be checked against the desktop client byte-for-byte before moving on. A login that works proves the crypto and packet sizes are right. Our server uses custom packet sizes, so a stock 317 web client would not log in.

What's next

Getting map and model rendering fast enough. If soft-rendering in JS is too slow, we'll look at compiling the Java parts with TeaVM.

Follow along or play the desktop version now: snowrsps.com.