Discussion :

[LittleWhite]

Bravo

Mais mais, dites moi ... tout cela, ça rajoute des copies de string ...
Je pense que l'on peut amélioré en utilisant des références ... en théorie ... mais bon ça ne devrait pas être trop grave ... car on est pas sensé appuyer comme des malades sur F10 ()

[fearyourself]

Exactement. F10 est la pour DES raisins de debuggage. Par contre, il est Clair que :
- il n est pas sur le chemin critique de l'exécution. Du coup, cela n'est pas nécessaire de l'optimiser.

Par contre, pour des raisons de modularité et évolution du système. Clairement, le coup des switch dans cette classe doit, à mon avis, disparaitre un jour.

Petite image d'un autre ville : le chateau du gentil roi Lord British:


Quand le temps le permettra!
Jc

[fearyourself]

Je reviens pour une fois pas pour une vraie mise à jour du jeu (vu que je n'ai rien fait à part continuer le décodage des fichiers des données) mais pour prendre le temps de présenter : http://gamengine.net.

C'est le domaine de mon jeu et cela me permettra de centraliser un peu tout et être indépendant.

J'ai donc mis un sous-domaine : http://backtoroots.gamengine.net qui permettra de gérer toutes les informations de ce projet.

Ensuite, je mettrai toujours les mises à jour ici et là-bas ;-)

Bonne soirée,
Jc

[LittleWhite]

Drole d'idee

Qu'est ce qui genait sous la SF pour que vous prenniez un vrai domaine (surtout que je croyais que la source forge fournissait des domaines, non ? en .sourceforge.net surement)

Bonne continuation

[fearyourself]

Hmm, beaucoup de petites choses en fait. Au final, je suis bien mieux dans cette configuration et je peux continuer mon jeu tranquillement ;-)

Question de goût et de choix je suppose!

Bon je retourne au projet et ajouter les Npc !
Jc

[fearyourself]

Petite mise à jour :

- Ajout des Npcs dans le deuxième jeu ;-)

Nous avons pour le moment une version temporaire avec beaucoup de choses encore à régler :
- Les discussions
- Les mouvements.

Ce jeu avait vraiment plus de détails, les Npcs avaient des horaires où ils allaient dormir, où ils étaient dans les magasins, etc. Du coup, il faut que j'ajoute cela dans la gestion des IA.

Souci ou problématique supplémentaire : les maps du jeu étaient parfois sur des niveaux différents. Cela veut donc dire que le PathFinder doit être modifier pour gérer la 3D ou alors il faut que je triche un peu. Solution à venir !

Petit screen shot :

Jc

[fearyourself]

Grosse embuche lors du chargement des Npcs, en effet, les villes ont plusieurs niveaux et les Npcs peuvent aller entre les niveaux.

Du coup, il est nécessaire d'avoir un MapHandler qui permet de gérer plusieurs Map sous-jacentes mais qui se partagent les Npcs.

Du coup, tout le monde passe via le MapHandler et il a fallu modifier un peu le code pour ce changement. A présent, la vue générique demande un MapHandler qui peut charger plusieurs Map d'un coup (si la ville a plusieurs niveaux).

On est un pas plus près à pouvoir gérer les emplois du temps de nos chers Npcs et leur mouvement inter-niveaux ;-)

Voici la nouvelle classe :-) :
http://backtoroots.gamengine.net/doc...apHandler.html

Jc

[fearyourself]

Ok, mise-à-jour difficile à cause de toutes les choses qui s'entre-mêlent. Au final, nous avons la première version des Npcs qui bougent dans la ville automatiquement.

Ceci est possible grâce à un ajout dans la classe AnimatedObject.

Je rappelle l'héritage pour cette classe:


Voici les ajouts dans cette clase :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
        /**
         * @brief the trip the AnimatedObject must take to go where he wants to
         */
        std::vector <HandleReturn> trip;
        int tripDestX,  /**< @brief X-coordinate of trip destination */
            tripDestY,  /**< @brief Y-coordinate of trip destination */
            tripDestZ;  /**< @brief Z-coordinate of trip destination */

Ceci permet de définir le chemin que le Npc doit prendre. On garde la destination puisque, si jamais il se retrouve bloquer, il peut recalculer sa destination.

