[I7(i6)] Des descriptions "riches"

GorgeRonde · Mars 9, 2010, 7:40

bonjour,

je suis nouveau dans le monde de l’if, aussi bien en tant que joueur qu’en tant qu’écriveur/programmain.

L’idée que j’ai pour ma fiction, c’est tout d’abord de créer un jeu en temps réel, par opposition au tour par tour. J’ai commencé à programmer le moteur temporel, en « injectant » du code i6, que je comprend assez bien puisque je connais le c et le java. Pour le moment je me débrouille de ce côté-là.

Pour organiser mon code, et afin d’avoir plus de variété dans les descriptions des choses et des pièces, j’ai pensé à utiliser des tables : cela me permettrait d’associer une description à un jeu de conditions nécessaires. Pour vous donner une idée ca ressemblerait à ça

Table of Example
desciption …condition
« a »…whether or not it is after 10:30 PM and joe is dead
« b »…whether or not it is before 10:30 PM and joe is alive
« c »…whether or not the box is open
« d »…if joe wears a wolley

Mais voila. On ne peut mettre dans les tables que des objets et des valeur. Et encore si elles sont constantes.
Je me demande donc comment pouvoir réaliser ce genre de truc.
Est-ce que je peux modifier la façon dont se comportent les tables dans inform 7 ? Ca me semble peut-être assez lourd…

Je me suis dit aussi que je pourrais écrire les conditions sous forme de string, puis les parser afin de déterminer quelle est la description qui convient le mieux à la situation. D’une part ca me permettrait d’éviter des conflits entre différents jeux de conditions, par exemple en déterminant un score pour chaque ligne de la table, et d’autre part ca me permettrait d’établir un système de priorité.
Par exemple et je fais ca en brouillon, donnons que

« $–B 8:00 PM ; 3–joe is dead » = Si(impérativement(=$)) il est avant(=B) 8 heures du soir et(=;) si(avec une priorité de 3) joe est mort
« $–A 5:00 PM ; 5–joe is dead » = Si(impérativement(=$)) il est après(=A) 5 heures du soir et(=;) si(avec une priorité de 5) joe est mort.

et que il est 7:00 PM et que joe est mort.

Alors 1 aura comme score 3
et 2 aura comme score 5.
Du coup, le programme optera pour la description attachée à la condition n°2.

Mais si il est 4:00 PM, alors dans ce cas la première partie de la condition n°2, c’est-à-dire qu’il soit impérativement après 5:00PM, n’est plus remplie. Auquel cas le programme opte pour 1.

Alors d’après vous, est-ce que cette idée de string est la bonne solution ?
Je précise que je tiens à cette idée de table, ca me clarifierai beaucoup la tache. En effet, ce que je repproche au IFs auxquelles j’ai jouées jusqu’ici, c’est principalement leur manque de richesse dans les descriptions. Celles-ci varient peu et lorsqu’elle le font c’est uniquement pour servir l’intrigue.
J’aimerai plutot construire mon IF sur la notion d’un monde dans lequel le joueur aurait l’occasion de remplir plusieurs mini-quêtes, et j’aimerai vraiment porter l’accent sur cette sensation de liberté chose qui je pense repose en grande partie sur des descriptions riches et variées.

Bien sur je reste ouvert à tous types de conseils.

Autre chose,
Existe-t-il des jeux en temps réels ? Ceux que j’ai pu trouver sur l’ifdb, n’étaient pas des fictions interactives mais des jeux d’arcade. Aussi, existe-t-il des jeux qui n’attendent pas forcément une commande de la part du jouer pour imprimer du texte ?

merci

Mule_hollandaise · Mars 9, 2010, 12:29

Salut,
Je ne suis pas un pro de I7, et je laisserai les pros te répondre plus particulièrement, mais je pense pouvoir donner quelques indices tout de même.
Je pense que programmistiquement parlant, utiliser des strings est encore la solution la plus générale et diversifiée pour stocker des informations, même si faire un parser est toujours lourd – mais faisable.
Juste une question : pourquoi ne pas faire des gros If…Else… dans ton objet, tout simplement, voire des switch avec une variable locale ? (ça par contre ça peut être lourd, parce qu’il faut penser à tout bien updater quand tu modifies le monde suite à une action, mais…) Est-ce justement une contrainte imposée par le temps réel ?
Sinon, pour le temps réel, ça peut être une bonne idée, et j’espère que c’est pas trop difficile à programmer, vu que ça doit t’obliger à réécrire le parser ! (enfin, pas la façon dont c’est parsé, mais la façon d’acquérir les strings d’input du joueur) Cela étant, je n’ai pas d’exemple en tête pour des fictions interactives en temps réel – je pense bien que ça n’existe même pas, du moins ça n’a pas du tout été développé pour le moment. Tu serais donc pionnier
En tout cas bienvenue ici, en espérant que tu trouves une réponse à toutes tes questions

Akien · Mars 9, 2010, 1:12

Pour quelque chose se rapprochant des fictions interactives et en temps réel il y a les MUD.
Maintenant je ne sais pas si le style de jeu d’un MUD a déjà été transposé en jeu offline/solo.

Stab · Mars 9, 2010, 2:44

Pour le temps réel il est possible d’utiliser les possibilités de glulx en fait. Tu peux toujours utiliser l’extension Basic Real Time d’i7 → inform7.com/extensions/Sarah%20M … index.html

Sinon pour le reste je vois pas trop en fait… Y’a surement une manière plus simple de faire ça…

Otto_Grimwald · Mars 9, 2010, 8:44

Évocation de ce sujet ici :
groups.google.com/group/rec.game … fedb91aa5f

De façon générale ifwiki a une page sur le sujet : ifwiki.org/index.php/Real-Time

