Discussion :

[FFTiger]

Bonjour tous le monde,

Je travaille actuellement à la conception d'un jeu de carte, pour me former en C++ (j'ai deux semaines d'expérience). Dans ce jeu chaque carte possède 4 valeurs qui leurs sont associées (auxquelles viendront se compléter un nom, une image etc). J'ai créé une classe qui permet de manipuler ces cartes, seulement pour l'instant les cartes doivent être créées durant l'exécution du programme.

J'aimerais créer une collection de cartes prédéfinies qui soit aisément manipulables. J'entend par là qu'il soit possible de connaitre la liste des cartes par programmation. Là seule solution que je voyais était de créer un vector et d'instancier toutes les cartes en début de programme... Seulement, j'ai le sentiment que ce n'est pas très propre. Je pensais aussi à spécifier leurs attributs dans un fichier d'en-tête mais à ce moment là comment connaitre la liste des cartes dans mon programme ?

Pour information, je parle d'une collection de quelques centaines de cartes qui comme je le disais auront une image associée quand je passerai à la partie graphique du jeu.

Sinon, voici les sources : http://koyo-k.svn.sourceforge.net/vi...o-k/trunk/src/

Merci d'avance.

[Alp]

Tu ne peux pas stocker les informations des cartes dans des fichiers ?
Tu définis un format, de sorte que tu saches comment lire le fichier pour récupérer chacune des 4 informations concernant une carte.

Pour les entrées/sorties concernant les fichiers, regarde donc ceci : http://cpp.developpez.com/faq/cpp/?page=fichiers

[FFTiger]

Certes, mais ce qui m'ennuie c'est que ces fichiers seront éditables avec un simple bloc-notes... Je veux dire si il est trop aisé de modifier les attributs des cartes ça pose un problème... De plus si je stocke ces informations en créant mon propre format de fichier, ne vais-je pas réinventer la roue ? J'ai peur de me confronter à des problèmes de performance, car en quelque sorte, je devrai manipuler ces fichiers un peu comme une base de donnée. Sachant qu'à terme je compte introduire des fonctionnalités de jeu online, d'où la nescessité de stocker des informations sur les joueurs également. Ne serait-il pas préférable que je stocke tout ça dans une BDD (mySQL coté serveur), mais coté client je met quoi ? Étant donné qu'il devra y avoir un double pour les fonctionnalités offline ?

[Alp]

Le client doit avoir ces informations avec lui. Etant donné que ce sont des informations fixes, tu peux crypter le fichier, et au lancement du jeu du décryptes et enregistre tout. Ou alors, tu codes en dur. Tu peux par exemple créer une structure/classe qui représente une carte, et instancier les N cartes en dur.

[FFTiger]

Tu peux par exemple créer une structure/classe qui représente une carte, et instancier les N cartes en dur.

Oui c'était ma première idée... qui ne me semblait pas très propre (voir mon premier post). Mais si c'est la solution alors... Bref je vais continuer mon prog, étant donné que ce point n'est pas le plus urgent, histoire de me perfectionner un peu en C++ et je reviendrai sur ce point.

Sinon, quand je parlais de stocker les informations coté serveur c'est simplement pour des questions de triche. En faisant en sorte que le client ne puisse envoyer que des commandes au serveur du genre pose telle carte ici, et en afficher le résultat sans communiquer lui même au serveur la valeur des cartes ou de ses caractéristiques, je pense rendre impossible toute tricherie. Mais effectivement le client doit forcément posséder ces informations en double.

Merci pour tes réponses en tout cas ;-)

[Luc Hermitte]