Ensuite, la fonction qui gére le tour handleTurn est virtualisée pour devenir chez NpcU5 (la définition de Npc pour ce jeu) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
int NpcU5::handleTurn (Map *map, int haveMovedTurn, AnimatedObject *group, int direction)
{
    //Ok, actually we have to see if we have a new schedule
    int newSched = getCurrentPosition (Engine::getInst ()->getHour ());
 
    //If not the same, we have work to do
    if (newSched != currentSchedule)
    {

Ce code permet de savoir si on a un nouvel endroit où aller. Ensuite, on demande au code de calcul de chemin si on peut y aller :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
            //Find the path
            bool found = PathFinder::getPath (map, getPosY (), getPosX (),getPosZ (),  destY, destX, destZ, trip);

Si on trouve un chemin, on met à jour certaines variables locales et ensuite on laisse AnimatedObject gérer le reste.

En effet, ce dernier commence sa fonction handleTurn par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
    //Before doing anything, let's see if we have a trip ready, forceIt is used for the tryGo
    bool forceIt = false;
    if (trip.size () != 0)
    {
        //Then we want the last one
        direction = trip.back ();
        forceIt = true;
        trip.pop_back ();
    }

Le forceIt est en fait une solution pour le laisser passer par les portes (sinon on refuse qu'un Npc ouvre les portes pour l'instant...).

Au final, la seule chose qui reste est la gestion du cas où on est bloqué (un autre personnage bloque le chemin). Ceci est géré facilement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
//We were blocked, normally we don't care except in the trip case, if trip was used, forceIt is true
                if (forceIt == true)
                {
                    //Then we will recalculate it
                    bool res = PathFinder::getPath (map, getPosY (), getPosX (),getPosZ (), tripDestY, tripDestX, tripDestZ, trip);
 
                    if (res == false)
                    {
                        HandleReturn back = static_cast<HandleReturn> (direction);
                        //If we didn't find a solution, push back where we were supposed to go
                        trip.push_back (back);
                    }
                }

Et voilà, on a une jolie video qui permet de montrer cette solution :
http://backtoroots.gamengine.net/files/path-finding.avi

J'ai encore quelques détails à régler et il faut que j'ajoute la gestion inter-niveau mais c'est en bonne voie ;-)

Jc

[fearyourself]

Histoire de terminer l'année en beauté, j'ai finalement une première version de mon path-finder multi-niveau :yeah:

Au final, l'idée est de trouver les escaliers et trouver un chemin entre la position de départ et l'escalier, ensuite l'escalier et le point final dans l'autre niveau.

Ensuite, on attache les deux chemins ensembles et le tour est joué ;-)

Bien sûr, j'ai dû faire quelques modifications pour autoriser le mouvement des personnages dans les autres niveaux mais voici deux videos pour montrer cet élément du jeu ;-)

La première video montre le départ du niveau courant vers le niveau du dessus:
http://backtoroots.gamengine.net/fil...h-finding.mpeg

La deuxième video montre l'arrivée d'un personnage du dessus vers notre niveau :
http://backtoroots.gamengine.net/fil...finding-2.mpeg

Bonne année à tous,
Jc

[LittleWhite]

Bravo
Et bonne année

[fearyourself]

Bien le bonjour tout le monde,

Alors bien que je n'ai pas grand grand chose à montrer, je me permets de faire une petite pause dans les posts de développement afin de donner quelques informations sur la gestion des personnages dans ces deux jeux.

Prenons cela comme étant une présentation de ce qui se faisait en 1985 et 1988.

Dans le premier jeu, nous avons en fait une gestion de discussion ultra simpliste, où les personnages répondait aux demandes de : name, health, job et ensuite, chaque personnage avait potentiellement 2 mots clés qui donnaient plus d'informations. Les discussions sont donc très limitées.

3 ans plus tard, le système de discussion est devenu scripté. Non, ils n'utilisaient pas LUA ou autres techniques, mais avaient une solution pour que les personnages posent des questions au joueur, changeant la réponse dépendant de la réponse et utilisant des GOTO pour aller dans d'autres parties de la discussion.

Ils avaient aussi une distinction si le personnage connaissait votre nom ou pas, ce qui permettait d'avoir une solution plus personnalisée et une plus grande immersion !

Là où ils ont fait forts aussi : ils mettaient des randoms sur le fait que le personnage disent son prénom ou pas, ce qui permettait d'ajouter de l'aléatoire vu qu'après sa présentation, il pouvait poser une question.

Pour ce qui est de l'intégration de ces nouvelles choses dans mon projet, il y a du boulot, mais j'ai déjà décodé pas mal de choses. Par exemple, dans le premier jeu, tout était en texte. Dans le deuxième, pour des raisons de place, les mots les plus souvent utilisés étaient en fait codés via un octet code. Solution bourrine mais pratique pour ne pas perdre de la place.

Bon, j'y retourne,
Jc

[LittleWhite]

3 ans plus tard, le système de discussion est devenu scripté. Non, ils n'utilisaient pas LUA ou autres techniques, mais avaient une solution pour que les personnages posent des questions au joueur, changeant la réponse dépendant de la réponse et utilisant des GOTO pour aller dans d'autres parties de la discussion.

J'ai cherché un peu, et la toute première version de LUA ( 1.0 ) et de 1993 Donc c'est normal ( http://www.lua.org/versions.html#1.0 )

Ils avaient aussi une distinction si le personnage connaissait votre nom ou pas, ce qui permettait d'avoir une solution plus personnalisée et une plus grande immersion !

Là où ils ont fait forts aussi : ils mettaient des randoms sur le fait que le personnage disent son prénom ou pas, ce qui permettait d'ajouter de l'aléatoire vu qu'après sa présentation, il pouvait poser une question.

Ils avaient déjà d'excellent idée (je me demande comment était leurs fonction d'aléa à l'époque)

Pour ce qui est de l'intégration de ces nouvelles choses dans mon projet, il y a du boulot, mais j'ai déjà décodé pas mal de choses. Par exemple, dans le premier jeu, tout était en texte. Dans le deuxième, pour des raisons de place, les mots les plus souvent utilisés étaient en fait codés via un octet code. Solution bourrine mais pratique pour ne pas perdre de la place.

J'imagine que cela ressemble à des tables de hachages (qui me semble être une solution très logique pour compresser des phrases (Note: j'ai jamais étudié la compression)).

