Event Policy: Difference between revisions
Moonridden (talk | contribs) (i understand formatting) |
Moonridden (talk | contribs) (Disaster event policy update) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 42: | Line 42: | ||
Well administered events are considered Staff Labor. | Well administered events are considered Staff Labor. | ||
A Player's Antag Opt-In Status is used to decide the depth to which the Player wishes to participate in Event-based Antagonism or Threat, and should be respected unless there are extenuating circumstances. | |||
Characters that are normally station crew should not suddenly be in extremely important positions or flip-flopping into roles that break suspension of disbelief. | Characters that are normally station crew should not suddenly be in extremely important positions or flip-flopping into roles that break suspension of disbelief. | ||
| Line 90: | Line 90: | ||
==== Who can run a Story Event? ==== | ==== Who can run a Story Event? ==== | ||
Story Events need approval from | Lore based Story Events need approval from an Event Curator or Manager, due to their sensitive nature. | ||
==== What is a Story Event? ==== | ==== What is a Story Event? ==== | ||
| Line 109: | Line 109: | ||
Small Roleplay Events can be run freely. | Small Roleplay Events can be run freely. | ||
Large Roleplay Events should be run sparingly. Get an | Large Roleplay Events should be run sparingly. Get an Event Curator to approve if worried. | ||
==== What is a Roleplay Event? ==== | ==== What is a Roleplay Event? ==== | ||
| Line 124: | Line 124: | ||
Small Intensity Events can be run freely. | Small Intensity Events can be run freely. | ||
Large Intensity Events should be run sparingly. Get an | Large Intensity Events should be run sparingly. Get an Event Curator to approve if worried. | ||
==== What is an Intensity Event? ==== | ==== What is an Intensity Event? ==== | ||
| Line 151: | Line 151: | ||
==== Who can run a Disaster Event? ==== | ==== Who can run a Disaster Event? ==== | ||
All intentional Disaster Events must be approved by | All intentional Disaster Events must be approved by an Event Curator or Class 3 Staff. Large Disasters must be announced two shifts in advance. | ||
Large Disasters | |||
==== What is a Disaster Event? ==== | ==== What is a Disaster Event? ==== | ||
Latest revision as of 00:15, 5 December 2025
Affected Groups
Defines those that the Policy affects.
Anyone that wishes to run or deeply participate in an Event.
This does not impact the participants in an Event, but the Event Leaders and other Staff.
Preamble and Description
Defines the intent of the policy, provides useful links, and prepares the Reader.
We consider an Event to be an interference on our part meant to provide entertainment for Players in some way. While Events typically impact groups of people, they can be targeted at individuals as well. Events provide novel content that the game itself would not normally give.
Event Policy provides a 'short' reference on limitations for Event running.
It defines lots of concepts and tries to keep scopes precise, just like you should be.
It is important to keep an Event to a general theme, particularly for ease of logging.
Events should come with meaning and reason. We don't just click buttons, we make memories.
Writer Credits and Background
The writer(s) jointly provide a statement on the policy.
Event Policy is one of the few fully new and meaningful bits of Staff Policy that has come about with the changing of hands and player base over time. We're all learning together, and this document exists to help keep our silly events a reality.
Writer 1 - Moonridden/Moonridden
Defines Writer 1's contributions to the page, and how they feel on it. This section is by the Writer.
I'd like to think that I learned my lesson this time around, but maybe not. This is a large topic to talk about, and its equal parts administrative struggle to realistic expectations of staff and crew.
This policy should be an equally accessible document to Crew that wish to run an Event with Staff assistance as it is to Staff themselves. I've removed a shitload of jargon and hoops to jump through and tried to focus more on the individual types and their execution. The Policy section of this document remains a bloated, rambly mess, but I think at the moment it is a necessary evil. At least with me as the exclusive writer. If you think you can improve this document, message me.
Policy
Defines the extents of the Policy coverage, using as few descriptive groups as possible.
Core
All Events are to be logged no matter the intensity.
All Staff are permitted to run Events. Trial Staff may not run events, but they may participate.
Well administered events are considered Staff Labor.
A Player's Antag Opt-In Status is used to decide the depth to which the Player wishes to participate in Event-based Antagonism or Threat, and should be respected unless there are extenuating circumstances.
Characters that are normally station crew should not suddenly be in extremely important positions or flip-flopping into roles that break suspension of disbelief.
Events that use Central Command characters must respect CentCom Policy limitation on their use.
Event Operations
The Staff initiating the Event are the Event Leaders, unless otherwise stated.
Large Events create a lockout for all other Staff on usage running other Events, or 'loud' usage of Staff tools such as the Aux Cord.
You must inquire with the Event Leaders to add, modify, or contribute content in their event. Issues regarding an event should be directed to the Event Leaders, or Staff Manager.
Lore Team Obligations
The aim of these Obligations is not to restrict creativity, but instead to help create a cohesive and consistent setting for the server. If you want to break one of these rules for an event you’re welcome to reach out to the current lore head to discuss being given an exemption.
Avoid contradicting official lore as written on the wiki. It’s not expected that you’ll have all of our server’s lore memorized by heart so it may happen by accident but try and do your due diligence. For example, if running an event involving SolFed’s military try and be reasonably familiar with the contents of the related wiki page to ensure you don’t contradict any of it.
Try and keep the relations between different groups consistent with the setting in your events. Don’t have groups that are not enemies suddenly fighting in your event. If players from different factions that are not enemies end up organically coming to blows that’s fine.
You can introduce new groups and concepts! So long as you’re not introducing a new major power or concept it is fine to come up with corporations, pieces of technology, nations, species, and so on. If it is tonally consistent with the rest of the setting and doesn’t contradict anything you should be good. Furthermore, if you come up with something you’d like to be added to the official canon you are welcome to reach out to the current lore head to potentially have it added to the wiki.
Event Taxonomy
This covers the specifics of Events, their classifications, planning, execution, and documentation.
While all of this is POLICY it is difficult to enforce it like the more Rules oriented writing above. You will be judged on concepts, merit, effort, and execution if the criteria or expectation is not listed.
Event grading is broken up by two different metrics: Scale and Variety.
Scale
Event Scale describes the intended size and impact of the Event. This is your Who and the Where.
We have two different Scales: Large and Small.
Large Events are indiscriminate with who they impact. This can be for ease of classification too.
Small Events target select departments, a narrow group, or an individual. Limited scopes.
Event Variety
Event Variety describes the archetype of the Event. This is your What, How, and Why.
Events come in 5 different flavors: Story, Roleplay, Intensity, Disaster, and Admin.
Each type comes with its own expectations and guidance. Check out the individual Guides for help.
Story
Who can run a Story Event?
Lore based Story Events need approval from an Event Curator or Manager, due to their sensitive nature.
What is a Story Event?
Story Events create or utilize Game and Server Lore to offer immersive and cohesive narratives for Players to enjoy. Story Events are usually run in episodes, and reference previous experiences and actors in their execution. This Event type provides a feeling of continuance for those that experience it by leveraging previous Events or commonly known Lore as a practice in rewarding knowledge of the culture.
These Events are not easy to run and require planning. Be prepared to write up a script and get all your paperwork, documents, references, and actors organized before executing one.
How do we classify a Story Event?
Expands or alters established Server or Game Lore.
Utilizes major groups of power, figureheads or people of extreme power (admirals, CEOs).
Follows the Lore Team Obligations, as seen on the Events Policy.
Roleplay
Who can run a Roleplay Event?
Small Roleplay Events can be run freely.
Large Roleplay Events should be run sparingly. Get an Event Curator to approve if worried.
What is a Roleplay Event?
Roleplay Events create opportunities for Player to interact with scenarios, settings, and situations. By providing something novel for Characters to express themselves through, we can offer better chances for Players to make connections. These Events use social interactions, role expression, and character expression as the foundations of their design. Nova Sector features Canon Shifts, these events give Players more chances to be able to say, "Hey remember that time we did X during Y?".
How do we classify a Roleplay Event?
Has a higher emphasis on Roleplay opportunity over mechanics, without Game Lore ramifications.
Offers ways for Players to express their Characters, their Abilities, and their Weaknesses.
Intensity Events
Who can run an Intensity Event?
Small Intensity Events can be run freely.
Large Intensity Events should be run sparingly. Get an Event Curator to approve if worried.
What is an Intensity Event?
Intensity Events use the full mechanical spread of the Game to provide Players a fresh interaction with the Game. Intensity Events are not always without Roleplay, but the way they accomplish that goal is different from what we normally expect. Some Intensity Events provide an opportunity for the Crew to interact with a Group or Entity of Power, which poses Threat in some way, that they can circumvent by playing along with the Threat correctly.
Other Intensity Events obligate the Crew to their Mechanical Load, be it Station damage or blackmail or a gateway invasion. These Events generate their Roleplay through shared experience and shared trauma. Something players finish and then look back on together with a sigh of accomplishment. An Intensity Event demands Game knowledge from the Players and the Event Leaders to fully succeed.
How do we classify an Intensity Event?
Provides Threat and a Mechanical Load to the Station.
Creates a Manpower and/or Resources Debt for the Crew to fulfill.
Interferes with peaceful station operations.
Threat is defined as perceivable danger or instability to the Crew or Station.
Mechanical Load is defined as the expected _intensity level_ of the required interaction by Crew to resolve the Threat.
Manpower is defined as the expected level of Crew involvement. Head counts, Energy, and Time.
Resources is defined as the material sum. Supplies, Machines, Tools, and access to them.
Debt is defined as the total perceivable ‘cost’ to resume normal operations.
Disaster Events
Who can run a Disaster Event?
All intentional Disaster Events must be approved by an Event Curator or Class 3 Staff. Large Disasters must be announced two shifts in advance.
What is a Disaster Event?
Disaster Events are intentional catastrophes that utilize significant changes to the gameplay environment as a vehicle for story telling or experience. Dangerous or life-threatening circumstances that individuals may not be able to contain or counter reasonably are a cornerstone of the design of this Event type. When you think Delta alert or higher, you are thinking of a Disaster. Releasing a Singularity or using the Meteors Gamemode is a Disaster. Romerol is a Disaster. Tuning up a Mold so it produces hot oxygen and tritium which burns a giant hole in the Station that takes nearly an hour to kill and wont be cleaned up is a Disaster.
Unless otherwise stated, any scheduled Disaster Event is not canon.
True Disaster Events should not look like an Admin Event.
How do we classify a Disaster Event?
Utilization of Delta+ Alert Levels.
Anything that demands a Mass Casualty scenario.
Anything that disfigures the Station to an unrecognizable degree.
Anything that derails the shift in an intrusive way.
Admin / Fun Events
Who can run an Admin Event?
Admin Events may be run by any Staff.
What is an Admin Event?
Admin events are things happening for a reason only known to the executing Staff.
These are situations where the bus is used for reasons only the performing Staff can defend.
This can be odd responses to prayers, interventions, or things that are ‘just because’.
These are typically impromptu, but some are planned.
If no one saw it, interacted with it, or was impacted by it, it is not an Admin Event, unless otherwise stated in other Policy.
Event Planning and Documentation
Planning your event is the smartest thing to do. Now, I'm not saying give me a write-up and get me to sign off on it for you to spawn in a cat with a cute name that spawns cockroaches every five minutes, but I am saying to get every single one of your ducks in a row when it comes to Events that demand good execution. It should be clear that there is a difference between something you can come up with and execute in ten minutes, and something that you will be lording over the entire shift.
When running meaty Events that feature multiple plot points, gimmicks, actors, or other moving parts, it is best to write it all down and plan it AHEAD of your execution. Doing so in the light of the Staff Forum or the Server Events channels gives you the opportunity to get more review or assistance, improving your overall quality.
There is, still, something to be said for running an Event because of a good situation or scenario. Good Events can unfold from entirely natural circumstances. If you see an opportunity and you can meaningfully act on it, do so. This game is about strange and spontaneous interactions after all.
All Event Variants that demand approval from a certain rank MUST come with a presentation of your work materials and preparation. Few will approve concepts alone.