Daorklis

Vision

Daorklis rebuilds the Silkroad Online server so that the real 1.091 client cannot tell it apart from the original. The reference client itself is always the ground truth: outside sources on opcodes or behaviour only count once they have been checked against it. Anything not yet proven carries an EXP marker in the code, so assumptions stay visible.

Alongside it runs a client of our own on our engine. All content lives in a single source. From it we generate the server data, the engine client, the PK2 files for the original client and, on request, the reference data of the original server. Everything is edited visually in the studio.

Three tracks, one after the other

Original values are always the default. Every deviation in the configuration is marked “changed, original: X” right next to it and can be reset.

The big picture

Everything is built centrally on a build server. The game server runs in its own container, and both share the working data. Development happens from a laptop over a VPN.

• Build server: builds server and engine, hosts the editor service for web editor and studio, and an isolated sandbox for analysing the original binaries.
• Game server container: login, coordinator, realm and the database. The build server builds them and restarts them there.
• Update server: distributes signed packages of studio and client. The launcher only fetches files that changed.
• Original server stack: the reference. A capture proxy records traffic between original client and original server.
• Backups: database daily, assets weekly, code in Git hosting.

Our own client

The Daorklis client runs on our engine and loads the original worlds, models, effects and interface. It looks like Silkroad, but every pixel and every rule is ours to change. These images come straight from the client, rendered from the real world and model packs.

What our own client makes possible

The original client stays fully supported for faithfulness. The engine client is where Daorklis can grow beyond 1.091.

One content source

Instead of maintaining content in several formats, there is one source in a readable text form (RON). The crate dk-content knows the types, and the tool dkc imports, validates and exports. Every file has exactly one canonical spelling, so changes stay small and traceable in Git.

Every kind of data has two ID ranges: original up to 99 999, Daorklis from 1 000 000. Nothing is ever deleted by renumbering, only by leaving a tombstone, so old references never point at something else.

Server

Three services, connected only through the account database. Each can be restarted on its own without players in the world noticing. Only the realm saves everyone first.

The crates marked green are shared between server and engine client. The game core dk-game knows nothing about network, database or clock, and a boundary test keeps it that way. The server code is about 204 000 lines of Rust.

• Run modes: with or without GUI, debug or release, in a terminal or as a background service. Stopping is always clean.
• Configuration: one TOML file per area. Original values are the default; most settings reload live from the GM window.
• Honest assumptions: EXP markers for unproven knowledge, TODO markers for open work, both in generated registers. When an unproven path runs, the server logs it once.

Numbers

Both servers were measured on the same physical machine, a 16-core Threadripper. Ours ran in a container with 10 vCPU and 16 GB, release build, with bots from a separate machine. The original ran in a Windows VM with 8 vCPU.

Load, measured

All players stand in one spot, the worst case: everyone sees everyone, so traffic grows with the square of the player count.

A login storm of 500 accounts at once puts 482 players into the world within about 5 seconds. The limit there is the deliberately slow password hash, about 35 ms per check per core.

How many players on which machine

An estimate, not a measurement: we have measured up to 500. It assumes players spread across the world like on a real server, about 0.3 % of a core each plus headroom for crowded towns and fights, and the database on the same machine.

Logins scale with cores too: a big login storm takes longer on fewer cores, but players already in the world are not slowed down by it.

Networking

The server speaks two languages. The original 1.091 client uses the old Silkroad protocol over TCP. The engine client uses a modern, encrypted channel over QUIC. Both end up in the same game world.

The legacy frame

Every packet starts with a six-byte header, all little-endian. If the top bit of the size is set, the rest is encrypted with Blowfish and padded to 8 bytes.

Counter and checksum protect every client packet. If either is wrong, the server disconnects immediately.

From launch into the world

