From 4c392761c1c46e162f62d524be3e8f78ec028498 Mon Sep 17 00:00:00 2001 From: papush! Date: Wed, 4 Dec 2019 22:34:01 +0100 Subject: [PATCH] ajout de notes --- doc/notes.txt | 102 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 doc/notes.txt diff --git a/doc/notes.txt b/doc/notes.txt new file mode 100644 index 0000000..bdc92e4 --- /dev/null +++ b/doc/notes.txt @@ -0,0 +1,102 @@ +On a voulu commencer en écrivant le code le plus simple et efficace +qui permettait de réaliser un pac-man. Celui-ci n’utilisait que très +peu de classes ou patrons de conceptions, il était simple et efficace +mais aussi très spécifique et inflexible. + +On a donc corrigé le tir en passant à une architecture de moteur de +jeu entité-composant. + +Le moteur de jeu est entièrement séparé du jeu lui-même et d’autre jeu +pourraient être implémentés sur le même moteur sans le changer ou +presque. + +Le système entité-composant se base principalement sur l’idée de +favoriser la composition par rapport à l’héritage. Son principe est +simple : chaque objet dans une scène d’un jeu (une scène étant un +« écran » de jeu ou une phase, comme un niveau mais aussi un menu…) +est une entité. Une entité consiste d’un ou plusieurs composants qui +lui ajoutent une fonctionalité ou un comportement. Cela permet de +simplifier la hiérarchie de classe, mais également de mettre en place +certaines optimisations du domaine de la programmation orientée +données. Avec l’entité et le composant, la troisième brique +élémentaire de cette architecture est le Système, aussi appelé Serveur +ou Moteur. Ceux-ci fonctionnent indépendamment et effectuent un +traitement sur sur toutes les entités qui possèdent un composant qui +touche un aspect similaire au serveur. + +Plus concrètement, sur l’exemple de notre jeu pac-man : le pac-man, +les fantômes, le labyrinthe et les pac-dots sont des entités. + +Ils ont tous un composant « représentation graphique » entre autres +qui permet de les afficher à l’écran et contient les données +nécessaire pour cela (leur image, mais aussi leur niveau/hauteur pour +savoir lesquels afficher au-dessus des autres). + +Le moteur dispose d’un serveur graphique qui, à chaque itération de la +boucle principale de jeu, itère sur tous les composants graphiques et +en effectue le rendu pour finalement l’afficher dans la fenêtre du +jeu. + +Un deuxième composant que beaucoup d’entités vont posséder est lui lié +à la gestion de la physique. Le serveur physique associé va à chaque +tour de boucle calculer les nouvelles position des entités (pour +celles qui doivent/peuvent se déplacer) mais aussi calculer et +résoudre les collisions, éventuellement en envoyant un signal aux +entités concernées en cas de collision. + +Finalement, chaque entité peut avoir un comportement personalisé sous +forme d’une fonction appelée à chaque itération. + +Le moteur contient donc la définition d’une entité, des différents +composants et serveurs et de la boucle principale. Le jeu lui est +séparé du moteur et n’est qu’un ensemble de scènes, qui sont une +simple collection d’entitées avec des composants pré-établis et des +comportements personalisés. + + +En termes de patrons de conception utilisés : + + - le système entité-composant est lui-même un patron (d’architecture + plus que de conception), + + - le décorateur est utilisé à divers endroits, par exemple pour + ajouter diverse responsabilité à une boîte de collision et la + rendre traversable (simple zone de détection « trigger » comme pour + les pac-dots), solide statique (un mur), solide dynamique (pac-man, + les fantômes), + + - le singleton, chaque serveur ne peut être instancié qu’une fois et + le patron singleton permet également de retrouver cette instance de + n’importe où dans le code plutôt que d’avoir à passer des + références de partout, + + +Évolutions futures possibles : + + - système de gestion des entrées, chaque entité qui veut recevoir des + entrées (clavier, manettes) doit posséder un composant qui décrit + quelles actions l’intéresse et le comportement à adopter + lorsqu’elles sont reçues, + + - système d’animation, celles-ci sont pour l’instant gérées + manuellement dans le comportement personalisé des entités mais + devraient être un composant spécialisé (le lecteur d’animation) qui + lit des animations qui seraient alors un nouveau type de resource + qui modifient les propriétés d’une entité (et ses composants) au + fil du temps, par exemple changer l’image d’un pac-man pour + utiliser alternativement celle avec bouche ouverte et celle avec + bouche fermée (waka-waka). On peut également penser à une machine à + état qui gère les états et transitions entre ces états (dans un jeu + 3D, passage de l’état « debout » à l’état « courrir » qui ont + chacun leur animation, tout en effectuant une transition entre les + deux animations pour éviter les changements brutaux), + + - gestion spécifique des resources, pour l’instant chaque composant + stocke les resources dont il a besoin, principalement des images. + un moteur de jeu plus complexe peut avoir une gestion des resources + spécialisée pour optimiser l’utilisation mémoire gérer + automatiquement les conversions entre différents formats, + + - de manière globale, généraliser tous ce qui peut être généralisé + dans les fonctions personalisées de chaque entitée sous la forme de + composants.