Bonjour / Bonsoir à tous

Je me présente, je suis Benevolar un étudiant d'une vingtaine d'année en informatique et à l'heure actuel les études c'est pas la joie
Pour tout vous dire, j'ai beaucoup de cours théorique et pas assez de pratique. (2h45 par semaine sur  ordinateur, je ne sais pas pour vous mais je trouve que c'est trop peu) Alors pour pallier à ce manque, j'ai décidé de me lancer dans un projet de programmation. C'est pour moi un passe temps mais aussi une occasion de mettre en pratique ce que j'ai appris en plusieurs années d'études.

Genèse

Pourquoi une idée aussi peu originale ?

Tout d’abord, je sais pour avoir essayé que créer une idée originale de A à Z, d'avoir une réelle vision d'un jeu qui nous donne envie de franchir le pas et commencer à coder c'est pas simple. Beaucoup d'idée paraissent bonnes lorsqu'on les a mais développer son idée pour permettre d'établir un cahier des charges fixe est vite compliqué. C'est la raison pour laquelle j'ai choisi de tenter de reproduire un concept existant dont le cahier des charges est déjà fait. Cela me permet réduire la taille d'une étape lors de la création de jeu et pas des moindres.

Pourquoi un jeu de carte et pas autre chose ?

J'ai voulu choisir un projet qui repose sur la technique (code) plus que sur l'artistique (design). L'idée d'un jeu de stratégie au tour par tour s'est imposée d'elle même.

Pourquoi un jeu de carte au tour par tour et pas un tower defense (par exemple) ?

L'idée m'a traversé l'esprit mais je me suis vite rendu compte d'un chose : j'ai déjà réalisé un tower défense par le passé
Il me fallait un projet que je n'avais encore jamais fait, un projet qui me motive. Pour me motiver un projet doit remplir certains critères :
- le projet ne doit pas être trop court sous peine d'avoir un intérêt inexistant (adieu pong, tetris, flappy bird)
- le projet doit nécessiter un certain degré de difficulté mais pas trop (on oubli les mmo3d & cie)
- le projet doit tourner autour d'un sujet que je maîtrise (désolé mais hearstone c'est pas mon truc)
- le projet doit attirer ma curiosité lorsque je me pose la question "comment ils ont codé ça ?" (inventaire, craft, plateforme => poubelle)

Mais un jeu Yu Gi Oh c'est trop difficile, voir impossible à réaliser seul non ?

Peut être... Tu as déjà essayé ? Non ? Moi non plus ! Même si je me plante c'est pas grave, ça aura été une bonne idée d'essayer. De plus si ce projet n'était qu'un passe temps je ne me permettrait pas de créer ce post ici. J'ai aussi un autre objectif en tête : celui de partager avec ceux qui me lisent mon expérience, mes réussites ou mes échecs au sein de ce projet. Je serais donc amené à poster régulièrement non pas des images du jeu mais des schémas de conceptions, des bouts de code sur lesquels discuter de ce qui est bien / pas bien dans le projet. Ce sera pour vous (je l'espère) un projet intéressant à suivre et pour moi une source de motivation et de retour.

Généralité et avancement

Le projet est commencé. Je dispose des ressources graphiques de mes précédents essaies. Pour le moment je créé des classes en C# avec Visual Studio. J'ignore si je dois découler obligatoirement de MonoBehaviour ou non. (je débute avec unity) Il est fort probable qu'une étape de refactoring s'impose d'ici peu car je me sens un peu perdu dans mon propre code qui est redondant par endroit et non homogène dans sa façon de résoudre un problème (j'ai 2 classes quasi identiques dont le fonctionnement de l'algo principal diffère, il va falloir choisir la meilleure implémentation parmi les 2 solutions et faire pareil partout ou bien trouver une 3ème implémentation) PS : je dispose d'un livre sur les design pattern qui me sera surement utile (une fois lu dans son intégralité).

Objectifs