Bon, j'y retourne,

Amusez vous bien

[fearyourself]

J'ai cherché un peu, et la toute première version de LUA ( 1.0 ) et de 1993 Donc c'est normal ( http://www.lua.org/versions.html#1.0

Ben voilà, donc c'est effectivement bien normal :-)

Ils avaient déjà d'excellent idée (je me demande comment était leurs fonction d'aléa à l'époque)

C'est clair, à mon avis, un simple random % 4 par exemple.

J'imagine que cela ressemble à des tables de hachages (qui me semble être une solution très logique pour compresser des phrases (Note: j'ai jamais étudié la compression)).

En effet, en fait, l'octet en question est un indice dans un tableau d'offsets qui donnent directement le string en question par rapport à un début donné.

Jc

[fearyourself]

Après un peu de boulot, on a les discussions en place dans le jeu pour le deuxième port. Je peux vous montrer une video de cela ici : http://gamengine.net/wordpress/wp-co...iscussion.mpeg.

Je vais faire un post plus tard montrant les entrailles du système si cela intéresse quelqu'un. Bien que mon code ne soit pas tellement intéressant, je peux faire un post sur comment le tout était encodé dans le jeu d'origine, chose plus intéressante à mon avis.

Jc

[fearyourself]

Bon cela fait un moment que je n'ai pas fait de mise à jour sur ce fil, je m'en excuse, j'ai été en plein travail de fond et donc le temps ne me l'a pas permis, voici les sujets :

Bug de discussion

Quand on fait un port d'un jeu, on découvre des bugs dans les fichiers de base ! Dans un des fichiers de discussions, quelques octets ont été mal placé, ce qui faisait qu'on obtenait :

gorn
hass
<or>

au lieu de :

gorn
<or>
hass

Du coup, si on demandait "gorn", on obtenait comme réponse : hass au lieu de :

He is a prisoner in the dungeon!

Chose corrigée via un patch que j'ai créé :-).

Autre bug mineur : une gamine vous demande 3 pièces d'or mais vous en prenez 4 . J'ai rajouté les corrections dans un sous-répertoire du projet : "Utils".

Outils du jeu

J'ai développé un décodeur des discussions, ce qui permet d'avoir toutes les discussions correctement visible à l'utilisateur http://codex.ultimaaiera.com/wiki/Ultima_V_Transcript.

Le deuxième outil est le patch que j'ai pour les fichiers de données.


