Theory - Herzucco/Puppets.js GitHub Wiki

#Introduction

Puppets suit la philosophie de programmation en : entities, components, systems (ECS).

Ce modèle de programmation utilisé et apprécié dans le jeu vidéo pour sa modularité amène des concepts que nous expliquerons les uns après les autres.

##Le concept

La programmation ECS a de multiples formes, plus ou moins poussées et plus ou moins à l'opposé de la programmation objet plus classique. Puppets suit néanmoins un concept d'ECS bien précis.

###Les Entités Chaque objet dans un jeu est une entité. Un ennemi est une entité, le background est une entité, la souris est une entité... Ainsi, peut importe le type d'objet que l'on veut, tous représentent exactement la même chose à l'origine.

Une entité n'est rien d'autre qu'un id : une chaîne de caractère ou un nombre. Dans Puppets, les entités sont des nombres.

Mais alors, si ce ne sont que des id, comment savoir que telle entité peut se déplacer, et que telle autre n'est qu'un gestionnaire d'inputs ?

C'est ici qu'interviennent les components. Il y a plusieurs façons de lier les components à leurs entités. Dans Puppets les entités, qui sont des nombres, réfèrent chacune à une liste unique de components qui décrit tous les components de cette entité.

###Les Components Là encore, selon les types d'ECS, il y plusieurs façons d'envisager ce que sont les components. Pour Puppets, les components sont des ensembles de données.

Cela signifie que les components n'ont pas à avoir d'intelligence.

Exemple : un component Position2d, qui va, une fois attribué à une entité, lui accorder une position dans un repère à deux dimensions. Ce component se résumera à un objet contenant une valeur x, et une valeur y.

Il s'agit uniquement d'objets listant des données qui seront ensuite utilisées par les Systèmes.

###Les Systèmes Les systèmes sont les moteurs du jeu. Ils représentent l'intelligence du jeu.

Lors de la définition d'un système, deux choses sont à déclarer : sa tâche, et les components qu'il requière pour fonctionner.

Un système nécessite en effet de savoir quels sont les components dont il a besoin pour travailler, car ce sera son seul repère. En effet, les systèmes sont parfaitement dissociés des entités.

Il est donc impossible de lier un système à une entité.

Pourtant, il faut bien que ces entités soient traitées, que le background soit affiché, que les ennemis bougent, etc...

Pour cela, voici comment Puppets opère. Pour chaque entité, tous les systèmes vont regarder si elle possède les components nécessaire à leur fonctionnement. Si ce n'est pas le cas, le système ne se lance pas. Au contraire, si l'entité possède bien les components demandés par le système, alors le système se lance et exécute sa tâche avec les components dont il a besoin attribués à l'entité courante.

Exemple : Une entité possède un component position2d. Un système dont la tâche est d'augmenter la valeur x d'une position de 10 demandera comme component impératif le component position2d. L'entité que nous avons définie le possède. Son component position2d va donc entrer dans le système, qui va pouvoir augmenter sa valeur x de 10.

##Les avantages Les avantages de la programmation ECS résident avant tout dans sa modularité.

La modularité d'un tel système est absolue. Une entité n'étant qu'un simple id, on peut lui attribuer et lui désattribuer des components volonté. Un background peut subitement devenir un ennemi, et vice versa, même si ça n'aurait pas forcément de sens.

D'un point de vue Game Design, il est très agréable d'avoir une telle modularité.

##Les désavantages Le confort de la programmation objet et son fameux "this" disparaissent, ce qui peut déstabiliser.

Aussi, cette façon de programmer impose de suivre le concept DRY (Don't Repeat Yourself), afin que les systèmes et les components soient génériques.