Thursday, January 22, 2015

Proposal: Mission Creep

Reached quorum 5 votes to 0. Enacted by Kevan.

Adminned at 23 Jan 2015 23:01:24 UTC

In the rule “Missions”, replace “A new Mission may not share its System with any other Pending Mission. The Team Size must be an integer between Quorum and the number of Androids, exclusive.” with:-

Each Mission’s System is chosen at random, and its Team Size is a random integer between the number of Androids and Quorum, exclusive.

Replace the second paragraph with:-

The Responder Team for a Mission is a group of Crewmembers equal to the Team Size. When a Mission begins, the Computer should select a number of random Crewmembers equal to the Team Size (those who happen to be nearest to the problem), and announce it in a comment to the post: this is the Responder Team for the Mission. In comments to the post, Crewmembers may vote FOR or AGAINST the Responder Team. If the post has a Quorum of FOR votes, including votes from every member of the Responder Team, the Responder Team is approved: the Computer may process the Mission as Attended. If a Mission is more than 72 hours old and cannot be processed as Attended, the Computer may process it as Unattended.

At any time, the Pilot may post a comment (known as a “Roster Comment”) to the post listing a number of Crewmembers equal to the Team Size: if he or she does so, this group becomes the Responder Team for the Mission and all votes on that post made previously to that Roster Comment are ignored for the purposes of this rule.

To the “Sabotage” rule, add:-

An Android may prepare to Sabotage a specific Mission by sending a Private Message to the Ship’s Computer informing it of this intention.

Remove the paragraphs beginning “A Mission is Completed…” and “A Mission Fails…” and in the place they occupied add:-

When a Mission is processed, the following steps are taken in order:

  • Each System whose Severity is not “None” has a 50% chance of having its Severity incremented.
  • If the Mission is Attended, and if an Android is among its Responder Team and has prepared to Sabotage the Mission, the Mission fails as if it were Unattended.
  • If the Mission is Attended and the previous condition was not met, then the Mission succeeds, and nothing happens.
  • If the Mission is Unattended, the Severity of its System is incremented once.

The Mission is then over, and no further actions can be taken on it.

Trying a few fixes: randomising the Mission generation so that I don’t have to gamesmaster it; giving them default random Teams which the Pilot can overrule (resetting the voting); assuming that everyone is Repairing unless they send a Sabotage intention to the Computer (which they can do in advance of being picked); having Success/Failure as a Computer action rather than an automagical effect dependent on secret Computer knowledge; and tying the ongoing Severity increases to subsequent Mission processes (and making it tracked rather than remembered).

posted by Kevan at 22 Jan 2015 10:40:00 UTC Comments (5)

Comments

Sylphrena:

22-01-2015 18:08:43 UTC

for

Bucky:

22-01-2015 18:41:30 UTC

imperial

Skju:

22-01-2015 19:16:48 UTC

for Although the Roster Comment paragraph seems a little vague.

And shouldn’t it be restricted to not-Attended Missions (or does it not matter)?

Kevan: he/him

23-01-2015 08:52:51 UTC

The Roster Comment paragraph isn’t doing much, it’s just changing the list of Crewmembers that make up the Responder Team, and invalidating any votes cast on the previous Team. I can’t see that it needs to say anything more - am I missing something?

“Attended” is just a keyword that gets briefly passed to the Mission-closing mechanism, and then “no further actions can be taken” on the mission.

ais523:

23-01-2015 22:43:35 UTC

for