Discussion :

[Knightdead]

Bonjour,

L'année dernière j'ai commencé à coder une IA de poker. Avec mes faibles connaissances en informatique (j'étais en Terminale) j'ai réussi à recoder un moteur de jeu de poker, mais avant de m'attaquer à la partie IA, je voulais mettre le tout dans une interface graphique sympa avec une table, des joueurs, leur tapis à la table devant eux, et quelques onglets pour changer les paramètres de mon programme sans avoir à bouger les variables et instancier les objets à la main dans mon code.

Petit hic là, ça ma l'air assez dur sans aucunes connaissances là-dessus, j'ai donc ramé, j'ai regardé quelques tutos sur les interfaces graphiques qui commençaient généralement par des explications sur les délégués et les événements, ou alors j'en avais lu un entièrement sur le modèle DAO sur ce site (si je ne me trompe pas, le principe était de séparer le programme en plusieurs couches (métier, données, interface je crois ?) et les relier avec Spring, j'ai pas trop compris, je ne pourrais pas l'appliquer à mon programme, je ne sais même pas si l'interface graphique que je veux est faisable avec ce modèle.

Au final le projet est en stand-by car je ne sais pas trop où je vais, je ne sais pas comment je suis censé structuré mon programme. Cette année je suis en maths sup, l'info qu'on fait est assez théorique, avec des langages de haut niveau alors j'ai rien appris ni sur les interfaces graphiques ni sur le C# et je ne suis pas avancé.
Peut-être vaut-il mieux que j'utilise une librairie faite pour les interfaces graphiques, pour que je puisse travailler à plus haut niveau ? Pourtant la création d'interface graphique m'a l'air assez simplifiée sur Microsoft Visual C# Express (que j'utilise) alors peut-être que je n'avance pas seulement parce que je cherche au mauvais endroit ?

Je vais vous expliquer quel type d'interface graphique j'aimerais obtenir, j'espère que vous saurez m'orienter.

Déjà voici la liste des classes que j'utilise :
Pièce jointe 179041

Aucune classe n'hérite d'une autre.
La classe Table contient un attribut game de type Game, avec toutes les infos sur la partie en cours sur cette table, dans cette classe Game y a des joueurs (classe Seat), etc...
Concrètement je voudrais que mon programme ressemble à une fenêtre sur laquelle il y a une table, on pourrait changer le nombre de places sur cette table à l'aide d'un champ (l'interface modifierait donc l'attribut maxSeats de ma classe Table), ce qui modifierait l'affichage de la table directement. Le moteur de jeu attend la décision d'un joueur, et je voudrais pouvoir utiliser l'interface graphique pour récupérer la décision du joueur (ou d'une classe IA s'il s'agit d'une IA), du coup il faudrait que ma classe Seat (qui représente un joueur à la table) puisse demander à l'interface graphique d'afficher un certain nombre de boutons, puis d'attendre l'appui de ceux-ci, puis redonner cette saisie à la classe Seat qui retournerait son résultat au moteur de jeu qui continuerait la partie.
J'aimerais également pouvoir afficher des onglets dans ma fenêtre, qui permettent d'aller modifier des paramètres (il s'agit donc encore une fois de modifier les attributs de classes déjà instanciées à partir de mon interface graphique).


Comment j'ai procédé ?

Pour le moment j'instancie ma fenêtre dans ma classe Program
Ensuite ma table est initialisée dans la classe Program également, les joueurs également, les joueurs sont ajoutés à la table, le programme vérifie quels joueurs sont prêts à jouer, les ajoute à une classe Game, et après je démarre la partie à l'aide d'une méthode StartNewGame() dans ma classe Game, qui lance le moteur de jeu, c'est cette classe Game qui va calculer les actions possibles par chaque joueurs (Seat) quand c'est leur tour de jouer, et de leur demander de prendre une décision, et c'est là que j'aimerais faire intervenir mon interface graphique.

Le fait d'instancier ma fenêtre dans Program est-il mauvais ? Car aucunes de mes classes ne peuvent voir ma fenêtre, pourtant je ne peux pas non plus faire une fenêtre par classe, je ne peux pas non plus créer mes classes dans la classe Program, car je ne pourrais pas instancier mes objets.
J'ai l'impression que la plupart de mes problèmes viennent du fait qu'il faut que j'utilise massivement les événements alors que je ne les maîtrise pas du tout, et également du fait que la structure de mon code est à revoir car je n'ai pas l'habitude de faire du C# et de "gros" programmes. (Celui-ci doit faire plus de 1500 lignes, c'est mon premier qui en fait autant, d'ailleurs savez-vous comment afficher le nombre de lignes d'un projet, avec toutes ses classes comprises, à partir de cet IDE ?)

J'ai fait de mon mieux pour être clair alors j'espère que vous comprendrez où je bloque et saurez m'aider.

Merci d'avoir pris le temps de lire mon post !

PS: J'ai envisagé plusieurs fois de faire d'abord mon programme en console, de gérer d'abord juste la communication entre les classes avec des événements (mais même ça je ne sais pas trop comment faire de toute façon..) avant de faire l'interface graphique, j'imagine que c'est le plus judicieux, mais j'avais peur qu'il y ait trop de changements à faire pour repasser en fenêtre après, je ne sais pas trop comment condenser tout le code qui permet "l'interface homme-machine" au même endroit.

[theMonz31]

bonjour,

Si on part sur une solution à base de winForm, j'aurais tendance à avoir l'approche suivante:

Un UserControl pour représenter un joueur.

Un Usercontrol pour représenter une table...

La table ajoute des Usercontrol joueur quand le nombre de joueur change, etc...

Après, pour commencer basique, t'es user control peuvent juste être composé de controles de bases (bouton, picturebox, label)...

Il faudrait que tu arrives à définir le rendu visuel que tu veux aussi pour s'en rapprocher au bout d'un moment...

[Knightdead]

D'accord, je vais me renseigner sur les UserControl, je vais suivre ce tuto : http://morpheus.developpez.com/usercontrols/

Par contre pour faire communiquer les classes entre elles je ne vois vraiment pas comment faire ? Faut-il que je change des choses sur la visibilité/l'imbrication des classes ?

[Pol63]

si tu veux un truc joli wpf est peut etre plus adapté
wpf oblige presque à séparer le code métier (jeu dans ton cas ^^) du code l'interface, ce que ne fait pas trop windows forms
donc si tu as déjà du code qui ne gère pas d'interface tu peux partir sur wpf je pense
il y aurait juste un peu de code à rajouter dans celui ci

en windows forms on travaille beaucoup avec les events des controles
en wpf, on définit comment se dessine graphiquement une classe en gros, ou dire qu'un bouton appelle une méthode de l'instance qu'il est en train d'afficher, le tout avec du binding
binder un controle à une propriété (genre maxseats) c'est bien, mais après il faut aussi l'inverse (que la modification de listeactionpossible d'un joueur fasse apparaitre les boutons par exemple)
pour ca il faut que le code de base gère le fait d'avertir l'interface, pour ca le plus simple est d'implémenter INotifyPropertyChanged dans tes classes, et lever l'event qui va avec dans chaque propriété
ce qui fait que sur le control joueur tu afficheras l'équivalent d'un itemscontrols (listbox sans sélection) qui aura un bouton par action possible, si aucune action possible rien ne sera affiché
quand listeactionpossible changera sur une instance de joueur l'interface sera mise à jour automatiquement sans taper de code (grace à INotify... que wpf gère)

et il faudra des classes intermédiaires (ne serait ce que pour gérer le positionnement des joueurs)

néanmoins ca serait quand même plus simple à coder en windows forms, mais wpf ressemble plus à l'avenir (vs >= 2012 pour faire du wpf, c'est mieux)
pour wpf se renseigner sur les 4 types de panels existants, le binding (et les converters), datacontext qui est pratique dans la plupart des cas, les datatemplate, et le MVVM

[Knightdead]

Wow, merci beaucoup pour cette réponse très précise.
Cependant pourquoi utiliser wpf si c'est plus dur ? Pour prendre de bonnes habitudes de programmation de GUI ? C'est vrai que cette fonction de binding a l'air incroyablement puissante, je comprends déjà comment ça marche.
Si jamais je décide d'utiliser windows forms, quelles sont les classes/interfaces dont je pourrais avoir besoin spécifiquement ?

[Pol63]

pourquoi faire du c# alors que quick basic de 1980 (environ) est plus simple ?

windows forms c'est une techno d'affichage qui date de windows 95, légèrement amélioré avec gdi+ peu après (98 ?)
chaque control a un handle de form de windows, chaque controle se redessine tout le temps (enfin juste trop souvent à mon gout ^^)
la transparence existe mais c'est un bricolage, donc dans certains cas ça ne fonctionne pas et on comprend le bricolage derrière
tout est rectangle
etc...

wpf ca date de 2008, ca commence à être utilisable sans trop galérer depuis vs 2012 (même si je trouve que ca manque de certaines choses)
c'est une techologie d'affichage entièrement vectorielle, qui gère aussi un peu de 3d si nécessaire
tout a la forme qu'on veut (un bouton triangle ou d'une forme très complexe est faisable)
la transparence est bien gérée
l'affichage se fait via directX donc utilise certaines capacités de la carte graphique (winforms processeur seulement)
et on a un langage descriptif d'interface et de lien avec les données (xaml) qui est plutot lisible (basé sur l'xml)
on début on pose encore les controles sur les windows comme on en a l'habitude avec winform ou autre, puis rapidement on écrit ce qu'on veut, c'est beaucoup rapide dans la précision (car le placement des controles est vraiment agréable à utiliser)
et autre avantage moins visible, wpf utilise beaucoup moins de classes non managées (control, graphics, bitmap pour windows forms) donc y a moins de chose à penser à disposer (IDisposable)
dernier avantage, en winforms quand ton appli est finie et que tu veux changer le design tu pleures (ou tu te pends si ton chef veut vraiment que tu le fasses ^^)
en wpf tu rajoutes quelques lignes de xaml pour préciser l'affichage par défaut (affichage, forme, couleur, comportement ...) de chaque controle dans application.xaml et c'est réglé (controltemplate, style)

c'est plus dur surtout parce que c'est plus complet et sur une approche différente
et il a aussi des inconvénients (enfin n'étant pas allé au bout je ne peux dire que telle chose est nulle car j'ai peut-être juste raté un truc)

après si tu pars sur windows forms, il n'y a pas d'interface vraiment utile, les bindings existent aussi (et dans ce nécessitent aussi INotify...) mais sont beaucoup moins puissants (pas de bouton qui appelle une ICommand)
après tout se code, si tu veux du binding aussi puissant en winform tu peux le coder toi même, c'est l'avantage de .net, c'est que tu peux te rajouter plein de choses, y compris dans l'exécution de visual studio
et donc il faudrait gérer les events de tes controles, et les events de tes classes de jeu
sur l'event combobox de selection de nombre de joueur : changer la variable nombre de joueur, appeler la méthode qui s'occupe du placement des joueurs (et donc des controles qui vont avec)
sur l'event de la classe de jeu qui dit que les actions possibles d'un joueur change, il faudrait que tu retires/caches ou réaffiche le panel de controle, sur l'event d'un bouton rappeler la méthode qui gère le bouton
...