Skip to content

Comments

Spy Antagonist Design Doc#603

Open
TheSecondLord wants to merge 3 commits intospace-wizards:masterfrom
TheSecondLord:spy
Open

Spy Antagonist Design Doc#603
TheSecondLord wants to merge 3 commits intospace-wizards:masterfrom
TheSecondLord:spy

Conversation

@TheSecondLord
Copy link

Started working on this, and figured I should follow guidelines and write a doc before anything is set in stone. Meet the spy.

Never wrote a design doc before, hopefully this is acceptable. Please let me know if any parts need to be rewritten for conciseness because I feel like it gets a little wordy at parts. If you want to discuss on discord, ping me in a development channel @ livelaughlord, or just tell me why it sucks in github comments.

Initial implementation of the bounty board UI, just for examples sake. Subject to change of course.

image

@qrwas
Copy link
Contributor

qrwas commented Feb 12, 2026

The concept sounds interesting, but there's one thing I don't like: using a single code for every PDA. It sounds... kind of weird?
Maybe it's worth adding some extra interaction that would be accessible to everyone, but at the same time, make the process more engaging.
For example: unscrew the PDA > toggle certain 'contacts' (similar to the access interface that opens when you use a multitool on a door circuit) > and only then enter the code. A sort of 'jailbreak' that downloads malware from the 'bluespace internet.' You could even add an 'installation' delay.
This would slightly slow down the initial setup or recovery, but without knowing which components to interact with, it would prevent accidental discovery—or at least make it highly unlikely. This way, you need to know two things: the current 'jailbreak' sequence and the access code itself.
🤔

@qrwas
Copy link
Contributor

qrwas commented Feb 12, 2026

This would add a bit more logic to the process: Syndicate agents already spawn with hacked PDAs, whereas spies would have to obtain the malware themselves.
Or maybe I’m just overcomplicating things, and a standard code won't be an issue at all. 🤷‍♂️

@TheSecondLord
Copy link
Author

For example: unscrew the PDA > toggle certain 'contacts' (similar to the access interface that opens when you use a multitool on a door circuit) > and only then enter the code.
Some thoughts on this:

  • Thematically, I definitely like the idea of having to actually tamper with the PDA, and is something I tried to work into the design but ultimately scrapped.
  • Is the idea for the secret code to be inputted through wire pulses (e.g. red - yellow - green - red unlocks the spylink) or is this tampering just a prerequisite before you're able to enter a code? If the former, how does this interact with locking it afterwards? Would cutting these wires have any effect on this? Should these wires be linked to actual functions on the PDA, like disabling it's ability to light up? How would this handle weird interaction priority jank when it comes to chameleon PDAs, which iirc can also be locked via screwing?

@ScholarNZL
Copy link

ScholarNZL commented Feb 13, 2026

I could envision a system where the spy gets visual cues on how to tamper correctly. Every PDA then can be made random for it's tamper per department, if we wanted to feature creep a little.

Failed attempts to tamper could result in a broken PDA; where the PDA would occasionally spark, spit out it's pen, or spit out its ID card to prevent non-spies from obtaining Black Market access. Once a PDA is broken, even a correct series of inputs would still fail, forcing the player who did the wrong thing to go seek out a replacement.

Just needs to then be complex enough not to brute-force.

@Djungelskog2
Copy link

Thief but good

@qrwas
Copy link
Contributor

qrwas commented Feb 13, 2026

  • or is this tampering just a prerequisite before you're able to enter a code? If the former, how does this interact with locking it afterwards?

I would look at it from this perspective.
Physical-electrical hacking -> a code that can be entered, with the execution result being hidden accordingly.
I’m not sure yet how the first part will look, but the idea with the wires seems interesting. You could also link other functions to it, such as power supply, a flashlight, an access reader, a receiver for news/manifest updates, or whatever.
Essentially, the hacking will be as you described: a specific sequence of pin activations, followed by standard code entry and lockout.
As for cutting the wires, it would serve to disable certain physical functions of the PDA, but those should definitely be handled as separate pull requests.

@TheSecondLord
Copy link
Author

