max bittkerandClaude Fable 5 2fa65b8342 feat(sdk): player-to-player trade API
Three layers over the game's request/offer/accept/confirm trade flow:

Layer 0 - state and primitives. StateCollector publishes a `trade` slice
(screen, partner, both offers, both accept flags) read from the
trademain/tradeconfirm interfaces; accept flags come from the server-set
status text, the only place the game reports them. Sends reuse existing
packets: request is interactPlayer op 4 (requesting someone who already
requested you IS the accept), offers are INV_BUTTON with automatic
Offer-X count-dialog handling, accept is IF_BUTTON, decline is
close-modal. waitForTradeRequest surfaces chat type 4, which the default
chat readers filter out.

Layer 1 - bot.trade(target, {give, want, accept}). Opens the session,
offers, holds accept until the partner's offer satisfies the policy, and
re-verifies on the confirm screen before the irreversible second accept.
Offer changes reset both accepts server-side, so the confirm screen's
offers are final - re-checking there makes offer-switching unable to slip
past. Reports the observed inventory delta rather than assuming.

Layer 2 - bot.serveTrades(policy). The receiving half of a muling setup,
as an explicit loop that owns the bot rather than a background hook.

Two engine behaviours the porcelain has to work around, both found by
running it against two live bots:

- Accepts are gated on tick advancement. Every executed action publishes
  a snapshot with an unchanged tick, so a retry loop waiting on "any
  state change" spins at full speed, exhausts the engine's per-tick
  packet budget, and backlogs that client's own update stream by minutes
  while the trade advances server-side.

- "Trade closed" needs two ticks of confirmation. openMainModal writes an
  IfClose for the side modal before the IfOpenMain of the confirm screen,
  so a single closed-looking snapshot mid-trade is the offer->confirm
  transition, not a decline.

Verified end to end against a local server with two lite clients: gift,
mutual exchange with both sides enforcing `want`, and an unmet-want
decline. Adds 15 unit tests covering the pure helpers and the porcelain
flows including the confirm-screen re-verification.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-09 23:06:19 -04:00
2026-02-08 02:13:46 -05:00
2026-03-18 16:49:20 -04:00
2026-02-04 10:50:42 -05:00
2026-07-26 15:16:37 -04:00
2026-07-26 15:16:37 -04:00
2026-08-09 23:06:19 -04:00
2026-03-10 12:25:53 -04:00
2026-01-28 19:36:15 -05:00
2025-05-08 16:21:39 -04:00
2026-03-10 12:25:53 -04:00

RS-SDK

Research-oriented starter kit for runescape-style bots, including a typescript sdk, agent documentation and bindings, and a server emulator. Works out of the box - tell it what to automate!

RS-SDK Demo

Discord Hiscores

Build and operate bots within a complex economic role-playing MMO. You can automate the game, level an account to all 99s, and experiment with agentic development techniques within a safe, bot-only setting.

The goals of this project are to provide a rich testing environment for goal-directed program synthesis techniques (Ralph loops, etc), and to facilitate research into collaboration and competition between agents.

Task Length Distribution

There is currently a leaderboard for bots running on the demo server, with rankings based on highest total level per lowest account playtime.

See the benchmark comparing models for evaluation results across different LLMs.

Note

RS-SDK is a fork of the LostCity engine/client, an amazing project without which rs-sdk would not be possible. Find their code here or read their history and ethos

Getting Started:

git clone https://github.com/MaxBittker/rs-sdk.git

Out of the box, you can connect to the provided demo server, choose a name that is not already taken!

With claude code:

bun install
claude "start a new bot with name: {username}"

Manually:

bun install
bun bots/create-bot.ts {username}
bun bots/{username}/script.ts 

Agent API and knowledge

The exact generated API surface is documented in sdk/API.md. High-level bot.* methods attempt to observe method-specific game effects; low-level sdk.send* methods confirm browser-client dispatch and do not prove the server applied the effect.

