Modernize the interface without replacing the system of record.

Preserve the Server; Replace the Experience

DelveGlass is an in-progress R&D case study in replacing an aging client experience without replacing the authoritative system behind it. The server remains responsible for gameplay, rules, saves, accounts, and process execution. The client focuses on presentation, input, accessibility, and mobile-native interaction.

The immediate target is WebTiles-compatible Dungeon Crawl Stone Soup servers. The broader pattern is familiar to government modernization: keep the system of record stable, build a clean protocol boundary, and deliver a better interface without rewriting everything underneath.

This is Intelligrit Labs R&D, not customer delivery. The public work shows the protocol adapter, the responsibilities retained by the server, and the client behavior being built around it.

The Constraint

DelveGlass does not bundle Crawl engine code, tile sheets, title art, or generated WebTiles client code. Server messages are treated as game-state data. The native client maps that data to original assets, original UI, and an original renderer.

That boundary matters. It keeps the client additive to the existing ecosystem, avoids pretending to own what it does not own, and makes the technical work cleaner: protocol in, user intent out.

The first client implements a clean WebTiles protocol adapter: connect to a WebSocket endpoint, request the no-compression subprotocol, decode JSON message batches, render state in Godot, and send standard WebTiles commands back to the server.

The state surface is deliberately broad enough for a real client: map, player, menus, messages, targeting, inventory, lobby, new-game prompts, and early movement/action commands.

The product direction is a polished native client. Godot renders Crawl's tiled, grid-authoritative state as a 3D tactical board with native mobile UI around it. A later desktop build can reuse the same renderer, assets, and protocol adapter while adding keyboard-first controls.

Accessibility voice prompts are part of the shared client infrastructure. They are off by default, enabled through options, routed through a prompt service, and designed to either stack behind current speech or overwrite current speech depending on user preference.

Many legacy systems cannot be replaced all at once. The backend is still authoritative. The workflows are still active. The data is still operationally important. But the interface is slow, inaccessible, desktop-only, or built around assumptions that no longer fit the users.

DelveGlass is a small, concrete test of that pattern: identify the protocol boundary, preserve the system that must remain authoritative, build a modern client around it, and keep accessibility in the architecture from the start.

A full rewrite is not always the right first move. A new client can improve daily use while the existing server continues to own rules, records, and process execution.

The customer-relevant proof would be specific: protocol conformance, supported workflows, accessibility behavior, and demonstrated operation against the agreed server interface. Legacy Modernizationexplains the broader replacement path; How to Buy explains assessment and acceptance.

Community Posture

DelveGlass is intended as an unofficial compatible client unless the Crawl team explicitly says otherwise. The project should be additive to the existing ecosystem: operate a reliable public server, support free web users where practical, contribute server fixes upstream when useful, and list community servers only when operators opt in.