Hey ! J'ai effectivement commencé à regarder Rust et à voir ce qu'il y a en graphisme 2D. Je regarderai ce qu'offre Piston qui semble être un moteur assez complet (ou un ensemble de lib, je sais plus trop avec le vocabulaire propre à Rust...).
Par contre, c'est un langage assez complexe et avec pas mal de choses qui lui sont propres. J'ai lu que la moitié du livre pour l'instant (chapitre 10/20), sans avoir encore pu aborder le plus gros (programmation fonctionnelle et orientée objet). C'est un langage très intéressant, par exemple il permet de stocker des données de différents types dans des listes. J'avais jamais vu ça dans d'autres langages ! Après je m'y retrouve avec le C++ avec lequel je vois des concepts proches.

Bref, j'ai commencé à développer un embryon d'architecture ECS mais en C++. L'apprentissage de Rust est un peu trop long, j'y vais en douceur. Et en plus, si finalement je mets ça dans du C++, ça évitera de tout recoder.

Cette refonte me permet de passer directement sur du C++17, voire commencer à intégrer du C++20 tel que les "concepts" qui servent de contraintes sur les classes/fonctions génériques.
Le code est donc un peu mieux foutu avec des améliorations sur la sécurité. J'utilisais déjà des pointeurs dits intelligents mais le code et la technique s'améliorent encore car c'est prévu dès le début. Au final, il pourrait très bien être écrit en Rust comme en C++.

C'est clair que ça va changer pas mal de choses sur l'architecture, et si les performances suivent ça ne sera que mieux. L'ECS me permet en plus quelque chose qui était impossible jusque là : la communication via des événements ! Et ça manquait cruellement, même si je dois encore creuser le sujet vu qu'il reste des inconnues.

Un autre point, c'est OpenGL. Avec cette nouvelle architecture, il me sera possible profiter du multithreading et de l'utiliser à fond. Et comme j'ai déjà appris pas mal de choses en OpenGL, je me dis que la transition vers Vulkan devrait être plus facile.
L'autre avantage de Vulkan, c'est qu'avec une seule API on peut aller sur plusieurs plateformes (au lieu de OpenGL + OpenGL ES). Avec ce moteur, je voulais m'orienter surtout vers de l'embarqué (et principalement le Raspberry Pi). Vulkan pourrait me permettre d'unifier le moteur sur desktop et autres plateformes, et peut-être même le web assembly plus tard. Mozilla a proposé une API pour le web basée sur Vulkan : https://www.developpez.com/actu/125712/Mozilla-propose-au-groupe-Khronos-une-nouvelle-API-graphique-pour-le-Web-Obsidian-est-basee-sur-Vulkan/

Bon, pour l'instant je vais me contenter de finir mon POC purement C++, à voir ensuite.

J'ai continué à faire des recherches sur le développement d'une architecture ECS. C'est un changement de paradigme, au-delà de la programmation orientée objet, c'est ce qu'on appelle du "Data-Driven Programming" (ou programmation orientée donnée).

Je ne connais pas du tout ce paradigme, j'avoue être particulièrement enthousiaste à l'idée de découvrir une nouvelle façon de programmer. Mais avant de me lancer dedans, il faut voir comment ça se goupille...

J'ai vu le moteur de jeu 2D/3D Amethyst écrit en Rust.
https://amethyst.rs/