sequenceDiagram
    autonumber
    participant C as Original client
    participant G as dk-login (gateway)
    participant R as dk-realm (agent and world)
    C->>G: 0x5000 handshake (Blowfish, key exchange)
    C->>G: 0x2001 module id SR_Client
    C->>G: 0x6100 version check
    G-->>C: 0xA100 ok or patch list
    C->>G: 0x6101 shard list
    G-->>C: 0xA101 shards
    C->>G: 0x6102 login
    G-->>C: 0xA102 token and agent target
    C->>R: 0x5000 handshake, 0x2001
    C->>R: 0x6103 token
    R-->>C: 0xA103 accepted
    C->>R: 0x7007 character list
    R-->>C: 0xB007 characters
    C->>R: 0x7001 select character
    R-->>C: 0xB001, then 0x3013 character data
  

All 378 known opcodes are defined in one place, in description files. The code is generated from them, and a test checks them against real captures.

The modern channel

Client kinds

Fixes and improvements

Along the way we found bugs in the original and holes in our own first versions. Original behaviour stays the default wherever players could notice, and every deliberate fix is switchable.

Bugs of the original we fixed

Security

• Passwords: argon2id instead of MD5. Old accounts are upgraded on their next login. Unknown account names take the same time as real ones, so nobody can probe for accounts.
• Dupes and exploits closed: trade, stall in both directions, pet dupe via relog, storage exploit, gold overflow, gold limits in the core.
• Traffic limits: packet rate limits like the original agent, stricter at login, packets before login dropped.
• Login protection: lockout after failed attempts, GM address list, optional per-address limit, a queue that answers “server busy” instead of falling over.
• Server binaries: tamper detection for debuggers and injection.

Performance and operations

• Location index and visibility cells instead of scanning every session: walk response p95 when spread out dropped from 22.5 to 6.3 ms.
• Saving only what changed: rows written per save cycle fell from 63 907 to 1 817, lost saves fell to zero.
• Send queue by bytes that merges movements; cost per packet at 500 players down from 22 to 17.6 µs.
• Single-service restarts: login, coordinator or realm restart alone; the realm saves everyone in about 7 seconds.
• Audit log partitioned by day and searchable, live config reload, patch publishing without breaking running downloads, daily off-site backups.

The engine

claudeengine is our own game engine in Rust, about 279 000 lines in 27 crates. Its first user is not a human but an agent: every feature can be checked as an image or a test without starting a game, and every system has its own documentation.

Under the hood

Studio

The studio is the one place to build Daorklis. It opens the client and the server as one solution, edits every kind of content visually and plays it live.

• Solution: client project and server code side by side; server files are edited and saved directly on the build server.
• Content editors: quests as a graph, items, monsters, shops and item mall, spawn nests and regions on the map, camera flights, effects.
• Scenes live: login, character select and the world, with Play against a development realm.
• Build and release: build and restart server services with one click, a release panel exports the server data, the client package and the PK2 patch.

Decompile work

To match the original exactly, we take it apart. Every original binary is analysed statically in an offline sandbox with Ghidra; nothing from it is ever executed there. Live behaviour comes from read-only probes, clientless bots and captures against the original stack.

Results never go into the server directly. Each finding is written as a handover; the server side implements it, removes the matching EXP marker and records the commit. The goal is a complete specification from which the server could be built from scratch.

Our tools

Most of what Daorklis needs did not exist, so we built it.

Our web tools

Three browser tools carry a lot of the daily work. They run next to the server and need nothing installed.

Documentation site

A static website generated from our reverse-engineering notes and the maintained reference data. We use it to look up an opcode, a protocol phase or a game system rule without digging through files. It covers the original server's startup and login protocol, all 378 opcodes with field layout, evidence and maturity per field, and 37 system specifications such as combat formulas, skills and quests, all searchable.

Asset viewer

A browser tool that reads the original client data directly: models, textures, effects and map files. We use it to check assets visually before and after converting them for our own client. It renders whole towns with terrain and buildings, plays skinned models with their animations and browses every raw file.

Server dashboard

The web front of our coordinator service, which keeps the list of running game realms. It shows realm health, uptime, live monster and player counts and the loaded game data tables. Further tabs show spawns, skills, drops, shops, quests and AI state, so the server's data and world can be checked at a glance.

Plan

Decisions