Event Checklist - Revision history

K5 at 01:18, 4 April 2025

2025-04-04T01:18:57Z

← Older revision		Revision as of 01:18, 4 April 2025
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's prerequisites. Once the GM has approved the event, it also ~~falls upon them to grant permissions~~ to ~~operators~~ as needed.		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 is up to their discretion when the event will be run. Some events will be also be added to the [[Preapproved Events\|list of preapproved events]] and can be run as needed in the future.

	=== 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.		Keep in mind that while <i>using</i> lore only needs a staff 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. Note that being merged does not necessarily mean being available for use: some entities may be merged but incomplete, or reserved for future use.

	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.		The GM has particularly strong discretion here: common features and entities can skip this check entirely. Keep in mind that while <i>using</i> code only needs staff coder approval, changes to code that may occur, like event rewards, 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		Additionally, keep in mind that the code is not always 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~~ ===		=== Rules Check ===
	~~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.		An event is a special circumstance, but that also means that it may be encouraged for players to break certain rules without the expectation of administrative consequence that you'd have on a normal 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.		Unless declared uncanon, Sojourn's rounds have persistence: an event that causes a department war, for example if both the Church and Soteria lay claim upon a crash-landed artifact, will likely be followed up with days or weeks of animosity between players, regardless of whether it has any lasting lore consequence.

			Unlike the other steps, these adjustments may be minor enough to need a sign-off from a single moderator, or major enough to need the entire administration to consider it. The GM will determine how much 'weight' of approval is needed before the event will be safe to run.

	== Volunteers ==		== 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.		Events should have as many roles as feasible filled by player 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.		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.

			==== Round Authorization ====
			Sojourn is, in principle, an HRP server. This means player-driven interaction takes the front stage. Before scheduling an event, the GM will contact the administration, who may determine that the current round has interactions that would be disrupted by the event, or that the event requires some amount of announcement (or secrecy).

			As a general rule, contact the most aware member of the administration first. In this scenario, a moderator actively observing the round outranks an admin who's not even logged into the game. GMs have a unique power to bypass this step under certain conditions.

	== Running the Event ==		== Running the Event ==
Line 56:		Line 63:

	=== Final Preparations ===		=== 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.		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.

Line 62:		Line 68:

	=== Event ===		=== 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.		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 present - so adapt for that as the event comes close to hitting.

	And once you're ready, run the event!		And once you're ready, run the event!

K5: /* Approval */

2024-11-18T23:09:58Z

Approval

← Older revision		Revision as of 23:09, 18 November 2024
Line 32:		Line 32:
	=== 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.

	~~However~~, 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		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. 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.		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 ==

K5: /* Approval */

2024-11-17T03:21:25Z

Approval

← Older revision		Revision as of 03:21, 17 November 2024
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 ~~and granting~~ permissions to operators ~~once the event is approved~~.		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 ===
Line 39:		Line 39:

	=== 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. If these ~~conditions cannot be met - either because the~~ event ~~is meant to~~ be ~~a surprise, or simply because there's a good opportunity~~ to ~~interfere~~ in ~~the~~ round ~~that would be lost - contact the administration for approval to override these requirements~~.		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.

	== Volunteers ==		== Volunteers ==

K5: 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..."

2024-11-10T06:49:21Z

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..."

New page

{{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 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 [[Event Archetypes|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 and granting permissions to operators once the event is approved.

=== 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.

=== 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.

However, 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 <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. If these conditions cannot be met - either because the event is meant to be a surprise, or simply because there's a good opportunity to interfere in the round that would be lost - contact the administration for approval to override these requirements.

== 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.