Packets

This game has a number of mechanisms for distributing information between GMs and players. They are:

  • Packets (GMs to players)
  • Queued Messages (GMs and players, to other players)
  • Quests (effort-tracking, player-initiated, but which can be GM-supplemented)

In general, these mechanisms serve some combination of the following three roles:

  • They track the progress made towards a particular goal.
  • They provide guidance as to the sorts of things necessary to accomplish a goal.
  • They provide secret information which needs to be revealed on-demand.

What's a Packet?

Conceptually, a packet is equivalent to, in real-world analogy, a folder with a bunch of sealed envelopes in it. Each envelope is a section of that packet, and each envelope is sealed. Each section contains a secret, which you can read when you unseal it. There are requirements and possibly costs to be paid for unsealing a section, and there may be results beyond revelation of a secret when a section is unsealed.

What are packets for?

A packet is a little bit like a portable GM. A packet allows a GM to lay out a plot, or an investigation, in advance, then hand it to one or more players, and let them play it out at their own pace. It means that things can be "GMed" without the GM needing to be online, and in most cases, it allows multiple players to cooperate in an adventure or in a discovery. They can get the story and/or facts revealed to them, bit by bit, as they need it.

Packets are generally created in response to some kind of player request. These requests typically fall into the following categories:

  • Player investigation of something that is beyond the scope of normal prop control. (Generally, this will be a cosmological investigation or an investigation into the ancient past, and is typically focused on multi-player cooperation to discover something.)
  • Player interaction with cosmological forces. (Generally, this governs attempts to do unusual things beyond the scope of normal gifts, and is typically adventure-oriented.)
  • Player pursuit of an external agent's agenda. (Generally, this substitutes for having to have GMs play NPCs for opposition such as NPCs of the Black Road, and is likely oriented towards scene seeds.)
  • Plots spawned by player-GMs and propcos, who want the convenience of packetized information.

A packet, in short, tends to substitute for a thorough and lengthy mailed explanation from a GM — they are typically intended to anticipate all the questions that a player might ordinarily have for a GM throughout the course of an investigation or plot. A packet breaks the information and play hooks down into bite-sized chunks, and keeps track of who's done what, making it easier for people to run complex plots. Because packets typically require significant cosmology and story fabrication on the part of the author, they take a while to generate, and thus, will generally be written solely in response to player requests.

Just like lore text, packets are not gospel truth; their revelations may contain experiences and acquired information, but that acquired information might be obscured or even outright untrue. Moreover, playing through a packet is not a guarantee of a positive outcome. In some cases, packets may be generated in response to a player-instigated investigation that leads to a dead end, for instance. In other cases, packets branch, and depending on the choices made, some end-state scenarios may be more attractive outcomes than others. Packets generally do not lead to an explicit reward, although some packets may provide training or other access to gifts or lores.

The structure of a packet

Every packet has a packet number, a creator, a creation time, and a subject (which describes what the packet is about). It also has one or more sections.

Every packet section has:

  • A seal, describing the IC conditions that must be true in order for the section to be unsealed.
  • Optional view prerequisites, describing the prereqs that must be met to see the seal condition.
  • Optional unsealing prerequisites, describing the prereqs that must be met to unseal the section.
  • An optional cost, which is the Focus that must be paid to unseal the section.
  • An optional action list of RPG effects that are executed when the section is unsealed.
  • A description, which is revealed when the section is unsealed.

To check what packets you have, type +packets
To look at a summary of all the seals on a packet that you have, type +packet packet-number

Obtaining a packet

Packets are typically created by the GMs in response to player requests for information. Such packets are then given to the player who made the request, or distributed to everyone that the GMs believe should have a copy. They can then circulate through play, as players can share packets with one another.

There are also "public" packets, which are made available for anyone to take, if they meet the prerequisites.

To see if there are any public packets available to you, type +packets/list
To read a packet's introduction and find out whether you want it, type +packet packet-number
To take a public packet that's relevant to you, type +packet/take packet-number

