2010-11-30 13 views
16

Donc, ma question ne porte pas sur la méthode de détection de collision, mais plutôt sur un large «quel code devrait posséder la détection de collision». J'ai écrit un jeu dans le passé (jeux Flash 2D relativement simples) et cela m'a fait penser à quel code devrait posséder la détection de collision? Permettez-moi de clarifier - dire dans un jeu que j'ai un groupe d'ennemis et un groupe de projectiles que le joueur a tiré. Donc, dans le passé, j'avais déjà dit une classe EnemyManager, que chaque image mettait à jour les positions des ennemis et de la même manière que les projectiles des joueurs avaient une classe PlayerProjectilesManager qui se déplaçait autour des puces. C'est cool - tout va bien et dandy. Mais alors, je décide que je veux que les balles à affectent les ennemis (fou je sais!). Cela signifie donc quelque part dans le code que je dois:Gestion de la détection des collisions dans les jeux

  1. Figure quels balles et les ennemis sont en collision (je me fiche de cette question)
  2. figure la réponse à chaque collision

Alors En fait, ce que j'ai fait dans le passé, c'est que la classe EnemyManager prenne en charge les collisions et pendant sa boucle de mise à jour, elle trouve les puces qui entrent en collision avec les puces ennemies (étape 1) et appelle le code pour gérer la collision (par exemple, l'ennemi perd la santé, la balle disparaît) (étape 2). J'ai donc donné le contrôle de la détection de collision et de la «réaction» de collision au EnemyManager.

A quelques commentaires à ce sujet:

  • Il se sent varie arbitraire pour moi que le EnemyManager est « contrôle » au lieu du PlayerProjectilesManager
  • la fois la détection de collision et « réaction » collision sont gérées par le même propriétaire , ce n'est pas une exigence de mon point de vue

À mon avis, une entité tierce gère la détection de collision. Par exemple, avoir un CollisionManager qui possède un code qui sait quels autres gestionnaires doivent avoir des collisions détectées. Cela conduit à d'autres questions comme les interfaces que les 'Managers' doivent exposer pour une détection efficace des collisions sans exposer trop d'entrailles à CollisionManager. Ensuite, je suppose que le CollisionManager a diffusé une sorte d'événement, contenant 2 objets qui se sont heurtés, etc ... et peut-être que le gestionnaire EnemyManager/PlayerProjectilesManager a pu écouter séparément ces événements et réagir en conséquence et séparément. Je commence à avoir du sens dans mon esprit. :)

Pensées? Presque chaque jeu a une détection de collision, donc je suis sûr que cela a déjà été discuté. :)

Répondre

11

c'est une bonne question. Personnellement, je ne le compliquerais pas tellement en utilisant "Managers". Disons que nous avons un GameEngine, qui exécute le jeu dans sa boucle principale. Cette boucle principale pourrait être composée de 3 étapes: obtenir l'entrée de l'utilisateur, mettre à jour l'état de tous les objets dans le jeu (en fonction de l'entrée de l'utilisateur) et enfin tout reprendre à l'écran.

Tout ce qui concerne la détection de collision se fait à la deuxième étape - lors de la mise à jour de l'état des objets. Disons que tous les objets du jeu sont stockés dans un pool. Cela inclut le joueur, les balles, les ennemis et même le monde (si vous voulez que le monde soit également affecté). Tous les différents objets pourraient avoir des propriétés communes - ils pourraient être Drawable, Movable, Collidable e.t.c. (pensez à implémenter une interface ou à étendre une classe de base pour avoir ces propriétés)

Pour chacune de ces propriétés, j'aurais une classe qui ferait quelque chose avec tous les objets du pool. Comme Mover.moveAll (objectsFromPool).Cela va déplacer tous les objets, qui sont mobiles. La même chose pour la détection de collision -> après avoir déplacé les objets avec le Mover, nous vérifions la collision avec CollisionDetector.cehckAll (objectsFromPool). Cette méthode checkAll() fera la détection de collision réelle entre les objets eux-mêmes, connaissant leurs coordonnées. Si un objet est Collidable, le CollisionDetector invoquera sa méthode onCollide (withOtherObject) et l'objet lui-même réagira correctement, selon l'objet qui l'a frappé. Disons que si le joueur est touché par le corps ennemi, il reculera par exemple. Si une balle est touchée par une autre balle, elle sera marquée pour suppression. Si l'ennemi est touché par une balle, il y aura des dégâts et la balle sera marquée pour suppression. Toutes ces réactions doivent être dans les objets correspondants eux-mêmes. Le détecteur de collision applique ses algorithmes pour détecter la collision entre deux objets, puis invoque leur méthode onCollide (withOtherObjct). Si un objet n'est pas Collidable, il sera simplement ignoré par le CollisionDetector (par exemple, les particules de pluie ou la poussière ne peuvent pas être Collidable).

J'espère que je réussi à me exprimer correctement :)

0

Questions spécifiques au développement de jeu sont mieux adaptés à https://gamedev.stackexchange.com/ par la voie.

Ainsi, dans le passé, j'ai dire une classe EnemyManager

Je considère une classe SomethingManager être un signe que votre code n'est pas encore organisé avec précision. Pour la plupart, les objets devraient se gérer eux-mêmes. S'ils ne le peuvent pas, cela implique qu'il y a des informations externes à leur sujet, et cette information a probablement une représentation plus spécifique que «manager». 3 exemples spécifiques au jeu peuvent être GameWorld, GameRegion ou GameLevel. Les ennemis existent dans un monde, ou une région du monde, ou un niveau de jeu actuel, donc un tel objet maintient sa liste d'ennemis.

et de même pour les projectiles que le joueur a une classe PlayerProjectilesManager

Projectiles serait trop vivre dans une sorte d'espace de jeu, un monde, une région ou niveau. Maintenant, vous pouvez probablement deviner que l'un des objets ci-dessus peut (et devrait probablement) être responsable de posséder tous les objets ci-dessus (peut-être indirectement, via une classe conteneur, mais pas via un gestionnaire de poids lourds). et responsable de la détection des collisions et de les résoudre.