space-wizards / docs

Documentation side for Space Station 14 and RobustToolbox
http://spacestation14.io/docs/
Mozilla Public License 2.0
25 stars 164 forks source link

Create emergency-orders-functionality.md #286

Open GoGoRoboto opened 2 months ago

GoGoRoboto commented 2 months ago

Emergency Orders Functionality

Designers Implemented GitHub Links
GoGoRoboto :x: No TBD

Overview

The primary goal is to get HoS' Emergency Orders in line with the other command members' exclusive round start items —
The item should be both useful for Nanotrasen personel and important to keep from antagonists. This is split into two sections; The orders will gain functionality for HoS to call in ERT (with restrictions) and antagonists will be able use an EMAG to call in a disaster (similar to the ninja).

Background

All head roles have one or more round start items which are specific to their role. Most share all of these properties:

The head of security's Emergency Orders are a syndicate objective item, but lack any other functionality. This leads the vast majority of HoS players to never interact with their emergency orders in a given round. It is unsurprising as there is nothing interesting to be done with it. Because of this, the Emergency Orders are one of the easiest steal objectives, despite being guarded by most well armed crew member.

While roleplay incentivises HoS players to guard the orders, the opposite is true mechanically as it takes up inventory space. Another way to describe the item is unfun. Perhaps lame. Definitely useless.

Right now these are issues with the Emergency Orders:

Terms

I am introducing a number of new terms for this proposal. These are:

Station-Side Functionality

On round start, the Emergency Orders will not have immediate functionality. Once the Initial Timer is complete, Support Options will be available once the Emergency Orders are placed into a Comms Console.

For the Emergency Orders to gain functionality, all of the following conditions must be met:

Some examples of Support Options:

There is plenty of room for both combat and funny Support Options.

EMAG Functionality

Once the Emergency Orders have been EMAG'd and subsequently placed into a comms console, EMAG functionality is enabled. EMAG Options are much simpler and have no additional costs. Once an EMAG Option is chosen, an announcement says "A communications console has been hijacked and an encrypted message has been sent to hostile entities."

EMAG Options should not regularily put the station under threat of complete destruction. Also, these should be syndicate-themed. The effect should be slightly delayed so there is not announcement overlap. Here are some options:

Things to Consider

