Discussion :

[fearyourself]

Ouais effectivement, tu as bon sur les deux points...N'empêche que perso j'aurais préféré en français.

Juste parce que le jeu est en anglais et que mes tests sont en anglais n'empêcheront à personne d'écrire les fichiers de configuration en francais ;-)

Jc

[fearyourself]

Petit ajout de la soirée : visibilité :-)

Voici deux images qui présente la première implémentation, j'ai encore un peu de travail pour le rendre un peu mieux. Ensuite, je vais ajouter la gestion de la nuit et des sources de lumière.

Jc

[bafman]

y'a pas moyen de désactiver le filtrage ? car la, c'est dommage, les perso font tout flou

[fearyourself]

y'a pas moyen de désactiver le filtrage ? car la, c'est dommage, les perso font tout flou

L'image de base étant si petite, je l'ai agrandie... Lorsque je passerai du temps à rendre tout plus beau, je demanderai quelqu'un de soit me polir ces graphismes où je tenterai d'en trouver des meilleurs.

On verra, je me suis habitué un peu donc cela ne me dérange pas trop ;-)

Jc

[LittleWhite]

Peut on avoir une explication sur la méthode utilisé pour la visibilité ( notamment pour les murs ).
J'imagine qu'il y a une histoire de distance ... peut être aussi une sorte de lancer de rayon tout autour du joueur ( en partant du joueur ), mais je ne suis sur de rien.
Sinon comme toujours, bon boulot

[fearyourself]

Peut on avoir une explication sur la méthode utilisé pour la visibilité ( notamment pour les murs ).

J'ai un peu optimisé le système ce soir car il n'était pas parfait. Il l'est sûrement pas, mais il fonctionne pas trop mal.

Tu as eu raison, c'est un lanceur de rayon plus ou moins. L'idée est de dire que rien n'est visible.

Ensuite, on va partir de la position du groupe et va vers chaque case du bord de l'écran. On part du milieu de la case du groupe vers un des coins de la case qu'on cherche.

Ensuite, on parcourt les autres cases de la carte pour déterminer si on a loupé quelque chose.

Enfin, à cause de certains artefacts, je recommence avec les horizontaux et les verticaux histoire d'avoir quelque chose qui semble nettement mieux.

Pour chaque droite, on part de la case départ et on avance en mettant chaque case qu'on découvre sur le chemin visible jusqu'à ce qu'on rencontre une case non transparente.

Au début, j'avais un peu peur que cela prenne trop de temps, je calcule tout cela à chaque changement de position. Par contre, quand j'ai calculé le temps de la mise à jour, ceci prend moins de 1 milliseconde.

Voici quelques images de la nouvelle version... Je vais bientôt ajouter le temps dans le jeu pour avoir la journée et la nuit.

Jc

PS : Le code se trouve dans le fichier Map.cpp pour les curieux...

[LittleWhite]

Idée idiote: On pourrait faire une sorte d'anti alisaing en jouant sur un calque en alpha.
( Bon ok, je vais me coucher )

[fearyourself]

Idée idiote: On pourrait faire une sorte d'anti alisaing en jouant sur un calque en alpha.
( Bon ok, je vais me coucher )

Moi j'avais pensé utilisé le stencil buffer afin de faire "bouger" les ombres en temps réel. Mais cela sera pour une autre version ;-)

Pour le moment, je me concentre sur les choses importantes :-) et arriver à une version jouable entière ;-)

Jc

[fearyourself]

Petite mise à jour de code :

On a maintenant la gestion de lumières et la gestion du temps. Quand ils fait nuit, on a de la lumière géré par certains sprites.



Ensuite, on a aussi certains Npc qui peuvent générer des lumières aussi. Genre un guarde qui se balade avec une torche.



Enfin, on a maintenant un nouvel objet : une torche !

Elle permet d'agrandir la visibilité pendant la nuit. Une fois allumée, elle le garde pendant un certain temps. La portée et la durée dépend de paramètres dans le fichier de configuration.


