Moirai

[rossjrw]

AWS

Obviously we'll need some sort of recursive system and character randomisation, as well as enough different (discoverable) options for actually committing the murder.

At that point it'll definitely be easier to reserve rhyming couplets just for "cutscenes", if we're to have any at all, because having to rhyme each and every little thing would be awful. In some areas, it already is.

[rossjrw]

• Every character will need to be a possible playable character.
• Plum's memory loss was used as a cover for the lack of plot and to introduce an incentive to interview yourself. This IS still a concern - the first half of the game will be the latter chronologically, and the player will not be magically aware of their character's schedule.
• The player's character shouldn't be the initial murderer. Therefore, I can consider removing the whole having to defend yourself thing. If that's the case then players might not even need to be aware of their own backstory.
• • Their own backstory may contain critical alias information that would not be available without being able to interview their own character.
• Should there be just 1 schedule, or multiple? If multiple, each murder-solution chain should (must?) share the same schedule. If 1, that might be too easy to work out. There's some benefit to throwing in some ambiguity, especially if some of the schedules are similar.
• • The schedule should be informed by the actions of the previous player's character.
• There should be about a 60% chance of solving a murder successfully. Players should have to interview every character to be able to comprehensively certain, but this shouldn't be allowed. Ambiguity should be introduced by having to produce a premature accusation, and the challenge should be finding the most efficient route of choosing interviews.
• Given that each run will definitely consume a murder and has about a 60% chance of consuming one, murders will be consumed far more often than they're produced. It may be worthwhile to simply keep a count of how many times a murder has been "consumed", with those with lower counts having preference for selection.
• • A solved murder should not be solvable twice.
• • The murderer should be informed who solved their murder, who was interviewed, and how many times their murder was failed to be solved.
• • • Therefore, unlike Moirai, there is no win or lose condition - all murders will eventually be solved.
• • If a murder is solved but that player fails to produce a murder (perhaps they quit), should the murderer be notified and the murder marked as solved?
• • • Could handwave it that the murder was solved but the solver failed to produce a paradox?
• • • Just modify the effects of the anomaly to account for it somehow

Dear [name],

Despite your best efforts, you have been found guilty for the murder of [character]. Your deceit was discovered by [character name], codename [player's username if applicable].

Your counterselves in other timelines were more fortunate. [n] other attempts were made at undoing your murder. In [n] timelines, the murder was solved, but your (investigator?) failed to produce a paradox to undo it.

[rossjrw]

Database structure

Murders
Would store the submitted murders.

• rowid
• Time of submission
• IP?
• Account name associated with it
• Alternative name, if provided (should be the option to appear anonymous)
• Which character this player was
• What actions the player took
• Extra data, for example a message or deathnote
• The ID of the solution that was submitted before this murder (a solution alone cannot mark a murder as solved, there must be an accompanying murder) (alternatively, some session ID generated by the game that matches a session ID in the solutions table)
• Whether or not this murder has been claimed by a player
• Whether or not this murder has been solved
• Whether or not this murder is a seed (default murder for when there are none left and cannot be marked as solved)

Claimant count:

• should be a claimant count, incrementing each time this murder is sent to a new player to solve
• less-claimed murders are prioritised for sending out to players
• • there's an argument to be made for more-claimed murders to be sent to players, because then the oldest murders will be sent out first... hmmm, might need to think on that one
• • the main problem is that I have no way of unclaiming a murder, e.g. I can't send a signal when the player gives up and closes a tab
• should increment the instant a new game is started to minimise the chance of double-claiming
• if the player quits then it doesn't really matter, just means the murder will have a slightly higher claimant count, it will be claimed eventually
• • will it, though?

Marked as solved:

• a murder can only be marked as solved if both
• 1. a solution has been submitted for this murder (it is completed)
• 2. a murder has been submitted after that solution
• once both of these happen the murder can no longer be claimed and the user that made it should be emailed with their results

Solutions

• rowid
• Time of submission
• Username and email, if known - do not prompt for this information, solutions should be sent silently (not sure about this one, it's not even necessary)
• Possibly a session ID, see murders
• The ID of the murder that this completes
• Data associated with the solution e.g. who was interviewed, what questions were asked, what information led to the successful solution

Instead of claimant count, bluesoul suggests a timeout:

• Claiming a murder sets the current time to that murder's assigned_at field.
• Completing a murder sets the current time to that murder's completed_at field.
• Solving a murder (by both completing the murder and submitting another murder in the same session) does something something

I'm not sure how this all works. I'll have to sit down with pen and paper at some point