Discussion :

[Azharis]

Voila, je voudrais avoir l'avis de personnes plus expérimenté que moi sur un sujet.

Pour apprendre à programmer, je développe différentes facettes d'un jeu de rôle en essayant de le faire le mieux possible.

Mais mon problème est le suivant :

Il y a un total de 13 races, donc 13 classes descendant toutes d'une classe Joueur.
Pour ces 13 races, il y a 19 caractéristiques qui ont donc des valeurs différentes pour chacune.
Ce que j'ai fait, c'est que dans chaque constructeur de race, j'affecte chaque valeur à chaque caractéristique :

Code :

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

1
2
3
4
5
6
Carac[eReflexes].base = alea(21) + 50;
Carac[eRapidite].base = alea(21) + 30;
Carac[eVitesse].base = alea(31) + 10;
Carac[eAdresse].base = alea(31) + 60;
Carac[ePuissance].base = alea(21) + 10;
...

Le "alea" est une macro pour les nombres aléatoires.
Les eReflexes, ePuissances, etc. sont une énumération des caractéristiques.

Ce qui me fait 19 lignes pour chaque race.

Ma question est : est-il préférable de faire comme ça ou plutôt de mettre dans un fichier d'en-tête des tableaux constants répertoriant toutes les valeurs et ainsi affecter chaque valeur dans le constructeur de Joueur (classe mère des races) de manière automatique.
Sachant qu'il y a aussi d'autres données comme les cheveux, les yeux, la taille max et min, etc.

Personnellement je pencherais plutôt vers la deuxième solutions.

Je vous remercie d'avance de vos sages conseils.

[Higestromm]

Selon moi je pense que c'est mieux... Par contre mettre des tableaux contants... je vois pas l'intéret vu que tu ne pourra pas modifier leurs contenu.

[Laurent Gomila]

Si Luc passe dans le coin, il te fera sûrement son petit topo sur "pourquoi il ne faut pas avoir 13 classes spécialisées pour 13 races, et quoi faire à la place"

Pour ce qui est du "quoi faire à la place", tu peux voir tes races non pas comme des spécialisation de joueur, mais comme une composition de caractéristiques. Et les caractéristiques de base genre reflexes, rapidité, vitesse, ... peuvent être inscrites dans des fichiers de configuration (XML ou autre) plutôt qu'en dur dans le programme, je pense que ce serait préférable.

[Azharis]

Pour Higestromm :
Je fais des tableaux constants car c'est des données qui ne bougerons pas, par exemple un humain aura toujours entre 80 et 100 en puissance.


Sinon, c'est sur que c'est une bonne idée de stocker les règles ( donc tous les tableaux constants ) dans des fichiers sur le disque dur, il ne me reste plus qu'à trouver comment ça marche.

[Azharis]

Pareillement, j'ai un tableau constant qui possède tous les noms des races et dans la class du personnage, plutôt que de stocker le nom de la race, je stock le numéro de la case du tableau. Sachant qu'il y a aussi la classe, la religion etc. qui est géré comme ça, est-ce que ça vaut mieux plutôt que de gérer directement en chaine de caractère ?

Ca alège l'objet mais ça allourdie le programme avec les constante.

Ca simplifie aussi la création du personnage.

[Clad3]

Je doit pas être reveillé car j'ai du mal a suivre ce que tu raconte ;o) ( enfin ca c'est ma faute lol ) .

Premiérement , je pense que c'est plus qu'une bonne idée de sotcker ce genre d'information dans des fichier d'un format de ton choix ( xml , txt ect .. ) plutot qu'en dur .

Je n'ai pêrsonellement pas la même approche que toi pour programmer ce genre de chose ( mais la mienne n'est surement aps la meilleur non plus ) .
Je ne code RIEN de précis avant que tout le "moteur" du jeu soit achevé .

je m'explique :

Par exemple, inutile d'écrire en dur tout les dialogue de ton jeu alors que celui n'en est qu'a 0.000001% de developement . Par contre, j'en ai écrit 1 ou 2 , pour pouvoir tester simplement certaines fonction d'affichage de texte .
idem pour les races , si tu a de quoi gérer tout tes attributs ect ( ce qui va être au coeur de ta classe "race" ) ; et bien lance toi dans la création d'une classe "race" ( pas une par race, non non non , une classe générique ) .Puis teste la avec UNE race ( les humains par exemple ) .