Unsealing a packet section

When you look at a sealed packet section, it will tell you:

  • The Focus cost to open it
  • What prereqs must be met to see the seal (the "View Reqs" line), if any
  • If you can see the seal, what prereqs must be met to open it (the "Requires" line)
  • If you can see the seal, the seal condition

To decide whether or not to open this section, first read the seal condition. Typically, the seal will either describe an IC circumstance (i.e., "unseal this section when you open the box"), or a description of something that you can investigate (i.e., "the book you've found has a red leather cover") and implies "unseal this section when you investigate this". The seal may also consist of an explanation of what's meant by things on the prerequisites line (the prerequisites may imply IC conditions as well, such as being in a certain place). Don't try to unseal the section until that particular IC condition holds true.

If there is a Focus cost, you need to have that many points of Focus available to you — it will be spent when you unseal the section. There may also be a "group" Focus cost. If it has a group Focus cost, other people can donate Focus to you to open it (representing their time and contributions), but if they do so, the total cost will be the group cost (which is normally higher than the individual cost, reflecting the inefficiency of cooperation).

You will also need to meet the requirements, which take the form of a prereqs list. This may require you to have certain gifts, certain lores, be holding a particular token, be in a particular room, etc., when you unseal this section.

To unseal a packet section, use:

+packet/unseal packet-number/section-number

If you have everything you need to unseal a section, but lack all of the gifts and lores necessary, you can usually get one other person to help you. (Some sections can't be cooperatively unsealed; sometimes it doesn't make sense to have help.) If someone else cooperatively unseals a section with you, you'll be able to use their gifts and lores in addition to your own (but NOT their tokens, other open packet sections, etc.). To do this, use:

+packet/unseal packet-number/section-number with player

This is otherwise basically identical to unsealing the section on your own — the player who is helping you does not see what you unsealed, and if he has the same packet, the same section is not simultaneously unsealed for him.

What happens after you unseal a packet section

Some packet sections might have an action list. An action list can do various things — it could teleport you to a secret room, grant you a lore, grant you training towards buying a lore, or alter a doom counter, among other things.

However, the meat of a section is its description. To read the description of a section, type:

+packet packet-number/section-number

To show a packet seal of a sealed section, or the description of an open section, to other people, type:

+declare packet:packet-number/section-number to targets

Typically, a section description will be one of two things — a description of what you find, or the set-up for a scene. Findings are typically intended to be played out in a scene, at your discretion. Scene set-ups are intended to essentially allow self-GMing of scenes. Sometimes, such set-ups will include descriptions of NPCs or the like; you may ask another player to come play NPCs in the scene, if you'd like.

This is particularly key: Packets are intended to facilitate opportunities for scenes. Do not rip through a packet, read everything, and not play things out.

Sharing packets

Most packets are not intended to be solo endeavors. Usually, no individual player will be able to unseal every section in a packet by himself; he will need help, and in many cases, other people can also individually investigate the same thing. In the majority of cases, anyone who discovers a particular triggering event or comes upon a circumstance (such as a room in which a murder was committed) can obtain a packet.

A player who has a packet can share it with other people using:

+packet/share number with person

A player who has opened a particular packet section may be able to reveal it to other people. Not all sections can be revealed. Revealing lets the other person open the section, just as if he were unsealing it himself, but usually at a likely lower cost and less difficult prerequisities.

Sections that can be revealed have a reveal price in Focus, which is paid by the person whose section is being opened (i.e., not the person doing the revealing, but the person who is the target of it). Sometimes, this price is 0, making the reveal free.

Sections that can be revealed may also have reveal prerequisities, which are the prereqs that must be met by the target of the reveal. These prereqs are used instead of the normal unsealing prereqs.

To reveal a section to someone else, use:

+packet/reveal packet/section to person

Group Packets

