Bonjour à tous,

Je suis confronté à un problème et c'est pourquoi je fais appel à votre aide.

Pour situer le contexte, j'ai réalisé un Stratego en C# / WPF dans le cadre d'un cours. Il est totalement fonctionnel mais j'aimerais l'améliorer en rajoutant la possibilité de jouer des parties en réseau local.

J'ai cherché pas mal de temps sur gamedev.net pour savoir comment m'y prendre, mais ça reste beaucoup d'idées d'implémentation, la manière de transférer les données etc. Mais ce que j'aimerais savoir c'est comment "l'architecturer" dans le reste du code pour que ça reste propre.

En gros j'ai un package "Views" avec tout mes .xaml, un package "Models" avec tout mes .cs qui concernent la logique du jeu et un package "Data" pour la base de données. Ici, je suppose qu'il est préférable de créer un nouveau package "Network" qui contiendra mes classes relatives au réseau... ?

Pour le fonctionnement en lui-même, je compte faire au plus simple et partir sur du Client-Client, vu qu'il n'y a que 2 joueurs. L'host (TcpListener) créer une partie, il attend qu'un client (TcpClient) se connecte. Le client entre manuellement l'IP du host et se connecte. Ensuite la planche de jeu est chargée en local et uniquement les (dé)/placements des pièces sont envoyés par le réseau à l'autre joueur, le reste est calculer en local.

J'ai un objet "Move" qui contient la "Piece" qui va bouger et la cellule (objet "Cell") sur laquelle il se déplace. Dois-je sérialiser l'objet "Move" et l'envoyer ? D'autres solutions ?

Je ne vois pas trop non plus quelle classe je pourrais avoir besoin pour le TcpListener, TcpClient...
Et puis, les transactions réseau doivent se faire dans un Thread séparé ?

Autant de questions que je me pose. Si vous avez un exemple concret ça m'intéresse également =)

Merci d'avance.

P.S. : c'est la première fois que je réalise cela, je n'ai aucune idée s'il existe des patterns spécifiques ou autres méthodologies, je suis ouvert à toutes informations

Pas mal de questions en effet pour un projet de programme en réseau. Tu as donc choisis de procéder à une architecture client-client. Tu peux effectivement utiliser les classes TcpListener ou TcpClient, mais il existe également les sockets qui sont des technologies très puissantes. Pour ce qui est de l'architecture en elle même, tu ne peux pas te baser sur une architecture de jeu solo que tu as déjà codé. Tu dois tout refaire (eh oui), car ça ne fonctionnera pas du tout de la même manière. Commences par prendre une feuille de papier et détaille comment tu veux que les données soient transmises, à quelle moment etc... Le plus simple est de faire un schéma avec deux carrés qui correspondent à tes clients avec l'un qui est l’hôte. Ensuite marque dans chaque carré le rôle de chacun, ce qu'il doit faire. Une fois que tu seras arrivé à quelque chose qui te semble correct, tu recoderas le jeu avec cette architecture. Si tu veux de plus amples explications sur un point spécifique n'hésite pas

Peux-tu m'expliquer plus précisément ce qui ne va pas dans ce que j'ai fait et ce qui devrait être refait ?

J'ai peut-être oublié de mentionner que j'ai développé également une IA pour le jeu, donc tout n'est pas basé dans les event "Mouse_Click" sur les cases de la grille...

Personne pour m'aider ?

Tu peux utiliser WCF en auto hébergement.

Tu peux en dire plus/mettre du code sur tes classes Move/Piece, qu'on puisse avoir une idée de à quoi elle ressemble ?
Tu utilises le pattern MVVM ?
C'est pressé ?

Citation : Gretho

Tu peux effectivement utiliser les classes TcpListener ou TcpClient, mais il existe également les sockets qui sont des technologies très puissantes

Il me semble que Tcp<bidultruc> en .NET et son homologue UDP sont des encapsulations de Socket, dédiées à la gestion TCP ou UDP...

Citation : Spaz

Tu peux utiliser WCF en auto hébergement.

+1, pour peu que le jeu n'ai pas pour objectif de devenir une structure immense pouvant héberger des centaines de joueurs en simultané. WCF te permettra de communiquer très simplement d'un point à un autre, sans te soucier :
-Des problématiques liées aux interfaces réseaux et à leur configuration
-Des problématiques liées à la sérialisation/désérialisation des données (une petite config sera à faire quand même)
-Des problématiques d'ordonnancement des données reçues (suivant la config choisie bien sur)
En plus de tout ça, vu que WCF est configurable via les fichiers de configuration d'application .NET, toutes les classes de gestion de la configuration WCF sont déjà créées => Tu pourras sauvegarder des paramètres dans les fichiers de config sans devoir refaire tout ce qui est relatif à la sauvegarde de données dans un fichier de configuration (pour, par exemple, faire un système de "serveur favoris" ou équivalent).

Merci pour les infos, je vais jeter un oeil à WCF et je vous tiens au courant =)