Le premier objectif que je me fixe c'est de ne pas lâcher l'affaire tant que j'y prends du plaisir (et donc d'arrêter dans le cas contraire).
Le second c'est d'aller plus loin que la dernière fois. J'avais déjà créé un projet identique il y a un longtemps en java et non en C# et j'avais fini par lâcher l'affaire pour diverses raisons mais toujours dans l'idée de revenir plus tard à la charge avec de meilleures connaissances et une plus grande expérience me permettant de faire face à la complexité d'un tel projet. Le troisième objectif dépend de vous et non de moi : je souhaite avoir des retours, c'est la raison principale qui me pousse à partager mon projet avec vous alors n'hésitez pas à donner votre avis.
La réussite du projet n'est pas un objectif en soit cependant j'ai tout de même un objectif final en tête (en imaginant que j’arrive à surmonter chaque problème, j'ai un objectif final me permettant de me dire "le projet est terminé") Cet objectif c'est tout simplement de faire une partie contre l'IA et de perdre en ayant fait le maximum pour gagner, car ce ne sera pas un jeu en ligne (désolé mais le réseau c'est pas mon truc) mais une sorte de simulation de duel où l'on peut créer son deck et jouer contre une IA (avec un deck pré-établi)
Je sais que la création d'une IA sera sans doute encore un mur à franchir mais si jamais j'arrive jusqu'à cette étape j'ai quelques idées à tester.

Le projet et son originalité

Ce projet est là pour attirer les apprentis codeurs ou les simples curieux (comme moi) plus que pour attirer de potentiels joueurs. Si jamais un projet similaire non abandonné voit le jour, n'hésitez pas à m'en faire part. J'ai cherché sur internet pour m'inspirer et je n'ai trouvé que des projets abandonnés ou des projets réussis mais avec sans ressource accessible. Ce projet est une sorte de "tuto en direct de ce qu'il ne faut pas faire", cependant c'est ce qui le rend intéressant.

Voilà voilà , je vous remercie de m'avoir lu jusqu'au bout

ps : je viens de me relire et je me rend compte que je n'ai pas expliqué les règles du jeu de carte. J'ignore si c'est réellement utile, n'hésitez pas à me le faire savoir

-
Edité par Benevolar 15 juin 2017 à 0:29:59

Petite étape de remise en forme du code avec l'apparition de la classe "exemplaire" permettant d'encapsuler une ICarte afin d'y ajouter une quantité. La création du deck se voit donc séparé en plusieurs fichiers avec une meilleure lisibilité / maintenabilité

L'interface ICarte est très importante. Elle contient les getter principaux d'un élément Carte (et ses classes filles). Plus tard, trier et filtrer les cartes selon leurs attributs sera très utile pour créer un deck. La création d'un deck consistera à déplacer des cartes d'une banque de carte vers le deck du joueur (deck ou extra deck). La banque sera constitué de Carte et le deck d'Exemplaire d'où l’intérêt de la classe ICarte sur laquelle va reposer les méthodes de tri et de filtre. Une seule implémentation de tri pour les ICarte permettra de trier à la fois le deck, la banque de carte et tout autre nouvelle classe implémentant l'interface ICarte.

Vous pouvez aussi voir qu'il y a des méthodes GetAtk, GetDef, etc dans la classe abstraite MagiePiege. Pour le moment je n'ai pas trouvé mieux que de créer des valeurs par défaut pour les getters afin de faciliter les tris sans quoi il aurait fallu trier en plusieurs étapes (tester le type de carte, cast le cas échéant, utiliser le getter adéquat, faire la même chose sur la 2ème carte, comparer les deux résultats)

D'ordinaire on commence par créer un schéma et lorsqu'il parait acceptable on commence à coder. J'ai fait l'inverse donc j'ai du code à ne plus savoir quoi en faire avec plusieurs design pattern (pour tester), une fois qu'un test d'implémentation semble correcte je l'ajoute au schéma. Si jamais vous voyez une atrocité dans mes schémas ou que vous avez une remarque quelconque, n'hésitez pas à donner votre avis.

PS : le schéma a été réalisé avec Dia. J'aurais aimé trouver "ajouter une énumération" mais je n'ai pas encore trouvé comment on fait (et si c'est possible ou non d'ailleurs).

