Discussion :

[fearyourself]

Informations générales du projet:
Le projet est sur source forge : https://sourceforge.net/projects/backtoroots/
Langage de programmation : C (pour la partie LUA), C++ pour le reste
API pour les graphismes : SDL + OpenGL + Glut (temporaire, pour le texte) + libxml2
Nombre de révisions sur le GIT : 511
Nombre de fichiers cpp : 103
Nombre de fichiers h : 113
Nombre de fichiers de configuration : 429
Nombre de lignes de code : 46185 (26780 effectifs)
Nombre de lignes dans les fichiers de configuration: 11490 (7672 effectifs)

La sortie de Valgrind après une mini utilisation, à savoir que ceci provient des internes de SDL + OpenGL (on aurait plus avec Glut si on utilise Glut pour le rendu texte) :

==15374== HEAP SUMMARY:
==15374== in use at exit: 97,833 bytes in 1,679 blocks
==15374== total heap usage: 646,378 allocs, 644,701 frees, 421,488,230 bytes allocated
==15374==
==15374== LEAK SUMMARY:
==15374== definitely lost: 712 bytes in 13 blocks
==15374== indirectly lost: 7,397 bytes in 334 blocks
==15374== possibly lost: 0 bytes in 0 blocks
==15374== still reachable: 89,724 bytes in 1,332 blocks
==15374== suppressed: 0 bytes in 0 blocks

BackToRoots est mon petit projet des soirs perdus et des weekends pour programmer et s'amuser.

Le but est d'avoir un moteur qui gére les jeux de rôle à tuile et à tour. C'est vieux, c'est moche, c'est limité, c'est en 2D, qu'est-ce que c'est bon !

Voici quelques screenshots :

Je gére les graphismes de base :


Mais aussi la version VGA :


Jc

[fearyourself]

Ce post sera une mini explication de comment je gére les chargements des villes :

Nous avons d'abord un fichier qui définit la ville

#Image of the city
data/novea.bmp
#Default sprite sheet
data/sprites.bmp
#Size of one tile
16 16
#Size of image
32 64
#Number of animated sprite conventions (B,G,R, filename, Passage: cost to pass, 0 can't)
1
0 0 128 data/water.txt 0
#Number of non-animated sprite conventions (B,G,R,PosX,PosY,Passage: cost to pass, 0 can't)
6
0 0 0 5 1 1
0 255 0 6 0 1
255 0 255 15 5 0
0 128 0 14 3 1
0 170 0 6 1 1
0 128 255 11 35 1

Tout ce qui commence par un # est un commentaire géré par le système. Ensuite, nous avons :

• l'image de la ville
• l'image par défaut pour les tuiles
• la taille par défaut des tuiles
• le nombre de tuiles de l'image par défaut
• le nombre de tuiles animées
• les tuiles animées
• le nombre de tuiles non animées
• les tuiles non animées

Les tuiles non animées sont par exemple les routes, les murs, les ponts. Les tuiles animées sont l'eau par exemple...

Une ligne est définie par exemple :

0 128 255 11 35 1

Cela veut dire que la couleur (0,128,255) (en BGR), représente en fait la tuile (11,35) de la feuille des tuiles et le 1 veut dire que cela coûte un mouvement pour passer à travers.

Un 0 veut dire qu'on ne peut pas passer à travers.

Les tuiles animées sont définies par un autre fichier de configuration, les tuiles non animées par leur position dans le fichier de sprite par défaut.

Une ligne est par exemple:

0 0 128 data/water.txt 0

Veut dire que la couleur (0, 0, 128) (en BGR) représente la tuile définie par le fichier data/water.txt. Le 0 veut dire que cette tuile est infranchissable.

Remarquer que cela nous permet de faire ceci :

128 128 128 data/water.txt 1

qui voudrait dire que nous avons une tuile définie par data/water.txt mais qui est franchissable. Par contre, la couleur dans l'image ville serait différente. Nous venons de créer : un passage secret !

Une ville est représentée par une image :


Les conventions du fichier de configuration permettent de dessiner comme on veut la ville avec les couleurs de nos choix et ensuite de mettre la convention dans le fichier de configuration.

Voili voilou pour l'histoire de la gestion des villes, des fichiers configurations et de l'image de la ville :-)
Jc

[Suiland]

-
Salut , Exellent ! j'attends la suite avec impatience .

