Je travaille sur un serveur de jeux générique qui gère les jeux pour un nombre arbitraire de clients en réseau TCP jouant sur un jeu. J'ai un «design» piraté avec du ruban adhésif qui fonctionne, mais qui semble à la fois fragile et rigide. Existe-t-il un modèle bien établi pour la façon d'écrire une communication client / serveur qui est robuste et flexible? (Sinon, comment amélioreriez-vous ce que j'ai ci-dessous?)
En gros, j'ai ceci:
- Lors de la configuration d'un jeu, le serveur a un thread pour chaque socket de joueur, gérant les requêtes synchrones d'un client et les réponses du serveur.
- Une fois le jeu en cours, cependant, tous les threads à l'exception d'un sommeil, et ce thread passe en revue tous les joueurs un à la fois pour communiquer sur leur mouvement (en inversant la requête-réponse).
Voici un diagramme de ce que j'ai actuellement; cliquez pour une version plus grande / lisible, ou PDF 66kB .
Problèmes:
- Cela nécessite que les joueurs répondent exactement tour à tour avec exactement le bon message. (Je suppose que je pourrais laisser chaque joueur répondre avec des conneries aléatoires et ne passer à autre chose qu'une fois qu'il me donne un coup valide.)
- Il ne permet pas aux joueurs de parler au serveur à moins que ce soit leur tour. (Je pourrais demander au serveur de leur envoyer des mises à jour sur les autres joueurs, mais pas traiter une demande asynchrone.)
Exigences finales:
La performance n'est pas primordiale. Cela sera principalement utilisé pour les jeux non en temps réel, et surtout pour opposer les IA les uns aux autres, pas aux humains nerveux.
Le jeu se fera toujours au tour par tour (même à très haute résolution). Chaque joueur reçoit toujours un coup traité avant que tous les autres joueurs aient un tour.
L'implémentation du serveur se trouve être en Ruby, si cela fait une différence.