Discussion :

[Pol63]

après adapter un jeu avec copyrights ...
c'est bien pour apprendre, mais ca ne sera pas distribuable je pense

t'as pas une idée de jeu à inventer ? ^^

[Uranne-jimmy]

Malheureusement ce n'est pas moi qu'il faut appeler pour l'originalité et tout ça ^^
Si on lui change le nom, qu'on modifie une ou deux mécanique et qu'on copie pas les cartes ça passe ?

[Kropernic]

Alors, ça en est où ? ^^

[Uranne-jimmy]

Je suis en mode tuto, si on peut dire ^^ je n'ai pas l'occasion de trop toucher aux logiciels de modélisation. J'ai tout de même ça :



Sinon du travail papier :
Je vais avoir deux types de cartes, des portes et des trésors. Donc deux pioches, et une défausse par pioche.
Le joueur va avoir une main, un plateau qui lui est propre (où il pose ses cartes actives), des cartes.
Les cartes portes un effet mais ne font rien.
Le joueur est contrôlé par l'utilisateur, il peut piocher, poser une carte devant soit ou en défausse ou sur le plateau d'un autre joueur. Décider de comment passer ses tours (invoquer ou ouvrir la porte, demander de l'aide en combat, ...)
Les pioches peuvent se mélanger, elles ont aussi une fonction pour chercher une carte particulière (effet de type "chercher dans la pioche").
La défausse montre seulement la carte sur le dessus, généralement la dernière déposée.
Le plateau porte les plateaux des joueurs, et les cartes, le dé pourrait être compris dans cette unité.
Un maitre du jeu passe les différentes étapes de jeu du joueur en lui proposant d'une manière ou d'une autre les actions, et passe d'un joueur à l'autre. Dans l'absolu j'aimerais qu'il n'empêche pas la triche mais permette aux joueurs de la signaler (ex : la personne pose un deuxième objet lourd, rien n'est signalé tant qu'un joueur l'a pas demandé). Il est aussi celui qui distribue les cartes, active les effets.
Je n'ai pas vraiment parlé des attributs des différentes classe mais j'ai également un début de ça quelque part.
Par contre je vois pas du tout comment transcrire ça, et je pense qu'il y a des trucs qui manque et des maladresses...

[Kropernic]

Une carte Trésor doit avoir une propriété Valeur.

Pour la manière dont devrait se dérouler le jeu, si je devais le programmer, je pense que je m'inspirerais de la manière dont se déroule MTGO (Magic The Gathering Online).

Ce serait donc une application client-serveur où, à la fin de chaque phase, le serveur demande aux autres joueurs s'ils font quelque chose avant d'autoriser le joueur dont c'est le tour à passer à la phase suivante et continuer son tour de jeu.

De cette manière, cela crée une fenêtre pour permettre aux autres joueurs de signaler une triche, de balancer un monstre ou de faire tout autre action possible. Avec WCF, c'est assez facile à mettre en place.

[Uranne-jimmy]

J'ai pas du tout commencer à réfléchir au côté serveur dans le sens où là par contre, j'y connais vraiment rien du tout ... Mes seuls connaissances viennent d'un serveur monté en interne dans ma boîte et les tâtonnement pour faire du LAN hamachi sur minecraft.
De même, je connais Magic que de nom, je n'ai jamais joué au jeu en ligne affilié, le seul jeu de carte en ligne qui soit un peu plus qu'un poker c'est le jeu de Battle.net (je suis nul d'ailleurs). Mais je comprends le principe, une interrogation à chaque fin ou début de phase d'un joueur. Ca me parait sympa, assez simple, le soucis c'est que j'imaginais plus d'interaction, le jeu étant lui même assez vivant, mais je vais pas être capable de faire beaucoup plus ^^'

[Kropernic]

Bin le serveur peut envoyer un question à chaque client (joueur) après chaque action qui est faite par le joueur courant mais bon... ça fait bcp de va et vient.

Pour débuter, vaut mieux commencer simple et affiner par après.

[Uranne-jimmy]

Oui c'est vrai, j'ai un peu du mal avec la règle : "d'abord ça marche, ensuite c'est efficace et seulement après c'est joli" ^^

Du coup je vais finir mes tutos d'architecture logiciel et passer aux serveurs, histoire de pas partir dans le vide.

[Uranne-jimmy]

Pour l'instant rien qui tourne mais quelques éléments en place. Si vous avez quelque chose à dire la dessus.
Pour les tableaux que j'utilise, peut être qu'un système avec clé serait plus propre (dictionnaire ? je connais pas les termes, je sais juste que ça existe). J'ai pas rempli les fonctions ni rien, mais je m'y atèle dès que j'ai un peu de temps, étant donné que je n'ai pas encore intégré la partie réseau, je veux pas avoir à défaire ce que j'ai fait.
Je n'ai aucune idée de comment définir l'objet Effet plus que ce que j'ai fait :/ Je crois que je vais devoir laisser le plus gros du code des effets dans la classe maîtresse.

salledetest.zip

[Kropernic]

En y réfléchissant pas plus de 2 secondes, pour les effets, je ferais une liste exhaustive des effets existants et créerait une classe dérivée de effet pour chaque effet particulier.

En sachant que les effets "Piocher 1 carte" et "Piocher 2 cartes" sont les mêmes effets. Juste un paramètre qui change.

Doit pas y avoir 200 effets différents à mon avis.

[Uranne-jimmy]

Oui, je voyais la chose presque comme ça. Mon problème est de comment faire communiquer le maître du jeu, qui fait l'effet, et l'effet qui se décrit.
Dans ma façon de voir les choses, l'effet est une classe à part, elle n'est lié au déroulement du jeu que quand on l'appel.
Malgré ça je ne vois pas comment faire autrement que comme ça: le maître voit que la carte activé a un effet, il observe l'effet et par un select case, active un code précis avec les arguments partagés. C'est le select case qui me dérange.
Ou alors il faut donner à la class effet les outils nécessaire pour qu'elle se débrouille seul, donc : le contrôle sur les joueurs, sur le plateau, sur les decks. Et là aussi ça me parait farfelu.

[Kropernic]

My bad !!

J'ai pas utilisé le bon terme...

Utilise plutôt des interfaces pour les effets.

Ensuite, si la carte A a besoin de l'effet "Piocher 2 cartes", la classe qui code la carte A aura juste à implémenter l'interface IPiocher2Cartes. De cette manière, une carte peut même avoir plusieurs effets.

[Uranne-jimmy]

mmh. L'outil me parait adapté, mais j'ai du mal à comprendre sa logique.
L'interface permet d'obtenir le même nom de fonction pour toute classe qui l'implémente, mais il faut définir cette fonction malgré tout c'est ça ?
Si je fais l'interface piocher :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Interface IPiocherCarte
    Sub Piocher(ByVal i As Integer)
End Interface
 
Class CarteA
    Implements IPiocherCarte
 
    Sub Sub1(ByVal i As Integer) Implements IPiocherCarte
          'code qui fait l'effet, unique à une carte
    End Sub
End Class

Une autre question vient juste de m'arriver : les cartes sont issus de maximum de classes qui sont Tresor et Door, si je fais les effets sont forme d'implémente il faudra que je change et que je fasse une classe par Carte ? Ou alors tu pensais à implémenter sur les classes filles de Effet ?
Là je vois une masse de travail grandi par rapport à un Select case dans la classe maîtresse.
Désolé j'ai jamais fonctionné avec les interface pour le moment ^^' je suis en ce moment même en train de me documenter.

[Kropernic]

Ne t'excuse pas ! Je réfléchis à la question en même temps que toi. Je trouve que c'est un excellent exercice de conception.

Est-ce qu'on ne peut pas mettre un définition par défaut dans une interface ? J'ai un truc comme ça en tête que j'aurais lu dans une news récemment. Ca permettrait de coder les effets directement dans les interfaces et que, s'il faut changer le comportement d'un effet pour une carte, on peut le recoder dans la classe de la carte qui implémente l'effet.

Mais bon, j'suis vraiment pas un pro en conception. Personnellement, je fais des applications de gestion. Du coup, la première chose que je fais à chaque fois, c'est de modéliser la DB (en normalisant le plus possible). Une fois que j'ai la DB, j'ai automatiquement (à peu de chose près) les classes de l'application.

[Uranne-jimmy]

Et mon boulot consiste en un contrôle très procédurale de Excel (et dans une moindre mesure word) en fonction des paramètres qu'on me donne donc je suis même plus dans la programmation objet ^^

J'ai regardé ton lien : en définissant une CoClass il arrive à travailler sur un interface et partant de là faire en sorte que l'interface se comporte comme une instance de sa coclass. C'est ... bizarre non ?

J'ai vu sur un site un gars qui, lui, créer une classe (Accounting) qui sert juste à porter une partie du code mais j'ai du mal à l'adapter à mon histoire.

Dans l'absolu, il me faut en effet trouver un moyen de lier des procédures à un effet, comme un interface mais qui ne détient pas uniquement les signatures des procédures utilisés. (je réfléchi en écrivant, ça sort dans l'ordre que ça veut) Il me faudrait donc, en langage imagé qu'au moment de l'activation de l'effet, le maître dise à l'effet (qui est donc un objet à part entière) "Envoie moi les instructions".
Avec mon vieux select case, la réponse ressemblerait à ça :"ouvre le dossier "truc" tout est dedans" à la manière d'une procédure pour ceux qui travail étroitement avec leur service qualité. Mais en suivant ce que j'ai pu lire, on s'éloigne du principe même de la programmation objet : ajouter un effet revient à modifier quelque chose dans la classe Maître.
Si l'effet s'active quand on l'appel : card.effect.activer() A lui seul il ne pourra pas faire grand chose, il n'a pas accès ni aux joueurs, ni aux cartes, sauf si on lui donne en argument de façon systématique la liste des joueurs, l'ensemble des cartes, ... Ca fait beaucoup, ça revient à donner le contrôle du monde au plombier pour qu'il change un robinet sans soucis, mais ça me parait la chose la plus propre qui foule mon esprit.