Dit moi comment fait tu pour déffinir le sens des sprites comme les ponts ou les rivières , tu utilise une couleur différente ou tu l'écrit dans ton code?

Très sympa de faire profiter les autres d'un développement en cours en plus je suis très interressé par la configuration d'une carte par couleurs pour un projet perso donc je vais suivre ton projet avec beaucoup d'attention .

A Plus

Suiland ...

-

[fearyourself]

-
Salut , Exellent ! j'attends la suite avec impatience .

Dit moi comment fait tu pour déffinir le sens des sprites comme les ponts ou les rivières , tu utilise une couleur différente ou tu l'écrit dans ton code?

Très sympa de faire profiter les autres d'un développement en cours en plus je suis très interressé par la configuration d'une carte par couleurs pour un projet perso donc je vais suivre ton projet avec beaucoup d'attention .

A Plus

Suiland ...

-

En fait c'est très simple, je ne me suis pas amusé à changer quoi que ce soit. Dans le code j'ai une solution pour faire des flips horizontaux/verticaux mais pas encore de rotation (ce serait facile à ajouter).

J'ai mis une régle dans mon développement de ce jeu : garder le tout simple et finir une première version avant de me lancer dans des améliorations/optimisations.

Une fois que j'ai ce premier moteur qui tourne, j'écrirai un mini script pour le tester et, seulement à ce moment-là, je me lancerai dans des optimisations pour rendre le moteur plus performant. :-)

Les graphismes sont pris de cette feuille de sprite :

(pris de cette discussion : http://gmc.yoyogames.com/index.php?showtopic=457780)

Si vous ajoutez ce fichier dans data sous le nom de data/sprites.bmp et que vous l'agrandissez les Y à 1024 (sans changer la taille des sprites, juste l'image), vous devriez avoir un programme qui tourne.

Enfin, pour répondre à la question : tu verras qu'il y a un pont vertical et des ponts horizontaux. Donc je n'ai pas besoin de faire quoi que ce soit.

Mais si tu voulais l'ajouter, ce serait facile, il suffirait d'ajouter un champs dans le fichier de configuration qui donne l'angle de rotation. Vu que tout est fait en OpenGL, ca serait facile à gérer.

Jc

[Suiland]

-
Ah .. , je me suis mal exprimé , en imaginant que le pont soit déffini par la couleur marron foncé sur la carte de la ville , je me demandais comment l'ordinateur savait qu'il faut afficher le pont horizontalement ou verticalement .

Sinon le perso il aura une petite anim?

Merci ..

Suiland ...
-

[fearyourself]

-
Ah .. , je me suis mal exprimé , en imaginant que le pont soit déffini par la couleur marron foncé sur la carte de la ville , je me demandais comment l'ordinateur savait qu'il faut afficher le pont horizontalement ou verticalement .
-

Une ligne de configuration est définie comme ceci pour les tuiles non animées :

0 128 255 11 35 1

On a la couleur (0, 128, 255) (BGR)
On a la position de la tuile (11,35) donc dans la map, 12ème colonne et 34ème ligne.
Est-ce qu'on peut marcher dessus : 1 -> oui en un mouvement.


Donc suffit de mettre par exemple :

0 128 255 11 35 1
0 255 0 6 0 1

On a donc la couleur (0,128,255) pour le pont vertical et (0,255,0) pour le pont horizontal.

Est-ce cela que tu voulais dire ?

Sinon le perso il aura une petite anim?

Oui c'est déjà en place ! Voici le fichier d'animation pour le perso :

#Sprite image
#Number of states
#
#For each state:
# Speed
# Number of frames
# Texture
data/sprites.bmp
32 64
500
4
16 0
17 0
18 0
19 0

- On a donc la feuille de sprites, le nombre de tuiles.
- La vitesse d'animation
- Le nombre d'images pour l'animation
- Les coordonnées pour chaque image

Ensuite, le moteur de jeu demande la mise à jour et c'est fait en interne

Espérant avoir répondu à tes questions,
Jc

[Suiland]

-
Oui merci pour ta réponse , en fait tu utilise une couleur différente pour horizontal et vertical .

Cela fait pas mal de couleur a gerer , dis moi par curiosité est qu'il est possible de détecter 2 couleurs sur une case ?
Ex : marron avec une croix rouge , marron avec une croix jaune etc ...

Sinon elle font combien tes cases de couleur sur la carte car l'image est floue et je n'arrive pas a voir .

