Discussion :

[lagwag]

Voila c'est parti, je me lance dans le dev des outils (pas le runtime).

Il y aura plusieurs editeurs: scene, personnage (anim), dialogues... Mais avant, j'ai fait l'éditeur principal (l'originalité du soft) qui permet de scenariser son jeu.



- La boite verte, c'est une boite systeme. Je pense que le nom est assez explicite pour comprendre à quoi elle sert.

- La boite orange c'est une boite cinematic. Elle permettra de passer en mode cinematic et de jouer une video.

- La boite rouge c'est une boite bridge. Ca permet de mieux structurer.

- La boite bleue c'est une boite puzzle.

A mon avis c'est assez clair... j'explique quand meme:

On avance de gauche à droite en commencant par START. La boite rouge 12:00 est connectée avec deux boites bleues. Ca veut dire qu'apres etre sorti de la boite rouge, le joueur peut résoudre les deux enigmes dans n'importe quel ordre. Ensuite les deux boites bleues sont connectées à une boite rouge sans nom. Ca veut dire qu'il faut resoudre les deux enigmes pour acceder à la boite rouge. Evidemment, une boite activée ne peut plus etre désactivée (si on respecte le principe du jeu d'aventure point n click).

Chaque boite aura deux scripts associés. (Je vais dans un premier temps utiliser un systeme de script ultra simple pour gerer les actions... à terme je le remplacerai par une interface graphique). Donc deux scripts contenant des commandes: un qui est appelé lorsqu'on rentre dans la boite, et un autre lorsqu'on en sort.

Les actions dans le script permettront de faire des toggle sur des elements, changer des etats, activer/desactiver des phrases d'une conversation.

Cette présentation sera super efficace lorsque le runtime sera en place. On pourra lancer le jeu à partir d'une boite. On pourra verifier les etats de n'importe quel element à n'importe quel endroit sans lancer le jeu. La sauvegarde sera facile à gérer...

[lagwag]

La fenetre du projet en trois parties:
- Le graph pour scenariser son jeu
- Le script pour changer des etats, lancer des actions
- L'état de tous les elements... toute la puissance du soft réside ici

in/out permet d'indiquer si ya du code ou pas dans la boite.

Le petit carré en bas à droite des boites permet de valider ou pas la boite. C'est à dire qu'on peut, comme je le disais plus haut, simuler une partie en specifiant les enigmes validées. Il suffit d'appuyer sur F4 pour cocher ou décocher. Evidemment, si on coche une boite, toutes les boites parents sont validées. Et si on décoche une boite, toutes les boites enfants sont invalidées.

J'en viens au plus important... grace à ce systeme, la troisieme fenetre affichera l'état de tous les elements du jeu en fonction des boites validées. On saura ainsi si tel objet se trouve dans l'inventaire à tel moment.

[lagwag]

Quelques changements...

- deux carrés à gauche des boites pour savoir si ya du script associé (ENTER/EXIT).

- les boutons fleches pour acceder à la boite START ou END

- La loupe qui permet de chercher la boite qui ne serait pas connectée

- et le texte [...] pour savoir si ya un scenario à l'interieur... comment ca? C'est un gros changement. Les boites bleues (puzzle) peuvent contenir un autre graph avec deux boites START/END. C'est possible sur un seul niveau pour éviter de rendre le scenario illisible. Ca permet de séquencer une enigme si besoin, généralement pour les énigmes complexes lorsqu'il y a plusieurs choses à faire. Il suffit de double cliquer ou d'appuyer sur ENTREE pour ouvrir la boite... un nouvel onglet apparait en haut.

[lagwag]

On ne pourra pas spawner des elements, comme on le ferait dans un jeu d'action pour créer une nouvelle instance d'un enemi. Ca n'a aucun interet dans un jeu d'aventure. Chaque item possède sa propre histoire. Du coup, ca va super simplifier l'interface et faciliter le travail de l'utilisateur. Chaque asset est donc également une instance. Toutes ces instances seront créées au démarrage (pour éviter de bouffer trop de memoire, les elements graphiques seront chargés à la volée. Aucun instance ne sera détruite). Les assets sont des fichiers XML qui doivent commencer par une lettre definissant son type.

