Claim, Adopt, Fork

La mécanique centrale de Suddenly permet aux personnages de traverser les fictions. Un PNJ mentionné dans un compte-rendu peut être réclamé, adopté ou dérivé par un autre joueur via trois actions distinctes.

Les trois types de lien

TypeSignificationRésultatPNJ original
Claim"Ce PNJ était mon PJ depuis le début" — rétconPNJ remplacé par le PJ existantRemplacé
Adopt"Je reprends ce PNJ comme mon PJ" — transfertPNJ devient le PJ du demandeurTransféré
Fork"Mon PJ est inspiré de ce PNJ" — dérivationNouveau PJ lié, PNJ reste intactConservé

Statuts d'un personnage

Un personnage commence comme PNJ libre et évolue selon les demandes acceptées :

NPC → CLAIMED  (rétcon : le PNJ était le PJ depuis le début)
NPC → ADOPTED  (transfert : le PNJ devient le PJ du demandeur)
NPC → FORKED   (dérivation : nouveau PJ lié, PNJ conservé)

Contraintes métier

  • Claim — nécessite une cohérence narrative : le PJ proposé devait pouvoir être présent à ce moment
  • Adopt — interdit si le PNJ est déjà réclamé (CLAIMED) ou adopté (ADOPTED)
  • Fork — pas de contrainte de cohérence stricte, les deux personnages coexistent
  • Conflit — si deux joueurs veulent le même PNJ, le premier à envoyer une demande bloque les autres (statut PENDING)

Flow Adopt (exemple)

Bob voit le PNJ "Viktor" dans un compte-rendu d'Alice :

  1. Bob envoie une Adopt Request avec un message narratif
  2. Alice reçoit la notification "Bob veut adopter Viktor"
  3. Alice accepte avec une réponse narrative
  4. Le système crée un CharacterLink de type Adopt
  5. Viktor change de statut : ADOPTED, propriétaire = Bob
  6. Une SharedSequence est demandée aux deux joueurs

Cross-instance (fédération)

Quand Bob est sur une instance différente d'Alice, la même mécanique fonctionne via ActivityPub :

  1. Bob envoie une Adopt Request depuis son instance B
  2. L'instance B publie un Offer activity vers l'inbox d'Alice (instance A)
  3. L'instance A notifie Alice
  4. Alice accepte — l'instance A publie un Accept activity vers l'inbox de Bob
  5. Le lien est visible sur les deux instances

Toutes les requêtes ActivityPub cross-instance sont signées avec HTTP Signatures (RSA-SHA256).

SharedSequence — règle MVP

Un lien sans SharedSequence est invalide. Après acceptation d'un lien :

  1. Le lien est accepté → notification aux deux joueurs
  2. L'initiateur rédige sa partie de la scène (Markdown)
  3. L'accepteur complète la scène
  4. Les deux valident → publication sur les deux instances
  5. La SharedSequence est visible dans les deux parties concernées