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