Skip to main content

Building a browser client for a 317 Java game (work in progress)

Updated 2 min readMarkdown

I run SnowRSPS, a free custom 317 server online since 2012. This is a devlog, not a launch post: the browser client is still being built.

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.

About the author

  • Owner/dev of SnowRSPS, a custom 317 Java game server online since 2012, and Snow317.io (snowrsps.com/io).

No comments yet. Be the first to comment.