Si ca fonctionne bien , il n'y a pas de raison que ca ne marche pas avec les "troll géants" . Et ca tu pourra le faire plus tard, tranquilement .

Le conseil que je te donnerais ( enfin ca vaut ce que ca vaut, car je suis débutant aussi lol ) .
- Essaie de rester le plus générique possible ; et de garder un systéme flexible qui te permetra plus tard, par exemple de pouvoir ajouter plein de race, sans avoir a recodé plein de choses . ( -> d'ou l'importance du systéme de fichier ) .
- je trouve plus simple de commencer par les classes de vraiment "bas" niveau puis de remonter petit a petit .
( par ex : faire une classe pour gérer le chargement des ressources avant de créer la ressource elle même ...)

Voila j'espére ne pas avoir dit trop d'ânerie

[Azharis]

C'est sur que le fait d'avoir crée les 13 classes m'a pris énormément de tempslorsque j'ai du modifier certaines lignes mais maintenant qu'elles y sont, j'ai pas envie de les enlever.

De plus, le nouveau système que je veux mettre en place me permettrais justement de ne pas avoir à modifier une chose à 13 endroits mais seulement dans un seul. Et je pense aussi beaucoup au système évolutif, c'est pour ça que je crée des class pour chaque race, c'est pour pouvoir les distinguer facilement en cas de modifications ne touchant que certaines.

Pour les fichiers, il faut juste que je regarde comment ca marche.

[Clad3]

Et je pense aussi beaucoup au système évolutif, c'est pour ça que je crée des class pour chaque race, c'est pour pouvoir les distinguer facilement en cas de modifications ne touchant que certaines.

je pense que tu n'a pas comprit ce que j'ai voulu dire . Car avec ce que j'ai déécrit , tes races seront parfaitement distinguable et modifiable ; même par une personne non-initié . ( je peut te fournir l'exemple de certain fichier de ce type, et même si tu n'en a jamais vu avant , je suis sur que tu serait capable d'en créer un sur le même model ) .

Enfin , bonne chance

[Moucoulin]

Sujet très intéressant.

Pouvez vous détailler vos méthodes?

Personnellement j'aurai eu tendance à construire l'arbre des attributs de la façon suivante:

class perso générique{
// données membres communes à toutes les classes de perso.

//méthodes communes à toutes les classes de perso.

}

puis après les dériver

class persobarbarbare:public perso{
//données membres spécifiques au barbare

//méthodes spécifiques au barbare

}

Mais ça ne correspond à aucune des descriptions.



}

[Luc Hermitte]

Si Luc passe dans le coin, il te fera sûrement son petit topo sur "pourquoi il ne faut pas avoir 13 classes spécialisées pour 13 races, et quoi faire à la place"

Pour ce qui est du "quoi faire à la place", tu peux voir tes races non pas comme des spécialisation de joueur, mais comme une composition de caractéristiques. Et les caractéristiques de base genre reflexes, rapidité, vitesse, ... peuvent être inscrites dans des fichiers de configuration (XML ou autre) plutôt qu'en dur dans le programme, je pense que ce serait préférable.

Arf. A chaque fois que je retape le pavé, j'en ai pour une heure de rédaction. Je ne suis pas fichu de garder les adresses de mes pavés.
En plus, tu as parfaitement bien résumé l'idée et introduit l'autre chose que j'aurais signalée => mettre ces caractéristiques par défaut dans un fichier de configuration qui sera lu au lancement du jeu.
(Ceci dit, une recherche avancée sur PNJ ou race dans ce forum sera un pemier point d'entrée vers mes tartines).

(le pourquoi de cette autre approche => fléxibilité (je veux pouvoir me polymorpher, ou faire des possessions et autres contrôles à distances!!), et LSP (recherche avancée pour celui-là))

[Azharis]

Pour Moucoulin : C'est comme ça que je fais, j'ai une class Joueur qui possède toutes les caractéristiques est méthodes pour la création et la gestion d'un personnage, puis j'ai une class fille pour chaque race pour gérer certaines particularités de chaque race. En plus de la race, il y a la classe (classe de personnage : guerrier, barabare, archer, nécromancien, etc) qui améliore les caractéristiques de la races, j'ai alors fait une fonction amie pour chaque classe et lors de la construction, je passe en paramètre le pointeur de la bonne fonction.