-
Edité par Benevolar 27 juin 2017 à 16:54:53

Salut

Fait attention; si tu compte publier ton jeux en téléchargement (gratuit ou payant) de ne pas te retrouver avec une amende pour utilisation non autorisé de l'identité visuel du jeu officiel xD

-
Edité par Golden Panda 15 juin 2017 à 14:56:29

Je ne compte pas diffuser le résultat sous forme d'exécutable mais faire un tuto récapitulatif si jamais ça marche.

J'en profite au passage pour poster une mise à jour du schéma. ImageCarte est créé à partir du nom du fichier image et d'une référence vers une ICarte. Il possède un attribut Texture2D qui est chargé en mémoire uniquement si nécessaire.

J'ai réussi à modéliser les enumerations. Comme précédemment la plupart des enumerations comportent une valeur par défaut "NON" qui est renvoyé lorsque la classe ne correspond pas (une carte MagiePiege retourne NON lorsqu'on utilise GetAttribut par exemple). Seul TYPE_CARTE n'a pas de valeur par défaut car chaque carte est d'au moins un type.

J'ai trié les TYPE_1 par ordre alphabétique, ça n'a pas d'importance en revanche pour LIMITATION l'ordre dans lequel on déclare les éléments est important pour que chaque limite soit directement associée au nombre maximum de carte par deck via son indice de tableau (INTERDIT en case 0, LIMITE en case 1, ...) j'ai ajouté un type entier pour mieux voir. COULEUR correspond aux différents cadres de carte utilisés lors de l'affichage.

Je n'ai pas encore modélisé TYPE_2 car j'ai un léger doute sur le fait de créer ou non un TYPE_3. Le TYPE_2 actuel comporte FUSION, EFFET, NORMAL, RITUEL, UNION, TOON, SPIRIT, GEMEAU et NON. Deux raisons me font douter quant à cette implémentation de TYPE_2. La première est l’existence de monstre qui sont à la fois FUSION mais aussi EFFET. Il est possible que EFFET sorte de la liste au profit d'un boolean (par exemple). La seconde raison qui me pousse à imaginer un TYPE_3 c'est le fait que la totalité des types UNION, TOON, SPIRIT et GEMEAU sont obligatoirement de type EFFET. On aurait donc TYPE_2 (FUSION, RITUEL, NORMAL, NON) et TYPE_3 (UNION, TOON, SPIRIT, GEMEAU, NON) avec un boolean pour tester si le monstre est un monstre à effet ou non.

Un autre point sur lequel j'hésite encore est la position de l'effet de la carte. J'ai déjà modélisé des effets de carte (voir code expérimental ci dessous). Le problème c'est que je me retrouve avec une List<Effet> dans Carte. Hors, Carte a pour unique rôle d'offrir des informations sur la carte permettant de l'afficher à l'écran. Un effet n'est pas "affichable". J'ai pensé à placer les effets dans les CarteDuel; classe non visible à l'heure actuelle et représentant une carte lors d'un duel avec de nouveau attributs comme la FACE (RECTO, VERSO), le MODE (ATK, DEF) ou encore la ZONE (DECK, MAIN, CIMETIERE, ...); cependant je dois garder un lien entre la Carte et son Effet. J'ignore si je dois laisser la List<Effet> dans Carte ou la déplacer ailleurs et éventuellement créer une nouvelle classe CarteEffet à placer entre Exemplaire et Carte (gros doute là dessus) ou bien encore trouver une autre solution. Généralement une bonne solution parait lisible/propre/simple. Hors pour le moment aucune des solutions qui ne me viennent à l'esprit peuvent être qualifié de lisible/propre/simple. À voir.

Carte pot_de_cupidite = new Magie()
{
	nom = "pot de cupidite",
	description = "piochez 2 cartes de votre deck",
	limitation = LIMITATION.LIMITE,
	type = TYPE_MAGIE.NORMAL,
	effet = new List<Effet>
	{
		new Effet(new MainPhase() + new MonTour(),new ActionPiocher(Constantes.CONTROLLEUR, 2))
	}
};

