Dois-je écrire mon propre moteur physique, en raison de l'intégration du réseau?

11

Je développe actuellement un jeu de tir zombie de haut en bas en temps réel. Je code cela en Java, en utilisant JBox2D comme moteur physique. J'ai codé le réseautage cette semaine, et je suis maintenant à la synchronisation physique.

Je prévois d'utiliser le modèle client prédictif / serveur faisant autorité, où le client est libre de se déplacer, tant que le serveur l'approuve plus tard. Cela implique que le client envoie des paquets contenant des données de mouvement au serveur et que le serveur calcule la latence et simule à nouveau le monde à partir d'un état plus ancien.

Mon problème est que mon moteur physique actuel, JBox2D (essentiellement un port de Box2D), ne prend pas en charge le retour en arrière dans le monde, et il n'est apparemment pas si facile de sérialiser les données mondiales. J'ai 2 solutions, je pourrais soit modifier / étendre mon moteur physique actuel, soit écrire le mien.

Raisons d'écrire mon propre moteur physique -

  • Je peux supprimer des fonctionnalités inutiles. Dans un jeu descendant, je n'ai vraiment besoin que de mécanismes de collision et de forces de maniement. Aucune gravité n'est impliquée.
  • Je peux mieux comprendre le code et il serait [très probablement] plus facile d'implémenter des fonctions de restauration

Raisons pour étendre / modifier JBox2D

  • Écrire mon propre moteur de physique serait une tâche considérable, ce qui pourrait être fastidieux
  • JBox2D a une communauté largement solidaire, qui peut m'aider avec mon développement
  • JBox2D, a des optimisations spécifiques, pour des choses comme la détection de collision, qui le rendent utile
  • Certains travaux ont déjà été effectués à ce sujet, mais peu de code a été partagé

Alors, quelles sont vos opinions. Ceci est mon premier jeu, et je ne suis en aucun cas un développeur de jeux professionnel. Si quelqu'un pouvait fournir des liens vers des travaux déjà effectués dans le domaine (de préférence en utilisant JBox2D / Box2D / Java).

liamzebedee
la source
Notez également que si vous utilisez JBox2D, vous devrez l'utiliser strictfppartout, ce qui aura un impact sérieux sur les performances. Sinon, le serveur et le client peuvent ne pas obtenir exactement les mêmes résultats. Je recommanderais plutôt d'utiliser un point fixe.
sam hocevar

Réponses:

7

La détection de collision en 2D est tellement simple que je ne sais pas pourquoi vous vous donneriez même la peine d'utiliser un moteur physique en premier lieu. Et puisque toutes les forces de manipulation sont simples ou sur une courbe (pas de chute, modification des diagnostics, etc.) Personnellement, c'est une évidence pour moi que vous devriez choisir. Faire le vôtre est simple. Collision:

tenir compte des 3 collisions possibles qui peuvent se produire dans 2 rectangles:

  1. Bord à bord: Assez simple, vous obtenez l'axe d'un seul bord et d'un autre et vous décidez s'ils occupent le même espace ou assez près de celui-ci.
  2. Bord à coin: ce sera facilement le plus courant si vous avez des formes rotatives. Heureusement, c'est aussi assez simple à mettre en œuvre.
  3. Coin à coin: Cela se produira si rarement que cela ne vaut même pas la peine d'être mis en œuvre. La raison en est que 2 choses devraient se déplacer dans des directions exactement opposées sur le même axe exact jusqu'à la dernière décimale calculée de votre moteur. Maintenant, si tout tourne de 45 ou 90 degrés, cela PEUT (même probablement pas) valoir la peine d'être inclus

EDIT: Comme indiqué, je suis beaucoup moins familier avec cette question, et ne devrait pas être consulté sur la collision balle / projectile.

Lorsque j'ai travaillé avec des balles dans l'espace 2D, j'ai utilisé une sorte de cheminement qui fonctionnait à la fois en ligne droite et en courbe où je jetterais le projectile en utilisant le moteur physique (que je n'ai pas fait à partir de zéro) et en utilisant la collision standard.

Lisez à propos de la construction à partir de zéro dans les commentaires.


EDIT: * Croyez-moi, * quel que soit celui-ci, vous aurez besoin d'une forme de calcul mort dans votre moteur de jeux, en raison des projectiles et du nombre de projectiles qui pourraient être à l'écran à un moment donné. Vous ne voulez ABSOLUMENT pas mettre à jour chaque puce à l'écran par image à son emplacement donné. Mais c'est un excellent moyen de rendre un jeu incroyablement lent: D! Vous ne devriez jamais mettre à jour ces choses:

  • Un projectile est lancé
  • La direction dans laquelle il est lancé
  • Qu'il soit courbé ou non
    • Et si oui, quelle est la fonction de la courbe
  • De quel projectile s'agit-il (cela explique le graphique, les effets, les dommages, tout)

Maintenant, mettez à jour les données dans le moteur en fonction de ces données, plutôt que sur le serveur pour chaque fichu projectile, et envoyez des données par paquet pour chaque balle. (Imaginez faire cela avec seulement 2 mitrailleuses à l'écran! Jésus!)

Joshua Hedges
la source
Bien sûr, c'est relativement facile à implémenter, mais je suis également intéressé par l'optimisation de la détection de collision, que je n'ai aucune idée de comment implémenter.
liamzebedee
La méthode que j'ai décrite ne nécessitera vraiment pas d'optimisation si vous le faites comme décrit. La seule optimisation qui peut être nécessaire est le temps pendant lequel vous effectuez les vérifications et la fréquence de mise à jour des collisions. Par exemple: Ils n'ont VRAIMENT besoin d'être mis à jour qu'en cas de risque de collision.
Joshua Hedges
Pour développer ce que j'ai dit pour la dernière fois. Vous avez seulement besoin de vérifier la collision des bâtiments, par exemple, lorsque votre personnage se déplace en premier lieu. Vous n'avez besoin de vérifier la collision d'unités que lorsque vous avez même en vue des unités qui ne sont pas votre personnage. Il vous suffit de vérifier les collisions de projectiles, lorsqu'elles existent même (à ce moment). Vous pouvez ignorer toute forme de détection de type de collision (est-ce bord à bord? Coin à bord? Etc.) après avoir su que quelque chose touche même quelque chose d'autre ou près de lui. Sinon, sautez-le globalement.
Joshua Hedges
Sauf lorsque je traite des collisions côté serveur, dans lesquelles je dois détecter des collisions pour plusieurs joueurs, etc.
liamzebedee
4
@MadPumpkin: votre excès de confiance reflète mal votre réponse; vous parlez de détecter les collisions, mais vous ne mentionnez pas la détection de collision par balayage qui est au cœur absolu de la bonne gestion des balles dans un tireur 2D. En outre, même avec le balayage, la résolution est à peu près aussi importante que la détection, car vous devez décider quelle collision s'est produite en premier, résoudre les conflits potentiels et peut-être recommencer toute la résolution en cas d'entités supprimées. Certainement pas la question triviale que vous semblez impliquer.
sam hocevar