Jc

[Remizkn]

Et ba dit donc ça avance vachte bien, j'ai hâte d'y jouer une fois fini!

[fearyourself]

Et ba dit donc ça avance vachte bien, j'ai hâte d'y jouer une fois fini!

Doucement mais sûrement. Je continue de mettre en place les composants importants du jeu, ensuite je vais m'intéresser au mode combat mais j'ai encore quelques trucs à gérer.

J'ai décidé de finaliser le code sans combat d'abord et ensuite ajouter ce mode. Donc je vais sûrement, dans le futur proche faire une passe de commentaires, histoire d'avoir un code propre et commenter.


Enfin, je me dis que j'allais prendre un peu de temps et d'expliquer un peu comment la lumière et la visibilité sont gérées. Je m'excuse de la longueur potentielle de ce post mais je vais sûrement avoir pas mal de choses à expliquer.

Je vais aussi commencer par donner la version du SVN qui a ce code : r133.

Tout commence par l'heure de la journée. Cela est gérée par la classe GeneralViewState (je rappelle que nous avons notre moteur Engine qui peut avoir plusieurs états, GeneralView est un de ces états).

Vu que le moteur nous donne des mises-à-jour avec un delta temps, il est simple de faire :

Code :

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

1
2
    //Time it is
    timeItIs += diffTime;

Ensuite, l'affichage est facile:

Code :

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

1
2
3
4
5
6
7
8
9
    //Calculate time
    int timeTransfer = timeItIs / 100;
    int hours = (timeTransfer / 60) % 24;
    int minutes = timeTransfer % 60;
    bool dayTime;
    minutes /= 30;
    minutes *= 30;
...
    TextRenderer::getInst ()->renderString (1.0, 1.0, 1.0, 1.0, 290, 220, "", 18, timeLine.str ());

Ce qui permet d'avoir un temps qui bouge tous les 30 secondes. timeItIs étant en milli-secondes, je divise d'abord par 100 pour avoir quelque chose de correct.

Ensuite, comment gérer la journée et la nuit ? C'est très simple, vu que le rendu est géré par la classe Map, il suffit d'ajouter :

Code :

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

1
2
3
4
5
6
 
    //Decide how much percentage we should be displaying
    dayTime = (hours > 5 && hours < 21);
 
    if (map != NULL)
        map->render (10, 10, dayTime);

Maintenant, Map::render peut savoir s'il fait nuit ou non.

Nous voyons donc que c'est à la classe Map de gérer le rendu nuit ou non, et on peut maintenant présenter comment cette classe gérer tout cela.

En gros, on considére qu'une case est visible si : le joueur peut effectivement VOIR la case mais il faut aussi que la case SOIT illuminée.

Pendant la journée, toutes les cases sont illuminées. Par contre, pendant la nuit, seuls des objets de la map ou le groupe, ou des Npcs peuvent illuminés la Map.

Visibilité :

La première version de la visibilité mettait toutes les cases à visible et ensuite faisait une passe sur toutes les cases et lancer un rayon si la case était encore visible. Par contre, cette version prenait juste les coordonnées des cases et cela ne rendait pas quelque chose de très joli.

Au final, maintenant le rayon part du milieu de la case du groupe et va vers le coin le plus proche du joueur. Cela permet d'avoir un rendu nettement meilleur et symétrique.

Enfin, maintenant on fait l'inverse. Rien n'est visible au départ, on passe par les cases du bord et ensuite on fait les cases du milieu seulement si cela est non visible. Par contre, à cause d'artefacts, je refais les horizontaux et verticaux ensuite dans une deuxième passe.

Tout ceci est fait QUE lorsque le joueur bouge ou il y a eu un passe. Pour me simplifier la vie, en fait, ceci est fait à chaque événement clavier (ou passe) découvert par GeneralView.

Luminosité:

