2400 devlog: Codebreakers

Codebreakers is an action-thriller microgame about hackers, investigators, and innocent bystanders who know The Truth: This is all just a simulation. They’ve glimpsed enough of the code behind reality to exploit it, at the risk of attracting the attention of relentless daemons. Get it as part of the entire 2400 collection on Itch.io, and on its own and in the 2400 bundle on DriveThruRPG.

Origins of the simulation

I suspect it’s obvious that Codebreakers is an unabashed homage to (but legally distinct from and NOT AT ALL an authorized adaptation of) The Matrix. That said…

When I was a teenager in the mid-’90s — some time before The Matrix was made — I started working on an RPG with the (unintentionally hilarious) working title “Angel Mainframe.” The premise was that the entire world is a simulation; only a few people could recognize this and manipulate reality; and those people battled vaguely demonic beings who sought to keep them enslaved, structured in what should have been apparent to readers as a sort of Biblical allegory.

Also, if I remember correctly, the fallen angels could turn into cars.

So maybe Codebreakers was just finally executing an idea from 25ish years ago … that clearly needed some more time to percolate.

This brings to mind another, perhaps more unexpected influence: In Nomine, an RPG about the secret war between angels and demons on Earth. I fell for this game hard in the ’90s, and it may well remain the game I’ve run more than any other. As I’ll return to later in this post, the behavior of “daemons” owes as much to In Nomine’s demons as it does to The Matrix’s agents.

Also, I suppose you might say Resistors — another one of my own 2400 games — was sort of an early influence. That is, I started writing Resistors, got part way through writing a list of hacking effects that are basically magic spells, and realized, “Wait … what if they actually were magic spells? Like, what if these exploits actually rewrote reality?” And then I shifted everything I was writing into this game instead. It was months before I was able to get back to Resistors with an approach that excited me.

Anyway, that’s where Codebreakers came from. I certainly wouldn’t blame you for using it to run games in an unaltered Matrix setting, but I also think it would be fun to think about what “daemons” look like in your game. As usual, I left it vague on purpose (just in case you want to make fallen angels that turn into cars).

How (not) to write a magic system

Codebreakers v1.0 featured something new to 2400: “exploits,” a list of powers that allow you to hack reality in your virtual world.

And then, within 24 hours of publishing it, I overhauled the rules completely.

I got into some nitty-gritty details in Itch devlogs on both the original mechanics and why I revised them. Now, though, I thought it might be useful for 24XX hackers (and for myself) to look back on this as a case study of my thought process behind adding new rules. I’ll try to break down the intent and results a little more clearly this time around. So…

Exploits are, in a way, my first 2400-style “magic system.” I went in thinking I had a few design goals:

Limit effects. The characters can break the laws of physics, but are limited in terms of how much they can do that. If the characters were to start the game with powers comparable to Neo’s at the end of The Matrix, there wouldn’t be much in the world to present interesting challenges. (It’s telling, I think, that the filmmakers really dialed back Neo’s powers in the sequels.)

Limit frequency. In a “high-magic” setting, it’s no big deal if practically everything has an element of the supernatural. In this setting, though, preternatural strength, speed, and movement should be rare and shocking for onlookers, reserved for situations of great need.

Avoid bookkeeping. The most common methods to limit the effects of magic in RPGs tend to involve marking something on your character sheet, like losing access to a spell for the rest of the day after you’ve used it, or spending “points” or “slots” to track how many spells you can cast. In 2400, though, I prefer to ground every choice as much as possible on the immediate fictional context, and I try not to add too many things that would demand more bookkeeping. I wanted whatever solution I came up with to be resolved in the moment, with immediate (or at least imminent) fictional consequences.

Avoid extra rolls. This is a maxim of 2400 design I stole from Chris McDowall. In 2400, this is both a matter of speed and of keeping the GM’s plate clear. Fewer rolls means turns go faster, and the focus of play is more on fiction than on dice. Plus, whenever a player rolls the dice, they’re potentially creating work for the GM: On a 4 or less, the GM is going to have to improvise how the abstract risk they warned about (if they even remembered to specify it) will be translated into a concrete, defined consequence. The GM has enough to think about already, managing a broader range of variables than any other player; I didn’t want to create more work for them by introducing extra skill rolls, and thus extra chances for disasters and setbacks.

