Quelle est la différence entre un serveur Web et un serveur de jeu?

Question

Je voudrais construire un jeu iPhone multijoueur au tour par tour qui nécessitera un serveur de jeu quelque part pour connecter les joueurs et diffuser les données de l'état du monde. J'essaie de comprendre comment le serveur de jeu fonctionnera pour que je puisse commencer à le concevoir et à le construire. Jusqu'à présent, je n'ai que de l'expérience dans la création d'applications web et, naturellement, mon esprit veut concevoir le serveur de jeu de manière similaire à un serveur web, mais est-ce possible? Les serveurs Web ASP.NET MVC que j'ai utilisés dans le passé fonctionnent en envoyant une demande de données de page Web au serveur et le serveur génère le code HTML ou XML ou JSON et le renvoie au client dans un paquet HTTP. Ce processus semble exactement le même pour un jeu multijoueur, sauf que le client ne demandera probablement pas de HTML, mais il serait logique de demander des données XML ou JSON, n'est-ce pas?

Mes questions sont ...

1. un serveur de jeu peut être écrit en utilisant ASP.NET MVC et fonctionnent comme un serveur Web en utilisant une API RESTful conçu par moi?
2. Existe-t-il une meilleure approche pour demander et recevoir des données de jeu que d'utiliser des paquets HTTP contenant des données XML ou JSON? Les données renvoyées par le serveur de jeu seront petites. Il est logique d'utiliser une API RESTful pour accéder aux données d'un serveur Web, mais l'utilisation d'une API RESTful pour demander des données de jeu à un serveur de jeu n'a aucun sens et, en fait, sonne comme pouvant entraîner des problèmes de sécurité. pensées?
3. Enfin, quelqu'un peut-il recommander des bons livres de jeu qui montrent des exemples sur la façon de construire un serveur de jeu décent?

Merci beaucoup d'avance pour votre aide!

Answer 1

Webservers manque un élément important ...

IE. Ils sont apatrides. La plate-forme entière du Web (et des serveurs HTTP en général) est basée sur le modèle qu'ils sont sans état, ce qui signifie qu'ils ne conservent pas les données lorsque vous passez d'une page à l'autre.

Il existe des moyens de contourner la limitation.Côté client: vous pouvez utiliser une session pour stocker des données lorsque le navigateur est ouvert; ou des cookies pour stocker des données à plus long terme. Côté serveur: les bases de données sont généralement utilisées pour stocker l'état à long terme. Alors ...

1. Oui, mais en fonction de combien et combien de temps vous voulez stocker l'état d'une session de jeu, vous trouverez peut-être que l'exécution du serveur jeu/moteur séparément (et non comme un serveur web) vous donnera beaucoup plus d'espace pour évoluer/grandir dans le futur. Oui, et non ... XML/JSON est à peu près le moyen de passer l'état de l'objet sur Internet parce qu'il est simple et indépendant de la plate-forme. Puisque vous pouvez/ne pas écrire votre propre backend de serveur, je vous suggère de jeter un oeil en utilisant XML-RPC avant d'envisager de lancer votre propre solution à partir de zéro. Je ne sais pas pourquoi vous êtes paranoïaque à propos de la sécurité. Si vous implémentez une politique d'accès assez stricte pour un cycle de requête/réponse acceptable, il ne devrait pas y avoir de problèmes. Comme je l'ai déjà dit, regardez XML-RPC. La clé est, ne donnez pas à l'utilisateur l'accès à plus de données du serveur de jeu dont ils ont besoin. Non, principalement parce que je n'écris pas de jeux. Cependant, j'ai de l'expérience dans l'écriture d'applications d'architecture client/serveur et ce n'est pas une opération de fusée. Je vous suggère de jeter un œil sur le site FAQ de Stack Exchange Game Development qui est sur le point de toucher la version bêta.

Answer 2

La principale différence est qu'un serveur Web génère beaucoup de contenu relativement statique en utilisant (relativement) peu ou pas d'informations d'état. Même lorsque l'état est utilisé, il est généralement spécifique à la session ou à l'utilisateur. Les lectures sont beaucoup plus fréquentes que les écritures, de sorte que la mise en cache peut aider à augmenter le débit. Vous pouvez également faire confiance aux navigateurs Web pour transmettre des données d'état et des cookies de manière (relativement) fiable. Au contraire, la plupart du temps, un serveur de jeu gère les mises à jour des clients, conserve une grande quantité d'état global (jeu, lecteur, statut) et envoie des mises à jour aux clients lorsqu'ils en font la demande. La mise en cache est impossible et vous ne pouvez pas faire confiance à vos clients pour vous dire l'heure du jour - vous devez supposer qu'ils essaieront de tricher de la manière qu'ils peuvent.

L'utilisation d'une API REST n'est pas un problème, car vous pouvez utiliser les mécanismes d'authentification standard que vous utilisez déjà.

Le chapitre 3 du livre "Beautiful Architecture" décrit l'architecture du projet Darkstar (maintenant RedDwarf), un serveur d'applications évolutif pour les jeux en ligne et les mondes virtuels. Bien que l'échelle de RedDwarf soit BEAUCOUP plus grande que ce que vous voulez, le livre décrit ce que vous devez faire lorsque vous créez un serveur de jeu.