La classe Map contient pas mal de fonctions maintenant pour gérer tout ce qui est visibilité et luminosité. Vu que certains bouts de code sont pareil ou presque, j'ai factorisé autant que j'ai pu. Par contre, je considére que la visibilité du joueur est quasi infini et que la luminosité a un rayon, donc forcément, il y a certaines petites différences. Ces différences rendent le code des fonctions qui font le boulot un peu plus compliqué qu'à l'origine.

Au final, on doit gérer :
- Sommes nous en mode visibilité ou luminosité (cela change quel est le membre de la classe Cell que nous allons changer)
- Sommes nous en mode radial ou infini

Voici les points d'entrées:

Code :

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

1
2
3
4
 
        void calculateVisible (void);
        void calculateLit (void);
        void calculateObjectLights (void);

calculateVisible : ce que le joueur peut voir, cela change à chaque événement coût faible pendant le jeu

calculateLit : pour le moment je suppose que la map ne peut pas avoir des sources de lumières qui changent leur luminosité (au pire, je peux utiliser un objet animé qui ne bouge pas pour faire cela). Du coup, cela est fait au départ lors du chargement de la Map.

calculateObjectLights : on passe par tous les objets qui ont une luminosité et on regarde ce qui est visible ou non. Ceci est fait à chaque rendu pendant la nuit, donc cela a un coût modéré mais vu que cela est fait seulement pour les objets qui ont une source de lumière, au final, cela a un coût plus ou moins faible.


Ces trois fonctions vont initiailiser la map et ensuite faire leurs lancers de rayons pour déterminer si la case est : illuminé par une case de la map, illuminé par un objet de la map, visible par le joueur.

Au rendu, on passe par chaque case et au rendu, un simple test permet de faire :

Code :

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

1
2
3
 
    if (dayTime == false && isMapLit == false && isObjectLit == false)
        return;

Algorithme pour le lanceur de rayon:

Les trois fonctions font en fait plus ou moins la même chose.

- Ils parcourent la map et font des appels à cette fonction :

Code :

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

1
2
 
        void calculateVisibleOrLit (int sx, int sy, int cx, int cy, int ex, int ey, bool visible, int radius);

On va lancer des rayons dans le carré (sx, sy), (sx+ex, sy+ey). Les rayons partiront tous de (cx, cy). visible nous dit si oui ou non on s'intéresse à la visibilité par rapport à la luminosité et radius nous donne le rayon (0 si infini).

Par exemple, voici un bout de code de cette fonction :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
    for (j = sx; j < sx + ex; j++)
    {
        if ((radius > 0) && (calculateDistance (j, sy, cx, cy) > radius))
            continue;
 
        //Up and down
        interest = getVisibleOrLit (sy, j, visible);
        if (interest == false)
            handleVisibilityOrLit (cells, cx, cy, j, sy, visible);
 
        if ((radius > 0) && (calculateDistance (j, sy + ey - 1, cx, cy) > radius))
            continue;
 
        interest = getVisibleOrLit (sy + ey - 1, j, visible);
        if (interest == false)
            handleVisibilityOrLit (cells, cx, cy, j, sy + ey - 1, visible);
    }

Ce bout de code commence par gérer la ligne du haut et du bas. On part de sx et on va jusqu'à sx + ex. Ensuite, on regarde si on a un rayon, si oui, on regarde si la distance entre cette case et (cx, cy) est en dessous du rayon.

On va lancer un rayon si la valeur de la case est false. Vu qu'on gére SOIT la visibilité SOIT la luminosité, getVisibleOrLit nous permet de faire récupérer la bonne valeur de facon transparente.

Ensuite, on lance le rayon via la fonction handleVisibilityOrLit.