Merci pour tes réponses .

Suiland ...
-

[fearyourself]

-
Cela fait pas mal de couleur a gerer , dis moi par curiosité est qu'il est possible de détecter 2 couleurs sur une case ?
-

Non, c'est impossible pour l'instant. Cette image représente l'image de fond donc : 1 pixel une tuile.

Il n'y a pas, dans cette variante du moteur, la possibilité de mettre plusieurs tuiles sur la même case.

Sinon elle font combien tes cases de couleur sur la carte car l'image est floue et je n'arrive pas a voir .

Je ne comprends pas la question mais au final, ceci sera fait par un éditeur dès que le moteur est en place. Du coup, personne ne sera obligé de faire cela à la main ;-)

C'est vraiment un pixel -> une tuile. L'image fait 64 * 64 pixels, donc 64 * 64 cases. Pour le moment il y a 7 couleurs différentes je crois... Ce n'est pas trop difficile à gérer ;-)

Jc

[Suiland]

-
Ah d'accord j'ai été abusé par la taille 512*512 de ton screen , ok je comprends mieux , désolé .

Je vois que tes tiles sont déffinies 16*16 , est que tu aura la possibilité de monter facilement a 32*32 ou cela n'est pas possible ?

Suiland ...
-

[fearyourself]

-
Je vois que tes tiles sont déffinies 16*16 , est que tu aura la possibilité de monter facilement a 32*32 ou cela n'est pas possible ?
-

Oui, en fait le moteur l'accepte déjà... Je peux accepter n'importe quelle sprite sheet, il suffit de dire combien de tuiles en X et combien en Y. Et le moteur gére le reste.

Pour la taille à l'écran, j'ai en fait un multiplicateur de taille que je peux changer à la volée si je veux. J'utiliserai ca pour que l'utilisateur puisse choisir son zoom à la volée aussi.

Je permets aussi déjà l'utilisation de tuiles de tailles différentes. Le rendu fonctionnera de facon transparente...

Comme dit, je garde la plupart de moteur ultra simpliste car je veux qu'il fonctionne ;-)

Jc

[Suiland]

-
Cool ! Sinon tu déffini tes layers comment ? est qu'il sera possible de déffinir le layer d'une tile .

Tu pense avoir une démo quand ?

Suiland ...
-

[fearyourself]

-
Cool ! Sinon tu déffini tes layers comment ? est qu'il sera possible de déffinir le layer d'une tile .

Pour le moment, il n'y pas de layers. Un fond et ensuite un rendu par dessus avec le joueur et les NPC.

C'est tout pour la première version ;-)

Pour le moment, je ne gére pas la transparence, je fais simple et j'aime ca ;-)

Tu pense avoir une démo quand ?

Hmm ca va dépendre du temps que je vais avoir. En quelques heures, j'ai une ville dans laquelle le joueur peut se balader et avec une gestion des murs. Les animations sont en place.

Mais il y a encore tellement de choses à faire :-)

Jc

[LittleWhite]

Wouah, déjà tout ça ...

J'avais appris ( dans la théorie ) la méthode de chargement par BMP, en cours l'année dernière.

( Bon maintenant il faut que je lise tout les posts )