[Kropernic]

J'ai l'impression que, dans un premier temps, ce serait pas mal de définir le cadre dans lequel le jeu va se dérouler. C.-à-d. comment les joueurs vont communiquer entre eux.

Tu parles de maître mais la dernière fois que j'y ai joué (ouch... ça fait un paquet d'années !), il n'y avait pas de MJ.

Perso, en partant sur une archi client-server à base de WCF (car c'est facile à mettre en oeuvre, faut juste regarder pour les paramètres réseaux), je vois quelque chose du genre (je reprécise que je n'ai jamais écris autre chose qu'un chat comme appli client-server ) :

1. Le serveur :
   
   • tout passe par le serveur
   • c'est lui qui gère les talons et les défausses
   • c'est lui qui reçoit les actions de tous les joueurs et qui vérifie s'ils peuvent effectuer l'action qu'ils tentent de faire (on verra pour la triche plus tard)
   • c'est lui qui informe les joueurs (y compris le joueur en cours) de l'action que le joueur en cours effectue.
   
   
2. Le client (joueur) :
   
   • il possède un plateau (les cartes qu'il pose devant lui) : après faudra sûrement modéliser ce plateau également car faut pouvoir gérer le fait qu'il ne peut par exemple poser qu'un casque car il n'a qu'une tête.
   • il possède des cartes
   • chaque joueur possède aussi une collection de joueurs afin d'avoir les autres adversaires pour pouvoir afficher les choses correctement.

Quand un joueur (veut) joue(r) une carte, il informe en fait le serveur qui vérifie si c'est légal et, si oui, répercute l'info vers les autres joueurs.
Quand un joueur veut piocher une carte, il demande en fait un carte au serveur et le serveur lui la donne.

[Uranne-jimmy]

Ce que j'appelle maître n'est qu'une entité uniquement existante dans le logiciel, pas dans le jeu ("Une classe pour les gouverner toutes"). Il s'assure du bon fonctionnement, passe les différentes phases de jeu et les tours, lance la partie (création des pioches, mélange des cartes, distribution par joueur ...), en bref, il porte toutes les procédures qui sont en fait les mécaniques de jeu.
C'est l'équivalent visiblement de ce que tu appelles serveur et que je n'ai toujours pas pris en compte (parce qu'il me faut d'abord m'instruire, mais la je sature).
Les effets se déclenche de deux manières, en gros :
d'abord un effet flip à l'ouverture de la porte, dans le cas des malédictions (je met les combats de côté, encore une fois),
ou alors par activation par un joueur, pour lui même ou pour(ou contre) quelqu'un d'autre, là encore je met l'équipement de côté, mais ça serait en gros le même principe.
En matière de cadre j'ai ça. Et pour moi, le serveur, donc, gère l'activation de l'effet, en enlevant un niveau, en enlevant un équipement, en donnant une carte, etc.

Sur le reste : c'est ce que j'avais en tête : chaque joueur à un plateau personnel, mais le serveur en a un aussi, visible de tous (donc dans le cas d'une architecture serveur, le client possède une copie de ce plateau) avec en visible les deux decks et les deux défausses, dont la première carte est visible.

[Uranne-jimmy]

Rebonjour,
J'ai laissé le temps à mon cerveau d'imaginer solutions, vu au passage l'excellent interstellar et revue l'excelent V pour vendetta (because remember, remember ...), et je m'amène avec les conclusions que j'ai pu donner.


Pour les effets en fait :
J'ai donc une classe Effect, qui a une tripotée d'enfants : Piocher, PerdreNiveau, ... Ca me permet de donner sans problème un effet à la carte :

Code :

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

Dim c as Card  = New Card(...,..,...,New Piocher("..."))

Et chaque fils de Effect possède l'interface DoEffect afin d'avoir tous la (les ?) même méthode(s), j'ai finalement opté pour donner à la méthode qui active l'effet en argument un tableau d'objet, c'est super général mais avec ça je pourrais travailler sans me poser de question, peut être que je ferais des modifications une fois tout les effets en place, si je vois que je peux préciser un peu tout ça.

Qu'est ce que vous en pensez ?