Cette dernière fonction gére séparément les cas horizontaux et verticaux (question de performances). Dans le cas général, nous devons d'abord calculer l'équation de la droite. Avant de faire cela, comme je l'ai dit au début, nous allons modifier légérement le point de départ et d'arriver.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
    double startDX = startX + 0.5;
    double startDY = startY + 0.5;
    double endDX, endDY;
 
    if (endX == startX)
    {
        endDX = endX + 0.5;
    }
    else
    {
        if (startX > endX)
        {
            endDX = endX + 1.0;
        }
        else
        {
            endDX = endX;
        }
    }
 
    if (endY == startY)
    {
        endDY = endY + 0.5;
    }
    else
    {
        if (startY > endY)
        {
            endDY = endY + 1.0;
        }
        else
        {
            endDY = endY;
        }
    }

D'abord (startX, startY) vont se voir bouger légérement de 0.5. D'un point de vue mathématique, les coordonnées de la case sont en fait le coin supérieur gauche. Ceci nous permet de nous positionner au milieu.

Enfin, (endX, endY) sont modifiés dépendant de leur position relative à (startX, startY) pour qu'ils représentent le coin le plus proche du point de départ.

Je pense avoir raconté l'essentiel, j'espére que ceci vous a intéressé,
Jc

[fearyourself]

J'ai lu, et je me demandais, comment avez vous appris à faire un design d'un jeu aussi bien.

Hmm, je ne sais pas vraiment. J'ai lu quelques articles et quelques livres mais c'est plus par expérience. J'ai écrit pas mal de petits jeux sans jamais les terminés car il y avait toujours un détail qui bloquait.

Trop souvent, cela a été de chercher trop grand, trop vite, trop compliqué.

En même temps, cela permet de voir ce qui fonctionne bien.

Je veux dire, votre machine à état et tout le reste est super assemblé.

, on verra si cela dure mais j'ai une surprise pour cette aprem mais pour le moment, j'avoue que cela semble fonctionner pas trop trop mal

Avez vous fait un design en UML avant de vous lancer ?
Des expériences passées, j'imagine qui cela aide beaucoup

Non, pas d'uml, ce n'est que de l'expérience passée. Je trouve que j'ai du mal à faire un design en UML, cela me lasse beaucoup et j'ai une tendance, en cours, de dire "Ah oui mais si cela était comme ca, ce serait nettement mieux".

Il y a deux risques dans comment je fais les choses :
- Le code est créé à la volée et peut aller dans une direction opposée de ce qu'on aura besoin plus tard
- Le code devient vite instable

Sinon, comme d'habitude, je suis super impressionné par le code ...

Ouai pas sûr que ce soit mérité, mais ;-)

Je voulais savoir, maintenant que je viens de crée un projet sur google code, pourquoi aviez vous choisi de placer votre projet sur la sourceforge?
( Avantages, inconvénients )... je veux savoir ce qui a conduit votre choix

Moi, j'ai été sur sourceforge depuis bien longtemps, à une époque où il fallait attendre un peu avant d'avoir son projet accepté. Ils avaient un processus d'acceptation, etc.

Pour le OpenSource, moi j'aime bien SourceForge, c'est simple et ca fonctionne. SVN est supporté et je connais bien SVN.

Il y a pleins d'autres endroits qui fonctionne et dont j'entends du bien :
- Git
- Google code

C'est un choix personnel... Honnêtement, j'ai déjà un compte chez SourceForge, donc je n'ai vraiment pas cherché loin. Cela fonctionne bien et je ne vois pas pourquoi changé.

C'est pour cette même raison que je code en VI et non avec une EDI sophistiquée. Cela fonctionne pour moi et ca me va, pourquoi changer ;-)

Cet après-midi je raconterai mon dilemne de hier soir et tu verras les soucis de ne pas faire un UML ;-)

Jc

[fearyourself]

J'ai un peu de temps donc je vais me lancer dans l'explication du dilemne de hier soir ;-)

Dans le jeu de base, tu pouvais en fait parler aux gens et certains pouvaient rejoindre ton groupe. Il suffisait de demander "join" et la personne répondait oui ou non dépendant de ton expérience.

Petite remarque :
- Le jeu de base était simpliste, la personne rejoignait le groupe SI le nombre de personnes dans le groupe était inférieur à ton niveau actuel.