Packet progress is ordinarily on an individual level; every person working on the packet has their own copy, and opens up sections on a personal basis.

However, some packets are marked with the "group" flag. These packets are "single track", collaborative group packets. This means that everyone's progress towards opening the packet is tracked in common; i.e., what if one person with the packet unseals a section, everyone who has the packet will have that section unsealed.

When you try to do a sign-off on a group packet, attach a token, have pre-reqs checked, etc., the code will automatically take care of making sure that these things go to and read from the group track. From your perspective, a group packet shouldn't require you to do anything differently from the way that you normally interact with packets.

Scene Seed Packets

Many packets, particularly those that are self-training for lores at 6+, are structured in such a way that they are simply a framework for scenes. These packets contain a large number of scene seeds; each scene seed is basically a dramatic framing device, with the details left to you.

The scenes in those packets are typically broken down into groups that are thematically organized. For instance, one scene in a group may tell you to go into shadow and retrieve an exotic plant; another scene in that group might tell you to go into shadow and hunt a mystical beast; and one more scene in that group might tell you to go into shadow and obtain a particular type of item. Most scene groups have a "gateway" section that, when unsealed, make the scene sections within that group available for unsealing; the group concludes with a "reward" section that, when unsealed, ties the group together and dispenses a small reward. Such packets usually have a final conclusion section, which you can unseal when you've completed all the groups; it usually provides a small bonus reward. We utilize this structure to make the packet flow more manageable, and to provide incremental rewards along the way, while still encouraging people to make the effort to finish the whole thing.

How a Scene Seed Works

Here are two typical scene seeds:

  • There is a matter between you and another person which is unsettled. Perhaps it is an old debt, an old score, an apology which should have been given but has gone unsaid, etc. Whatever it is, you feel the urge for closure on the matter, and settle it with that other person.
  • Encounter someone (a PC) who can accompany you on a physical adventure of high danger (probably of an "extreme sports" nature). You must be pushed to your physical limits and experience utter exhaustion. At some point during this, you must find yourself in a situation where you can either save yourself or save your friend, and make a decision; one of you must take a consequence as a result of your choice.

Basically, a scene seed is simply an idea for a scene. Some scene seeds, like the first, are very simple; others, like the second, can be quite complex. Simple scenes, which are typically just conversations, will probably take an hour to play; complex scenes are usually "adventures" and may take an entire evening and incorporate many elements.

The Mechanics of Unsealing a Scene Seed Section

Usually, to unseal a scene seed section, you will need to obtain the sign-off of one or more other players. The idea is that you go out, grab a person (or a few people), and play out the scene. Then, when it's done, you ask one or more of those players to sign the packet section.

You can tell who can sign off on a section by looking at the prereqs for that section. They will typically have one of the following:

  • sigcount:N - You need N people to sign the section.
  • signreq+N:prereqs - You need N people who meet the prereqs to sign the section. The list of prereqs is given as req1.req2.reqX; the signer needs to have all of those reqs.
  • signstat+stat:total - You need to achieve a sum of total by adding together the stat (Force, Grace, Wits, or Resolve) of all signers.
  • sign:character - You need the named character to sign the section.

Someone can sign off on your packet section with:

+signoff your-name's packet/section

If someone is cooperatively unsealing a packet section with you, they will also automatically sign off on it. You can get someone to cooperate with you, by using:

+packet/unseal packet/section with other-person

Rules for Unsealing Scene Seed Packets

Explicitly, the purpose of a scene seed packet is to drive play, and therefore, we want you to actually play through the scenes as you go through the packet. It is never permissible to handwave the scene. Opening packet sections without playing the scenes is explicitly considered to be cheating and, if discovered, will result in penalties not only to the packet holder, but to those assisting the cheating by signing off under false pretenses. (We encourage you to log these scenes, so if any questions are raised about the legitimacy of an unseal, a log can be reviewed.)

