Event Checklist: Difference between revisions
Created page with "{{SidebarStaff}} = Overview = For an event to be properly created and run, without risk of the event being declared noncanon, a handful of steps need to be taken. These steps range from simply verifying the lore basis of a minor event's premise, all the way to fully validating all the possible outcomes, sanctions and other long-term consequences of an event. = Procedure = While only the final event needs to actually be approved before it's run, there are a few stages..." |
|||
(One intermediate revision by the same user not shown) | |||
Line 28: | Line 28: | ||
== Approval == | == Approval == | ||
This phase of event handling is the responsibility of Game Masters to oversee, as they are responsible for verifying the event | This phase of event handling is the responsibility of Game Masters to oversee, as they are responsible for verifying the event's prerequisites. Once the GM has approved the event, it also falls upon them to grant permissions to operators as needed. | ||
=== Lore Review === | === Lore Review === | ||
All lore-related details of the event must be validated with the lore team. As many possible outcomes as reasonable should be workshopped and regarded, especially if they lead to long-term consequences for the server outside the event. Finally, characters should be reviewed both in motivation, background, and accuracy - though events involving combat can be a bit more lax here. | All lore-related details of the event must be validated with the lore team. As many possible outcomes as reasonable should be workshopped and regarded, especially if they lead to long-term consequences for the server outside the event. Finally, characters should be reviewed both in motivation, background, and accuracy - though events involving combat can be a bit more lax here. | ||
Keep in mind that while <i>using</i> lore only needs a writer's approval, changes to lore that may occur require a lore staff head's approval. | |||
=== Code Validation === | === Code Validation === | ||
As a general rule, any code that has been <i>fully merged</i> is assumed to be ready for use in an event. Test-merged code should receive approval and guidance from a coder. Custom maps should be reviewed by a coder - preferably with a writer and a member of the administration in the room, making sure that nothing out of the ordinary is included - such as unique items. | As a general rule, any code that has been <i>fully merged</i> is assumed to be ready for use in an event. Test-merged code should receive approval and guidance from a coder. Custom maps should be reviewed by a coder - preferably with a writer and a member of the administration in the room, making sure that nothing out of the ordinary is included - such as unique items. | ||
Keep in mind that while <i>using</i> code only needs a coder's approval, changes to code that may occur require a code staff head's approval. | |||
Additionally, keep in mind that the code is not self-evident. Certain objects will behave in ways that may lead to problems once the event begins. Consult with coders in advance to ensure that anything whose function you're unsure of will work the way you need it to once the event comes around | |||
=== Round Authorization === | === Round Authorization === | ||
Interfering with a round in progress, or springing an event on players without ample warning, is generally a negative thing. What exactly counts as ample warning is a somewhat vague and malleable thing, but a good guideline is that no player should be unaware or unprepared for an event when they join the round. Whether this means a few days of advance notice or a <i>nearly unanimous</i> player vote in favour of running an event, players should not have the expectation of a normal round before the round begins, or the desire to continue having a normal round should event staff be trying to push an event through without warning. | Interfering with a round in progress, or springing an event on players without ample warning, is generally a negative thing. What exactly counts as ample warning is a somewhat vague and malleable thing, but a good guideline is that no player should be unaware or unprepared for an event when they join the round. Whether this means a few days of advance notice or a <i>nearly unanimous</i> player vote in favour of running an event, players should not have the expectation of a normal round before the round begins, or the desire to continue having a normal round should event staff be trying to push an event through without warning. Contact the administration, who will determine if a round is suitable for an event, and which of these measures are needed before an event can be allowed to run in said round. | ||
Keep in mind that while <i>using</i> a round only needs a moderator's approval, consequences to players that may occur require an administrator's approval. | |||
== Volunteers == | == Volunteers == |
Latest revision as of 23:09, 18 November 2024
Administration | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Server Policy | ||||||||||
Staff Ranks | ||||||||||
|
||||||||||
Policies | ||||||||||
|
||||||||||
This template is currently incomplete; some data is misplaced for testing purposes. Do not create pages from the redlinks. | ||||||||||
Overview
For an event to be properly created and run, without risk of the event being declared noncanon, a handful of steps need to be taken. These steps range from simply verifying the lore basis of a minor event's premise, all the way to fully validating all the possible outcomes, sanctions and other long-term consequences of an event.
Procedure
While only the final event needs to actually be approved before it's run, there are a few stages in the process of putting the event together which will greatly benefit from input from appropriate staff while it happens.
Preplanning
Before any details are hammered down, the basics of the event need to be established. Who are the main actors? What are their goals? What lore will be leveraged during the event? Which archetype will the event fall under, if any?
Consulting with development staff on these details is recommended here, as a bad outline can lead to the event being completely trashed simply due to it failing to fit the setting and server.
Event Writing
With the outline complete, it's time to nail down the plot and playout. If the event is meant to have RP, then the various information that should be exposed, the goals that arise and how they're completed, and how NPCs will interact with the colony should all be nailed down. For more mechanical events, the rewards and challenges enroute are more important, as well as any possibility that the event might enter an RP phase, or what happens when it goes wrong. In both cases, details on how the difficulty should be adapted to more or fewer players should be considered.
Consequences
Review the consequences of the event. Will it just be another day, to be whisked away into the past as soon as the round ends, or will things change within colony bounds as a result? No need to go overboard at this phase, but getting a general sense of how things will lead to various outcomes - or no permanent changes whatsoever, in some cases - is important for any events with consequences.
Resources
While creating new icons and other objects is possible, for use during the event, the main element that is created - where needed - is the event's map.
- Don't leave too much empty space. Unless it serves some purpose, areas in the map should all be dedicated to whatever story the event is to tell.
- Establish portals in believable places. If an area is meant to be 'far' from the colony, set up its entrances to be further away - leveraging the shuttles to close the distance through the jungle instead of walking.
- Event maps should be connected to relevant areas, and might even feature a direct shuttle waypoint - especially if the map is being reused multiple times.
- Make multiple paths to the goal for larger events. Preferably from different locations and directions. The best maps will have high-difficulty routes through areas of highest challenge, but still allow accessing and completing objectives from different entrances without entering those tougher regions.
- If using the colony itself as a map, don't alter too many critical things, simply due to the difficulty of fixing some things, and the impossibility of fixing others without admin intervention.
Approval
This phase of event handling is the responsibility of Game Masters to oversee, as they are responsible for verifying the event's prerequisites. Once the GM has approved the event, it also falls upon them to grant permissions to operators as needed.
Lore Review
All lore-related details of the event must be validated with the lore team. As many possible outcomes as reasonable should be workshopped and regarded, especially if they lead to long-term consequences for the server outside the event. Finally, characters should be reviewed both in motivation, background, and accuracy - though events involving combat can be a bit more lax here.
Keep in mind that while using lore only needs a writer's approval, changes to lore that may occur require a lore staff head's approval.
Code Validation
As a general rule, any code that has been fully merged is assumed to be ready for use in an event. Test-merged code should receive approval and guidance from a coder. Custom maps should be reviewed by a coder - preferably with a writer and a member of the administration in the room, making sure that nothing out of the ordinary is included - such as unique items.
Keep in mind that while using code only needs a coder's approval, changes to code that may occur require a code staff head's approval.
Additionally, keep in mind that the code is not self-evident. Certain objects will behave in ways that may lead to problems once the event begins. Consult with coders in advance to ensure that anything whose function you're unsure of will work the way you need it to once the event comes around
Round Authorization
Interfering with a round in progress, or springing an event on players without ample warning, is generally a negative thing. What exactly counts as ample warning is a somewhat vague and malleable thing, but a good guideline is that no player should be unaware or unprepared for an event when they join the round. Whether this means a few days of advance notice or a nearly unanimous player vote in favour of running an event, players should not have the expectation of a normal round before the round begins, or the desire to continue having a normal round should event staff be trying to push an event through without warning. Contact the administration, who will determine if a round is suitable for an event, and which of these measures are needed before an event can be allowed to run in said round.
Keep in mind that while using a round only needs a moderator's approval, consequences to players that may occur require an administrator's approval.
Volunteers
Events should have as many roles as feasible filled by volunteers. As a general rule, event staff should reserve only important roles or more difficult (read: needs server buttons often) characters for their own number. If possible, draft a few standby volunteers in case someone is unable to show up once the event arrives.
Volunteers should be designated prior to the event, and coached in advance on their characters and roles within the event. When selecting volunteers, pay attention to which players are more robust, versus which players are better at roleplay, so that they best fit their positions. Remember to establish limitations and rules for them in advance, so the event doesn't devolve into a gunfight or hour long boring meeting.
Running the Event
If the event is set up in advance, select a date and inform the playerbase that an event will be occurring. The more advance warning, the better, but too much and it'll lose hype. Try and choose a time where many players will be participating for the most important events.
Final Preparations
Ensure that all the volunteers are ready for the event before or as the round begins, so that the event doesn't fall apart right as it's about to begin. Keep one or two standby volunteers in the loop, just in case someone leaves midway.
Unlike regular OOC, AOOC is immune to regular ick/ock rules so long as the event team is moderating it and the event through it. Use this to your advantage for keeping the event running smoothly. Similarly, a private voice chat (or two) can be used to coordinate volunteers and staff live, should the event demand that precision in control, or just for the convenience of participants.
Event
When setting up the event, use assistance from as many willing staff as needed to speed up the setup. The timing of an event within a single round can heavily impact its difficulty - especially with Research players - so adapt for that as the event comes close to hitting.
And once you're ready, run the event!
Postmortem
With an event complete, there's paperwork to do to make sure that it's properly kept in the server's persistency.
- Record and log any relevant details that the event generated or interacted with, lore- or narrative-wise.
- Publish detailed news entries to ensure that any players who were not involved can be caught up to speed - especially for Arc events where players who didn't play a previous event might need to know what's going on for the next.
- Ensure that as many lore points as possible are logged for further use, lest they end up becoming dark lore that only some people are aware of.