Hier soir, j'ai voulu mettre cela en place et donc je me suis retrouvé confronté à un mini problème.

D'un côté, j'ai une classe Character qui hérite de Class qui permet d'avoir toutes les informations sur un perso du groupe : force/rapidité/arme/armure/etc.

De l'autre côté, j'ai une classe Npc (Non playing character) qui hérite de AnimatedObject qui permet d'avoir toutes les informations sur un personnage non joueur : quoi dire/quoi vendre/quoi acheter/comportement.


Comment faire pour les fusionner dans le cas où :
- On attaque un NPC
- On demande à un NPC de nous rejoindre.

J'aurai pu potentiellement faire du multi-héritage au niveau du Npc. On peut le laisser hériter le Character et le AnimatedObject. Souci : les deux contiennent des membres avec les mêmes noms, cela deviendrait probablement un tant soit peu compliqué.

Au final, j'ai accepté de faire quelque chose de différent : un Npc contient un pointeur vers son caractère. Lors d'une discussion, on procéde normalement, par contre, si le join est une réussite, on fait simplement:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
                {
                    //Remove from cell
                    cell->empty (false);
                    //Get character
                    Character *character = npc->getCharacter ();
                    //Set name of character
                    character->setName (npc->getName ());
                    //Add to group
                    group->addCharacter (character);
                }

Ce qui montre que c'est vraiment facile : on vide la cellule, on récupére le caractère, on met à jour le nom (plus en dessous), et on ajoute au groupe.

Pourquoi met-on à jour le nom ? Cela permet d'avoir en fait un caractère "générique" pour tous les Npc si besoin est. Du coup, on peut avoir un caractère "Citoyen" mais le Npc est nommé Bob. Lors du join ou d'un combat, on pourra prendre le caractère, on change le nom et c'est gagné :-)

Petite reflexion après coup : tout ceci a fonctionné comme sur des roulettes une fois le dilemne levé. Le double héritage bien que possible me semblait un peu bancal et moins clair que ce que j'ai fait ici.

Avec une pré-étude, potentiellement, j'aurai trouvé une autre solution mais pour le moment, cela me semble propre et très fonctionnel.

En quelques images :

Notre bergére Katrina est dans le magasin de nourriture.


On lui parle un peu


Après la demande de nous rejoindre, elle se retrouve ajouter au groupe !


On a sa fiche directement, le Npc Katrina a disparu, laissant la place au caractère du groupe Katrina :-)


Jc

[LittleWhite]

Je suis un peu perdu tout de même. Il faudra que je jette un coup d'oeil sur le code.
( Mon message semble ne plus être présent sur le forum O_o ) Pourtant vous y avez répondu ...

Pour le personnage/groupe, je suis un perdu.J'imagine que vous avez une liste de pointeur sur les personnes de votre groupe ( ou même sans pointeurs ).
Mais alors pourquoi vous avez besoin de faire tout ce jeu avec le nom des personnages.
Si j'ai bien compris, pour le coté Engine, vous gardez le nom du type de personnage, et pous le coté User, vous affichez le nom du personnage. Non?

Pour l'UML, je pense qu'il ne faut pas rester bloqué sur un UML fixe. On fait un UML, ça donne une première grande idée de ce que ce sera, et puis après, pendant la conception on peaufine .

[fearyourself]

Je suis un peu perdu tout de même. Il faudra que je jette un coup d'oeil sur le code.\

Si cela t'intéresse :-)

Pour le personnage/groupe, je suis un perdu.J'imagine que vous avez une liste de pointeur sur les personnes de votre groupe ( ou même sans pointeurs ).

En effet un vector de personnes du groupe.

Mais alors pourquoi vous avez besoin de faire tout ce jeu avec le nom des personnages.

On a une séparation des personnages et des joueurs non persos. Cela est fait parce qu'un caractère du groupe n'avait pas besoin d'avoir les informations des discussions.

Par contre, à présent, vu qu'on peut demander à quelqu'un de nous rejoindre, on a besoin de passer du mode NPC au mode perso du groupe.