Pour la fonction Real Time, j’avais vu aussi l’extension, comme proposée par Stab, cela devrait valoir le coup de comparer ce qu’elle peut faire par rapport à ton travail initial.

Enfin, par rapport à la question initiale sur les descriptions, il faut savoir que plus tu décriras l’environnement, et plus il te faudra créer des objets et des réponses en rapport avec ce qui est évoqué, ce qui complique la programmation. Si le ciel ne contient que des nuages et le soleil, c’est gérable, mais si en plus il y a par moment un martinet qui vole dans le ciel, puis une buse, puis un avion, et que les nuages ressemblent parfois à Donald Duck ou à un lion, il faudra que le jeu puisse comprendre lorsque le joueur essayera d’en savoir plus sur les oiseaux et les lions dans les nuages…

Quant à la meilleure manière de gérer cela, je ne connais pas trop les tables, mais tu devrais pouvoir utiliser la forme :

To say test open box: if box is open, say "blabla".

(avec des tests aussi complexes que tu le souhaites)

Ensuite, tu peux afficher le résultat avec say « [test open box] », quitte à rajouter un test supplémentaire du genre say « [if porte is not locked][test open box][otherwise]Bla bla ou autre test[end if] » (non testé mais un truc du genre devrait fonctionner)

Je ne pense pas qu’on puisse liste cela dans une table, mais pour avoir une réponse un peu plus pointues et des solutions éventuelles, tu peux envoyer un message sur le forum usenet: RAIF : groups.google.com/group/rec.arts … ion/topics

GorgeRonde · Mai 27, 2010, 12:56

Me voila de retour.

ALORS JE N’AI PAS ENCORE COMMENCÉ A ECRIRE MON JEU.
non.

Je construit mon API/bibliothèque d’extension pour l’instant, ca progresse, ca progresse.

Pour ce qui est de mes tables, j’ai finalement opté pour l’option des colonnes : un type de condition par colonne. Chaque table « riche » (par exemble une table d’évenements ou de descriptions) est associée à une activité qui traite et interprete ces conditions - a sa manière. J’évite donc de passer par la solution du parser.

Le temps réel marche pas mal non plus, mais il me reste qqs bugs à éclaircir :
j’essaie donc de faire fonctionner ce que j’appelle des auto-event : des bouts de textes capable de s’afficher indépendamment du joueur (pas besoin de taper qqch pour les voir apparaitre donc). J’avais initialement déclaré une « triggering action » pour déclencher ces auto-events. Entre temps, j’ai fais connaissance avec les activités, et j’aimerai donc changer mon action en activité. Voila comment c’est censé se passer:

-je vérifie que la date de mon auto-event n’est pas antérieure à la date actuelle. Sinon je m’arrete la.
-je dis la description de mon auto-event.
-je détruis mon auto-event.

Ca marchait plutot bien avec les Check, Carry out, Report des actions, mais je n’arrive pas à obtenir le meme fonctionnement avec les Before, For, After des activités.
J’aimerai donc que si mon test temporel échoue dans la partie Before, ni le For ni le After soient exécutés. Voici comment j’essaie de m’y prendre :

1.Before triggering a scheduled auto-event (called target):
2.	if the concise time of day is before the schedule time of target:
3.		if the triggering activity is going on: [cette ligne conditionnelle est un peu inutile c'est juste pour montrer la bizzarerie de mon probleme]
4.			abandon the triggering activity;

et j’obtiens:

Comment se peut-il, si l’activité n’est pas en cours, qu’il puisse passer le test de la 3eme ligne ?

Otto_Grimwald · Mai 27, 2010, 7:04

désolé, je ne connais pas bien les activités.

Cependant, j’ai eu un problème un peu similaire avec les scènes, dans certains contextes, j’avais une erreur qui ne me semblait pas très logique :

MauriceHateful is a scene. MauriceHateful begins when the time since MauriceArrive ended is at least 10 minutes. [MauriceArrive étant une autre scene] MauriceHateful ends when the time since MauriceHateful began is at least 25 minutes.

Au début du jeu j’avais « run time pb P56: the scene MauriceArrive hasn’t ended, so you can’t ask when it did. »

(ce genre de test auparavant ne provoquait pas ce genre d’erreur, mais ils ont dû modifier des règles ensuite).

J’ai pu m’en sortir en modifiant ma règle :

MauriceHateful is a scene. MauriceHateful begins when Maurice is hateful for the first turn.

avant un changement « now maurice is hateful » au moment opportun, mais c’est plus long à coder.

GorgeRonde · Mai 28, 2010, 10:48

Finalement, voici comment je m’y suis pris:

[code]

Triggering something is an activity.

Rule for triggering a scheduled auto-event (called target):
	follow the triggering auto-events rules for the target;

The triggering auto-events rules are an object-based rulebook.

A triggering auto-events rule for a scheduled auto-event (called ae)
(this is the check triggering auto-events rule):
	if the concise time of day is before the schedule time of ae:
		stop the action;
A triggering auto-events rule for a scheduled auto-event (called ae)
(this is the carry out triggering auto-events rule):
	say "[description of ae]";
A triggering auto-events rule for a scheduled auto-event (called ae)
(this is the report triggering auto-events rule):
	destroy ae;

The check triggering auto-events rule is listed last in the triggering auto-events rules.
The carry out triggering auto-events rule is listed last in the triggering auto-events rules.
The report triggering auto-events rule is listed last in the triggering auto-events rules.
[/CODE LOUCHE]

ce qui est assez moche. J’aurais pu aussi rester au niveau des Before, for, et after rules de l’activité et me servir d’une variable d’activité afin de vérifier qu’elle passe bien le test de la before rule.