Cap Horn : v0.1 Systèmes de base
UnRealCloud Il y a 3 ans Premium Pro5

C’est parti pour le voyage.

Pour tenir sur la distance, j’ai besoin que les fondations soit solides. Il me faut donc des outils d’anciens projets remis au propre et 100% fonctionnel. C’est pourquoi tout ce qui peut être individualiser en libraire le sera et sera posté.

J’en avais parlé dans un précédent projet, j’utilise le paradigme d’Entity Component System. Je l’utilise car j’en avais vraiment plein les bottes du OOP, et de me trimballer des classes de bases qui sont destiné à devenir énorme ( à moins que vous fassiez de l’héritage multiple), ce qui brise certaine loi http://guillaume.belz.free.fr/doku.php?id=ecs#criteres_de_qualites_et_approches_historiques.
Bon en théorie
Les juges et les lois
Ça m’fait pas peur
C’est mon code ma bataille
Fallait pas qu’il s’en j’aille
Oh oh oh

Donc au pire, pourquoi pas, tout le monde s’en porte bien.

Mais ce qui me dérangeais le plus c’est la maintenabilité du bouzin. J’avais pas envie à mi parcours de devoir me refacto la moitié du code, parce que j’avais pas pensais à X cas. Et étant tout seul, c’est impossible que mon plan UML tienne la route, il faut être honnête.

Donc je suis tombé par hasard sur la méthode ECS et j’en suis ravi pour deux raisons:
– 1 Facile à intégrer en lua/love, qui te laisse beaucoup de liberté (Unity l’a intégrer aussi l’an dernier je crois, ça me ferait presque retourner dessus …)
– 2 Facile à sauvegarder. Je pense que qui conque qui s’est frotté à la sérialisation voit le problème

En gros mes objets ne sont que des données, donc à sauvegarder c’est un pur plaisir. Je veux modifier une fonction dans ma classe personnage entre deux versions? Pas de problème j’ai juste à modifier mon système recharger une donnée même d’une vielle sauvegarde elle sera compatible.

Du coup ECS, remède à tout? Non mais on s’en rapproche 🙂

Un des GROS problème et déjà la visualisation :
pour ceux qui veulent en savoir plus:

et surtout

( des grands malades chez overwatch)

Après le problème de la visualisation, y a un tout petit petit problème c’est la communication entre deux système. Cela est bien détaillé ici https://medium.com/@savas/nomad-game-engine-part-7-the-event-system-45a809ccb68f
pour les amis du C 🙂

Mais c’est un problème que j’avais rencontré avant. C’est le système d’événement. Et c’est le dernier système qui me manque pour commencer l’aventure, donc je vais commencer par introduire mon travail par ce concept.

L’idée est, si un événement « A » apparait, comment « X « objets qui pourrait être intéressé par cet événement soit au courant? Alors je suis pas expert de tous les paradigmes, mais il existe Pub-Sub(Publisher-Subscriber) Design Pattern, qui me convient bien.

Vous pouvez trouver ma libraire ici
https://github.com/ValentinChCloud/event-lua

L’idée est super simple mais diablement efficace.
Imaginons j’ai deux objets A et B . Deux objets avec deux « box collider », qui peuvent se percuter. Ce que j’aimerais c’est que quand A et B se percutent, replacé A et B à une certaine distance l’un de l’autre.

Avant ce que je faisais, c’est dans mon code qui gère la physique

 

if is_collision(object_A, object_B) then
-- Résoudre la collision, object_A.x = object_A.x - 2 par exemple
end

Propre net efficace.
Maintenant j’aimerais que lors d’une collision mes deux objets perdent des points de vie si ils en ont. Ah… Vous le voyez venir le code en spaghetti avec des liens douteux?
Le plus simple serait d’avoir une variable boolean, que vous mettez sur true si collision et qui sera traité bien plus tard.

if is_collision(object_A, object_B) then
-- Résoudre la collision
object_A.has_collide = true
object_B.has_collide = true
end

Le truc bien chiant, et faut être sur que la variable ne sera pas modifié entre temps. Et qui doit être traiter à la fois par votre système de point de vie, qui disons déclenche une animation, donc on doit faire parvenir une autre variable  etc etc …

Dooooonc, après m’être arraché tous les poils de barbes. J’en suis venu à la conclusion qu’il fallait trouvrt autre chose.
Et ce fut le système d’événement . Vous pouvez jeter un coup d’œil à ma libraire, ca sera plus clair je l’espère.

Mais cela colle très bien avec ECS, car finalement quand un événement apparait, tous les systèmes concernés traitent l’événement. Ils peuvent créer un autre événement par dessus, tout ça dans la même frame.

if is_collid(Object_A, Object_B) then

event:publish("collide_event",Object_A,Object_B)

end

Du coup tout le monde peut accéder à cet événement avec ces deux objets. Donc à la suite tous les systèmes vont traiter l’évenement.

 

Donc c’est finalement un tout petit module, mais avec un intérêt colossal, je sais pas comment j’ai pu m’en passer tout ce temps ^^.

 

 

Les autres pierres fondatrices

Avec cet v0.1, plusieurs systèmes sont là, mais rien de transcendant. Mais j’ai maintenant tout ce qu’il faut pouvoir commencer à coder le cœur du jeu en réutilisant ce qui a était fait.

 

Je pense faire le prochain post sur les lumières, un des systèmes majeurs qui est aussi présent pour cette v0.1, pour ce qui ne sont pas inondé par mes messages sur discord, cela donne ça

 

Merci de m’avoir lu, et bon code 🙂

 

Comments (5)

Salut UnRealCloud,

Merci de partager ton enthousiasme avec nous au travers de ton devlog ainsi que les liens vers les vidéos.

Je t’avoue que j’ai eu l’impression d’avoir manqué la saison 1 ;-D en lisant, mais manifestement c’était bien le premier épisode !

Merci d’aller plus doucement si tu veux que l’on arrive à te suivre. Manifestement tu as du vécu en programmation objet, il va falloir que tu te mettes à notre portée sinon on va vite décrocher.

Ce sera donc un challenge supplémentaire.

Bon code à toi.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.