Voilà une question posée sur une mailing list (pas de moi) dont la réponse m'intéresse également (les réponses données sur la mailing list ne me conviennent pas trop et le message se fait un peu vieux) :
 

 
Donc, j'aimerais également avoir votre avis sur la manière la plus élégante de résoudre son problème.
 
Merci

je crois qu'il part d'une mauvaise conception de ce qu'est la conception objet c'est a dire que parce que c'est objet c'est moins "impersonnel".
 
Bref savoir si c'est la tortue ou le bonhomme qui s'apercoit
qu'elle est morte c'est se preoccuper du sexe des anges.
 
Le principal probleme de la POO c'est d'un de partager
du code et donc de reutiliser les structures
(par heritage), de travailler sur des algos generiques
et de definir par le biais de module une separation
des taches (gestion de la logique, affichage).
 
LeGreg

D'accord avec Legreg.
 
C'est trop compliqué de toute facon de réagir là dessus...Ca dépend de l'architecture...
 
Pour ce problème, la réponse habituelle, c'est de considérer un système de message, de callback et une gestion centralisée...La tortue determine toute seule s'il elle crève et elle envoie un message à l'arène (ou à l'objet qui la tue si l'implémentation l'oblige) qui s'occupera de détruire l'objet.
L'arène stocke les éléments du décors et les éléments mouvant.
Le bonhomme fait les tests en demandant des infos de visibilité à l'arène, etc.

Pour moi c'est proche de la solution 3.
 
A la base, les collisions de sprites peuvent être détectées par chaque sprite quand il bouge, mais il vaut peut-être mieux que ce soit le jeu qui les détecte à chaque frame, question d'optimisabilité d'algorithme et de synchronisation des mouvements.
Par exemple, inutile de tester les collisions entre tirs.
Je pense que l'arène n'intervient pas ici.
 
-Chaque couple de collision de sprite dipose d'un code propre.
-Cette fonction agit sur les deux intervenants par leur méthodes.
-Chaque type d'objet dispose de méthodes sauter, mourir, ect...

 
Pour la collision avec le terrain, je pense que chaque sprite, au moment du déplacement, demande à l'arène ce qu'il a cogné (peut être rien), et agit en conséquence.
 
 
Après, bien sûr, il faut voir sur quel os on tombe en codant tout ça...
 
 
Ce que je n'ai pas bien compris, c'est comment on gère les séquences de mouvements.
Il me semble que ça ressemble à un automate, je parcourais un tableau de pointeurs de fonctions.

pour la premiere partie :
c'est le bonhomme qui fait l'action de tuer la tortue (il interragit sur la tortue)
pour moi une action = un envoie de message
 
donc le bonhomme envoie un msg a la tortue lui disant qu'elle doit mourrir
ca donne un truc du genre
 
Bonhomme bonhomme;
Tortue tortue;
bonhomme.kill(tortue);
 
void Bonhomme::kill(const BaseClass & baseClass) {
    baseClass.setKill(true);
}
 
bien sur Tortue derive de BaseClass (faut trouver un nom plus jolie) tout comme la classe Bonhomme
 
y'a aussi le pattern Observer qui peut etre interessant dans ce cas.

Chaque élément collisionnable possède un protocole pour être comparé à un autre, s'il collisionne, il appelle le message de collision de l'autre.
 
C'est bien entendu un double dispaching : tu "dispatche" les collision sur tous les éléments "collisionnable".  
 
pour éviter de te tapper n^2 (n étant le nombre d'objets collisionables dans la scène) tests de collision, tu découpe l'écran en zones et tu compares pas un mec qui est à gauche avec un mec qui est à droite de l'écran (genre octree en 3D).
 
Par contre il te faudra n^2 méthodes (n étant le nombre de classes d'objet collisionable), à cause du double dispatch mais fait une factorisation du code (pas moins de méthode mais code centralisé).
 
Un petit exemple de double dispaching : http://nraynaud.com.free.fr//td3dispatching.html