Pour un truc pareil, je trouve les fichiers abusés (à moins qu'il s'agisse d'un jeu où le nombre de cartes peut sans cesse évoluer (cf Magic:tG et ses rejetons)).
Et tout lister en dur maladroit.

Peut-être un vecteur que tu remplis avec une double boucle ? Une sur les couleurs, et une sur les valeurs. Et pour le tarot, une 3e boucle indépendante.

[FFTiger]

Oui je vois ce que tu veux dire (enfin je crois), sauf qu'il ne s'agit pas de ce genre de cartes ^^. Donc ta solution ne convient pas. En fait, même si ce n'est pas tout à fait cela disons que ca s'apparente plus à des cartes de type RPG. Il n'y a pas de continuité dans les valeurs. Chaque carte est très spécifiques exemple :

Carte 1 : 4 - 5 - 7 - 1
Carte 2 : 1 - 9 - 5 - 4
etc

Donc je ne peux pas ajouter ça dans un vecteur en faisant des boucles. Ou du moins je ne vois pas comment. Donc si je dois tout mettre dans un vecteur, il faut que je face les push_back un par un... Enfin je sais pas, c'est tout ce que je vois. Mais une liste de X00 push_back...

PS : Par contre le nombre de carte n'évolue jamais... Seulement un joueur ne possède que certaines cartes du jeu en début de partie, il les acquiert au fur et à mesure. C'est pour ça que tout charger en mémoire est peut être un peu superflu... Il ne reste donc que les fichiers ? ^^

[Alp]

Pour un truc pareil, je trouve les fichiers abusés (à moins qu'il s'agisse d'un jeu où le nombre de cartes peut sans cesse évoluer (cf Magic:tG et ses rejetons)).
Et tout lister en dur maladroit.

Peut-être un vecteur que tu remplis avec une double boucle ? Une sur les couleurs, et une sur les valeurs. Et pour le tarot, une 3e boucle indépendante.

Comme il l'a dit, ce ne sont pas les cartes classiques. Il faut donc une solution générique pour un jeu de cartes où le nombre de cartes est fixe.

[Luc Hermitte]

Un clone à Magic:tG donc.
Oui, un fichier me parait mieux. Tu auras besoin d'ajuster tes cartes, d'en rajouter sans avoir à tout recompiler.

[Alp]

La solution du fichier permettent de ne pas recompiler lors :
- d'ajouts de cartes dans le fichier
- de modifications

C'est bien ce que j'avais cru comprendre dans mon premier post. C'est un problème qui est d'ailleurs assez récurrent (le choix BDD/fichier/en dur dans le code) et pour lequel tu risques de trouver pas mal de discussions ici.

[FFTiger]

Bon je vais faire ça alors ^^, vous m'avez convaincu. Sinon il ne s'agit pas d'un clone à Magic:machin :p, mais d'un clone du Triple Triad : http://www.wikisquare.com/ff8/triple_triad

Merci pour vos réponses

[Luc Hermitte]

(J'avais zappé des messages...)
Tu peux toujours rajouter des checksums sur chaque fichier.
Ainsi quand plusieurs joueurs doivent jouer ensemble, chaque client vérifie que son checksum correspond à celui des autres joueurs.

Simple et suffisament efficace, et s'il veulent se mettre d'accord sur de nouvelles valeurs pour les cartes, ils s'arrangent entre eux.
Après si tu as un serveur, autant que son rôle comprennent aussi l'arbitrage, et qu'il soit celui à résoudre tous les combats.

EDIT: ce sont tous des clones de magic.

[koala01]

Salut,

La première chose à faire, quand on veut réellement programmer en C++, c'est de prendre l'habitude de penser "objets" et non "données".

Ainsi; avant même de t'intéresser à la signification des valeurs représentées par tes cartes, ou aux valeurs qu'elles doivent contenir, il faut que tu commence par réfléchir... au services qu'une carte peut rendre: aux différents messages qu'elle peut émettre ou auxquels elle doit pouvoir répondre.

Une fois que tu auras la "certitude" d'avoir trouvé tous les messages qui peuvent arriver ou partir d'une carte, tu pourras commencer à penser au fait qu'il te faut une "collection" de cartes, et il te faudra trouver les messages nécessaires pour faire fonctionner cette collection (ce qui risque d'ailleurs peut-être de rajouter des messages émis ou reçus par ta carte)

Puis, viendra le temps de passer aux autres objets que tu va rencontrer dans ton jeu:

• Le joueur,
• La partie,
• le "serveur" éventuel,
• tous les autres auxquels je ne pense peut être pas

Mais en te concentrant en priorité absolue sur les différentes relations qui existent entre les objets et les messages que chacun de ces objets est susceptible d'émettre ou de recevoir, ce qui peut à chaque fois impliquer l'ajout de l'un ou l'autre message dans l'un ou l'autre objet.

Pour cela, il n'y a rien de mieux qu'un papier et un crayon (et, si tu as déjà approché, une méthode d'analyse et de conception comme le Merise ou comme l'UML)

Ce n'est qu'une fois que tu auras une idée claire des différents objets, des relations qui les unissent et des messages qu'ils émettent/reçoivent que tu pourras envisager de réfléchir aux données qui vont leur permettre de réagir correctement à la réception ou avant l'envoi d'un message.

Et ce ne sera qu'à partir de là que tu pourras envisager une méthode cohérente pour en assurer la persistance, tant sur le disque dur que sur le serveur

Les avantages de cette méthode qui, j'en convient, te force presque à penser de manière diamétralement opposée à la manière "classique" qui voudrait que

je doit faire tenir telle et telle information dans mon objet, quels sont les messages qui me sont nécessaires

c'est que tu vas déjà éliminer une série de messages "parasites" (comprend: qui n'apportent strictement rien: Pourquoi créer une méthode getQuelqueChose ou une méthode setQuelqueChose, si le QuelqueChose en question n'a qu'une utilité que strictement interne à la classe ?) , qu'elle te permet, sur base des messages que tu as clairement reconnus utiles et/ou importants, de "disqualifier" une série de valeurs qui auraient pu prétendre au titre de membre potentiel et donc d'arriver en définitive à une classe "aussi dépouillée que possible", mais qui fait exactement ce que tu attend d'elle.

Le dernier conseil que l'on néglige trop souvent: Délègue les responsabilités. Si une classe a deux responsabilités distinctes, c'est sans doute qu'elle en a une en trop