Fallen London is full of secrets. Full, full, full. You may already have guessed the price that was paid for the city, or the original names of the streets of Spite. If you've got far enough into the game, you may know who the Topsy King used to be, or what the Correspondence is. If you've been paying close attention, you may have some idea why the Masters cover themselves or what the Church does with all those candles. But everything in the game is due a reveal eventually - the real nature of the Bazaar, the source of glim, why death is different. Whether warm amber is actually something unhygienic.

So there's an ocean of backstory, secrets and continuity material. And we add to it all the time, God help us. Here's some of the ways we keep it straight.

Keeping it all inside. One thing I brought away from software development is this: information in documentation is OK, but information is most valuable when it's in the team's heads. So we have as many meetings as is practical with a distributed team, we have a bunch of specific techniques (more below), and above all we work collaboratively.

Final repository of truth. Of course we do need something less volatile than our brains. Another software dev thing - DRY, don't repeat yourself. The actual content database (250,000 words and counting) is the final repository of truth in the game. Where practical, we use that as our reference point. Where content hasn't been implemented yet, we have a deliberately limited number of secondary docs, including...

The view from above. We have one really big Google spreadsheet with more or less every important secret in the game. There's a row for every subject, and the columns run from very shallow to very deep to [REDACTED]. So a shallow secret about the Masters is that they're all only five foot high and wear platform shoes, a medium one is that they're made of balsa wood, a deep one is that their secret motivation is to kick ass and chew bubblegum. And so forth. The advantage of organising it this way is (i) we can scan and remind at a glance (ii) we can make strategic decisions about how much info to release when.

Coloured lights. When any of us adds new content to the secrets birdseye or another doc, we do so highlighted in our own heraldic colour. We may kick it around a bit. Then I come along and black-and-white it if I'm happy, and it's canon. It doesn't allow for fancy version control, but it's a very simple at-a-glance way of handling additions.

Email discipline. Email discussions about ideas and plots easily get bogged down in half-formed ideas and interleaved discussion with too many loose ends. We have a specific protocol we bring out for these occasions: no interleaving, only clear and specific suggesions with no 'perhaps something like...', 'I propose...' as a clear flag for suggestions so people don't feel their ideas are stepped on, that sort of thing.

Three gates. Everything we write gets subbed by another team member to weed out bloopers and typos and game imbalances. We have a set of guidelines and house rules for that, plus the birdseye. It then gets reviewed by me, as a final check on continuity and so I can mess with the prose if I think it needs messing. (When I've written it, the process is a little murkier, but it should always get a sub.) The key thing here is that we don't sub as a hierarchy - anyone can get assigned to sub anything. This has the added, big, advantage that we're constantly keeping abreast of each others' work: which takes us back to the very first point, above.

Any of you folks build or maintain worlds - for fun or professionally - as part of a team? What tools and techniques do you use?