TheSecondLord commented Feb 13, 2026

Physical-electrical hacking -> a code that can be entered, with the execution result being hidden accordingly.

The idea's good, but if both a wire sequence and a code is required then what's the gameplay reason for needing both? I think it'd be better off with either-or, instead of having 2 codes but each is useless without the other. Also keep in mind that the wires adds an arbitrary requirement for the spy to use their main tool, meaning if you aren't in a role with access to a lathe, you'll have to run to cargo or get lucky in the tools room to get a multitool every time.

@SolventMercury
Copy link

SolventMercury commented Feb 14, 2026

The idea's good, but if both a wire sequence and a code is required then what's the gameplay reason for needing both? I think it'd be better off with either-or, instead of having 2 codes but each is useless without the other. Also keep in mind that the wires adds an arbitrary requirement for the spy to use their main tool, meaning if you aren't in a role with access to a lathe, you'll have to run to cargo or get lucky in the tools room to get a multitool every time.

Code with no wires: Someone could say the code over chat (especially since code can be learned just from someone else looking at the PDA), now everyone has a spy PDA

Wires with no code: Spies have no way to lock the PDA without also destroying it. Could be desirable for a "This message will explode in 5 seconds" texture to the RP, but also inconvenient.

Code and wires: Spy PDAs can be captured in functional state, but only if a spy is caught off guard, and capturing them only results in at most one PDA in the hands of the spy's enemies.

Effect on TOTs - likely negligible, as the limiting factor to PDA uplink use is access to telecrystals, not just access to uplinks. I forget if tots have personalized codes, but if not, you could theoretically have sec opening uplinks using a code they busted off a different TOT? But I've never seen that happen, so I assume it's either not possible, or so powergamey that even the shittest of secs haven't dared try it.

@ScholarNZL
Copy link

I had some thoughts on how the unlocking/locking could work:

PDAs now have easily accessible wire terminals, which can be accessed with a barehanded, somewhat lengthy doafter.

Wires are then revealed. PDAs are low voltage, and do not require insuls to tamper with. Certain wires interacted with in a particular order make contact with your spy network / black market trader for a limited time.

Spies get visual cues on this workflow -- non-spies do not.
Each successful tamper will result in a +X% additional chance to break the PDA, which would make the spy need to make wise decisions about when to unlock.

Incorrect tampering by anyone, spy or not, would result in a broken PDA, the effect could be that the pen auto-ejects, or that the screen is cracked, whatever you like, but the intent would be that a tamper would be impossible, and that PDA would need to be replaced.

@TheSecondLord
Copy link
Author

Code with no wires: Someone could say the code over chat (especially since code can be learned just from someone else looking at the PDA), now everyone has a spy PDA

They would use the same system as uplinks where inputting the code doesn't actually save the code as the ringtone so you can't just read it even if the spylinks open. You can only get the code from a spy telling you.

Wires with no code: Spies have no way to lock the PDA without also destroying it. Could be desirable for a "This message will explode in 5 seconds" texture to the RP, but also inconvenient.

Alternatively, wire pulsing unlocks the PDA but locking is still just done through a "lock spylink" button in the PDA UI, same as locking an uplink. Only unlocking would need to be wire based.

Also, this wouldn't touch anything about how tot uplinks work, they'd be exactly the same. The only extra feature, assuming it works the way it does in the current design doc, is that a PDA can have both an uplink and a spylink unlocked at the same time on it, which just displays both buttons.

@TheSecondLord
Copy link
Author

Spies get visual cues on this workflow -- non-spies do not. Each successful tamper will result in a +X% additional chance to break the PDA, which would make the spy need to make wise decisions about when to unlock.

Whats the reason for making the PDA only unlocked for a limited time, and making spies have to be selective about when to open it? I can't think of any gameplay justification for subtley punishing a spy for checking their spylink. Besides that, I'm not against PDAs having an easy-remove wire cover so you can open it without unscrewing.

When I heard the original wire idea I had it in my head that the PDA would have a power wire but the code would deliberately avoid ever selecting that wire for the code, so while you could still shock yourself as usual while messing with wires, you would never need insuls to input your code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants