Jeu multijoueur avec JavaScript backend et frontend. Quelles sont les pratiques exemplaires?
je pense créer un jeu multijoueur web dans noeud.js . Cela signifie que j'utiliserai le même langage dans le backend et dans le frontend. Il serait en temps réel et d'environ 20 personnes max dans chaque chambre, donc j'ai quelques réflexions:
-
Comment puis-je compenser le retard parmi tous les utilisateurs pour que tout le monde voit la même chose au même moment? Je pense à suivre le temps de ping moyen de chaque joueur, trouver le le plus lent, et informer les autres clients de l'heure (en millisecondes) ils doivent être retardés chacun afin que tout le monde est aussi synchronisé que possible.
-
je pense à lancer le code du jeu dans le backend aussi bien que dans le frontend (puisqu'il est JavaScript sur les deux extrémités) et juste avoir un mécanisme de correction d'erreur pour synchroniser avec le 'vrai jeu' dans le backend. De cette façon, le jeu devrait fonctionner en douceur sur la frontend et avec seulement quelques problèmes lors de la synchronisation. De plus, cela minimiserait le piratage JavaScript frontend puisque les tricheurs seraient synchronisés avec le jeu backend.
-
si je reçois les actions du joueur par la socket (touches), informer tous les autres clients des actions des autres joueurs et dans l'intervalle "jouer" le jeu dans le backend et envoyer des informations de synchronisation à chacun de l'état du jeu entier de temps en temps pour synchroniser ?
Qu'en pensez-vous? Y a-t-il d'autres choses que je devrais considérer ou faire attention?
s'il vous plaît poster des pensées ou des liens vers de la documentation ou des articles concernant le jeu multijoueur.
EDIT: elles sont utiles:
- Gaffer on Games - très bons articles de Glenn Fiedler sur le réseautage de jeux multijoueurs et physique
- La Quake3 Modèle De Mise En Réseau
7 réponses
1-est impossible. Vous ne savez pas exactement combien de temps prendra un message pour arriver sur un client et aucune mesure que vous prenez sera nécessairement applicable au prochain message que vous envoyez. Le mieux que vous pouvez faire est une approximation, mais vous devez toujours supposer que les gens verront soit des choses légèrement différentes ou les mêmes choses à des moments légèrement différents. Je recommande simplement d'envoyer l'état actuel à tout le monde et en utilisant interpolation / extrapolation pour lisser le gameplay, donc que tout le monde voit le jeu quelques millisecondes dans le passé, avec le retard variant à la fois entre les joueurs et au fil du temps. En général, c'est rarement un gros problème. Si vous voulez vraiment amortir quelques états passés sur le serveur, vous pouvez interpoler entre eux et envoyer différentes vieilles données à différentes personnes dans une tentative de synchroniser ce qu'ils voient, mais combiné avec la simulation côté client et le jitter dans les temps de transmission, vous verrez encore quelques différences entre les machines.
2-la manière typique est d'exécuter la simulation sur le serveur, et d'envoyer des mises à jour régulières (petites) aux clients. Les Clients exécutent généralement leurs propres simulations et ont un moyen de se fondre entre leur propre état prédit/interpolé et l'État autoritaire que le serveur leur envoie. Toutes les décisions autres que l'entrée de l'utilisateur doivent être prises côté serveur. En fin de compte, la façon dont vous les mélanger est juste un compromis entre un aspect lisse et un état précis, donc c'est une décision esthétique vous aurez à faire.
3 - votre client doit généralement traduire une pression de touche en action logique. Votre serveur ne se soucie pas des clés. Envoyez cette action logique au serveur et il peut la diffuser à d'autres clients s'ils en ont besoin. Généralement bien que vous n'auriez pas besoin de faire quoi que ce soit ici - tout changement pertinent causé par l'action changera typiquement l'état du jeu, et sera donc envoyé dans la diffusion normale de cet état.
Je n'aborderai pas vos points directement parce que les autres réponses le font très bien. Mais, je suggère d'examiner HTML5, WebSockets, et Comet qui promettent d'améliorer considérablement la performance en temps réel. Ces technologies vous permettent d'avoir des requêtes HTTP de longue durée, permettant au serveur de pousser les données vers le client plutôt que le client sondant le serveur. Cela peut considérablement accélérer les choses.
voici quelques ressources qui devraient s'avérer utiles:
-
C'est très dur à faire, et je peux voir beaucoup de problèmes avec la synchronisation à "le plus lent'. Pouvez-vous relâcher cela pour que les clients puissent être "éventuellement cohérents"?
-
ça sonne bien.
-
je voudrais envoyer des événements d'action courte de l'avant se termine à l'arrière-plan, avoir l'arrière-plan Modifier l'état du jeu et publier les événements de modification de l'état du jeu de retour aux clients, avec beaucoup attention à n'envoyer que les événements nécessaires aux bons abonnés. À ce stade, vous pouvez rejeter tous les événements qui ne semblent pas correspondre ou qui semblent comme des contrefaçons/piratages.
La meilleure façon est de garder une trace de tous les objets dans un seul endroit, à savoir le serveur. Tout le monde verra l'information des serveurs un temps de voyage plus tard que cela "se produit réellement" et les commandes des gens prendront un voyage pour s'inscrire sur le serveur. Il n'y a vraiment aucun moyen de contourner cela. Pour certaines applications, il peut être pratique de simuler votre propre mouvement tout de suite sans attendre une réponse du serveur, mais cela conduira sans aucun doute à un cauchemar avec la programmation du timing et les gens se verront typiquement "à la traîne". La détection des collisions est pratiquement impossible.
l'effet net de ceci est qu'il y aura une lenteur à partir du moment où vous entrez vos commandes jusqu'à ce que vous les voyez réellement se produire, mais avec un peu de chance les gens vont apprendre à faire face à cela et essayer d'entrer leurs commandes un peu plus tôt pour compenser. Avec des connexions lentes, les jeux en temps réel au rythme rapide sont tout simplement impossibles.
si vous êtes à la recherche d'un exemple de code à apprendre, Il ya un jeu multijoueur en ligne de Pong fait en ActionScript , avec physique côté serveur interpolé par les clients.
cet exemple de Pong est construit sur la Union platform , qui est disponible gratuitement pour un maximum de 1000 connexions clients simultanées.
Union a un JavaScript client framework, OrbiterMicro (Client JavaScript) .
et vous pouvez écrire votre logique côté serveur en JavaScript aussi, voir création de Modules de salle avec JavaScript .
(divulgation complète: je suis le co-fondateur de L'Union.)
une approche typique est de ne pas essayer de forcer tous les clients à exécuter à la même cadence verrouillée sur le serveur... il est juste moche. Au lieu de cela, envoyez des mises à jour fréquentes afin que les clients puissent mettre à jour chaque fois qu'ils reçoivent une nouvelle mise à jour.
normalement, un client va prédire comment les choses vont pendant de courtes périodes, puis être corrigé par une mise à jour du serveur. Vous pouvez également appliquer des corrections de temps. Par exemple, si le serveur vous dit "player 2 est à P voyageant à velocity V" vous pouvez essayer de connaître l'âge de ce message sur la base d'un ping récent, et corriger la position de P à P + x*D .
j'ai répondu à une autre question qui était similaire à celle-ci en ce qui concerne les questions de latence qui vaudra une lecture, synchroniser avec le client le plus lent pourrait ne pas être la meilleure solution selon le jeu.
Autres StackOverflow question: jeu Multijoueur mouvement de synchronisation