En passant, je vous signale que le moteur pourra gérer plusieurs persos comme dans Day of the tentacle.

Chaque asset possède son propre éditeur. J'ai commencé l'éditeur Objects (assez simple). Les objets pourront avoir plusieurs frames et plusieurs animations.

J'en viens maintenant aux evenements... Dans un jeu d'aventure point n click, les controles du joueur sont assez limités. Il peut:

- effectuer une action sur un objet ou perso à l'aide du click (je ne gere pas les verbes et je veux simplifier au maximum l'interface gameplay pour que les jeux puissent s'adapter sur n'importe quel device). J'ai nommé cet event, ACTION.

- utiliser un objet de son inventaire avec un autre objet ou perso. J'ai nommé cet event, USE. Il a un parametre, l'objet en question.

- aller dans un lieu. J'ai nommé cet event, GOTO. Il aura aussi un parametre.

- choisir une réplique. J'ai nommé cet event, SAY. Des parametres...

- et éventuellement lorsque le joueur deplace son perso vers un point précis de la scene. Je le laisse de coté pour l'instant.

Je ne vois pas d'autres actions possibles du joueur.

Et comme pour les boites du scenario (ENTER/EXIT), les evenements contiennent aussi un script. Il y a une petite difference... les scripts des evenements ne pourront rien modifier excepté la possibilité de valider une boite du scenario. C'est à dire, passer à la suivante. Pourquoi? Si des valeurs sont modifiées en dehors du scénario, je ne peux plus rien controler. Mais cette restriction n'est pas un inconvenient, au contraire. Seul le scenario controle le déroulement de l'histoire, pas les assets.

[lagwag]

La premiere version de l'editeur d'objets est terminée. On peut créer des anims, ajouter des frames dedans, ajouter des evenements de type ACTION ou USE et y associer un script. Pour USE, une liste contenant tous les objets et persos du jeu est proposée automatiquement à l'utilisateur.

J'enregistre tout ca dans le fichier XML. Les images sont au format PNG (elles sont converties).

Bon désolé pour l'exemple, ca n'a pas bcp de sens de charger un perso dans un editeur d'objets c'etait juste pour tester les anims.

[MoDDiB]

Bon désolé pour l'exemple, ca n'a pas bcp de sens de charger un perso dans un editeur d'objets

Pourquoi un perso ne serait il pas un objet ?
Ça te permettrait d'avoir un éditeur plus générique et de potentiellement pouvoir déplacer objets et persos. ( ou de faire parler une bouteille de shampoing )

[lagwag]

si l'objet parle et donc s'il a une conscience, c'est un perso.

en fait je partais du principe qu'un perso ne pouvait pas se retrouver dans l'inventaire, mais ca va meme pas car on pourrait imaginer que le joueur prenne un rongeur qui parle... ou effectivement prenne la bouteille de shampoing avec lui.

ouais tu as raison, je suis allé un peu trop vite sur ce concept de perso/objet. je modifie tout ca

merci.

[lagwag]

J'ai viré le type PEOPLE pour ne laisser que OBJECT. J'ai rajouté la notion de direction dans l'editeur. Là aussi c'est assez basique. Le perso est soit de profil (droite), de profil (gauche), de face, ou de dos. Si left n'est pas défini, je prendrai right en je ferai un mirror. Si front ou back pas défini, je prends left ou right mais l'effet sera moche. En gros pour les perso qui se déplacent, trois directions devraient suffire.... pour un jeu de pirate... il faudra les 4... à cause du borgne

Ya les anims system et les anims user. STOP, MOVE et SPEECH ne peuvent pas être supprimées et sont gérées par le moteur. Ensuite le joueur est libre de créer ses propres anims.

Il y aura des proprietes pour l'objet, pour les anims et pour les directions.

Je passe à l'éditeur suivant...

[lagwag]

Je bosse sur l'éditeur principal: la scene. C'est juste le début... On peut inserer des objets sur la scene et les déplacer (pas encore fait la taille... + compliqué à cause du scale... à reflechir). Tous les objets de la scene sont affichés dans la liste. Et chaque objet possede sa propre liste de spots qui me servira à gerer les déplacements. Sauvegarde/chargement dans le fichier xml, ca marche.