Maintenant, la tonne de questions ( bah oui, j'ai lu ). Je suis un gros flemmard, donc y a plein de réponse que je peux voir dans le code.

Le langage ? ( C ou C++ )
Les technologies ( SDL ? )
Comment on compte les lignes utiles ? ( wc -l ... avec un sed avant pour enlever les commentaires )
Thanks flying vim?
Ne connaissant pas le jeu de base, le coup de déplacement à 1 pour dire que l'on peut bouger dessus, et 0 que l'on ne peut pas ... est ce que c'est parce que le jeu de base est un jeu tour par tour ? ( Sinon, je suis à coté de la plaque ).
Comment fonctionne votre chargeur de fichier ( .txt ). Il est fait en C++ je crois ( vous connaissant travaillant en C++ ), utilise t'il des streams, ou des vieilles fonctions du C?
Et il bug free ? ( genre je rentre n'importe quoi, il va planter ? ( genre lettre à la place de nombre et autre ) ) Pour éviter les plantages, une exception pourra être utilisé?
Comment ... hum, il faut que je regarde le code :s mais il est déjà minuit ( même dans le pays ou je suis ) ... donc comment lisez vous les commentaires ( un peek() ) et si c'est un commentaire on passe la ligne ( getline() ? )

Euh, j'arrête là, et bonne continuation ( et merci de faire partager votre travail aussi librement )

[Suiland]

-
Décidemment je m'exprime mal désolé , je ne parlais pas de la transparence Alpha mais de la profondeur des sprites , l'ordre d'affichage , le perso est afficher par dessus les tiles d'herbe , ce que je demandais c'est s'il y avait la possibilité de déffinir cet ordre d'affichage .

Bon courage !!

Suiland ...
-

[fearyourself]

Multi réponse :-)

J'avais appris ( dans la théorie ) la méthode de chargement par BMP, en cours l'année dernière.

Oui c'est une bonne veille méthode mais hyper pratique. On ne joue plus avec un fichier texte mais sur une image, c'est plus visuel et plus facile.

Plus tard, lorsque j'aurai un éditeur, ca risque de disparaître et on passera directement à un fichier binaire. Pour l'instant, c'est pratique et facile.

Le langage ? ( C ou C++ )

C++

Les technologies ( SDL ? )

Toujours et encore, SDL/OpenGL. Lorsque le projet sera plus avancé, je risque de faire un port vers la SFML. On verra.

Comment on compte les lignes utiles ? ( wc -l ... avec un sed avant pour enlever les commentaires )

sloccount, un petit programme marrant.

Ne connaissant pas le jeu de base, le coup de déplacement à 1 pour dire que l'on peut bouger dessus, et 0 que l'on ne peut pas ... est ce que c'est parce que le jeu de base est un jeu tour par tour ? ( Sinon, je suis à coté de la plaque ).

Oui, bien que le jeu de base avait un système de "si tu n'as rien fait en 1 minute, y a un passe.

Comment fonctionne votre chargeur de fichier ( .txt ). Il est fait en C++ je crois ( vous connaissant travaillant en C++ ), utilise t'il des streams

Bonne question. Je l'ai pris de mon projet de turtleladel. C'est du C++ pur normalement.

Et il bug free ?

Quasiment sûr que non.

Je pars du principe que plus tard dans le projet je vais écrire l'éditeur donc même cette partie risque de disparaître un peu (quoi que l'éditeur pour générer des fichiers texte. A voir).

Pour éviter les plantages, une exception pourra être utilisé?

Clairement.

donc comment lisez vous les commentaires ( un peek() ) et si c'est un commentaire on passe la ligne ( getline() ? )

Pourquoi un peek ? ;-), je fais simplement ca :

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
 
   48 string LineParser::getNextLine ()
   49 {
   50     string line;
   51 
   52     // Read line by line
   53     while (std::getline (file, line))
   54     {
   55         if (verbosis)
   56             cout << "Reading line (" << fileName << ")" << ": " + line << endl;
   57         //Remove commented lines
   58         if (line[0] != '#')
   59             return line;
   60     }
   61 
   62     cerr << "Error reading line in file: " << fileName << endl;
   63     exit (EXIT_FAILURE);
   64 
   65     return "";
   66 }

bonne continuation ( et merci de faire partager votre travail aussi librement )

, hier soir j'ai commencé l'implémentation des NPC :-)

-
Décidemment je m'exprime mal désolé , je ne parlais pas de la transparence Alpha mais de la profondeur des sprites , l'ordre d'affichage , le perso est afficher par dessus les tiles d'herbe , ce que je demandais c'est s'il y avait la possibilité de déffinir cet ordre d'affichage

Pas besoin dans ce jeu: on a seulement deux niveaux :

les tuiles de la map et les objets/NPC/groupe. Donc on fait deux rendus sans un test de profondeur.

Au pire, si je voulais faire encore plus simple, je mettrais les tuiles à une hauteur de 0 et le reste à 1 et je laisse OpenGL gérer le tout.

Jc

[fearyourself]

Petite amélioration : j'ai ajouté dans le fichier d'une map : les NPC :-).

Histoire de faire simple, je trouvais qu'une image qui contient chaque élément : décor + NPC est mieux que deux fichiers différents et le besoin de jongler entre...

donc la nouvelle structure devient :

