là ou je suis bien emmerdé c'est que j'ai 2 actions possible sur mes objets : observer et interagir (actionner ou dialoguer)... et un seul bouton sur la souris (enfin j'avais testé avec le clic droit mais c'était infame). DU coup si tu as une autre idée je suis preneur.
Bah disons que tu n'es pas le premier à avoir imaginer le principe du point & click, et depuis près de 30 ans que le genre existe, autant dire que pas mal de solution d'interface ont été expérimentées, et pas mal avec succès, tu devrais peut-être simplement d'inspirer de ce qui a déjà fait ses preuves dans le domaine.
Sur des interfaces sans menu d'interaction (qui est ton objectif), il y a un modèle "2 boutons" très classiques qui fonctionne très bien:
- bouton droit = regarder
- bouton gauche = interaction (qui peut dans certain cas être "regarder")
Cela requiert que le curseur prenne une forme indiquant l'action qu'entrainera le clique gauche (parler? prendre? regarder? changer de lieu?).
Stasis a introduit une solution "1 bouton" qui fonctionne pas mal non plus:
- la description apparait automatiquement lorsqu'on pointe un objet
- le clique gauche permet l'interaction (là encore très idéalement assorti du curseur prenant une forme l'explicitant)
cette tempo est faite pour donner un "droit a l'erreur" au joueur quand il drag drop un objet de son inventaire pour le combiner avec un autre inventaire.
Bah, il suffit de faire en sorte que s'il glisse l'objet vers "inventaire" celui-ci se réouvre?
Enfin, tu dis a juste titre qu'il suffit de faire attention à comment on agence sa scène, mais juste à noter que la seule fois où j'ai rencontré le problème, c'était dans ton jeu test... (avec le vidéo-projecteur)
le créateur de jeu a la possibilité de redéfinir une feuille de style (CSS) qui s'appliquera en surcharge sur son jeu et donc de redéfinir toutes les polices, couleurs, pictos... etc.
Perso je trouve celles que j'ai mises par défaut assez neutres quand même (mais bon je suis pas designer) a part le picto "bad action" qui en effet fait un peu cartoon.
Bah s'il faut passer par des connaissances en CSS pour créer son jeu, autant dire que l'objectif d'offrir à chacun la possibilité de créer son jeu sans connaissance préalables n'est pas atteint. S'il faut passer par du CSS pour changer l'apparence de l'interface, il me semble difficilement contournable de permettre une gestion du "style" via l'éditeur, là encore de façon simplifiée (est-ce possible en fait? je n'y connais rien là-dedans).
OU sinon au moins arborer une interface neutre et un minimum "sympa", pas des police de caractère cheap, des icônes cartoon, une couleurs particulière imposée pour l'inventaire, ou encore d'horribles flèches de défilement aliasées à mort... :/
Bah je t'assure qu'en prenant les choses dans le bon sens, y'a vraiment possibilité de faire plein de choses.
Oui, mais le problème c'est que je trouve que le "bon sens" de ton éditeur manque justement de "bon sens".
Le très bon exemple est quand tu dis qu'on peut faire des appels conditionnels de scripts en plaçant ces scripts secondaires dans d'autres objets, y intégrant une condition, et les actionnant via l'objet initial. C'est vrai (et je l'avais signalé au-dessus), mais c'est clairement une voie détournée pour un truc qu'on imaginerait une fonctionnalité explicite, et surtout (justement!) sans doute pas un truc auquel pensera spontanément un "geek non informaticien"...
Le fait d'intégrer différents "états" à un objet ou à une scène est là encore une façon de rendre l'avancée de l'aventure plus simple à mettre en œuvre quand on est pas un "geek informaticien", c'est juste que ça me semble plus cohérent avec l'idée d'offrir un outils puissant et utilisable par le plus grand nombre. Tu intègres d'ailleurs la possibilité que les objets ou décors puissent avoir plusieurs représentations ; dommage que ces différentes représentations ne puissent pas justement être liées à des scripts spécifiques. En l'état il faut démultiplier les variables et les tests, ce qui permet de réaliser tout à fait la même chose, mais d'une façon qui peut devenir rapidement lourde à mettre en place (surtout avec l'interface actuelle).
Si encore tu pouvais rattacher des variables aux objets, on se rapprocherait d'une prog orientée objet ; mais là en l’occurrence ce n'est pas le cas. Et je te souhaite bien du courage pour convaincre qui que ce soit que l'aspect "orienté objet" n'est pas un outils qui simplifie et augmente la puissance d'un système de programmation (quand bien même on peut toujours faire EXACTEMENT LA MÊME CHOSE p.ex. en C et en C++ en terme de résultat... en théorie du moins...)
Enfin, tu le dis toi-même:
Maintenant c'est vrai que quand tu as un bouton dans ton jeu et que tu as 50 possibilités de conséquences différentes quand le joueur appuie dessus suivant le contexte, et 50 interactions disséminées ici ou la, c'était le bordel.
Une des améliorations récentes est la vue en mode "synthèse" des interactions (l'ancienne vue détail existe toujours).
C'est vrai que cette nouvelle vue synthétique est un vrai plus.
Mais il y a des problèmes plus profonds qui a mon sens rendent la réalisation vite bordélique, et toujours, SURTOUT pour un néophyte de la programmation, ce qui va donc à l'opposé de ton objectif il me semble. Et un type qui n'est pas néophyte ne supportera pas longtemps les limitations et approximations actuelles de l'éditeur. En fait très franchement, si perso je devais réaliser un ptit jeu d'aventure (et a fortiori un plus ambitieux), je préfèrerai me plonger dans un bouquin de programmation que me galérer avec Jawa dans son état actuel.
Il y a sinon des lacunes basiques dans les évènements conditionnels: on ne peut tester que des égalités et non-égalité, il faudrait intégrer des > et <
ça c'est censé marcher
Peut-être, mais ça ne marche pas... Comme je le détaille au-dessus, en utilisant ces tests il semblait bien se passer quelque chose par rapport aux limites indiquées, mais pas le comportement attendu...
en effet les multiplications et divisions sont pas supportées (ça me semble pas méga utile) ni les additions ou égalités de variables dans les effets et conditions (là je vais creuser si c'est faisable).
Alors franchement, un truc HYPER IMPORTANT quand tu programmes un outils d'aide à la création, NE T’ARRÊTE PAS A CE QUI TE SEMBLE UTILE! A partir du moment où tu implémente une fonctionnalité, implémente-la de la façon la plus large possible. Si toi tu ne vois pas l'utilité d'offrir autant de possibilité, d'autres la verront peut-être. Ne bride pas l'imagination de ceux qui utiliseront ton prog parce que "tu n'y avais pas pensé". Y'a pas grand chose de plus rédhibitoire dans l'utilisation d'un outil que de se trouver bloquer dans la réalisation d'un projet car un truc "tout bête" n'y est pas possible, juste parce que le type l'ayant développé pensait que ça n'était pas "méga utile".
dans l'arbo les objets sont par ordre alpha je crois.
Ç’a pas l'air, enfin tout dépend de ce que tu appelles l'ordre "alpha" ; il y a une hiérarchisation des plans j'ai cru comprendre avec la variable "plan", mais il n'y a en tout cas (du moins chez moi) pas de lien entre cette valeur et l'ordre avec laquelle les objets apparaissent dans l'arborescence de scène.
Pour l'ordre des objets dans l'inventaire initial j'ai trouvé une solution en les déplaçant vers la "corbeille" puis les replaçant vers l'inventaire dans le bon ordre, ce qui reste encore une solution d fortune peu satisfaisante. D'autant que l'ordre est inversé entre l'affichage dans l'arborescence et celui dans l'inventaire in-game.
Cela reste à mon sens intéressant de pouvoir choisir l'ordre des objets, p.ex. dans la scène-test que j'ai faite, on un portable dans l'inventaire. Cet élément peut revêtir une importance notable, supérieur à celui des autres objets, p.ex. en permettant d'accéder à un menu offrant un ensemble de possibilité. Il est donc logique qu'il apparaisse en premier, pour y permettre un accès rapide et le démarquer des autres objets. Il faut donc que l’inventaire puisse être remanié en cours de jeu, afin de pouvoir offrir cette place importante à un objet même si on l'acquiert en cours d'aventure. Autre exemple si plusieurs objets font parti d'un même ensemble (par exemple les morceaux d'un objets cassé), la présentation de l'inventaire sera bien meilleure si on peut les placer à la suite (et non éparpillés aux quatre coins de la liste en fonction du moment où on a acquis chacun). Ce ne sont que des exemples, la question n'est pas de prendre connaissance de l'ensemble des cas de figure où quelqu'un pourrait envie d'avoir cette possibilité, le simple fait que cela paraisse utile à ne serait-ce qu'une personne doit suffire à te convaincre que C'EST utile. Une nouvelle fois, dans un outil créatif, ne t'arrête SURTOUT PAS à ce que tu imagines toi utile. C'est la flexibilité qui fait la puissance de ce genre d'outil. Et actuellement Jawa en est malheureusement loin, alors que l'intention de départ parait excellente.
Tu n'abordes par ailleurs pas l'idée d'une unification entre scripts et dialogues interactifs, ce qui me semble là encore assez important si tu veux offrir un outil réellement complet et accessible. En l'état, vouloir combiner les deux doit se faire j'ai l'impression par encore des montages complexes où des scipts secondaires sont à encapsuler dans des objets fantômes... ce qui va toujours à l'encontre de ton objectif d'un outil puissant et simple d'emploi!
____________________________
Sinon BUG en vu: j'ai relancé ma scène test et il y a à présent des choses qui ne marchent plus!!
J'ai des interactions conditionnelles quand on utilise certains objets sur "Guy", liées à une variable "PATIENCE". Or quand cette variable passe à 1, les interactions bloquent littéralement (j'ai même pas la mention "action impossible", c'est comme-ci je ne faisait rien, et même l'objet ne revient pas dans l'inventaire, il se met à suivre le curseur alors même que j'ai relâché le clique gauche...). Alors même que le fait que la variable passe de 0 à 1 renvoie toujours au même script.
(ID de la scène = 346)
Bah disons que tu n'es pas le premier à avoir imaginer le principe du point & click, et depuis près de 30 ans que le genre existe, autant dire que pas mal de solution d'interface ont été expérimentées, et pas mal avec succès, tu devrais peut-être simplement d'inspirer de ce qui a déjà fait ses preuves dans le domaine.
Sur des interfaces sans menu d'interaction (qui est ton objectif), il y a un modèle "2 boutons" très classiques qui fonctionne très bien:
- bouton droit = regarder
- bouton gauche = interaction (qui peut dans certain cas être "regarder")
Cela requiert que le curseur prenne une forme indiquant l'action qu'entrainera le clique gauche (parler? prendre? regarder? changer de lieu?).
Stasis a introduit une solution "1 bouton" qui fonctionne pas mal non plus:
- la description apparait automatiquement lorsqu'on pointe un objet
- le clique gauche permet l'interaction (là encore très idéalement assorti du curseur prenant une forme l'explicitant)
Bah, il suffit de faire en sorte que s'il glisse l'objet vers "inventaire" celui-ci se réouvre?
(avec le vidéo-projecteur)
Enfin, tu dis a juste titre qu'il suffit de faire attention à comment on agence sa scène, mais juste à noter que la seule fois où j'ai rencontré le problème, c'était dans ton jeu test...
Bah s'il faut passer par des connaissances en CSS pour créer son jeu, autant dire que l'objectif d'offrir à chacun la possibilité de créer son jeu sans connaissance préalables n'est pas atteint. S'il faut passer par du CSS pour changer l'apparence de l'interface, il me semble difficilement contournable de permettre une gestion du "style" via l'éditeur, là encore de façon simplifiée (est-ce possible en fait? je n'y connais rien là-dedans).
OU sinon au moins arborer une interface neutre et un minimum "sympa", pas des police de caractère cheap, des icônes cartoon, une couleurs particulière imposée pour l'inventaire, ou encore d'horribles flèches de défilement aliasées à mort... :/
Oui, mais le problème c'est que je trouve que le "bon sens" de ton éditeur manque justement de "bon sens".
Le très bon exemple est quand tu dis qu'on peut faire des appels conditionnels de scripts en plaçant ces scripts secondaires dans d'autres objets, y intégrant une condition, et les actionnant via l'objet initial. C'est vrai (et je l'avais signalé au-dessus), mais c'est clairement une voie détournée pour un truc qu'on imaginerait une fonctionnalité explicite, et surtout (justement!) sans doute pas un truc auquel pensera spontanément un "geek non informaticien"...
Le fait d'intégrer différents "états" à un objet ou à une scène est là encore une façon de rendre l'avancée de l'aventure plus simple à mettre en œuvre quand on est pas un "geek informaticien", c'est juste que ça me semble plus cohérent avec l'idée d'offrir un outils puissant et utilisable par le plus grand nombre. Tu intègres d'ailleurs la possibilité que les objets ou décors puissent avoir plusieurs représentations ; dommage que ces différentes représentations ne puissent pas justement être liées à des scripts spécifiques. En l'état il faut démultiplier les variables et les tests, ce qui permet de réaliser tout à fait la même chose, mais d'une façon qui peut devenir rapidement lourde à mettre en place (surtout avec l'interface actuelle).
Si encore tu pouvais rattacher des variables aux objets, on se rapprocherait d'une prog orientée objet ; mais là en l’occurrence ce n'est pas le cas. Et je te souhaite bien du courage pour convaincre qui que ce soit que l'aspect "orienté objet" n'est pas un outils qui simplifie et augmente la puissance d'un système de programmation (quand bien même on peut toujours faire EXACTEMENT LA MÊME CHOSE p.ex. en C et en C++ en terme de résultat... en théorie du moins...)
Enfin, tu le dis toi-même:
C'est vrai que cette nouvelle vue synthétique est un vrai plus.
Mais il y a des problèmes plus profonds qui a mon sens rendent la réalisation vite bordélique, et toujours, SURTOUT pour un néophyte de la programmation, ce qui va donc à l'opposé de ton objectif il me semble. Et un type qui n'est pas néophyte ne supportera pas longtemps les limitations et approximations actuelles de l'éditeur.
En fait très franchement, si perso je devais réaliser un ptit jeu d'aventure (et a fortiori un plus ambitieux), je préfèrerai me plonger dans un bouquin de programmation que me galérer avec Jawa dans son état actuel.
Peut-être, mais ça ne marche pas... Comme je le détaille au-dessus, en utilisant ces tests il semblait bien se passer quelque chose par rapport aux limites indiquées, mais pas le comportement attendu...
Alors franchement, un truc HYPER IMPORTANT quand tu programmes un outils d'aide à la création, NE T’ARRÊTE PAS A CE QUI TE SEMBLE UTILE! A partir du moment où tu implémente une fonctionnalité, implémente-la de la façon la plus large possible. Si toi tu ne vois pas l'utilité d'offrir autant de possibilité, d'autres la verront peut-être. Ne bride pas l'imagination de ceux qui utiliseront ton prog parce que "tu n'y avais pas pensé". Y'a pas grand chose de plus rédhibitoire dans l'utilisation d'un outil que de se trouver bloquer dans la réalisation d'un projet car un truc "tout bête" n'y est pas possible, juste parce que le type l'ayant développé pensait que ça n'était pas "méga utile".
Ç’a pas l'air, enfin tout dépend de ce que tu appelles l'ordre "alpha" ; il y a une hiérarchisation des plans j'ai cru comprendre avec la variable "plan", mais il n'y a en tout cas (du moins chez moi) pas de lien entre cette valeur et l'ordre avec laquelle les objets apparaissent dans l'arborescence de scène.
Pour l'ordre des objets dans l'inventaire initial j'ai trouvé une solution en les déplaçant vers la "corbeille" puis les replaçant vers l'inventaire dans le bon ordre, ce qui reste encore une solution d fortune peu satisfaisante. D'autant que l'ordre est inversé entre l'affichage dans l'arborescence et celui dans l'inventaire in-game.
Cela reste à mon sens intéressant de pouvoir choisir l'ordre des objets, p.ex. dans la scène-test que j'ai faite, on un portable dans l'inventaire. Cet élément peut revêtir une importance notable, supérieur à celui des autres objets, p.ex. en permettant d'accéder à un menu offrant un ensemble de possibilité. Il est donc logique qu'il apparaisse en premier, pour y permettre un accès rapide et le démarquer des autres objets. Il faut donc que l’inventaire puisse être remanié en cours de jeu, afin de pouvoir offrir cette place importante à un objet même si on l'acquiert en cours d'aventure. Autre exemple si plusieurs objets font parti d'un même ensemble (par exemple les morceaux d'un objets cassé), la présentation de l'inventaire sera bien meilleure si on peut les placer à la suite (et non éparpillés aux quatre coins de la liste en fonction du moment où on a acquis chacun). Ce ne sont que des exemples, la question n'est pas de prendre connaissance de l'ensemble des cas de figure où quelqu'un pourrait envie d'avoir cette possibilité, le simple fait que cela paraisse utile à ne serait-ce qu'une personne doit suffire à te convaincre que C'EST utile. Une nouvelle fois, dans un outil créatif, ne t'arrête SURTOUT PAS à ce que tu imagines toi utile. C'est la flexibilité qui fait la puissance de ce genre d'outil. Et actuellement Jawa en est malheureusement loin, alors que l'intention de départ parait excellente.
Tu n'abordes par ailleurs pas l'idée d'une unification entre scripts et dialogues interactifs, ce qui me semble là encore assez important si tu veux offrir un outil réellement complet et accessible. En l'état, vouloir combiner les deux doit se faire j'ai l'impression par encore des montages complexes où des scipts secondaires sont à encapsuler dans des objets fantômes... ce qui va toujours à l'encontre de ton objectif d'un outil puissant et simple d'emploi!
____________________________
Sinon BUG en vu: j'ai relancé ma scène test et il y a à présent des choses qui ne marchent plus!!
J'ai des interactions conditionnelles quand on utilise certains objets sur "Guy", liées à une variable "PATIENCE". Or quand cette variable passe à 1, les interactions bloquent littéralement (j'ai même pas la mention "action impossible", c'est comme-ci je ne faisait rien, et même l'objet ne revient pas dans l'inventaire, il se met à suivre le curseur alors même que j'ai relâché le clique gauche...). Alors même que le fait que la variable passe de 0 à 1 renvoie toujours au même script.
(ID de la scène = 346)
Pages