Carte cyber_dragon = new Monstre()
{
	nom = "cyber dragon",
	description = "S’il y a un monstre sur le terrain " +
	"de votre adversaire et qu’il n’y a pas de monstre " +
	"sur votre Terrain, vous pouvez faire l’Invocation " +
	"Spéciale de cette carte depuis votre main.",
	limitation = LIMITATION.NON_LIMITE,
	atk = 2100,
	def = 1600,
	attribut = ATTRIBUT.LUMIERE,
	niveau = 5,
	type_1 = TYPE_1.MACHINE,
	type_2 = TYPE_2.EFFET,
	effet = new List<Effet>
	{
		new Effet(new MainPhase() + new MonTour(), new ActionInvocation())
	}
};

-
Edité par Benevolar 27 juin 2017 à 16:54:28

Salut

Nouveau message, nouveau diagramme. Depuis la dernière fois le diagramme a doublé de volume ! Et pour cause : j'ai trouvé une astuce qui m'a permis d'imaginer une implémentation plutôt efficace.

Cette astuce la voici : le TAG duel. Pour ceux qui ne le savent pas, un duel classique correspond à une partie en un contre un. Un TAG duel est une partie en deux contre deux. C'est bête dit comme ça et pourtant en partant du principe qu'un TAG duel pourrait être une amélioration à envisager dans le programme j'ai pu construire une architecture plutôt attrayante en tenant compte du TAG duel. L’existence du TAG duel m'a permis d'imaginer une multitude de petit objets aillant chacun une utilité simple qui lui est propre. C'est exactement ce qu'on attend d'un programme orienté objet : plein de petits objets, on évite un maximum d'avoir un gros objet qui fait tout.

J'ai ajouté le TYPE_2 et le "TYPE_EFFET_MONSTRE" comme énoncé précédemment. Le "NON" correspond uniquement à une carte non-Monstre. Le "CLASSIQUE" est une valeur par défaut pour un monstre qui ne rentre pas dans les autres catégories, rien à voir avec le fait d'être un monstre à effet ou sans effet, ça sera géré plus tard lorsque les effets seront ajoutés.

Bref, passons au gros morceau : le système de duel. L'idée est la suivante : lors d'un TAG duel c'est deux équipes qui s'affrontent. Un duel classique est donc une forme dégénéré d'un tag duel. C'est comme ça que j'ai pu créer l'objet Equipe qui représente une List<IJoueurDuel>. Je reviendrais plus tard sur le IJoueurDuel.

Chaque équipe a un terrain qui lui est propre c'est-à-dire que chaque joueur utilise un seul et même terrain. Le terrain comporte des zones distinctives identifiées par l'énumération ZONE. Il y a donc deux classes ZONE (énumération) et Zone (List<ICarteDuel>, là encore je reviendrais plus tard sur les ICarteDuel) à ne pas confondre, je changerais peut être les noms si jamais ça pose problème. Le TerrainPartage est décomposé en trois zones : le terrain, le cimetière et la zone de hors jeu. La zone de terrain est elle même découpée en 3 zones : la ZoneMonstre, la ZoneMagiePiege et la carte magie de terrain. Cette découpe permettra de cibler plus facilement une zone lors de l'utilisation d'un effet. 

Chaque Zone est une List<ICarteDuel>, j'ai créé cette nouvelle interface ICarteDuel pour étendre les attributs classiques d'une carte (atk, def, ...) aux éléments spécifique au duel (face recto, face verso, ...). ICarteDuel hérite de ICarte, on pourra donc trier et filtrer les ICarteDuel aussi facilement que les ICarte.

Il y a trois éléments spécifiques de ICarteDuel qu'il faut expliquer. Le premier c'est l'unique_id. Les ICarte possèdent déjà un id par carte, deux cartes identiques en tout point ont un id identique. L'unique_id est unique il sert à distinguer deux exemplaires d'une même carte. Les deux suivant vont de pair : le possesseur et le contrôleur. Le possesseur est le possesseur (joueur) de la carte. Le contrôleur représente l'équipe qui contrôle la carte. Je m'explique : certaines cartes ont un effet permettant de prendre le contrôle d'une carte adverse. Il faut donc avoir un "contrôleur" à modifier. Cependant, la plupart de ce genre de carte permettent aussi de rendre le contrôle de la carte à son propriétaire après résolution de l'effet. C'est là qu'intervient le possesseur : celui ci n'est jamais modifié, il permet simplement de retrouver le propriétaire d'origine.

