Skip to main content

Game Master policy

This document is meant to serve as a baseline of expectations for Game Masters and Trial Game Masters within the Sector Umbra project. It is intentionally broad, and will change over time as the needs of the community change.

General concepts

Any member of any of the teams of Sector Umbra is considered to be a direct extension of Project Management. Their actions represent Project Management as a whole, and they are authorised in such a way on the behalf of Project Management. For this reason, we define the following core values:

  • Continuous learning: As a member of the Umbra team, it is important to consider that everyone is a volunteer who is doing their best. It is therefore important to acknowledge that mistakes can happen, and it is even more important to take these moments as opportunities to learn for the future. The Project Managers do not consider a genuine mistake by an Umbra team member to be a mistake of the member, rather it is a mistake of the Project Managers in teaching this member that needs to be corrected.

  • Transparency & accountability: It is important for members of the Game Master team as well as other team members to be transparent and accountable about their actions. This builds further on accepting mistakes as a possibility that could happen to anyone at any time. For every action taken, we expect our Game Masters to be accountable, ensuring every step is warranted.

  • Professionalism & welcoming attitude: Sector Umbra aims to be an open and accepting platform for people to be who they want to be within reason. As one will be interacting with members of the GM team the most, we expect them to be welcoming and professional. Helpful and open. It's important for us to consider that the GM team is not just made up of yet another admin team, rather we imagine the role of the GM team as facilitators.

  • Privacy: As a member of the GM team, one gains access to a lot of information that is considered private. This ranges from private lore discussion about future events, to moderation records. From internal rule discussions, to whitelist background checking. This information is considered sensitive, and it should never be shared outside its intended target audience. Doing so in a major way, or doing so repeatedly, is grounds for removal.

    Additionally, certain types of information such as IP addresses, hardware ID's, ... have additional legal restrictions imposed on them. This information is only ever processed in accordance with our privacy policy. Violations of this are grounds for immediate removal.

In-game actions

General expectations:

  • Game Masters who choose to play during a shift must not have been adminned in the round (= not in the lobby) before. A playing Game Master is considered to be on the same level as any other player, except for the fact that they may choose to readmin during the round, but must then leave their character and spend the rest of the round as a Game Master.
  • Events, which have their own more specific section as well, must be conducted correctly. This means that testing things live which could have unexpected effects are generally strongly discouraged.

Rulebreaking behavior:

  • Above all, situations where a Game Master needs to handle a case which they themselves were a part of as a player must be avoided.
  • In general, due to the nature of our server, rulebreaking behavior does not occur often. However, it is still part of the primary duties of a Game Master to deal with conduct that goes against community expectations and standards.
  • When it is possible to deal with rulebreaking behavior via an in-character action, and the undesired behavior is considered to be minor enough to warrant this, the in-character action is preferred. This could range anywhere from sending a fax or announcement about a certain sensors scan to draw attention to someone's conduct from the required department, to ahelping someone on that department directly and giving them the in-character information they need to handle something correctly. Logging this is at the Game Master's discretion, and these actions do not count as an event.
  • If an in-character action is achieved via a disruptive method (i.e. ahelping another player, ...), the player who caused this must be informed via ahelp as well. It is the task of the handling game master to log this correctly.
  • When an out-of-character handling is required, it is the task of the handling game master to log this correctly via the admin notes system.

Punishments:

  • Bans and rolebans, dewhitelistings, ... are very rarely necessary, and are determined on a case-by-case basis. It is recommended that the handling Game Master seeks contact with Project Management to advise on the case.

Event policy (Scheduled sessions only):

  • An event is defined as a major Game Master intervention in the round with the purpose of making the round unique. This may or may not be tied to a player's prior request.
  • A major event is defined as events that impact more than 6 (= 7 or more) players, and/or more than 2 (= 3 or more) departments. All other events are minor.
  • Events are strongly preferred to be pre-planned and approved by the primary Game Master for the session. A pre-planned event needs to have been considered in terms of the following things: Start condition, end condition, projected departmental impact and mechanics (up to a technical level if necessary).
  • Unplanned events are generally discouraged, but can be held with approval of the primary Game Master, or another Game Master if the primary Game Master is the one proposing the event. Unplanned events must still have a consideration made about projected departmental impact. No more than one unplanned major event may generally be ongoing at the same time.
  • Trial Game Masters cannot approve events, planned or unplanned.

Unscheduled sessions:

  • During an unscheduled session, identified by a server member making a ping to the role, in-game actions are generally limited to actions that would prevent the round from ending prematurely during low populations, such as setting up distro, placing down a debug generator, saving a downed salvager by bringing them back to the station using admin tools, ...
    • When population (= number of active players) is lower than 5, no other events may occur.
    • When population becomes 5 or above, minor events are permitted.
  • Unscheduled sessions happen on the Extended game mode, unless specifically requested otherwise and approved by a Project Manager.
  • At most one Game Master may choose to remain adminned while playing one of their own characters. Ghosted Game Masters or Game Masters playing ghostroles do not count towards this limit, but it is encouraged to keep the number of adminned Game Masters low.
  • Project Managers may always remain adminned during unscheduled sessions. Adminned Project Managers do not count towards the limit imposed by the previous point.
  • Project Managers reserve the right to end the shift early at any time, even expeditiously, when the server is required for other purposes. These purposes do not need to be disclosed.

Other usages of the server outside of sessions:

  • Outside of a scheduled or unscheduled session, a couple of types of usage are still permitted:
    • Game Masters may use the server for testing event ideas mechanically, as well as further refining their own skill in admin tooling. Trial Game Masters may use the same provision, but are encouraged (not required) to seek supervision from a mentor while doing so.
    • Players may connect at any time the server is up to edit their character.
    • Players may also join the shift to help Game Masters test their ideas at the request of the Game Master.
    • Lastly, players may run their own special private events on the server with assistance of Game Masters or Project Managers. Please contact one of these people to get started.
  • In general, only events during scheduled or unscheduled sessions are considered part of continuity, unless otherwise stated by a Project Manager.

Limited or restricted actions

Certain actions are generally undesirable. This lists those actions, such that it is known these should be avoided.

  • It is undesirable for ceremonies, court cases or other events to be held on central command which request high attendance, and these should be kept to on-station scenarios during scheduled sessions or unscheduled sessions. This is justified as follows:

    • These events (trials, promotions, awards, ...) will place a subset of the players in the spotlight, and will cause other players to feel left out for various reasons, be that inability to attend, not having received the same gesture when they made a similar achievement, or other reasons.
    • In the universe of the Umbra Sector, NanoTrasen is a competitive megacorporation and everything NanoTrasen does for its employees has some sort of competitive reasoning behind it. Generally, hosting events like this on Central Command cannot be justified correctly. In a sense, Central Command does not care.
    • Events where maximum attendance is invited are generally drawn out long and may be experienced as genuinely boring by players not in the spotlight at the time. Sector Umbra is an open platform focused on allowing the players to explore their own capabilities, and being forced to attend something they may not want to, but must for reasons of social pressure, is not something we consider to fit in that ethos.

    It is expected from Game Masters to identify these events before they happen, and to prevent them from happening, explaining to the player why this choice was made.

Back to top