J'ai prévu de faire une petite moulinette pour renommer les assets, en changeant toutes les références. Il ne faudra pas renommer un fichier à la main, ni le supprimer. Je ne suis pas tres fan de tout mettre dans un seul fichier projet... c'est risqué et ca fait ramer.

Je cherche un graphiste pour réaliser l'exemple du soft lorsqu'il sera operationnel... Une demo tres simple avec deux persos, deux lieux, deux ou trois objets, trois ou quatre enigmes.

[lagwag]

C'est un peu difficile d'expliquer cet editeur en quelques mots... Je diffuserai prochainement des versions.

Il y a deux modes:

- le mode objet pour placer ses objets/portes comme dans n'importe quel editeur. Les elements sont encadrés en bleu. Multi-sélection avec la gestion des proprietes (on peut editer une propriete de plusieurs objets en meme temps). Bref, pas grand chose à dire

- le mode spot s'active en double cliquant sur un objet ou en le selectionnant depuis la liste. Les objets selectionnés (si yen a), sont conservés mais affichés avec une bordure rouge et l'objet à éditer passe en vert. Dans ce cas, les spots s'affichent à l'ecran et dans la deuxieme liste. Les spots ont leurs proprietes comme pour les objets.

Le concept c'est de placer des points partout où le perso pourra se déplacer. Chaque spot possede un scale pour le perso qui se déplace d'un point à un autre (lerp). Donc quand le joueur clique sur l'écran, je dois identifier le spot le plus proche du click et ensuite trouver le plus court chemin entre deux spots. Tout ca sera dans le runtime mais on peut quand meme voir un apercu du scale en selectionnant le spot depuis la liste. Le perso quitte son rectangle pour se balader à l'endroit du spot.

Par defaut le nom des spots est SPOT tout betement. Pas besoin de les nommer sauf si on veut les utiliser dans le code.

Il faudra associer un spot avec un objet à prendre. Comme ca lorsque le joueur decidera de prendre un objet, le perso atteindra d'abord le spot spécifié pour lancer son anim... ca me fait penser que je dois rajouter la possibilité de jouer les anims dans l'editeur de scene...

[OuiOuiDidou]

Juste un post pour dire que ..... j'ai rien à dire mais que je trouve que tu pars super bien
Donc en gros juste : Bon courage
Voila, j'aime bien encourager les projets qui tiennent la route. Manifestement, celui la à l'air bien parti.


Petite question : le moteur est/sera open source si j'ai bien compris ?
Quel langage utilise tu ?

[lagwag]

Merci. L'avantage c'est que je suis à la fois le développeur et le (futur) utilisateur de ce soft. J'ai déjà un scenario très avancé, ça m'aide beaucoup.

Un exemple:

L’éditeur des persos/objets c'est bien mais çà va être très vite pénible à utiliser, surtout pour les gros projets. Il faut créer un nouvel item anim, importer les images pour chaque direction. Appliquer les paramètres... J'aurai pas loin de 50 persos, et encore plus en objets. Je ne vais pas m'amuser à les rajouter à la main... J'ai prévu une moulinette qui lira un dossier contenant des sous dossiers et fichiers (en respectant une convention pour les noms), et qui générera les assets. Si les assets xml existent deja, elle les modifiera pour ne pas écraser la balise des scripts. Ainsi, le graphiste aura juste à composer ses éléments graphiques en nommant correctement ses fichiers et dossiers... un fichier par frame.

Le soft n'a pas pour but de faire plus que le développement d'un jeu point n click. Je pars du principe que les éléments fournis sont toujours bien calibrés. Quitte à fournir des utilitaires en plus... Il faut respecter les étapes du développement d'un jeu. Ce n'est pas un fourre-tout. Pour les anims, toutes les frames devront être de la même taille. Pour des questions d'optimisation de l'exécution, j'effectuerai des crops et ajusterai les points pivot lors de la compilation du jeu. Sinon ça oblige à rajouter des paramètres pour chaque frame et du coup, le batch processing devient inutile.

