ajout de notes
This commit is contained in:
parent
639ed42143
commit
4c392761c1
102
doc/notes.txt
Normal file
102
doc/notes.txt
Normal file
@ -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.
|
Reference in New Issue
Block a user