Une idée de FI par semaine - Version CrocMiam

Création
41

Idée 14 : « interpréteur » avec traduction automatique à côté

Je mets des guillemets à interpréteur parce qu’on peut imaginer un concept similaire pour des jeux à choix, mais comme c’est généralement moins standardisé, je me concentre sur le parser ici.

Il s’agirait de faire une version de https://iplayif.com/ avec un split-screen :

  • à gauche le jeu original, avec son input pour les commandes
  • à droite le jeu traduit par un service de traduction et l’input désactivé

On peut déjà traduire une page avec nos navigateurs, même une page dynamique comme un interpréteur, mais avec les deux versions en parallèle, c’est bien plus pédagogique et ça permet de n’utiliser la version traduite que si on galère trop avec l’original.

Le guess the verb est déjà suffisamment pénible dans la langue du jeu, je n’imagine même pas si on essayait de traduire aussi les commandes, d’où l’input traduit bloqué.

3 « J'aime »
42

C’est vraiment une super idée sur un concept qui m’est cher :slight_smile: et la technologie a suffisamment avancé pour le permettre de nos jours. Y’a quelques années j’avais eu une idée similaire mais à base de « un jeu qui contient les deux versions du texte et utilisons le split screen de glulx » mais c’est relou et le split screen de glulx est pas super portable/stable il me semble. Bref oui tout à fait !

43

Oui, je me souviens de proto split screen multi langue, c’était très intéressant mais aussi très spécifique à chaque jeu. Là j’imagine un truc automatique (rien à faire côté auteur) pour faire un peu plus le pont entre les communautés.
Je ne sais pas si les anglophones qui testent nos jeux copient-collent les bouts difficiles dans un traducteur à côté, mais ça serait beaucoup plus pratique d’avoir les 2 en parallèles, avec les mêmes styles de texte. Il y a peut-être même des APIs de traduction qui pourraient donner la correspondance presque mot à mot et permettre de surligner le passage dans l’autre langue au survol.

44

Soit ça, soit avec un dictionnaire ouvert à côté, oui.

1 « J'aime »
45

Éventuellement, avoir un onglet récapitulatif avec les commandes de base dans la langue du jeu (celles qu’on trouve sur la carte postale, typiquement, mais dans un format moins imprimable et plus web, et peut-être avec des icones plutôt qu’une simple liste, histoire de retrouver plus facilement ce qu’on veut faire), ça serait une addition pratique pour ce genre d’outil.
La carte postale, c’est pas mal, mais ça reste un truc à imprimer, et elle est faite plus pour des locuteurs de la langue, savoir que je peux taper « prendre [truc] » ou « poser [machin] sur [bidule] », c’est très bien pour retrouver la bonne formulation si je sais ce que veulent dire « prendre » et « poser », mais c’est pas tellement fait pour ceux qui ne parlent pas bien la langue.

1 « J'aime »
46

Oui, c’est intéressant de récapituler les commandes de base, mais ça doit être fait à la main pour le coup. Cela dit, ça doit pas être bien dur de le faire pour une poignée de langues.

47

Oui, je pensais à le faire à la main, effectivement.

48

Idée 15 : Moteur multi-moteurs pour projet collectif :wink:

À 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.
2 « J'aime »