Scenes also cannot be "double counted" against multiple scene seed packets. You can, as a group, all play through the same section of the same packet and have it count for everyone relevant, but even if that scene fulfills the requirements of scenes in multiple packets or multiple sections of the same packet, you can only unseal one section per played scene.

Moreover, we intend for scene seed packets to drive diverse play, including encouraging you to seek out those that you might not have played with before or do not play with frequently. Consequently, many of these packets enforce signoff diversity requirements.

The reward section of a scene group will often contain a prereq of sigspread+N:sections
This indicates that, across the signoffs on the listed sections, you need to have gotten signoffs from at least N characters. So, for instance, if you were asked to go collect a plant, go collect an animal, and go collect an item in three different scenes (as packet sections 10/5, 10/6, and 10/7, say), each with sigcount:1 as the seal prereq, and the reward section for the group reads sigspread+3:10/5.10/6.10/7, it means that you needed to ask 3 different characters over those scenes (i.e., one different person each scene).

The final reward section of a scene seed packet, and potentially some other sections as well, will often contain a prereq of sigalts+N:sections. This works exactly like the sigspread prereq, but it is for players rather than characters. In other words, if you got signoff from multiple alts of the same player, they only count once. In short, you can't go to a small number of players, get the cooperation of all their alts, and finish that packet; you must genuinely seek out a wider RP circle.

There are a few packets that use a timelock rather than, or addition to, requiring signatures. These packets typically have no Focus costs to unseal most if not all sections. A timelock means that time separation is enforced; a certain number of minutes must pass between the time you unseal one scene seed section, and the time when you unseal the next timelocked section. The timelock is intended to prevent people from simply ripping through these packets instantly. It does not represent when you should be continuing to do the next unseal, but rather the absolute minimum interval between starting two seeds; it simply acts as something of a traffic cop to try to discourage cheating.


Quests

Quests are basically free-form scene seed packets which can be written by anyone. Rather than providing a specific, section-by-section structure, quests require a certain total number of scenes, an optional amount of Focus and involved players to complete. They are used to track efforts towards particular goals. They're useful for a number of things, including:

  • GM response to player requests to work towards audacious goals, setting a framework and level of effort for achieving those goals.
  • Keeping track of collaborative efforts ("single track" group efforts, rather than individual ones).
  • Keeping a record of your scenes towards a particular goal you're pursuing.
  • Player-to-player goal-setting and tracking, usually within a particular prop.
  • Record-keeping for conflicts.

The Structure of a Quest

A quest begins with a goal — the thing that you're working towards. In most cases, it will be a unique IC effort of some sort, but some quests will be common to many people (for instance, quests for learning higher levels of certain lores).

A quest also has a description, which explains how it is that you're going to accomplish that goal. This provides the general context and structure for the scenes that you're going to have in the course of completing this quest.

Next, a quest has a level of effort necessary. This is expressed in four ways: in the number of scenes required, in a Focus cost, in terms of number of involved characters, and in terms of number of involved players (with all alts of a player counting only once). The Focus cost can be gradually paid throughout the course of the quest. The involved people must sign off as participants in the scenes that you run for the quest.

Finally, a quest may have certain RPG pre-requisites that you must meet before you are able to complete it.

Rules for Quest Scenes

When you play through a quest, you do a series of scenes that are thematically appropriate to the quest's description. When you're done with each scene, you should do the following:

  • Figure out the current scene number. +quest ID will tell you what the next scene number should be.
  • Write a summary of the scene, with +quest/scene ID/scene
  • Ask the characters who participated in your scene to sign off on it, with +signoff yourname's quest/scene
  • If necessary, edit and post a log, and record its URL with +quest/log ID/scene = URL

You will need to write the scene summary, or fill in a log URL, before anyone can sign off on that scene. You can fill in a placeholder summary quickly, and come back to edit the scene details later, if you want.