1 #Image of the city
2 data/novea.bmp
3 #Default sprite sheet
4 data/sprites.bmp
5 #Size of one tile
6 16 16
7 #Size of image
8 32 64
9 #Number of conventions
10 #Each convention is defined by:
11 # - The color (B,G,R)
12 # - Type of convention
13 # - Not animated (background image) 0
14 # - Animated background 1
15 # - NPC 2
16 # - The color under the NPC (can be a previous convention except NPC)
17 # - The name of the information file
18 # - Sprite file (if animated)
19 # - NPC file (if NPC)
20 # - The passage cost (0 for not allowed) (if animated or not)
21 8
22 #Animated
23 0 0 128 1 data/water.txt 0
24 #Non animated
25 0 0 0 0 5 1 1
26 0 255 0 0 6 0 1
27 255 0 255 0 15 5 0
28 0 128 0 0 14 3 1
29 0 170 0 0 6 1 1
30 0 128 255 0 11 35 1
31 #NPC
32 255 0 0 2 0 0 0 data/guard.txt

Comme on voit : j'ai fusionné les conventions ensemble. Maintenant on a le type de la convention qui permet de distinguer entre.

Finalement, dans le cas d'un garde, on a une convention en plus pour exprimer ce qui se trouve en dessous du NPC (dans le cas où il bouge :-)).

Ironiquement, cela a simplifié le code de gestion de ce fichier puisque je n'ai plus qu'une classe MapConvention au lieu de 3 différents types ;-)

Jc

[LittleWhite]

Et dire qu'il y a deux ans, j'ai essayé de me faire un zelda like ... et bah ... il faudrait que je m'y remette ( avec un redemarrage complet ) ( me faut toujours des artistes )

Bon tout ça pour dire, que pour moi NPC ça veut dire:

- Dialogues ( donc sorte de collision de proximité pour les activer )
- Mouvements, pour rendre NPC vivant ( même des chemins, c'est pas grave )

Y aura t'il tout ça dans votre superbe projet ?

Et puis pour le chargement de fichier, je me doutais bien que tout venait de turtleladel mais j'avais oublié le nom donc j'allais pas dire un truc faux ( pour pas avoir la honte )
( et puis comme ça, je sais aussi comment c'est géré dans turtleladel )

[fearyourself]

Et dire qu'il y a deux ans, j'ai essayé de me faire un zelda like ... et bah ... il faudrait que je m'y remette ( avec un redemarrage complet ) ( me faut toujours des artistes )

Qui n'a pas tenté ca ;-)

- Dialogues ( donc sorte de collision de proximité pour les activer )

Le jeu de départ n'avait pas ca donc ca ne sera pas dans la première version. La seule chose autorisée comme interaction par un NPC était une attaque et donc envoi en mode combat.

- Mouvements, pour rendre NPC vivant ( même des chemins, c'est pas
grave )

Le jeu original avait trois types de mouvements :
- Pas de mouvement
- Aléatoire
- Aller vers le groupe

Pareil, je vais respecter ca et ensuite je le changerai/ajouterai...


Y aura t'il tout ça dans votre superbe projet ?

Et puis pour le chargement de fichier, je me doutais bien que tout venait de turtleladel mais j'avais oublié le nom donc j'allais pas dire un truc faux ( pour pas avoir la honte )
( et puis comme ça, je sais aussi comment c'est géré dans turtleladel )

Exactement :-)

[fearyourself]

Voilà après quelques heures derrière le PC, j'ai réarrangé un peu le code et j'ai finalement fini réussi à avoir une première gestion des NPC :




Nous avons donc maintenant : des NPCs qui bloquent le chemin (on ne peut plus aller sur un NPC ;-)), ils bougent de facon aléatoire mais respectent les murs, etc.

Ils bougent lorsque le joueur bouge (ou ne bougent pas d'ailleurs). Ils sont bien sûr animés.

Et on peut les ajouter via une convention dans l'image directement.

Bien que je ne sois pas sûr que j'ai raison de comment certaines choses ont été faites, ca me semble pas mal pour l'instant ;-)
Jc

[LittleWhite]

Bien que je ne sois pas sûr que j'ai raison de comment certaines choses ont été faites, ca me semble pas mal pour l'instant ;-)
Jc

Le forum est là pour ça, et je suis toujours très interessé par vos projets, vu que je trouve le code magnifique . ( Tient, d'ailleurs, d'après un de vos message sur un autre post, j'ai un doute sur le fait que vous vérifié les pointeurs )

Comme bien souvent j'ai posé une tas de question idiote, à cause du fait que je ne connais pas le jeu de base :s.