Architecture du code

[Laurent Vaucher]

Un des trucs qui a pas mal le vent en poupe ces derniers temps dans le développement de jeux, c'est ce qui s'appelle l'architecture Entity-Component-System.

On trouve pas mal de truc sur Google là-dessus. Ça prend un peu de recul par rapport à l'orienté-objet à proprement parler, pour éviter les casse-têtes liés à l'héritage.

Le principe de base, c'est que tous les objets du jeu sont de bêtes conteneurs de composants, eux-mêmes bêtes conteneurs de données. Par exemple le composant qui s'appelle généralement Transform contient la position de l'objet dans l'espace, le composant Input indique que l'entité reçoit les entrées utilisateur, le composant Camera indique que l'objet définit la vue, le composant RigidBody indique que l'objet est soumis à la simulation physique...

Du coup, un objet peut contenir n'importe quelle collection de composants, et cette collection peut évoluer dans le temps : un objet qui était mobile peut devenir immobile, un objet silencieux peut se mettre à faire du bruit, etc. Cette composition dynamique a l'avantage de s'affranchir de la rigidité de l'héritage.

Le troisième élément, les systèmes, sont ceux qui contiennent réellement le code et la logique propre à certains composants.

Un avantage supplémentaire de cette architecture, c'est que les dépendances sont réduites. Un composant ne dépend de rien et un système ne dépend que des composants qui l'intéressent. Par exemple le système physique n'a rien à faire de l'aspect sonore d'un objet. Le système d'IA se fiche des animations graphiques d'un personnage. Le résultat c'est qu'on peut plus facilement se partager le codage, que c'est plus facile à tester, que c'est plus modulaire.

Du coup, histoire d'illustrer un peu mon propos, j'ai fait un petit proto JavaScript sur la page des protos. Vous pouvez regarder le code pour avoir une idée. Je l'ai fait en JavaScript parce que (j'espère) c'est lisible et qu'en C++ ça m'aurait pris bien plus de temps. Mon implémentation est tout sauf efficace, mais pour une maquette c'est suffisant.

Ça vous cause, ou je barbe tout le monde.

[chrivier]

c'est interessant comme principe

il faudrait faire un proto c++, pour lancer tout le monde ;)
ou alors on part sur javascript.

On Jun 14, 10:47 pm, Laurent Vaucher <laurentvauc...@gmail.com> wrote:
> Un des trucs qui a pas mal le vent en poupe ces derniers temps dans le
> développement de jeux, c'est ce qui s'appelle l'architecture
> Entity-Component-System.

> On trouve pas mal de truc sur Google là-dessus<http://www.google.fr/search?q=game+entity+component+subsystem>.

> Ça prend un peu de recul par rapport à l'orienté-objet à proprement parler,
> pour éviter les casse-têtes liés à l'héritage.
>

> Le principe de base, c'est que tous les objets du jeu sont de *bêtes* conteneurs
> de composants, eux-mêmes *bêtes* conteneurs de données. Par exemple le
> composant qui s'appelle généralement *Transform* contient la position de
> l'objet dans l'espace, le composant *Input* indique que l'entité reçoit les
> entrées utilisateur, le composant *Camera* indique que l'objet définit la
> vue, le composant *RigidBody* indique que l'objet est soumis à la

> simulation physique...
> Du coup, un objet peut contenir n'importe quelle collection de composants,
> et cette collection peut évoluer dans le temps : un objet qui était mobile
> peut devenir immobile, un objet silencieux peut se mettre à faire du bruit,
> etc. Cette composition dynamique a l'avantage de s'affranchir de la
> rigidité de l'héritage.
> Le troisième élément, les systèmes, sont ceux qui contiennent réellement le
> code et la logique propre à certains composants.
>
> Un avantage supplémentaire de cette architecture, c'est que les dépendances
> sont réduites. Un composant ne dépend de rien et un système ne dépend que
> des composants qui l'intéressent. Par exemple le système physique n'a rien
> à faire de l'aspect sonore d'un objet. Le système d'IA se fiche des
> animations graphiques d'un personnage. Le résultat c'est qu'on peut plus
> facilement se partager le codage, que c'est plus facile à tester, que c'est
> plus modulaire.
>
> Du coup, histoire d'illustrer un peu mon propos, j'ai fait un petit proto