La question des noms arrive quand on a deux guardes différents, par exemple, un qui a quelque chose a dire de spécial et un autre générique. Ils auront les mêmes informations lorsqu'un combat sera demandé, ils auront les mêmes armes, etc.

Du coup, on aura les mêmes informations via les informations des caractères. Par contre, il faut bien un nom au caractère. Donc quand on passe du NPC au caractère, on met à jour le nom, c'est tout. Peut-être qu'une vue du code aiderait

Pour l'UML, je pense qu'il ne faut pas rester bloqué sur un UML fixe. On fait un UML, ça donne une première grande idée de ce que ce sera, et puis après, pendant la conception on peaufine .

C'est clair ;-)

Jc

[fearyourself]

Ajout de la journée : La téléportation !

Ce que cela permet : une première étape à pouvoir charger des maps différentes et donc : sortir de la ville pour la première fois ! :yeah:

On a donc 3 images :

Avant la téléportation :


Après on arrive à l'île du sud mais j'ai enlevé le pont ;-)


Ensuite, il y a un perso sur l'île, c'est l'ami Truelle :-)


La même case permet de revenir au point de départ.

Pour le moment, je ne gére que les téléportations dans la map, mais ce n'est qu'à un pas pour charger une nouvelle map ;-)

Jc

[LittleWhite]

La première fois que j'ai entendu parlé de téléportation, j'ai été étonné.

Après en regardant vos image, je n'ai pas compris. Comment voit on un téléporteur ?
Comment c'est écrit dans le fichier ?
Enfin j'imagine que cela à au moins, la case de destination

QUoiqu'il en soit,

[fearyourself]

La première fois que j'ai entendu parlé de téléportation, j'ai été étonné.

Après en regardant vos image, je n'ai pas compris. Comment voit on un téléporteur ?

On ne le voit pas forcément. Cela peut se cacher en fait comme ici. Je pourrais utiliser une tuile spéciale mais voit ceci comme un secret de la map ;-).

Comment c'est écrit dans le fichier ?
Enfin j'imagine que cela à au moins, la case de destination

QUoiqu'il en soit,

Ceci se fait dans le fichier de la map :

#Teleportation
#This one is local to (0, 0)
255 100 100 3 0 0 0 1 49 61
254 100 100 3 0 170 0 1 54 19

On a la couleur de la map, ensuite le type (3 étant téléportation) ensuite la convention pour en dessous du teléporteur (ce que le joueur voit).

Est-ce local ou non (doit-on charger une autre map, si oui on aurait le nom de la map), et les coordonnées destination.

Ensuite c'est facile, s'il y a un mouvement, on regarde si on doit se téléporter, si oui, on fait le nécessaire (chargement de la map, mis-a-jour de la position).

J'ai ajouté un test pour être sûr que la case destination n'est pas occupée si oui, on a un message du style

"Something odd happened, you got sent back

Jc

[fearyourself]

Après l'implémentation des téléporteurs, on était à qu'un pas de pouvoir passer d'une map à une autre.

Du coup, forcément, je me suis permis de trouver une image de la map du monde du jeu de base, et j'ai ajouté la possibilité de sortir de la ville et d'y retourner.

Quelques images:



J'ai décidé pour la première fois de mettre une video du jeu afin de montrer un peu comment ca se passe. Vu que cela tourne sur mon portable, avec le logiciel de capture, les images par secondes ont baissé. Normalement, je tourne à 60 images par secondes.

La video, montre comment on se balade dehors, comment on rentre dans une ville et je la traverse. A la fin, je m'amuse à regarder l'inventaire et équiper une arme et une armure.

Bonne visionnement,
Jc

[Syl_20]

Je viens de voir la vidéo (j'ai lutté pour trouver le bouton de téléchargement)
C'est super sympa mais c'est en vitesse accéléré? Le perso va super vite, la ville est traversé en seconde

En tout cas gros potentiel j'ai hâte d'en voir plus