Bonjour,
Pour la toute première fois, je m'initie aux joies de la programmation réseau sur un petit projet personnel : une esquisse de jeu de stratégie/exploration au tour par tour. Pas de grosses contraintes sur les performances réseau donc, mais j'aimerais quand même faire les choses bien.
Voici le modèle que j'ai en tête pour le moment :
Légende : Les boites claires en petit pointillés représentent les différents processus qui sont mis en réseau (serveur, client, etc.), qui peuvent être sur une même machine ou non (par exemple un joueur peut lancer le serveur sur sa machine et jouer en même temps).
Les boites situées à l'intérieur distinguent les différents threads au sein d'un même processus.
Les flèches en trait plein montrent les interactions réseau (TCP?), celles en pointillés les interactions entre threads (je pense à une communication basée sur une queue d'événements/messages).
Côté serveur :
- Worker est le thread qui va faire le gros du travail, i.e. toute la gestion du jeu (IA, pathfinding, etc.). C'est lui qui est responsable de l'état du serveur à tout instant. Il est possible que je décide par la suite de créer des sous-threads qui vont s'occuper d'une tâche précise et lourde (sauvegarde automatique, calcul du tour d'une IA) pour laisser le champ libre à d'autres tâches plus simples que peuvent demander d'autres clients au même moment.
- Dispatcher écoute les actions des clients (déplacement d'une unité, demande de fin de tour ...) et les transmet à Worker qui va les répercuter sur l'état du serveur. C'est lui qui se charge aussi d'envoyer des messages aux différents clients (annonçant par exemple le début de son tour à un client).
Côté client (client simple) :
- GUI (game user interface) se charge d'afficher joliment l'état du jeu au client, et lui permet d'agir sur le jeu (donner des ordres, etc.). Maintient une copie partielle de l'état du jeu (seulement les unités qui sont visibles par ce joueur) construite à partir des instructions du serveur.
- Net. Com. (network communication) se charge d'écouter et transmettre à GUI tout message provenant du serveur (confirmation d'action du client, actions visibles des autres clients) et d'envoyer des messages au serveur (demande d'action, etc.).
Côté admin (client admin) :
- CLI (command line interface) est un thread de gestion en ligne de commande du serveur. C'est par cette interface sobre qu'un admin peut envoyer des commandes au serveur, demander au serveur des informations sur sa configuration, sur la partie en cours, mais aussi sur les différents clients (adresses IP en cas de bannissement, etc), bref tout un lot de requête qui seront a priori refusées aux clients normaux (via un simple système de mot de passe ?). Il est possible que cet élément disparaisse par la suite, mais je pense que ça me sera tout de même bien utile pour démarrer.
- Net. Com., comme pour un client usuel.
Est-ce que vous voyez un gros soucis dans cette approche, ou une chose qui m'aurait échappée ? La seule expérience que j'ai en réseau est ce que j'ai pu apprendre en jouant : il y a donc sans doute aussi des points qui sont un peu naïfs...
Merci d'avance pour votre avis en tout cas !
Partager