Alors pour l'histoire de l'open source... Oui, le moteur a de grande chance d’être open source et je n'ai rien décidé pour l'instant. Il faudra que ça tourne sous Windows, Mac, Linux et les mobiles. MonoGame a l'air d’être intéressant. Par contre pour les outils, au début je voulais faire une application crossplateform, finalement j'ai utilisé ma propre bibliothèque compatible Windows uniquement, pas open source. Tout est programmé en C++ avec les API Windows sans aucune autre bibliothèque. A terme, si ça marche, il y aura toujours la possibilité de faire un portage. Je n'ai pas le temps de m'investir dans une autre bibliothèque. Les outils ne feront que cracher du XML, les assets seront totalement ouverts. Il y aura un format binaire pour le moteur. J'ai pas encore bien réfléchi à ça, je pense qu'il faudra à part, un utilitaire de compilation en ligne de commande pour convertir les assets XML en fichiers binaires... et une version différente pour chaque plateforme. Cet utilitaire devra être open source si le moteur est open source. Ainsi rien n’empêche un programmeur de développer un nouvel éditeur juste pour les persos, tout en gardant le reste.

[lagwag]

Les anims dans l'editeur de scene c'est fait. Ca tourne à 4 frames par seconde, pas besoin de consommer davantage les ressources, c'est juste pour calibrer la position des spots... pour savoir si le perso touche bien l'objet à prendre lorsqu'il tend la main.

Le "Z-Buffer" est un peu galère à gérer. J'ai deux soucis:

- La vitesse de déplacement du perso. Horizontalement, ca ne pose aucun probleme, il suffit de fixer une vitesse en pixels par seconde. Le probleme c'est verticalement. Je pense à un parametre dans les spots, à moins de trouver une solution plus simple.

- L'ordre d'affichage des objets. Si je place un objet au milieu de la scene et si le perso peut aller soit devant soit derriere. Encore une fois grace aux spots, je vais pouvoir gérer ca. Il faut d'abord classer les objets/persos par plan comme des layers, en remontant ou descendant les items de la liste. Dans la majorité des cas, ca suffira car souvent le perso suit un path tres simple qui ne laisse pas le joueur se balader librement dans la scene. Dans le cas contraire, il faut specifier pour les spots necessaires, que tel objet devra changer de plan. A l'utilisateur de se démerder pour contourner l'objet en placant des spots à la bonne distance. Ca me fait penser à une autre feature... lancer un apercu d'un déplacement d'un spot à un autre... un slider 0-100 me tente bien.

J'ai peu de temps aujourd'hui à consacrer au projet... je bosserai sur ces points ce soir.

[MoDDiB]

- L'ordre d'affichage des objets. Si je place un objet au milieu de la scene et si le perso peut aller soit devant soit derriere. Encore une fois grace aux spots, je vais pouvoir gérer ca.

