Skip to content

Rewrite classes that have statuses to act like state machines

Mikron edited this page Dec 5, 2018 · 3 revisions

This is a concept to be considered.

Concept

The idea is simple:

  • Every major class (Story, Character, CharacterSheet, Recap, etc.) has a set of n variables (n > 0) that define its state
  • An existing example that is closest to the concept: Session status
  • Variables have defined exits for each value, for example in progress session can move to interrupted or completed only
  • Most other parameters - like visibility are determined by statuses on save, and is stored in DB; this will result in denormalisation (as there will be fields in DB that depend on other fields), but this seems to be the only way to use them quickly and in the way they are used now (avoiding a strong refactoring); optionally, drop it into another table not to contaminate the original
  • States would be visible to GM, and in some cases to players

Possible variables for classes

Session

todo

Epic

  1. Once created, Epic is in In planning state and nothing is there yet, just the GM or even not them
  2. At this stage, everything is mutable without any warning
  3. To enter In preparation stage, several things have to be added
    • Some description - a new field or simply description box
    • At least one participant that is not the manager - you may need more than one, but lets assume only one will suffice; if created as GM, this is fulfilled
  4. More things can be added on later stages
    • Tags
    • Planned start date
  5. Once it is in In preparation state, list of participants cannot be emptied
  6. Most other states do not have limitations of required concent
  7. ... but concent may require certain state
    • Cannot add sessions in In planning, In preparation, Cancelled, Finished, Closed
  8. Possible states:
    • Proposed => In planning, Scrapped
    • In planning => In preparation, Scrapped
    • In preparation => In planning, Ready to start, Scrapped
    • Ready to start => Played, In preparation, Scrapped
    • Scrapped => In planning
    • Played => On hold, Lapsed, Cancelled, Finished
    • Lapsed => On hold, Resuming, Cancelled
    • On hold => Resuming, Cancelled
    • Cancelled => Resuming, Closed
    • Resuming => On hold, Played, Cancelled, Lapsed
    • Finished => Closed
    • Closed => none
  9. Clarifications:
    • Finished is an epic done, but not documented or archived. Closed is an epic around which there is little more to be done.
    • Scrapped is something that was planned, but never started. Cancelled is something that was happening but broke down on the way and is officially considered stopped without much chance of renewal.
    • On hold is something consciously paused, for any reason, with assumption it will be resumed when reasons end; there might even be some estimate when to resume. Lapsed is something that simply stopped being played for uncertain reasons and is in form of limbo.
    • In planning is something mainly Game Master works on: the epic can be announced, but nothing is set in stone yet: even mechanics can change dynamically. In preparation is a solid idea, a stage where characters are created and details discussed.
    • Resuming is an epic that is being un-cancelled or coming back in some way, but not yet operational; once a session is played, Played status resumes.

Epic states

Story

Publicity

  • hidden
  • to be published
  • public

Completness

placeholder, draft, in writing, written

Progress

planned, in progress, done

Character

Publicity

  • hidden
  • to be published
  • public

Completness

placeholder, draft, in writing, written

Recap

todo

Character sheet

todo

Group

todo