Le IJoueurDuel représente un joueur avec sa main, son deck et extra deck. Ce sont les trois éléments non-partagés entre les différents joueurs d'une même équipe lors d'un TAG duel. Si toute cette découpe fonctionne c'est avant tout grâce au Duel qui est devenu un singleton. Le Duel est donc accessible partout et tout le temps, une chaîne de responsabilité (design pattern) permet alors de retrouver tout les éléments recherchés.

Étant donné que le schéma a doublé de volume, ouvrez la en grand format dans un nouvel onglet sinon vous n'allez rien voir

-
Edité par Benevolar 27 juin 2017 à 16:53:52

Salut à tous, ça fait déjà une petite semaine

Depuis la dernière fois le diagramme a été énormément modifié. J'ai aussi dû retirer des "améliorations" après avoir suivi un tuto sur les bonnes pratiques en python ("import this" pour ceux qui veulent se renseigner). J'ai donc retiré la fonction Piocher de ZoneDeck car ce n'est pas utile pour le moment. J'ai déplacé la carte_magie_terrain de ZoneTerrain à ZoneMagiePiege ce qui est plus logique. J'ai retiré des getters inutiles ainsi que l'élément ZONE de Zone, je ne penses pas avoir besoin d'expliquer une chose aussi évidente. Ensuite j'ai commencé à créer un début de classes permettant de gérer des conditions (Test) à effectuer pour savoir si un effet peut être activé. Les Actions déclenchés par les effets lorsque les Conditions sont remplis ne sont pas encore implémenté. Au fur et à mesure le diagramme devenait illisible alors j'ai pris la liberté de déplacer les classes afin de gagner en lisibilité. J'ai regroupé 3 classes statiques (en haut à gauche) qui sont Getter, TrierPar et FiltrerPar. Les énumérations ont été regroupées juste en dessous afin de ne pas les voir empiéter sur la hiérarchie des classes. Ce qui a été fait la dernière fois concernant le Duel a été déplacé en haut à droite.

Passons maintenant aux nouveautés : les tests.

Pour le moment je me contente de tests simples à effectuer sur une seul élément à paramètre fixe c'est-à-dire je peux tester si une carte est de type montre, magie, piège, je peux aussi savoir si sa valeur d'atk est comprise entre deux bornes en revanche il m'est impossible pour le moment de faire un test impliquant une comparaison avec un élément modifiable dynamiquement comme par exemple tester si une carte a la valeur d'atk la plus élevé dans un groupe. Ce sera le cas plus tard mais pour le moment non. Ces tests se veulent le plus abstrait possible pour être réutiliser plus tard. Ils ne sont pas sensé être manipulable autrement que par la classe FiltrerPar qui va se charger de créer des instances de test. Le système de tri et de filtre est au centre du fonctionnement du jeu, il est fort possible que ces éléments soient modifiés et améliorés dans un futur proche. 

Expliquer le fonctionnement en lui même va être très compliqué, je préfère donc montrer un bout de code simple.

ListICarteDuel cartes = new ListICarteDuel();

cartes.Add(a);
cartes.Add(b);
cartes.Add(c);
cartes.Add(d);

cartes.Trier( TrierPar.Atk() );

ListICarteDuel magies = cartes.Filtrer( FiltrerPar.TypeCarte(TYPE_CARTE.MAGIE) );

int nb_monstre_fusion_niveau_5_et_plus = 
    carte.Compter( 
        FiltrerPar.Type_2(TYPE_2.FUSION) + 
        FiltrerPar.Niveau(5, TYPE_BORNE.SUPERIEUR) 
    );

-
Edité par Benevolar 27 juin 2017 à 16:53:29

Bon Yu Gi Oh c'est pas mon truc, mais voir l'avancée de ton projet c'est plutôt sympa 