Et si le changement devant/derrière opère durant le déplacement ?
( un personnage se déplace vers l'arrière plan et rencontre une branche de sapin sur la route par exemple )
Plutôt que de gérer des plans pourquoi ne pas donner un "z-index" index de distance pour chaque élément ?
Comme ça chaque élément pourrait être trié facilement.
Et ainsi gérer la vitesse de déplacement du perso sur cet axe et le scale etc....

Sinon je trouve ça dommage d'utiliser le C++ pour faire les outils alors qu'il y a d'autres outils bien plus productifs désormais ; mais tu as l'air de très bien avancer c'est donc sans doute dans ton cas un bon choix.

[lagwag]

Dans ton exemple de branche, le spot (du perso) qui sera derriere la branche aura un parametre pour indiquer que le branche doit se dessiner devant le perso. Il faudra faire en sorte de contourner la branche avec des spots autour. Les spots devront etre judicieusement placés.

Je ne pige pas bien ta methode. Le z-index est sur les objets/perso ou sur les spots? Si c'est les spots, effectivement je peux effectuer des lerp pour le perso en deplacement et comparer avec celui de la branche. Mais alors ca veut dire qu'il faut parametrer chaque spot... c'est de la folie. Et si on deplace un spot, le z-index est fichu. Dans mon esprit, le but est de parametrer 10% des spots.

Une autre solution serait de définir une grille sur le background. Non meme pas besoin de grille, juste des lignes horizontales pour former des bandes (row) et chaque ligne possederait une valeur Z entre 0 et 100 (0 c'est la "camera"). Par défaut, c'est linéaire, qu'une seule bande. Ainsi il suffirait de convertir la position Y d'un pixel en Z.

Ca implique une vitesse horizontale et une vitesse Z vu que les deux unités sont differentes

[MoDDiB]

Dans ton exemple de branche, le spot (du perso) qui sera derriere la branche aura un parametre pour indiquer que le branche doit se dessiner devant le perso. Il faudra faire en sorte de contourner la branche avec des spots autour. Les spots devront etre judicieusement placés.

Justement pour une petite branche d'arbre ou des fleurs le personnage n'aurait pas à éviter. Ceci peut aussi fonctionner avec le Lerp que tu as décrit après.

Je ne pige pas bien ta methode. Le z-index est sur les objets/perso ou sur les spots? Si c'est les spots, effectivement je peux effectuer des lerp pour le perso en deplacement et comparer avec celui de la branche. Mais alors ca veut dire qu'il faut parametrer chaque spot... c'est de la folie. Et si on deplace un spot, le z-index est fichu. Dans mon esprit, le but est de parametrer 10% des spots.

Le z-index serait sur chaque élément graphique à trier, ce n'est pas un travail énorme car tu peux utiliser la position screenY pour obtenir ce Z et ne définir à la main que le Y des objets en hauteur ( que tu ne définiras qu'une fois ) et ainsi lorsque tu déplaceras tes éléments le Z-index se mettra à jour automatiquement )
A toi de voir c'est certainement overkill pour ce que tu souhaites faire mais je préfère te prévenir.

[lagwag]

ok merci, je vais étudier ca.

Je viens de rajouter la gestion des langues: pour les noms des persos, des objets, des portes et les dialogues... et à terme pour les voix. Il suffit de définir les langues supportées dans les proprietes du projet, et elles apparaitront dans les proprietes des éléments.

On peut deja placer les doors (qui ne sont que de simples zones).

[lagwag]

voila c'est fait... avec une petite video pour vous montrer le resultat...

[MoDDiB]

voila c'est fait... avec une petite video pour vous montrer le resultat...

Nickel ! J'espère que cette méthode va énormément te simplifier le dév !

[lagwag]

Oui, et surtout pour l'utilisateur qui n'aura pas grand chose à parametrer.

J'ai du revoir entierement la gestion des assets parce que tout copier dans les fichiers xml c'est pas une bonne idée. On ne peut plus editer les xml depuis le bloc note vu la taille des fichiers, et ca fait ramer le logiciel. C'etait pour faciliter l'utilisation mais en fait c'est tout le contraire.

Les projets sont maintenant constitués du fichier .age (propriete du projet), du fichier scenario.xml pour le graph, et de deux sous dossiers: GRAPHICS et ASSETS. Il y aura plus tard un autre dossier pour les voix.

ASSETS contient tous les fichiers xml du jeu. Le code sera dans ces fichiers.

GRAPHICS contient une structure de dossiers et fichiers pour stocker toutes les images des assets. J'aurais pu me contenter d'inclure dans les fichiers xml, le path des images mais pourquoi rajouter des étapes intermediaires? Je n'ai rien mis dans les xml. Pas besoin car le soft sait où il faut chercher puisque la structure doit respecter une convention. Je reprends tout simplement les noms des objets, les noms des anims et les directions pour nommer les dossiers et fichiers.

Du coup, j'ai du refaire une passe sur l'editeur d'objet. Lorsque l'on crée un nouvel objet, le soft créer un nouveau dossier (GRAPHICS\OBJECTS\O1_HEROS\). L'edition se fait par l'explorateur (un raccourci pour ouvrir le dossier). On crée ses dossiers anims (STOP, LAUGH...). Dedans on ajoute ses frames (RIGHT_00.png...). Evidemment, un bouton "Import GRAPHICS" permet d'importer le dossier complet et de mettre à jour le fichier XML (en memoire tant qu'on ne decide pas de sauver).

Enfin, une moulinette permet de faire la meme chose pour tous les assets d'un simple clic.

Ca rend l'outil super flexible et chaque partie du dev reste indépendante (sans générer des dépendances de path partout dans les fichiers xml).