Design: the community platform
Design, 24 October 2026. Stage 1 built; the rest proposed.
Witchspace is meant to be built by the people who love it. In October 2026 the site didn't help them do that: the roadmap was a long block of text in the README, written for people who already knew the project, and already out of date; the Design section showed ten hand-picked documents and missed the most interesting ones; every way to contribute ended at "edit a file and open a pull request"; the ideas board, the designs, the roadmap and the backlog each held part of the picture and never met; and contributors were barely visible.
This design fixes that in four stages.
Principles
- One source of truth. Everything about a feature (what it is, how far along, what help it needs) is written once, beside its design, and every page that shows it is made from that.
- An invitation, not a changelog. Every page answers "what could I do here?" for someone who's never contributed.
- No wall. You shouldn't need GitHub, or code, to design a ship, write a character or report a bug. GitHub stays for those who want it.
- Credit where it's due, visibly, on the site and in the game.
- Close the loop. Ideas you vote for should be seen to move: designed, building, built.
1. One source of truth (built)
Every design document starts with a short header:
---
title: Exploration
status: building # idea, proposed, designed, building or built (or guide)
pillar: explore # trade, fight, explore or build
summary: One or two sentences for the roadmap and the library.
card: cobra-mk3 # the ship on its share card
stages: # optional: a design built in stages
- Stage 1: reasons to go, things to spend on | built
- Stage 2: worlds you can watch change | proposed
help: # what someone could pick up, and the skill it needs
- Write a trail: clues across several systems, with their people | writing
---
From those headers the site makes:
- The roadmap (
/roadmap/): every feature under one of the four things a commander does (Trade, Fight, Explore and Build), with its status, its stages as a row of steps, and how much help it wants. Building first, then designed, proposed, ideas; built last. - The design library (
/design/): every design document, all of them now, with its status. - Help wanted (on
/get-involved/): every task from every design, grouped by skill (ships, writing, art, playtesting, design, code), each linked to its design. - Each design's page shows its status, stages and help wanted above the text.
The README keeps a short summary and points to the roadmap page, so there's nothing to keep in step by hand.
2. Item pages and the ideas board (proposed)
- Each design's page lists the ideas board's suggestions about it (matched by keywords in its header), with their votes, and a button to suggest one with the design's name filled in (as ship pages already do).
- An idea taken into a design is marked so on the board, with a link to the design, and moves with it: planned, building, built.
- Signed-in voters hear when an idea they voted for moves.
3. A ship editor in the browser (building)
The biggest unlock for people who'll never use git. Draw a ship from points and faces (or start from one in the fleet), see it glow in neo-vector, turn it, check it against the rules (size, schema, the homage rules) as you go, give it a name, a maker and a story, and submit it. Submissions wait in a queue; a maintainer turns the good ones into pull requests, crediting the designer. Ships already have every field the editor needs.
Its submit button uses the same submission system as the AI connector (the Build connector plan), so a ship from the editor and a ship from a chat land in one queue. The submission system is built first, on the server; the editor follows on the site.
As built (27 October 2026, /ship-editor/): a ship is parts, and a part is points. The faces come from each part's convex hull (src/site/hull.ts, tested), so the hull is always closed, flat, convex and wound outward, and nobody wires faces by hand. Every ship in the fleet is made this way: mirror-symmetric, one to four convex parts. So any fleet ship comes back exactly as a starting point, panel lines included, and the tests check that for every one. A part is mirrored onto itself (a hull), a mirrored pair (wings, pods) or not mirrored, and a part with all its points in one plane is a plate (a fin).
- Drawing: you drag points in top, side and front blueprints, beside the ship glowing in 3D. You can add points, snap to a grid, undo, and set any point exactly by its coordinates. A point inside the hull is shown grey, since it changes nothing.
- The rest of the file: name, maker, role, description, colour and stats.
- Checks: the server's own checks run as you go (
POST /submissions/check), with its balance notes against the fleet (#236). - Handing in: Hand it in opens Hand in a design with the ship filled in, so there is one queue and one sign-in. The drawing is kept in the browser as you go, and the file can be downloaded.
- Next: drawing panel lines and an insignia, and the class table beside the stats.
4. The writers' room, profiles and credit (proposed)
- The writers' room: forms for the content the game needs most (saloon characters, rumours, trail stories, station descriptions, Legends' logs), each with the tone guide beside it and examples, into the same queue.
- Contributor profiles: who made what, from the credits in content files and the commit history.
- Credit in the game: authors on ship pages and in the game's own credits; a station or a Legend named for the community's most generous contributors; and, at the top of the ladder, running a station (player stations).
- Playtest reports from inside the game: a photo (P) and a note, straight to the queue.
Open questions
- Who looks after the submission queue, and how quickly should a submitter hear back?
- Should submissions be public while they wait (so others can comment), or private until accepted?
Think something here should change? Say so on the ideas board, where others can vote it up, or email hello@witchspace.org.uk. If you code: this page is docs/design/community-platform.md on GitHub, open to pull requests.