MCP execute_code snippets receive bot and sdk globals. Standalone files under bots/<name>/ instead use runScript(async ({ bot, sdk }) => { ... }); see learnings/README.md for copyable examples. The current executor evaluates JavaScript-compatible async bodies directly, so use the TypeScript API reference for type information but omit type-only syntax from an execute_code body.

Chat is shown by default. Note that seeing other players' chat exposes the bot to scamming and prompt-injection attempts; opt out with SHOW_CHAT=false in the bot.env file (or bun bots/create-bot.ts <name> --no-chat).

Warning: The demo server is offered as a convenience, and we do not guarantee uptime or data persistence. Hold your accounts lightly, and consider hosting your own server instance. Please do not manually play on the demo server.

Gameplay Modifications

This server has a few modifications from the original game to make development and bot testing easier:

  • Faster leveling - The XP curve is accelerated and less steep.
  • Infinite run energy - Players never run out of energy
  • No random events - Anti-botting random events are disabled

Architecture:

rs-sdk runs against an enhanced web-based client (botclient) which connects to the LostCity 2004scape server emulator.

There is a gateway server which accepts connections from botclient and SDK instances, and forwards messages between them based on username. Once connected to the gateway, the botclient relays game state to the SDK and dispatches low-level actions such as sendWalk(x, z) from the SDK. Dispatch success is not confirmation that the game server applied the intended effect.

This means that the SDK can't talk directly to the game server, but must go through the botclient. It will attempt to launch the botclient on startup if one is not already running.

You don't need to run the gateway/botclient in order to run automations against the demo server, but you may choose to if you are fixing bugs or adding features to the rs-sdk project

Running the server locally

Running the server locally has many advantages, primary being the ability to set a high tickrate.

You can set tickrate in server/engine/.env via the NODE_TICKRATE variable (default is 400ms, try 200ms or 30ms for faster gameplay, especially useful for headless testing). You can also change it at runtime with the in-game ::speed <ms> command (minimum 20ms, doesn't persist across restarts).

The chat profanity filter can be disabled with NODE_PROFANITY_FILTER=false (default on). The server censors chat before broadcasting and injects the setting into the browser client; headless lite runners have no config channel from the server, so also set PROFANITY_FILTER=false in the bot's bot.env (or process env) to stop their local re-censoring.

You want all three of these running:

# Game engine
cd server/engine && bun run start
# Web client bundler
cd server/webclient && bun run watch
# Gateway (bridges SDK <-> bot client)
cd server/gateway && bun run gateway

The gateway listens on ws://localhost:7780 by default (configurable via AGENT_PORT env var).

Development checks

Install the root and webclient dependencies, then run the same checks as CI:

bun install --frozen-lockfile
(cd server/webclient && bun install --frozen-lockfile)
bun run check

bun run docs:api regenerates the API reference. CI fails when that document does not match the public TypeScript class surface.

2. Connect a bot to the local gateway

The SERVER variable in bot.env controls where the bot connects. To use your local gateway, leave SERVER blank:

BOT_USERNAME=mybot
PASSWORD=test
SERVER=
SHOW_CHAT=true

When SERVER is empty, all connection paths (scripts, CLI) default to ws://localhost:7780.

When SERVER is set to a hostname (e.g. rs-sdk-demo.fly.dev), they connect to wss://{SERVER}/gateway instead.

Disclaimer

This is a free, open-source, community-run project.

The goal is strictly education and scientific research.

LostCity Server was written from scratch after many hours of research and peer review. Everything you see is completely and transparently open source.

We have not been endorsed by, authorized by, or officially communicated with Jagex Ltd. on our efforts here.

You cannot play Old School RuneScape here, buy RuneScape gold, or access any of the official game's services! Bots developed here will not work on the official game servers.

License

This project is licensed under the MIT License. See the LICENSE file for details.

S
Description
No description provided
Readme MIT
98 MiB
0 Stars 1 Watchers 0 Forks
Languages
Oberon 49.3%
TypeScript 49.2%
EJS 0.6%
HTML 0.5%
JavaScript 0.3%