From b7aab05a92cdcd71e9b73049a2c33f41785db501 Mon Sep 17 00:00:00 2001 From: Devin Zuczek Date: Tue, 30 Jun 2026 12:33:06 -0400 Subject: [PATCH] Revise README for clarity and updated instructions Updated the 'Why?' section for clarity and added details about the project's architecture and limitations. Revised prerequisites and configuration instructions for better readability. --- README.md | 90 ++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 62 insertions(+), 28 deletions(-) diff --git a/README.md b/README.md index e24160c..deb7bbe 100644 --- a/README.md +++ b/README.md @@ -9,32 +9,39 @@ each as an independent Worker on its own subdomain. > experimentation. It is not affiliated with, endorsed by, or connected to Rec > Room Inc. "Rec Room" is a trademark of its respective owner. -# Why? +## Why? There are already so many multiplayer clones, why? -1. None of them are fully open source -2. None of them run on microservice architecture -3. "Upgrading the server" is not a lasting fix +1. None of them are fully open source (some had leaks of old code). +2. None of them run on microservice architecture, and crash constantly. +3. "Upgrading the server" is not a lasting fix. +4. Exploits were rampant due to bad code. +5. This was fun (sort of). RecFlare uses a true microservice architecture which, if developed correctly, is near infinitely scalable and could support the same number of concurrent users -that the original game had. +as the original game. It will never run out of CPU, memory, or disk space. -Of course, all you need is money for the cloud costs... +Being truly open source means that this project should have more eyes on it, +resulting in bugs getting fixed faster. I hope. + +Of course, cloud services cost money. That's the only limitation. ## Client RecFlare is compatible with the -[CannedNet client](https://github.com/CannedNet/CannedNet) and the build of Rec -Room with manifest `7859140924515540835`. Other client or game versions expect +[CannedNet client](https://github.com/djdevin/CannedNet) and the build of Rec +Room with manifest `7859140924515540835`. Other client or game versions may expect different endpoints and response shapes and are not supported. +See the project page for information on how to mod the game to connect to this server. + ## How it works The Rec Room client discovers every service by fetching an _endpoints document_ from the name-server (`ns`) worker at the apex domain. That document maps each -service to a host like `https://api.`. Every service runs as a +service to a host like `https://match.`. Every service runs as a separate Cloudflare Worker attached to its own subdomain, so the client's traffic fans out across the workers in `apps/`. @@ -47,7 +54,7 @@ completely stateless and no data is stored alongside the microservices. ## Services -These are every RecNet service the client discovers, taken from the +This is a list of every RecNet service the client discovers, taken from the service-discovery map in [`apps/ns/src/endpoints.ts`](apps/ns/src/endpoints.ts). Each is reached at `https://.`. Services with a worker in `apps/` are implemented here; the rest are advertised in the endpoints document @@ -114,6 +121,8 @@ No. The services are plain [Hono](https://hono.dev) apps, so the request-handlin code isn't tied to Cloudflare and can be deployed to other hosting providers — AWS (Lambda), Vercel, Netlify, Fly.io, a plain Node/Bun server, and so on. +**However** + The catch is everything _around_ the code. RecFlare leans on Cloudflare for the deployment and infrastructure layer — custom-domain routing per service, plus the storage bindings (D1, KV, R2, Durable Objects) the workers use. On another @@ -122,13 +131,14 @@ object storage, a pub/sub or WebSocket layer) and wire up the deployment yoursel ## Prerequisites -- node.js v22 or later -- pnpm v10 or later -- bun 1.2 or later +- node (modern) +- pnpm +- bun +- jq - A Cloudflare account with a zone (domain) you control, for deploying -The free plan is good enough for testing (100k requests/day) but the client is -pretty chatty, so frequent testing may exhauast that quota. +Cloudflare's free plan is good enough for testing (100k requests/day) but the +Rec Room client is pretty chatty. Frequent testing may exhauast that quota. See https://developers.cloudflare.com/workers/platform/pricing/#workers @@ -142,32 +152,32 @@ just install **Configure your custom domain:** -For local development, set your base domain in a `.env` file at the repo root; it -is gitignored, so each clone needs its own copy. (For CI you can skip the file and -export `RECFLARE_DOMAIN` directly — see below.) +Create a new .env file: ```bash cp .env.example .env # edit .env and set RECFLARE_DOMAIN to your domain ``` +Or, export it: + +```bash +export RECFLARE_DOMAIN=rec.example.com +``` + `just deploy` resolves the base domain at deploy time and passes it to wrangler — each worker is attached to its custom domain via `--domain .`, and the base domain is injected as the `DOMAIN` var so the `ns` service-discovery document and the api share-link base URL are built at runtime. Nothing in version control is rewritten; committed `wrangler.jsonc` files have no routes. -The domain comes from the `RECFLARE_DOMAIN` environment variable; for local dev -that's loaded from `.env`, and an already-exported value (e.g. a CI secret) takes -precedence over the file. Per-app subdomain overrides come from -`RECFLARE_SUBDOMAINS` (a JSON object, e.g. `{"playersettings":"settings"}`). For -CI, set `RECFLARE_DOMAIN` as a secret and skip `.env` entirely: +Per-app subdomain overrides come from +`RECFLARE_SUBDOMAINS` (a JSON object, e.g. `{"playersettings":"settings"}`). -```bash -RECFLARE_DOMAIN=rec.example.com just deploy -``` +**Run the development microservices:** -**Run the development server:** +@todo This works, but the nameserver document won't use local services. You could still +call each service individually. Each instance of Wrangler runs on a different port number. ```bash just dev @@ -215,7 +225,31 @@ command. Some key ones: For a single worker, scope with -F, e.g. `just deploy -F playersettings`. -## Why a monorepo? +## FAQ + +### What year is this for? + +This works with 2023 clients. It has been tested with manifest 7859140924515540835. Other clients may not work. + +See the "Client" section above for instructions on how to modify a client to connect to this server. + +### Can I run this locally on my PC? + +It's not currently supported. But theoretically, you could. + +See "Run the development server" above. It may be possible later as Wrangler will mock remote services. YMMV for now. + +### Can I use this to make my own server? + +Yes, that's the point. + +### Can I copy this project and modify it? + +Yes, see the (LICENSE)[LICENSE). + +I would love if you contributed your changes back. + +### Why a monorepo? The services share types, auth logic, and tooling, so keeping them in one repo keeps those in sync: `pnpm` workspaces share dependencies, `@repo/` packages