Avoid a god stat. Or whatever you call it – that’s the term I found when I searched to find “the opposite of a dump stat,” at least. If a dump stat is “the stat you can afford to ignore because it doesn’t really matter,” a god stat is “the one stat everyone has to invest resources into.” Sometimes the solution to this is to spread out the stat, like making every spell (or exploit) its own skill, kind of like telekinesis and telepathy are their own skills in Inner System Blues. But in this case, I figured, why tie it to a stat at all, rather than something everybody just gets to do?

And so, the first iteration of “exploits”…

  • Limited effects by defining pretty narrow effects for exploits
  • Limited frequency by rolling luck to see if daemons notice
  • Avoided bookkeeping by not tracking any currencies or uses
  • Avoided extra rolls by eliminating the need for a skill roll entirely
  • Avoided a god stat by using only luck rolls, not skills, for exploits

Great! All set, right? Uploaded!

Codebreakers came out after about an eight-month gap since the previous 2400 game. I think I was excited to just get it out into the world as soon as possible. But within a day, I started thinking more carefully about what playing this would actually look like. I hadn’t even had time to properly playtest it, but I could still walk through it in my mind and see the pitfalls.

Looking back on it now, it’s easier for me to see that “avoid extra rolls” is a method, not the actual design goal. It’s a good method! I still try to stick to it. But I should’ve paid more attention to Chris, who pointed out in that same post I cited as inspiration, “Like all methods, this isn’t the answer to everything.” I made a mistake letting this design technique stand in for the actual design goals underlying it.

The REAL design goal: Keep the game fast. While the rules still only used a single roll upon exploit activation, this was unlike how every other player-triggered roll in the game works. The GM only makes luck rolls at their discretion, if ever at all. The players roll in 2400. That inconsistency would introduce slowdown. I don’t want you stopping play to wonder, “Wait, who rolls for this?” The answer should always be obvious.

In more complex games, you can rely on “rules mastery” over time to iron out wrinkles like this. 2400 is designed for the way I play, though, as someone with chronic illnesses and a small child. I can only play irregularly, and only for pretty short sessions, which makes it extremely unlikely anyone in any game I run will build “rules mastery” for an unfamiliar system. And so, my goal for 2400 is that you shouldn’t have to master the rules. The rules need to be intuitive and consistent so play is quick. Keep that in mind, and you can fit a lot into even short, irregular sessions.

The REAL design goal: Keep the GM’s plate clear. The original exploit rules managed to keep exploits to a single die roll, but completely failed to meet this major goal underlying the “avoid extra rolls” technique. All it did was move the roll from the players’ responsibility to being the GM’s responsibility. This creates work for the GM, and takes away an element of the game that’s actually a big draw to RPGs for many players. Even when you’re rolling to avoid risks, as a player, rolling dice is pretty fun!

Further, using luck rolls for exploits added an extra duty to the GM’s plate: deciding how big a luck die to roll every time an exploit was used. Picking difficulty numbers was never supposed to be part of the GM’s job in 2400. The whole reason the help and hinder rules work they way they do — a simple “yes” or “no” for each, not mutually exclusive, so you never have to weigh whether they cancel each other out — is to make the GM’s job easier.

You may be wondering at this point why I even used luck rolls for this at all. Part of it was that I was channeling my experience running In Nomine: When you perform supernatural effects in that game, there’s a chance of attracting the attention from supernatural enemies. In true ’90s RPG design fashion, the rules for this were unnecessarily complex and arcane, but basically boil down to … a luck roll. I figured I was improving upon the original by simplifying it. Ultimately, though, I think I was making the wrong thing right, rather than figuring out the right thing to make.

The other reason I used luck rolls instead of the standard skill roll for exploits, as noted above, was the goal to “avoid a god stat” — but again, this isn’t the real, underlying goal. It’s a method. And the method wasn’t even achieving the goal.

The REAL design goal: Offer players meaningful choices. I was afraid that if the use of exploits was associated with a single skill, players would feel forced to upgrade that skill to the exclusion of all else. But by separating exploit use from skills, I actually ended up undermining player choice and the goal to limit frequency of exploit use. The original rules saw the GM rolling sometimes quite large luck dice, which meant using superpowers was less likely to result in any negative consequences than using your own skill dice. This would encourage using exploits even more frequently, rather than seeing rolling skills as a viable choice.

Moreover, looking at the design more closely, I realized I need not have worried that players would lack meaningful advancement options. If you really love exploits, there are plenty of other advancement options to choose from: unlocking the exploits themselves. Heck, after revising the rules, I was able to free up space to add even more exploits.