> JavaScript sur la page des protos <http://slowfrog.github.com/chickenpix/>.

[Laurent Vaucher]

Je suis justement en train de recoder en C++ ce que j'ai déjà écrit en javascript.

Je pense que ce sera sûrement du C++ qui fera hurler les professionnels de la profession, mais comme tu le disais, ça fera un point de départ.

D'ici ce soir ou demain, ça devrait être fait.

Je le commiterai sous github. En attendant la formation git, je pourrai vous expliquer déjà comment récupérer le source. Il faudra juste que vous vous enregistriez sous github.

[Laurent Vaucher]

Ah, au fait Christophe, tu disais que tu avais écrit un Makefile qui compilait mon exemple précédent avec ClanLib.

Tu pourrais le poster ? (Pour l'instant je fais du g++ *.cpp mais c'est pas optimal)

Merci.

[chrivier]

je te poste le makefile



CC=g++
CFLAGS=`pkg-config --cflags clanCore-2.3 clanDisplay-2.3 clanApp-2.3
clanSWRender-2.3 clanGL-2.3 clanGL1-2.3` -pthread -c -Wall
LDFLAGS=`pkg-config --libs clanCore-2.3 clanDisplay-2.3 clanApp-2.3
clanSWRender-2.3 clanGL-2.3 clanGL1-2.3 clanGUI-2.3 clanVorbis-2.3 `
SRC_DIR=src
SOURCES=$(SRC_DIR)/precomp.cpp $(SRC_DIR)/program.cpp
OBJECTS=$(SOURCES:.cpp=.o)
EXECUTABLE=hello


$(EXECUTABLE): $(OBJECTS)
$(CC) $(LDFLAGS) $(OBJECTS) -o $@

.cpp.o:
$(CC) $(CFLAGS) $< -o $@
src: $(OBJECTS)

all: $(SOURCES) $(EXECUTABLE)


je ne suis pas hyper fan de l'utilisation de pkg-config, mais c'est
comme ça qu'il compile les exemples de la librairie Clanlib

Sinon j'avais des questions sur le code, mais si tu le transcode en C+
+, je comprendrais mieux

Pour la petite histoire c'est l'objet "prototype" présent dans tous
mes objets. Pas compris comment il était instancie dans Entity

[Laurent Vaucher]

Super ! Merci. Je vais l'utiliser.

J'ai posté le code à moitié fini dans le repository github. En attendant d'avoir un compte et de savoir utiliser git, il est possible d'aller sur https://github.com/slowfrog/chickenpix et de cliquer sur le bouton "ZIP" pour télécharger une archive de l'état actuel du repository.

Là, sous Linux, je fais make clmain et ça compile correctement. Je dis que c'est à moitié fini, parce que tout le code n'est pas encore "encapsulé"  correctement dans des composants.

Concernant la version javascript, prototype est une spécificité du langage. Quand on y met des attributs ou des fonctions, ça devient visible par toutes les "instances" de cet objet. C'est un peu comme une classe, sauf que javascript ne connaît pas les classes. Je ne vais pas vous embrouiller avec ça.

[chrivier]

j'ai pas réussi a compile avec ton makefile :(
il arrive pas a linker si on compile tout sur la meme ligne de
commande
du coup j'ai créé un projet avec Eclipse, il me gère le makefile tout
seul
et ça y marche :)

On 16 juin, 21:06, Laurent Vaucher <laurentvauc...@gmail.com> wrote:
> Super ! Merci. Je vais l'utiliser.
>
> J'ai posté le code à moitié fini dans le repository github. En attendant

> d'avoir un compte et de savoir utiliser git, il est possible d'aller surhttps://github.com/slowfrog/chickenpixet de cliquer sur le bouton "ZIP"

[Laurent Vaucher]

Ben si tu récupères la version github de maintenant, j'ai fait un Makefile avec ce que tu as envoyé.

Et ça y marche aussi, dis donc !

[chrivier]

je suis en train de me faire la main, en rajoutant l'animation avec
les flèches