The time between a Support Option being chosen and its on-station effect is not immediate. Ghost roles will need to be populated (and by extension lottery'd).

This is made with the future in mind. As new features, antagonists, and more are added, new Support Options can be created.

While no crew can directly and purposfully create ghost roles right now, the majority of antagonists have this ability. Either way, this change will only introduce a small number.

The Emergency Orders steal objective should potentially be changed to "Call in threat with Emergency Orders", or something.

It is possible that this change will cause some players to 'play' for ERT in nukie rounds. Quickly saving up money in warops seems fine, but round stalling for ERT by hiding the nuke probably isnt. It is possible there should be an anti-stall change that accompanies this. However, if given an appropriate Initial Timer, I do not see this being much of an issue.

Closing, Relating to Design Principles

This new functionality is intented to be a semi-regular part of security, cargo, command, antagonist, and ghost-role gameplay.

It should be costly and require coordination (both internally and with the called-in ghost roles) for the station to make effective use of this functionality. This means interaction between players. By the nature of Support Options costing spesos, the QM will have additional responsibility in keeping a rainy day fund — and the Captain should ensure this is done. Once a Support Option is called, the most relevant department head will be expected to coordinate with them. Due to the required conditions for the Emergency Orders to gain functionality, this change introduces far more roleplay interactions, responsibilities, and reactionary gameplay than meta actions. None of this is to say this change will force gameplay routes. ERT should be somewhat implactful but remain unrequired.

It should take planning and potentially antag coordination for an antagonist to make any use of EMAG functionality (gaining access to the orders and a comms console in the first place). The effect will naturally induce chaos as the station becomes aware of the anouncement's implications, but the chaos would be no more than a ninja should typically be causing.

These changes put the Head of Security's Emergency Orders in line with all of the other objective items when it comes to existent functionality. It also give HoS and sec a reason to protect the Emergency Orders.

This proposal was inspired by Arcticular's forum post and accompanying replies
https://forum.spacestation14.com/t/hos-emergency-orders-ert-rework-proposal/9936/5

Nothing has been coded. I am looking for opinions!

GoGoRoboto commented 2 months ago

First time making a PR proposal (or using github, really). Sorry if I made any mistakes in the process.

lzk228 commented 2 months ago

btw emergency orders will be removed in https://github.com/space-wizards/space-station-14/pull/30643

GoGoRoboto commented 2 months ago

btw emergency orders will be removed in space-wizards/space-station-14#30643

oof didn't know that. Since if that gets merged it will be a lot sooner than this would, I'm not worried. Worst case scenario emergency orders would be re-added/modified by this a while after. I don't see why there's not room for both of these concepts to coexist in some way considering sec now officially has two 'important roles'.

If the other PR is merged I'll try to update this accordingly

cohanna commented 2 months ago

i think this is a great concept and i hope you continue working on it I do have a few questions/suggestions though.

Why are CBURN calls only restricted to infected/survival? Personally, I don't see any issue in having the ability to call it on normal traitor/nukie/rev rounds.

A big issue is revs, this would be extremely crippling for rev rounds and would basically be auto-called as soon as revs are confirmed. I would also add the 1hr nukie timer to it (maybe even longer, idk).

What kind of ranges were you thinking for your randomized timers?

How many ERT agents were you thinking for your poor ERT and full fireteam ERT? (I would do no more than 3, and that might even be a lot)

Going back to revs, all of the command items are extremely useful for a rev round (excluding MAYBE the RD/CMO suit), do you think there can be some kind of non-emag functionality to it that is useful for antags?

For the emag functionality, summoning a loneopps might be a bit much even if they normally fail. Typically if the security orders get stolen sec will already be in a pretty sorry state and a loneopps will be the final nail in the coffin more often than not. Furthermore instead of a sleeper agent occurring maybe you get one or two syndie reinforces given to you instead? This would give more direct benefit to the traitor who obtained the item. I just feel that new antag roles opened up by this will need to be more underpowered than their normal form in order to not absolutely wreak havoc. (excluding the genetic ancestors that's funny af)

Looking forward to seeing this develop!

GoGoRoboto commented 2 months ago

Why are CBURN calls only restricted to infected/survival? Personally, I don't see any issue in having the ability to call it on normal traitor/nukie/rev rounds.

You're right, I don't see any issue with options for options sake. Plus, you never know when a round would end up needing one or the other.

A big issue is revs, this would be extremely crippling for rev rounds and would basically be auto-called as soon as revs are confirmed. I would also add the 1hr nukie timer to it (maybe even longer, idk).

Thanks, I'll keep this considered.

Going back to revs, all of the command items are extremely useful for a rev round (excluding MAYBE the RD/CMO suit), do you think there can be some kind of non-emag functionality to it that is useful for antags?

Spit balling, all I got is forcing station records issues and stuff like that, but I am not sure it needs to have non emag functionality. Perhaps preventing the emergency orders from being used should be an expected part of rev gameplay? Maybe headrevs spawn with an item that lets them call in some goodies to help with converting, once they have comms console access? A little off topic, but anything that spices up rev rounds would be great imo.

What kind of ranges were you thinking for your randomized timers?

5-15 minutes in either direction of the base time (50 min - 70 min). Obviously bigger ranges result in more overlap so less metagame chances, but it might be frustrating for one side if the ranges are large and they feel unlucky.

How many ERT agents were you thinking for your poor ERT and full fireteam ERT? (I would do no more than 3, and that might even be a lot)

'Poor ERT' would be 2-3. The name should change, since they're 'ERT rejects' and have sucky equipment. Surely ERT Fireteam could be 4, no? Even in admeme events, sometimes 5-6 still lose to nukies or infected pretty handily. That being said none of these ideas are concrete. I've got in it my mind there should be 3 tiers of each main support type.

For the emag functionality, summoning a loneopps might be a bit much even if they normally fail. Typically if the security orders get stolen sec will already be in a pretty sorry state and a loneopps will be the final nail in the coffin more often than not. Furthermore instead of a sleeper agent occurring maybe you get one or two syndie reinforces given to you instead? This would give more direct benefit to the traitor who obtained the item. I just feel that new antag roles opened up by this will need to be more underpowered than their normal form in order to not absolutely wreak havoc. (excluding the genetic ancestors that's funny af)

I agree that an antagonist should not have a pseudo win-button after emaging the orders. I think the design principle of more in control = less reward, but less in control = more reward is a good idea. Even if spawning a loneop is too much, you can see the idea that the antag who called it in has no control over what chaos ensues. A quick 8TC or some bombs would be the flip side.

Thanks for checkin it out!

MilenVolf commented 2 months ago

First time making a PR proposal (or using github, really). Sorry if I made any mistakes in the process.

PR's should be made in new branches from master, not in the master. If workflow will be approved, one test that is made to prevent making PR's in master will fail.