Script de discussion

En ayant avancé sur la gestion des discussions, ce deuxième jeu avait un système de script qui permettait de mettre la discussion en pause, attendre une touche, faire un goto vers un autre endroit de la discussion, demander quelque chose à l'utilisateur.

Cela a été entièrement intégré dans le moteur et voilà une présentation sous forme de video de ceci :

[ame="http://www.youtube.com/watch?v=rco1oe4FJ38"]Gestion de la discussion[/ame]

Ceci a été programmé en utilisant le moteur du noyau une fois que tout est décoder. Par contre, la gestion de la question à l'utilisateur a demandé un système de pile pour les discussions en cours, j'en ferai sûrement une présentation s'il y a un intérêt sous forme d'article.

Les Npcs nous rejoignent

On peut désormais demander à des Npcs de nous rejoindre, s'ils sont d'accord, il vont donc rejoindre l'équipe de facon transparente. Ceci était géré dans le premier jeu, et maintenant fait son apparition ici :-)

[ame="http://www.youtube.com/watch?v=3x8Hqa9WAjo"]Les Npcs nous rejoignent[/ame]

L'aubergiste

En commencant l'intégration des marchands, j'ai commencé par l'aubergiste. Il est plus compliqué à gérer que dans le premier jeu et pour le moment, ne dis que simplement bonjour mais, comme toujours en utilisant les données du jeu d'origine.

Au final, nous avons pu décoder pas mal de choses des fichiers binaires de base et j'ai écrit un nouveau petit outil pour trouver les données qui m'intéresse :-)

Voici juste une image (et non une video vu que, pour le moment, il ne dit que bonjour correctement) :



En espérant que ces nouvelles vous font plaisir ;-)
Jc

Ps: Comme toujours, s'il y a un point que vous voulez que j'aborde avec plus de détails, faites moi simplement savoir lequel et je me ferai un plaisir de rentrer dans les détails techniques !

[LittleWhite]

En espérant que ces nouvelles vous font plaisir ;-)
Jc

Bien sur
Bien joue pour cette progression :clap::clap:
Une release pour le week end creation jeux videos ?

[fearyourself]

Avec un peu de temps mort pour d'autres projets que je devais faire, j'ai repris celui-ci et j'ai terminé une première version de l'aubergiste

Il peut donc :

- Nous faire dormir
- Prendre un des joueurs, nous rendre un des joueurs.

Il ajoutait quelques informations sur le moteur nécessaire mais maintenant je vais attaquer les armes/armures, qui devraient être plus rapide à faire :-)

Jc

[Remizkn]

j'ai hâte de pouvoir poser mes belles mains sur ce jeu!

[fearyourself]

j'ai hâte de pouvoir poser mes belles mains sur ce jeu!

Bientôt, il y aura la deuxième tech release vu que j'arrive bientôt à la révision 400 de mon SVN ;-)

Je pense à la fin de cette semaine,
Jc

[fearyourself]

C'est toujours intéressant de pouvoir entrevoir comment les choses ont été faites en 1988.

Je travaille en ce moment sur les vendeurs d'armes et armures. Dans ce deuxième volet, les choses étaient mélangées et on avait un seul vendeur pour les deux (par rapport aux premier volet qui séparé les deux).

Au final, c'est aussi intéressant de découvrir les choses et tenter de décoder comment ils pouvaient bien faire les choses. C'est un mélange de : lancer le jeu d'origine et regarder le comportement, inférer ce qui se passe, ouvrir les fichiers binaires et tenter de trouver comment tout était mappé.

Je me suis dit que ce post allait simplement présenter ce que j'ai fait hier soir pendant une heure.

- J'ai finalement découvert les prix des armes et armures du jeu :
- Il se trouve que le jeu avait un prix de base qui utilisait l'intelligence du joueur comme modificateur du prix
- Ces prix sont globaux à tous les marchands
- Chaque marchand peut vendre armes ou armures et pour le moment je n'ai vu que 7 objets à vendre par marchand mais il semble que le système pouvait autoriser plus ou moins d'éléments vu que la liste des objets vendus par un marchand fini par un -1.

Pour moi, découvrir ce genre de détail est toujours intéressant et je trouve cela pas mal comment ils ont fait cela.

Avec un peu de chance : ce soir, je peux commencer l'implémentation du premier marchand :-)
Jc