1879: Bit of a Ramble about Byrons
So I was working on some notes for Personalities 02: You May Hiss The Villain, and sketching out some details about an elusive Byron that’s known from the dossier the organization hunting them has compiled. It’s not known if the person behind the handle is a man, a woman, a team, something else entirely, nobody knows. I got to thinking about how le Carre’s Law would apply here, as if the Byron is really good at their job, they’re going to be bloody hard to compile any sort of data around. They’re not going to leave traces. They know how to wipe logs, corrupt data stores, do all the necessary work to cover their tracks.
I also was thinking a bit about how the Byron was designed, and how the mechanics came about, and figured on nattering a bit about design philosophy here. Someone might find it interesting. We started with the basic idea, that we wanted a decker, and the naming was just too painfully obvious, we couldn’t snub Lady Ada in a steampunk game, so the white hats became Lovelaces and the black hats became Byrons, although the definitions there are a bit capitalist and classist – deliberately so, it’s all part of the social critique baked into the game mechanics. We looked back to FASA’s history, because you never reinvent the wheel, and if we were doing a decker, we were going to follow coding practices in the design of the Profession. Always check your old projects for useful code. Keep a library or pegboard or whatever you need to create to haul this stuff around with you, because you’ve built it once, why would you ever want to build it again?
And so we arrived at Virtual Realities 2.0 from the FASA Shadowrun line. The design philosophy there had been to strip the mechanics down, and make deckers playable as party members instead of side quests. We nodded and said yes, this is the right approach. Now, translating that into CoreStep was nontrivial. It took a lot of cycles, multiple Agile loops, redefinition of a couple of user stories. We came to the cardware mechanic and said again, never reinvent the wheel, and went to the Redbrick spell design mechanic for Earthdawn, which was the most recent version of a spell creation mechanic we had at the time. The 1879 spell creation mechanic is heavily based on it, you’ll se that in the forthcoming 1879 Players Companion, which is in layout at the time I write this. Great is my jubilation there, let me tell you, as it has been nigh onto a year since the manuscript went into lockdown, and then we had Spinal Tap’s own luck with drummers, er, layout people, and 1879 got Pottered in favour of Earthdawn, which in all fairness is our flagship line and the one paying the rent. The cardware mechanic never quite got to the one from column A, two from column B approach I had really wanted, a truly modular design where you picked the features and they came with a set of stat modifications to the main program, but we did get it down to only a couple of tables and a dice roll at the Debug and Compile stage of design and implementation. No, we did not include the Agile cycle, we’re not that cruel, and we decided the whole process of advancing the code from dev to unit test to QA to deployment was just way too much crunch even for a CoreStep system. We got it down to a points system, with some chances to swap points around, buy more points for adding features or boosting Ratings by adding days of writing time, that sort of thing. There’s a critical Debug and Compile step that’s very much like the final Thread Weaving Test to empower the Spell Pattern. If your code compiles, you’re ready to deploy.
In the end, the Byron came up with most of what we wanted for the first iteration. If there’s a Second Edition of 1879, there’s some tweaks we’ll apply, as some bugs only show up when you test under load. However, between CoreStep, and VR2.0, and the Redbrick spell system, we’ve achieved a playable decker in a steampunk world.