And so, overall, my “power use as a luck roll” rule didn’t actually do what I wanted. But you know what pretty neatly encapsulates what I did want? The same rule for “only roll to avoid risk” that I use everywhere else in the game.

The result: the Simulation skill. Every codebreaker knows this is a simulation, but manipulating this reality demands practice and insight. Roll Simulation to exploit reality, at the risk of attracting the attention of daemons.

Actually attracting daemons’ attention is such a big deal that this risk simply replaces whatever else you might have been risking for a roll — unless you’re already being pursued by them. This means if you use your powers to jump between buildings, you will make that jump — unless there’s someone with even greater superhuman speed hot on your heels.

As you advance, you can choose to improve your mundane skills, the range of powers at your disposal, or your ability to use powers without being caught. (But if your group still feels like Simulation is a god stat, just say the skill can’t ever be raised above d6.)

Remember: This is a case study, not a guidebook. It’s tempting for me to extrapolate from this — to suggest that 24XX is more brittle than it looks, and that you (or at least I) should try to fit new rules into the same format of existing rules, or else risk knock-on effects.

It’s tempting — but I think it’s incorrect. The game’s intended to be deliberately sparse so that you still have a “rules light” game even after bolting on some modular components. I could show you other examples of rules adjustments — by me and by others — that work just fine, even though they’re unlike anything else in the “Rules” column on the 24XX SRD.

Rather, I think my own takeaways from this are that I must keep in mind that my favorite design methods are not stand-ins for my design goals. Playtesting — or at least more careful reading — can reveal when I’m not actually achieving my own goals. And I should try to sit on a game for a bit longer before I rush to put it out into the world … just in case.

Combining with other 2400 games

To expand Codebreakers, you might augment character options using talents, powers, programs, and incantations (re-skinned as exploits) in Eos, Project Ikaros, Resistors, and Legends. And if you think the game might reach beyond the simulation, you may want to pull in another 2400 setting as the basis for the rest of the world. Perhaps the simulation is really…

  • A recruitment or training process for secret agents in ALT
  • An alien’s sick mind game or research experiment in Orbital Decay
  • A prison containing someone you need to spring in Resistors
  • A program to reform dangerous psychics in Project Ikaros

If reality is actually an illusion, then there is no simulation, and Codebreakers is actually a game about mystics or superheroes, depending on how you look at it. Note that Codebreakers characters start with more character options than previous 2400 games because exploits and the Simulation were presumed to not work outside this specific setting. If you are concerned about characters being “balanced” with one another, and you’re mixing in characters built in other 2400 modules, you might give the non-codebreakers a couple more skills, talents, or cyberware upgrades, so they get to be “super” too.

Use more open-ended “luck rolls” (not just d6) for any 24XX game when you want to tweak the odds of something going wrong. If you’re rolling to test for randomly encountering guards in a place that’s crawling with guards, maybe you roll a d4 instead; in a crowded city, where you might blend in better, maybe you roll a d12. Mind you, I generally don’t advise modifying the luck roll because it’s one more thing for the GM to track, and it can easily turn into an unnecessary burden akin to thinking up “difficulty numbers” for every challenge. That said, it can be a handy dial to remember you can turn.

Adapt daemons as “unbeatable” enemies in any scenario that could use one — alien predators, military detachments, cosmic horrors, or anything else that can realistically only be escaped, not defeated. You may find it useful to approach these using (or by adapting) the procedures for interacting with daemons, which are handled here as a series of GM-facing “moves” inspired by Powered by the Apocalypse games. Antagonists don’t have “stats” in 24XX games, but moves offer a nice way to define some parameters of interaction and how much of a threat they pose. 

Adapt exploits as “powers” in any 24XX game. Take a look at Resistors and Legends to see how you tailor this for a couple different settings. The basic idea is that “magic” is inherently risky, but the risk might vary from one setting to another. Either that built-in risk will be instead of another risk (like risking attention from daemons to avoid risk of falling off a building), or on top of a situational risk (like risking being hurt in combat while casting a spell, and risking magical side effects, both handled by the same roll). As long as the players are willing to accept the risks, the sky’s the limit — perhaps quite literally.

Featured image edited from original by Beeple (Mike Winkelmann).

6 responses to “2400 devlog: Codebreakers”

    • Man, you know I’ll update and revise things at the drop of a hat, right? 😆 Yeah, maybe I should edit this, but I mentioned Codebreakers on the Inner System Blues devlog, at least.

Leave a Reply to Kyle Maxwell Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a website or blog at WordPress.com