Explicitly, the purpose of tracking quest efforts is to drive play, and therefore, we want you to do real, meaty scenes for the quest. It is never permissible to handwave any scene in a quest. Writing a description of a scene that never actually happened, or faking a log for one, or having people sign off who weren't direct participants in the scene, is explicitly considered to be cheating and, if discovered, will result in penalties to all players involved — if you help someone else cheat, you're accessory to the crime, and we'll treat you accordingly. For some quests, the GMs may require that the URLs of logs be provided for each scene.

Any given scene should only count once against any player's set of quests or packets; it is acceptable for a scene to count against a single quest or packet for multiple players, but it must not be "double counted" for any given player - even if a scene fulfills the requirements of scenes in multiple quests, multiple packets, or multiple sections of the same packet, a scene can only be used by a character for one single thing.

Completing a Quest

When you have met all the requirements for the whole quest, use:

+quest/complete quest

to finish the quest.


Queued Messages

Queued messages are basically single-section packets which can be written by anyone. They're useful for a number of things, including:

  • Questions that GMs (or people running plots) have anticipated players asking, and which they are proactively answering.
  • Responses to questions that people have already asked, where a player should not receive an answer until his character is in a particular IC circumstance.
  • Player-created packets (just chain a bunch of queued messages together)

Using Queues

To see which messages are queued up for just for you, type +queue.
To see messages that anyone can access, type +queue/public.
You can look at just the new messages, private or public, since you last checked: +queue/new. This uses a timestamp, to be sure that each time you check for new messages, you only get ones you have not seen yet.
If you want more information on any queued messages, type +queue <list> The 'list' can be either a list of queue IDs, or the key word all.

If you receive a queued message, or can see a public message, you can attempt to retrieve it. If you meet the individual pre-reqs for it, it will be delivered to you via +mail. You can also try to cooperatively unseal it with someone else, meeting the cooperative pre-reqs for it; if you do this successfully, it will be delivered to both of you via +mail.

To attempt to look at the inside of a sealed message, type +queue/unseal <number> [with <player>].
Examples:

+queue/unseal 01b with Alonzo
+queue/unseal 413.

If you need help understanding the prereqs on a queued message, use the command +reqs qreq:<queue ID> to check the individual prereq, and the command +reqs qcoop:<queue ID> to check the coop prereq.

Writing Queues

To begin writing a queued message, use +queue/add <subject>. The subject you choose will be used as the subject of the queued message when it's delivered in +mail, and will show up when the recipients look their +queue. You will get back a queue message ID number. '+queue/list' will show all of the queued messages you've written that haven't been retrieved yet.

Next, type +queue/seal <queue ID>[=<text>]. This will set the text of the message's seal, or, if you didn't specify text, it will invoke the editor. The seal should be an explanation of the circumstances under which this message should be retrieved.

Then, type +queue/desc <queue ID>[=<text>]. This will set the text of the message itself, or if you didn't specify text, it will invoke the editor. This is what is discovered when the message is successfully unsealed.

Now, you're ready to set the prerequisites that the unsealing player needs to be able to personally meet. Use +queue/req <queue ID>=<prereqs> to set this.

By default, a queued message cannot be cooperatively unsealed (prereq of LOCKED). If you want to change this, use +queue/coop <queue ID>=<prereqs>. This will require the unsealing player to be able to pass that list, but he can do so with the help of one other person's gifts and lores.

You can proofread the whole thing with +queue <queue ID>.

You can now send the queued message to other people. To do so, use +queue/send <queue ID> to <list of players>. This will put the message in those people's queues. You can use this command to add more players at any time. If you change your mind, use +queue/retract <queue ID> from <list of players> to remove it from one or more people who haven't yet retrieved it.

You can continue to edit the seal, desc, and prereqs up until the point in time that someone unseals the message (and GMs can still do so afterwards). Use +queue/delete <queue ID> to delete a message. Deletion works even if it's already been sent, but it will not be removed from the mailboxes of anyone who already has retrieved it.

rpg
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License