Idée 15 : Moteur multi-moteurs pour projet collectif 
À chaque évocation d’un projet collectif de création de FI, il y a un moment où on parle de faire chacun un bout dans sa techno préférée et de trouver un moyen de coller le tout et de permettre un minimum de communication entre les parties.
J’imagine une page web avec un peu de JavaScript, que j’appelle le Chef d’Orchestre, et qui aurait pour rôles :
- de gérer un annuaire des points d’entrée de chaque partie, par exemple :
gondole => Twine "venise.html" / passage "debug gondole" fenetre_palais => Twine "venise.html" / passage "accès fenêtre 1er nord" cave_1 => inform "sous_sol.gblorb" / passage "entrée réseau de galeries" - de gérer des variables partagées, de recevoir des changements et de les exposer aux différentes parties
has_toolbox = true has_iron_key = false beacon_1_lit = true beacon_2_lit = false pet_name = "CrocMiam" pet_lives = 7 - de charger les moteurs et d’afficher le bon jeu quand une partie demande à passer à une autre
Et pour chaque techno, il faut préparer un template de base qui permet :
- de demander au Chef d’Orchestre de lire ou écrire la valeur d’une variable partagée
~ set_shared_var("has_iron_key", true) # ink let has iron key be the shared variable "has_iron_key"; [inform] - de gérer l’arrivée dans le jeu sur un passage précis
- de demander au Chef d’Orchestre de passer à un autre jeu (via l’annuaire)
(link:"Descendre à la cave")[(go-to-external:"cave_1")] <!-- Twine -->
Je pense qu’il est techniquement possible de faire rentrer dans ce système : Twine, ink, inform 6 et 7. Le gros qu’il manquerait, c’est Moiki.
Édité pour ajouter :
- bipsi/binksi me semblent compatibles également, vu les larges possibilités de scripting.
- il faudrait aussi prévoir un mode « développement » qui permet de tester sa partie en isolation. Ça permettrait de tester les arrivées/départs et de manipuler les variables.