Un jeu multijoueur en JavaScript est-il une mauvaise idée? [fermé]

8

Quels sont les inconvénients possibles de l'utilisation de JavaScript (côté client) lors de la création d'un jeu multijoueur?

Description du jeu: C'est un MMORPG / RTS. Cela signifie que les joueurs contribuent activement aux structures du monde et créent eux-mêmes une grande partie du contenu.

2d multiplayer javascript jcora
la source
Je suis curieux: quel mécanisme utilisez-vous pour que le client parle au serveur et quelle est la latence? Quelle plateforme utilisez-vous pour le serveur?
Will
Le serveur fonctionne sur mon netbook qui exécute Ubuntu Linux, et il est écrit en JavaScript côté serveur, qui s'exécute en utilisant node.js.
jcora
Je ne sais pas pourquoi j'ai initialement voté pour cette question. Passé à un downvote et envisageant de voter de près, car "___ est-il une bonne idée?" n'est jamais vraiment une question à laquelle il faut répondre. En effet, dans ma réponse, j'ai même souligné qu'il était impossible de répondre exactement à la question.
jhocking
De plus, j'ai envie de changer le titre en "Un jeu multijoueur en JavaScript est-il une mauvaise idée?" améliorerait la question. Au début, cela semble être un changement trivial, mais reformuler la question en recherchant les inconvénients la rend plus responsable qu'un "quelle technologie dois-je utiliser?" une question. Demander "est-ce que cette technologie est bonne?" invite juste le broyage de hache.
jhocking
1
Je ne sais pas ce que pensent les mods mais je l' aime beaucoup mieux maintenant. retour à upvote
jhocking

Réponses:

9

C'est bien si:

  1. Le serveur n'envoie aucune information sur les joueurs situés derrière le champ de vision du joueur local (doit être calculé côté serveur) au joueur local (pour éviter le wallhacking).
  2. La disponibilité de toutes les actions est vérifiée sur le serveur lorsqu'un joueur appuie sur le bouton d'action.
  3. Vous effectuez uniquement le rendu sur le client - toutes les actions sont effectuées sur le serveur et uniquement prévues sur le client.
  4. Toutes les actions chronométrées sont côté serveur.
Triang3l
la source
Oui, je fais ces choses.
jcora
10
Veuillez noter que ces instructions sont valables pour tous les jeux multijoueurs, quelle que soit la langue, la plate-forme ou quoi que ce soit.
o0 '.
10

Que votre jeu soit ou non adapté au développement JavaScript dépend du jeu. Vous n'avez pas décrit votre jeu, donc nous n'avons aucun moyen de répondre à la question dans le titre.

Cependant, je peux dire que votre problème de piratage n'est pas un problème ici. Non pas parce que JavaScript ne peut pas être piraté (il le peut et facilement), mais il en va de même pour toutes les autres technologies côté client. L'un des principes de base du développement de jeux multijoueurs est de "ne jamais faire confiance au client". Concevez votre jeu de manière à ce que tout ce dont vous avez besoin pour vous protéger du piratage soit exécuté sur le serveur, car le client sera piraté. Cela signifie uniquement envoyer des commandes d'interface utilisateur à partir du client (par exemple, "le joueur a cliqué sur le bouton Bomb") et calculer les résultats des actions du joueur sur le serveur. Ensuite, le serveur renvoie au client les résultats de ces actions.

Étant donné que quelle que soit la technologie sur laquelle vous vous êtes appuyé, vous devez concevoir votre jeu en supposant que le composant côté client sera piraté, la piratabilité de JavaScript n'est pas une considération lors de la décision d'utiliser ou non JavaScript.

jhocking
la source
Merci beaucoup. Je vais modifier mon article et décrire le jeu maintenant.
jcora
3
jamais jamais jamais jamais jamais faire confiance au client, que ce soit son javascript ou autre chose!
the_e
1
Bien que tous les clients de jeux soient en effet piratables, certains le sont plus que d'autres.
Jonathan Connell
2
C'est vrai, mais la distinction n'est pas pertinente. Lors de la conception de la sécurité de votre jeu, qu'importe si l'option A est plus difficile à pirater que l'option B si elles sont toutes deux piratées?
jhocking
2

Les gens peuvent changer le code client pour tricher, c'est un problème pour tout jeu multijoueur. Si la vitesse de réaction ou la résolution rapide des tâches mathématiques fait partie du jeu, vous ne pouvez pas empêcher complètement la triche.

Pour tout autre élément de jeu, vous devez vous assurer que le client n'obtiendra pas et ne pourra pas obtenir des informations censées être cachées au joueur. Et bien sûr, le serveur doit valider que chaque action entreprise par un joueur est légale.

Le plus gros problème que je vois dans les jeux JavaScript est que beaucoup de navigateurs ont tendance à bégayer, en particulier Firefox était assez mauvais la dernière fois que j'ai vérifié. Pour cette raison, JavaScript n'est pas un bon choix pour un gameplay sensible au timing. Mais pour les jeux au tour par tour ou au moins au rythme lent, JavaScript peut très bien fonctionner.

aaaaaaaaaaaa
la source
2

Changer les variables Javascript est assez facile à faire avec des outils comme Firebug (pour Firefox) ou les outils de développement de Safari / Chrome. Vous pouvez simplement taper javascript dans la console et il sera exécuté. En règle générale, ne comptez pas sur le côté client pour la sécurité. En dehors de cela, avec l'introduction de l'élément HTML5 canvas, javascript vous offre de réelles possibilités pour des jeux simples (Il existe une version javascript / html5 complète d'Angry Birds par exemple).

Pjotterke
la source