Comme j'appends ce langage, c'est encore mieux que Piston dont je parlais dans le post précédent. Ici, ça me permettra d'utiliser Rust et l'architecture ECS, tout en faisant un petit jeu (ce dont j'avais aussi envie) ! Bref, c'est ce qui s'appelle joindre l'utile à l'agréable en faisant d'une pierre trois coups.

Le fait d'utiliser un moteur basé sur la mécanique ECS pure me permettra de répondre à des questions sur le fonctionnement pour lesquelles je ne trouve pas de réponse sur internet. Dans la doc de Amethyst que j'ai très rapidement parcourue, j'ai vu des choses très très intéressantes encore. Ce sera probablement une grande source d'inspiration !!

J'ai une idée de jeu (plateformer 2D). En fait, je pense faire un jeu comme GrotteRaider que j'avais déjà réalisé avec un pote. J'aimais beaucoup ce jeu mais il était codé à l'arrache et le gameplay trop limité.
https://www.youtube.com/watch?v=e9O3BfUpXQU

Cet après-midi je veis esquisser un peu de gameplay avant d'installer Amethyst. Je vous tiendrai au courant du développement (dans un topic à part bien sûr).

Pour conclure, le projet hARMful va être mis entre parenthèse au moins pendant les deux mois d'été. Il n'est pas abandonné du tout, mais j'ai besoin d'en apprendre plus sur cet ECS et pour ça, il me faut pratiquer avec un moteur existant avant de reproduire.
En sus, j'en ai un peu marre de faire que du rendu. Développer un jeu c'est quand même plus drôle.

Rien de mieux que de s’immerger quelques temps dans la techno pour bien la comprendre
Fiou j'ai regardé Amethyst rapidement (juste un mec qui testait pour la première fois) pour voir le workflow et en fait si je dis pas de bêtises il n'y a pas de GUI ! Du coup c'est code pur à donf et commandes dans la console (pour les vrais de vrai )

Je me demande si tu va devoir intégrer ton propre moteur physique, quoi que j'imagine qu'ils ont fait des librairies pour ça. En tout cas je vais guetter le sujet !

Bonne continuation ++

Oui, c'est un moteur qui se code à la mano.

Les lignes de commandes sont très limitées en Rust. Cargo est une boîte à outils pour le langage Rust qui fait le café : il télécharge les dépendances, compile, exécute... le tout avec une simple ligne de commande. Du coup, t'as qu'à taper "cargo run" et il fait tout avant de lancer ton programme.
Il sert aussi à préconfigurer un nouveau projet !

Pour le moteur physique, je ne sais pas encore mais je n'en ai pas vu dans Amethyst. Je pensais à quelque chose d'assez basique, j'ai déjà eu l'occasion de coder celui de GrotteRaider et ça marchait plutôt bien !

Il y a aussi un éditeur graphique encore à l'état expérimental. Peut-être que ça viendra dans quelques années !

Merci !

Bonjour à tous !

Ca faisait longtemps que je n'avais pas posté sur ce topic.

J'avais du arrêter d'apprendre le Rust pour des raisons personnelles impliquant fatigue et manque de concentration. Je n'avais pas pu aller bien loin sur l'architecture ECS dont je percevais très mal la mise en œuvre.

Ces toutes dernières semaines, j'ai repris ce projet d'architecture autour d'un prototype que j'ai développé en Python. Le langage est simple et parfait pour prototyper. J'avais prévu de mettre ça en place autour d'un projet de mini-jeu 2D via pygame... mais ça c'était sans compter une mauvaise surprise liée à Python. Je ne peux pas continuer à développer sur Python tout en profitant des bienfaits de cette architecture et de tout le travail accompli.

Avant d'expliquer les soucis que je rencontre, je vais faire un petit point sur ce qu'est cette fameuse architecture ECS.

Il y a des années de ça, des moteurs 3D comme OGRE ou Irrlicht sont apparus sur la scène du logiciel libre. Ils utilisent la programmation orientée objet et, pour chaque type d'objet dans une scène 3D, on a une classe donnée. Ces moteurs profitent donc de l'héritage. Un souci avec ce fonctionnement, c'est le manque de flexibilité que cela peut engendrer.

Une autre vague de moteur, probablement lancée par Unity, propose une approche différente. Les objets ou entités de la scène 3D sont génériques (GameObject par exemple) et, au lieu d'un héritage, sont faits de "composants" qui leur apportent des fonctionnements différents. On peut par exemple attribuer un composant Caméra pour créer une caméra dans la scène 3D. Pour créer un mesh dans la scène, on pourra donc apposer un composant Mesh et un composant Material sur un autre "GameObject". On gagne donc en souplesse d'utilisation des objets de la scène 3D, comme par exemple changer le Material en cours d'exécution ou lui ajouter un composant pour en faire un RigidBody. Ainsi, la scène 3D peut très facilement être modifiée tout au long de sa vie.
Cependant, si elle apporte une plus grande flexibilité, cette architecture pose des problèmes notamment en terme de performances.

Il y a maintenant quelques années, une nouvelle gamme d'API graphiques sont apparues et seront probablement le futur de la 3D à moyen-long terme.
Les API "historiques" comme OpenGL et DirectX (11 et inférieurs) s'utilisent généralement dans un seul thread. Or, nos processeurs modernes possèdent de plus en plus de cœurs leur permettant de paralléliser les tâches. Dans un jeu vidéo, on peut avoir de nombreux threads comme l'un qui gère le son, l'autre le réseau et le thread dit principal qui va gérer l'envoi des données à la carte graphique pour faire le rendu des frames. Cependant, cela sous-exploite le processeur et la carte graphique.
Avec les nouvelles API comme Vulkan (générique), DirectX12 (Microsoft) et Metal (Apple), plusieurs threads peuvent envoyer des commandes à la carte graphique. Il y a un empilement des choses à faire côté GPU de sorte qu'on utilise au maximum le GPU qui n'attend plus ou moins que le CPU lui envoie des instructions. Du côté du CPU, cela signifie aussi qu'il est possible de créer plusieurs threads pour gérer le rendu.

Le souci avec une architecture comme celle proposée par Unity, c'est qu'elle est se révèle assez complexe à utiliser dans un cadre multithreadé. Les GameObjects sont organisés en arbre, l'arbre de scène. Or, il est difficile de prévoir le nombre de threads à utiliser pour parcourir cet arbre, sa profondeur, sa complexité. D'autant plus que cet arbre pourra grandir ou rétrécir, s'élargir ou se condenser au fil de l'exécution. Du coup, la stratégie doit être aussi évolutive pour donner suffisamment de travail à chaque thread sans en donner trop à l'un et pas aux autres.

Afin de faciliter grandement la mise en place du multithreading dans un jeu vidéo, il vaut donc mieux partir sur une mise à plat. Et c'est là que l'architecture ECS apparaît. ECS pour Entité-Composant-Système. On retrouve donc les notions d'Entités et de Composants comme pour Unity, mais on va voir que ce sont des éléments complètement différents. Bien qu'il s'agisse stricto sensu de programmation orientée objet, on parlera ici de programmation orientée données. Donc tout langage de programmation permettant la POO pourra servir à implémenter l'architecture ECS.
- Les Entités (ou GameObjects) ne sont plus des éléments d'un arbre. Ce ne sont plus que de simples ID (identifiants) uniques, autrement dit, une valeur entière. A chaque création d'entité, l'ID est incrémenté afin de toujours produire une nouvelle valeur différente de toutes les autres créées précédemment. On peut également prévoir la réutilisation d'un ID quand une Entité est détruite.
- Les Composants de Unity contenait à la fois les données et le traitement de ces données. Dans l'architecture ECS, les composants sont réduits à la simple agrégation de données. Aucune logique, aucune fonctionnalité ne leur est directement implémentée. Les Composants sont évidemment liés à une Entité mais pas comme sous Unity. Au lieu de mettre le Composant directement dans le GameObject, on va simplement faire un lien sous la forme par exemple d'un système de [clé:valeur], où la clé est l'Entité et la valeur le Composant. On peut créer une classe qui s'occupera d'établir et conserver ces liens.
- Les Systèmes sont, eux, les éléments qui vont traiter les données des composants. On a donc une séparation entre données et traitement. On peut voir les Composants comme des éléments d'une base de données et les Systèmes sont la partie traitement de ces données. D'où l'orientation données de cette programmation.

La structure de l'architecture est donc à plat, sans arborescence. On peut donc placer ces éléments dans des tableaux. Un impact intéressant de cela, en plus de permettre un multithreading facile (on découpe les tableaux en autant de bouts que de threads), est lié au fonctionnement des processeurs. Quand ils récupèrent des données adjacentes en mémoire comme des données d'un tableau, ils peuvent les traiter beaucoup plus rapidement grâce à la mise en cache. Des données dans un arbre peuvent se trouver à des emplacements mémoires trop éloignés, ce qui oblige le processeur à faire des accès mémoire plus nombreux. Cela engendre donc une latence bien plus importante et donc des pertes de performance.

On peut évidemment se poser la question de comment structurer nos objets pour avoir des liens de parenté entre eux. La réponse est simple et coule de source quand on l'énonce : le lien de parenté est lui-même un Composant ! De même que la transformation locale d'un objet, et de tout autre aspect indispensable pour un objet 3D.
A chaque type de Composant, on crée le Système qui lui correspond et qui est dédié au traitement de ce type de Composant.

Ce point exhaustif étant fait, je reviens à l'implémentation Python que j'ai faite. Attention, je ne prétends absolument pas avoir fait un truc parfait. D'ailleurs, si vous cherchez des exemples d'architecture ECS, je pense que vous aurez quelques difficultés à en trouver. Le pourquoi est simple, chaque projet n'a pas forcément les besoins et l'architecture ECS n'est pas un bloc de code imposé. En gros, chacun implémente l'architecture ECS à sa façon, suivant ses besoins. Il s'agit donc plus d'un guide que d'un outil qu'on utilise clé en main. Ma solution est donc pertinente dans le cas de mes projets mais elle pourra ne pas répondre entièrement aux besoins d'un autre développeur.

Voici le dépôt pour quiconque voudrait y jeter un oeil : https://github.com/dcarlus/PyECS

En plus des Entités, Composants et Systèmes dont j'ai parlé, j'ai ajouté quelques notions supplémentaires. Celle de Job qui est commune dans l'architecture ECS. Un Job va traiter en multithreading un ensemble de Composants, de préférence indépendants les uns des autres. On choisit le nombre de threads pour exécuter chaque Job.
Les Jobs s'exécutent successivement les uns après les autres au cours d'une même frame. On peut donc les hiérarchiser pour pré-traiter des données variées (position d'un perso, santé et force d'un perso, ...), les utiliser dans un autre Job (traitement de l'IA basée sur la position et les stats du perso) et enfin rendre graphiquement le résultat (animation d'attaque, rendu 3D).

Enfin, pour simplifier au maximum la gestion des données, une classe World. Elle centralise toutes les mécaniques de l'architecture ECS : création et suppression des Entités et des Composants qui leur sont liés, exécution du code, etc.

Au tout début du message, j'évoquais mes difficultés m'obligeant à abandonner Python pour poursuivre mes essais. Cela est dû à CPython, l'interpréteur par défaut de Python et à ma connaissance, le plus complet vis-à-vis des paquets de bibliothèques disponibles. CPython gère le multithreading mais hélas, il ne fait tourner qu'un thread à la fois (voir le Global Interpreter Lock pour plus de détails). Si bien que mon application de test, qu'elle utilise 1 ou 16 threads, tourne tout aussi lentement avec de nombreux personnages.
https://en.wikipedia.org/wiki/Global_interpreter_lock

Or, l'objectif de ce test est non seulement l'implémentation fonctionnelle de l'architecture ECS (réussite avec Python) mais aussi mesurer les performances grâce au multithreading (échec avec Python). Il existe d'autres interpréteurs que CPython, ceux-ci offrant un multithreading plus performant. Cependant, j'ai essayé d'installer pygame avec PyPy3 sans réussir. J'ai aussi voulu compiler pygame avec PyPy3, mais là aussi ça a été un échec cuisant (sous Windows). Il me reste l'éventuelle solution de tester cela sous Linux, lequel pourrait me permettre d'y parvenir.
Bien que cette expérience me frustre à cause de ce deuxième point non honoré (pour l'instant), je suis malgré tout très satisfait d'avoir réussi à implémenter une architecture ECS qui fonctionne et qui soit, je pense, assez simple d'utilisation. Il faut dire que c'était quelque chose de très abstrait pour moi et j'avais du mal à savoir comment l'appréhender.

Le projet ne s'arrête pas là. Je compte reprendre mon code Python pour le porter dans un autre langage comme C++ ou Rust que j'aimerais continuer d'apprendre. Je pourrai alors tester le multithreading en conditions réelles et avec des performances encore meilleures ! Je verrai pour faire peut-être un mini-jeu 2D à partir de là.

Bonjour,

Cela peut expliquer beaucoup de choses si je réfléchis du comment le BGE fonctionnerai, à cause d'un certains GIL (Global Interpreter Lock)... est-ce possible ?

Pas que le BGE mais tout programmes python, apparemment...

Donc si je comprends bien, ton moteur intégrera du 3D mais aussi du 2D ou tu vas le revoir pour uniquement du 2D ?

Oui ça peut s'expliquer pour le BGE. Je crois qu'ils passaient par CPython.

Là je veux faire un petit jeu 2D pour tester les performances. Mais le but final sera de faire de la 3D avec Vulkan !