Voilà c'était juste pour t'encourager à continuer ! 

Bonjour,

Je ne comprend pas, tu fais ton diagramme en fonction de ton code ? Normalement le diagramme est là pour t'aider dans l'analyse du projet. Une fois le digramme fait, le code coule tout seul. Faut juste passer quelques heures à réfléchir dessus.

Or là, tu fais ton diagramme en même temps que ton code ? Alors peut-être que c'est ton moyen de communiquer l'architecture des objets de ton jeu aussi.

Ca parait bizarre quand même !

L'idée est bonne sinon, et j'aimerai que ce soit un succès plutôt qu'un échec, pour toi comme pour nous

Bon courage dans ton projet,

Julien

Merci

Pour ce qui est de ma façon de travailler (qui n'est pas un exemple à suivre) je vais l'expliquer simplement : je n'ai jamais fait de C# avant et certaines choses possibles dans d'autres langage ne sont pas forcément possible en C# d'où le fait de coder et créer le diagramme en même temps afin de tester si la solution donné par le diagramme est implémentable ou si le diagramme doit être modifié. Par exemple la classe Getter en C# : 

public static int Atk(ICarte carte) {
    return carte.GetAtk();
}

En java, la classe Getter n'existe pas car on peut tout simplement utiliser :

ICarte::GetAtk();

J'utilise le code actuel pour faire des tests principalement. Je modifie le diagramme lorsque ça me semble pertinent ou bien lorsque j'ai besoin de schématiser ce que je code pour savoir si je vais droit dans le mur ou non. D'ailleurs les modifications que j'ai apporté au dernier diagramme ont été supprimées car j'ai trouvé plus simple Je laisse comme c'est car je trouve plus intéressant de voir cette étape de refactoring et l'expliquer plutôt que de balancer le résultat final.

Regarde du côté des Propriétés pour ton exemple. 

C# est très performant, et il fait énormément de choses, attention, si tu n'en a jamais fait, ne dit pas encore cette phrase : 

"certaines choses possibles dans d'autres langage ne sont pas forcément possible en C#"

J'en connais quelques uns qui te taperai sur les doigts sur ce forum haha

Bref, on est pas là pour ça. Je te souhaite une bonne continuation, merci pour ton explication qui est justifiée. 

C'est plutôt une étude de faisabilité en soit ? (A l'étape actuelle du projet hein)

Bonne journée,

Julien

jule04, quand on ne connaît pas très bien un langage, ou même le développement et l'UML tout simplement, ce n'est vraiment pas facile, voir impossible, d'avoir une bonne vision du projet et du code pur pouvoir faire des diagrammes qui ne changeront quasi pas durant tout le projet. Benevolar est en train de se former sur ce langage, et il tient ces diagrammes à jour, ce qui est déjà une très bonne chose ! Même si effectivement les diagrammes sont un peu dynamiques, c'est déjà ça 

Ma remarque n'est bien sûr qu'une remarque à ne pas mal prendre, n'oublions pas qu'on est tous passés par là 

Ah mais complétement, je dis ça pour qu'il prenne conscience que théoriquement  (j'ai mit tout ce que je pouvais) un diagramme ne dois pas bouger.

Dans la pratique, c'est totalement différent, c'est vrai. Après, l'UML est purement théorique et ne dépend pas du langage à mon sens. Un diagramme UML x pourra être développé en Y ou en Z. Après, 3h par semaine de pratique, c'est pas énorme mais tu verras que tu en seras que soulagé quand tu passeras à la pratique !

Je le redis donc, très bon projet pour pratiquer, bonne continuation à Benevolar. Et quand même, fait un peu d'étude. Réfléchi bien à comment composer une carte, les règles etc. Tes diagrammes seront moins dynamiques par rapport à aujourd'hui, mais au moins tu auras un fil conducteur qui t'aideras pour développer.

Bonne chance, et bon courage,

Julien

PS : essaye de faire une image cliquable pour les diagrammes, on les voit très mal (voire pas du tout).

-
Edité par jule04 27 juin 2017 à 15:12:09

Pas de problème jule04  

Bon je continue à suivre ton projet