« Je crée mon jeu vidéo » est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parle de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.
Dans l'épisode 12, on a parlé des interfaces graphiques et physiques. Dans cet épisode anniversaire, on va faire un premier bilan global de l'état du jeu. Et on discutera aussi d'autres événements liés aux jeux vidéos et qui me concernent et en quoi ça peut aider Akagoria.
Sommaire
Akagoria au bout d'un an
Il y a un an le 16 septembre 2013 était publié le premier épisode de cette série. Et même si Akagoria est né sans doute un peu avant, on peut considérer que sa date de naissance est bien ce premier épisode. Bon, ok, j'ai releasé early, mais pas très often il faut bien l'avouer. Au départ, je me suis donné deux à trois ans pour mener à bien cette aventure. Un an s'est déjà écoulé et je pensais que j'aurais avancé plus que ça. Donc, on va dire plutôt trois ans.
Les réussites
Dans ce qui a bien fonctionné, il y a tout d'abord ces épisodes. Douze épisodes ont été publiés de manière irrégulière mais cela me force à avancer, c'est un motivateur assez puissant. Ils me permettent de partager mes trouvailles, mais aussi de mettre de l'ordre dans mes pensées et de les concrétiser quand il le faut. Et c'est important parce qu'entre une idée dans un TODO et sa réalisation, il y a souvent un delta non négligeable et ça peut prendre plus de temps que prévu. En plus, ces épisodes me permettent de me poser la question : quelle est la prochaine étape ? J'ai à peu près toujours un ou deux épisodes en tête pour le futur quand je publie un nouvel épisode. Là par exemple, je sais ce que sera le prochain, et je sais ce qu'il me reste à faire pour qu'il puisse sortir. Yapluka. Voici donc la liste des douze épisodes pour ceux qui veulent faire du replay :
- E01 : les systèmes à entités (16 sept. 2013)
- E02 : le jeu et ses challenges (26 sept. 2013)
- E03 : la version zéro ! (14 oct. 2013)
- E04 : Paf ! les collisions (29 oct. 2013)
- E05 : de retour de la Paris Games Week (11 nov. 2013)
- E06 : génération procédurale de végétation (24 nov. 2013)
- E07 : cartes, données et systèmes à entités (16 déc. 2013)
- E08 : fiche de lecture de «L'Art du game design» par Jesse Schell (19 jan. 2014)
- E09 : Techniques de C++11 appliquées au système à entités (12 fév. 2014)
- E10 : génération procédurale de carte (partie 1) (07 mars 2014)
- E11 : génération procédurale de carte (partie 2) (28 avril 2014)
- E12 : interfaces physiques et graphiques (20 août 2014)
Je me suis permis de faire quelques statistiques sur ces épisodes. Sur le graphique suivant, on peut voir le nombre de pertinentages et le nombre de commentaires pour chaque épisode. On voit qu'il n'y a pas vraiment de corrélation entre les deux. Les moyennes sont respectivement de 50 et 51 mais cachent en fait de grandes disparités avec quelques épisodes qui font beaucoup monter la moyenne. La leçon de ces chiffres, c'est que ces épisodes vous plaisent et que vous y êtes fidèles.
L'autre réussite de cette première année, c'est d'avoir publié pas mal de code. Je n'avais jamais vraiment publié de code publiquement auparavant et montrer son code au monde entier, ça force vraiment à faire les choses à peu près bien, à mettre de la doc, etc. Je suis plutôt satisfait d'avoir réussi à produire ces codes-sources là. Bien sûr, ils sont perfectibles mais ils permettent déjà d'avoir quelques briques de base. Les bibliothèques notamment sont largement réutilisables par d'autres jeux. Voici les bouts de code produits :
- libes, une bibliothèque pour gérer les systèmes à entités. Cette bibliothèque se stabilise doucement mais sûrement ;
- libtmx, une bibliothèque pour lire le format TMX de Tiled, plutôt stable pour l'instant (en attendant les évolutions du format lors de la prochaine sortie de Tiled) ;
- libsuit, une bibliothèque d'entrées physiques et de widgets, encore en développement et qui suivra les besoins du jeu au fur et à mesure ;
- MapMaker est un logiciel de création de carte d'altitude, dont la partie commune est stable mais dont la partie spécifique à Akagoria est encore en développement, car je ne suis pas encore satisfait de la manière de construire la carte primitive ;
- SlowTree est un logiciel de génération procédurale de sprite en vue de haut, encore en développement car je veux continuer à explorer certaines pistes pour certains types de sprites.
J'en profite pour remercier tous les contributeurs occasionnels à ces projets et particulièrement Sébastion Rombauts qui a contribué à libes et à MapMaker grâce à de nombreux patchs. Grâce à lui, vous aurez une version sans bug du bruit à base de simplexe dont on avait parlé dans l'épisode 10 et qui avait manifestement un bug.
Les difficultés
Dans le moins bon, je n'ai sans doute pas avancé autant que je l'espérais au départ. Dans ma tête, j'étais parti sur un planning de deux ans avec un développement important du code la première année, et un développement du reste ensuite (scénario, dialogues, sprites, musiques, etc). Or, le code est très très loin d'être opérationnel pour commencer à développer activement le reste.
Comment expliquer ce retard ? Tout d'abord, le temps est une denrée très aléatoire quand on développe un jeu amateur. À l'automne dernier, j'ai eu pas mal de temps libre et donc j'en ai beaucoup profité pour avancer sur plein de fronts. Mais à partir de début 2014, j'ai baissé le rythme drastiquement, en partie à cause d'une activité professionnelle plus prenante (y compris sur mes week-ends), en partie parce que j'ai fait un peu de hors pistes en allant explorer des choses complètement inutiles pour mon jeu. Je voyais le temps défiler et j'étais dans l'incapacité d'avancer convenablement. C'était très frustrant.
Retour sur les choix techniques
Au bout d'un an, il est temps de revenir sur les choix techniques faits au départ pour se demander s'ils sont pertinents.
Commençons par le plus simple. Il y a des choix que je ne regrette pas : SFML, Box2D, TMX. Ces trois technologies sont très efficaces et répondent bien au besoin d'un jeu amateur. SFML est une excellente abstraction et, même si on aimerait qu'elle soit un peu plus complète, j'apprécie sa simplicité et sa documentation riche et utile. Box2D est également une excellente bibliothèque, assez simple à prendre en main. On arrive à faire ce qu'on veut, même si parfois on se demande si la manière dont on procède est bien la bonne manière de faire. TMX enfin, avec son éditeur Tiled, est un format qui me donne vraiment entière satisfaction. Sa généricité n'empêche pas qu'on puisse le spécialiser comme on le souhaite via son système de propriétés. En fait, le plus difficile dans ces trois choix est de les faire cohabiter intelligemment.
Finissons par le choix d'utiliser les systèmes à entités. Là, je dois dire qu'au bout d'un an, je reste perplexe. D'un côté, je vois bien que théoriquement, ce paradigme n'offre que des avantages (en particulier dans le style de jeu que je vise). D'un autre côté, dans la pratique, c'est assez complexe. Ce qui est dur, c'est de bien délimiter les systèmes en fonctionnalités et de choisir les bons composants. Qu'est-ce qui relève de l'état du jeu, qu'est-ce qui relève de données statiques ? La frontière est mince et mouvante. Ce qui serait simple, ce serait d'avoir déjà l'ensemble des systèmes et l'ensemble des composants. Construire les bons systèmes et les bons composants quand on part de zéro et qu'on n'a quasiment aucun modèle, c'est très compliqué. Je pense que j'aurais été beaucoup plus vite pour développer mon jeu avec un paradigme objet plus traditionnel. Mais je pense que je vais rester sur les systèmes à entités pour aller jusqu'au bout de l'expérimentation et contruire un jeu complet avec ce paradigme.
Perspectives
Quelles sont les perspectives ? Tout d'abord, il faut que j'arrive à finir le code (ou en tout cas une partie suffisamment importante du code) pour commencer le contenu du jeu. Je pense que je vais passer en mode sale pour le code qui reste à faire. Comprendre par là que je préfère avoir un code qui marche mais pas tout à fait nickel plutôt que d'essayer à tout prix d'avoir un code propre et bien pensé. En un mot : fonctionnalités plutôt que réutilisabilité. J'espère que dans un an, pour le deuxième anniversaire, on y sera.
L'autre point important, c'est d'avancer sur les sprites. Pour l'instant, Naha m'en a fait quelques uns qui sont plutôt réussis. Il va falloir continuer et sans doute accélérer un peu le rythme parce qu'il manque encore beaucoup de choses à ce niveau. J'aimerais pouvoir générer tout un tas de choses sur la carte primitive et qu'on puisse la modifier facilement sans devoir passer du temps à des tâches répétitives. Par exemple, pour définir une forêt, il est plus simple de tenter de la générer (éventuellement en guidant cette génération) plutôt que de placer les arbres un à un.
Ma première GameJam
J'ai participé à ma première game jam au début de l'été. C'était un moment fort enrichissant à plusieurs niveaux. Pour ceux qui ne savent pas ce qu'est une game jam, c'est une sorte de concours en temps limité où le but est de développer un jeu.
Cette game jam, baptisée Game Cancoillote, et organisée par deux de mes étudiants, s'est déroulé fin juin sur un week-end, dans les locaux de l'Université de Franche-Comté. Ils avaient bien fait les choses, on avait une grande salle pour toutes les équipes, et bien sûr à manger et à boire, ce qui a favorisé une excellente ambiance !
Il y avait cinq équipes qui ont utilisé des technologies très différentes. Une équipe a utilisé GameMaker, une autre Java, une autre HTML5/JS, une autre un moteur de jeu propriétaire, et la dernière, la mienne, a utilisé ce bon vieux couple C++/SFML. Même au niveau des concepts de jeu, il y a eu quelques surprises. Celui que j'ai préféré était l'équipe HTML5/JS qui a fait un jeu d'aventure en pointer-et-cliquer. Ils ont imaginé un scénario par rapport au thème de la game jam et ont utilisé l'université comme décor. Ils ont pris des photos panoramiques de divers endroits, ils ont aussi utilisé certaines vues de Google Maps (ouais, problème de copyright toussa). Et ensuite, ils ont incrusté un personnage en dessin. Et bien ça rend plutôt bien.
Pour ma part, j'étais dans une équipe composée de cinq personnes : trois étudiants (la major d'une spécialité de Master, le major et le second de licence 3) et deux profs (une collègue et moi-même). Sur le papier, une très bonne équipe. Deux des étudiants avaient déjà fait un jeu (dont un en projet semestriel avec moi), mais ma collègue était une novice complète. On avait déjà réfléchi à une idée globale de jeu avant la game jam tout en sachant que nous allions devoir nous adapter au thème (non-connu à l'avance) de la game jam. Notre idée était de partir sur le principe de pierre-feuille-ciseaux avec trois machins qui lutteraient les uns contre les autres.
Ce qui est bien, c'est que l'adaptation a été simple. Le thème de la game jam était une équation qui disait en gros qu'il fallait qu'il y ait de la physique dans le jeu et qu'il ne devait pas y avoir de gagnant dans le jeu. Nous avons alors imaginé qu'on pouvait avoir un jeu solo (donc pas de gagnant) où on contrôle une boule représentant une des trois entités et qu'on serait au milieu d'une sorte d'arène en train d'éviter ou de chasser les boules des autres entités qui arriveraient au hasard. Chaque rencontre donnerait lieu à une collision et une réaction : la disparition d'une boule en cas d'entités différentes. Et pour le fun, on a pris une variante japonaise : le guerrier, le tigre et la mère du guerrier. Voilà à quoi ça ressemble :
Au final, ce n'est pas si mal que ça pour le temps imparti. Nous n'avons pas eu trop de difficultés. Nous avons utilisé Box2D pour la physique (même si on aurait pu développer le moteur physique nous-même dans ce cas simple). Les avatars de chaque camp utilisent des photos prises dans la grande toile et j'aimerais bien les modifier pour pouvoir publier le jeu correctement sans avoir de problème de copyright. En revanche, l'illustration en bas à droite est l'œuvre d'une graphiste présente à la gam jam et qui a fait quelques dessins pour toutes les équipes (elle était très demandée).
Pour la beauté du geste, on a même fait un écran d'accueil avec cette même illustration.
Au niveau du nom, nous n'avons pas été très originaux. Une fois que tout sera d'aplomb niveau copyright, j'essaierai d'imaginer un nouveau nom (ou si vous avez des idées, n'hésitez pas à les partager en commentaire).
Un club de développement de jeu vidéo
La grosse nouveauté pour moi cette année, c'est que je lance dans mon université un club de développement de jeux vidéo. Je l'ai baptisé Dead Pixels Society. L'idée est de faire un jeu vidéo sur l'année universitaire avec une équipe d'une dizaine d'étudiants (pas forcément uniquement des informaticiens d'ailleurs) de tous niveaux.
Je ne sais pas ce que ça peut donner, mais j'ai des étudiants déjà très motivés par cette idée. Évidemment, j'espère aussi initier des étudiants complètement novices aux arcanes du développement d'un jeu vidéo. Pour cela, j'ai réalisé quelques fiches sur des aspects techniques basiques d'un jeu vidéo : la boucle de jeu, les systèmes de coordonnées 2D, les couleurs et la transparence, les sprites et animations, les moteurs physiques, etc. L'idée est de faire passer quelques concepts sans entrer dans les détails et sans s'attacher à une technologie en particulier. J'ai encore quelques idées de fiches mais je crois avoir brossé une bonne partie du sujet. Si vous avez des suggestions, n'hésitez pas à m'en faire part en commentaire.
J'aurai sans doute l'occasion de revenir sur les activités de ce club au cours des prochains épisodes ou dans des journaux. Si nous arrivons à enrichir le paysage des jeux libres d'un nouveau jeu par an, je me dis qu'on aura réussi quelque chose de bien. Cette activité parallèle à Akagoria va aussi sans doute me permettre d'avancer sur mon propre jeu. Outre le fait que j'ai maintenant un créneau fixe chaque semaine consacré au développement de jeux vidéo, il y a aussi les idées (et les bouts de code) qui peuvent émerger dans un autre jeu et dont je pourrai me resservir.
Aller plus loin
- Akagoria, la revanche de Kalista (359 clics)
- le tag gamedev (125 clics)
- Dead Pixels Society (174 clics)
# avance ?
Posté par BAud (site web personnel) . Évalué à 4.
cool, article sorti avec une semaine d'avance ;-)
[^] # Re: avance ?
Posté par rewind (Mastodon) . Évalué à 2.
Il n'y a pas de fonction supprimer ?
[^] # Re: avance ?
Posté par grim7reaper . Évalué à 2.
Inutile.
Pour ceux qui l’ont vu passer dans leur RSS, il était toujours accessible via le cache Google.
# entité
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quand tu avais dis que tu séparais données de parti et données statique du jeu, car les entités ne stockaient que "l'état du jeu", j'avais tiqué. Pour moi tu te trompais. L'état du jeu inclus tout. Pour avoir fais plusieurs code, ayant des arbres séparés, à chaque fois la conclusion est : "plus jamais", c'est bien trop chiant de naviguer dans plusieurs arbres à la fois.
Par contre, en cas de sauvegarde/sérialisation, il est inutile de sauver les assets du jeu dans la sauvegarde. Le problème est donc la sauvegarde, pas le fait de savoir quoi mettre dans les entités.
"La première sécurité est la liberté"
[^] # Re: entité
Posté par rewind (Mastodon) . Évalué à 2.
Nous sommes bien d'accord : le problème, c'est bien la sauvegarde. Dans un système à entités, normalement, tu sauvegardes tous tes composants, de manière à retrouver exactement ce que tu avais quand tu as sauvegardé. Les données statiques, pour moi, elles doivent être à part, parce qu'on ne va pas les charger de la même manière ni depuis la même source. Mélanger les deux comporte le risque de complexifier la sauvegarde, ce qui serait un comble vu que c'est un des avantages des systèmes à entités.
Mais je comprends bien ton point de vue, et je mesure la difficulté de tout séparer.
[^] # Re: entité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il n'est pas possible de poser un flag "àsauver" sur les composants ?
"La première sécurité est la liberté"
[^] # Re: entité
Posté par rewind (Mastodon) . Évalué à 3.
Si, mais il faudrait le faire pour tous les composants, et même pour chaque champs de chaque composant. Ou alors, il faut mettre cette logique dans la fonction de sauvegarde qui pourrait avoir cette information mais ça complexifie la sauvegarde. On passe d'un truc simple comme ça :
Et pour le chargement :
À un truc complexe comme ça :
Et la sauvegarde devient aussi plus sportive parce que, pour les champs non-sérialisés, il faut savoir comment les initialiser, et pour les composants non sérialisés, il faut les recréer à partir d'une autre source. Du coup, la procédure est plus complexe, à mon sens.
[^] # Re: entité
Posté par barmic . Évalué à 2.
Personnellement j'aurais plutôt fais :
ou au moins
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: entité
Posté par rewind (Mastodon) . Évalué à 3.
Normalement, un composant n'a aucune méthode, c'est juste une structure de données. Tout ce qui relève du code doit se trouver dans un système (ici, un système qui serait en charge du chargement et de la sauvegarde des données).
[^] # Re: entité
Posté par barmic . Évalué à 5.
AMHA les données statiques devraient juste être gérées un peu différemment histoire de ne pas les dupliquer en mémoire, la donnée dans l'entité c'est une référence vers l'asset et quand tu sauvegarde tu sauvegarde l'identifiant de l'asset. A la désserialisation, tu recharge l'asset si ça n'est pas déjà fait et tu crée une référence dessus. Ça ne me paraît pas fortement complexifier la sauvegarde et ça permet de garder la souplesse des systèmes à entité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: entité
Posté par rewind (Mastodon) . Évalué à 3.
Oui, c'est un peu l'idée que j'avais en tête. Mais ce n'est parfois pas si simple. L'exemple que j'ai en tête et qui m'a causé beaucoup de souci, c'est la carte. C'est typiquement un truc statique donc chargé à part. Mais elle a des interactions avec des entités, par exemple pour les collisions. Un arbre sur la carte, il n'a pas d'état dans le jeu mais il a un corps qui apparaît dans le moteur physique. De même, le fond de carte. Au début, j'avais une entité pour chaque tuile et du coup, j'affichais tout avec le système en charge de l'affichage. Grosse erreur ! Les tuiles ne font pas partie de l'état du jeu ! Mais il faut quand même bien les afficher. Donc c'est le système en charge de l'affichage qui affiche la carte, puis toutes les entités qui ont le composant qui va bien pour être affichées, comme le héros par exemple. Et dans le cas du héros, le sprite fait bien partie de l'état du jeu, parce qu'il peut changer en fonction de l'animation. Bref, quand je dis que la frontière est floue entre les deux, je parle de ça.
[^] # Re: entité
Posté par barmic . Évalué à 5.
Pourquoi ? Tu as déjà joué à worms ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: entité
Posté par rewind (Mastodon) . Évalué à 4.
Voir la réponse en bas. Dans mon cas, ça ne change pas pour l'instant, donc c'est statique. Il est évident que pour worms, ça changerait donc ça serait à mettre dans un composant.
# Système à entité
Posté par barmic . Évalué à 5.
D'abord merci pour tes 13 dépêches très intéressantes. Certaines m'ont plus intéressées que d'autres parce que je ne suis pas très jeux vidéos, mais elles étaient toutes très bien écrites. Je pense que tu as fais découvrir à beaucoup de gens ce qu'est un système à entité (moi inclut !).
Justement j'ai une question sur les systèmes à entité. Je pense avoir bien compris le découpage système/entité/composants, mais je me demande comment faire des systèmes multi-entités. Pour du jeu vidéo c'est par exemple comment limiter le nombre d'unités ou gérer des collisions. Est-ce qu'il faut créer des composants qui pointent sur des entités (par exemple une entité stat qui connaît la liste des entités unités) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 3.
Alors, je ne suis pas sûr de bien comprendre la question, mais je vais essayer de répondre.
Si la question est : est-ce qu'une entité peut «pointer» vers d'autres entités, la réponse est oui. Comme exemple, on peut imaginer une entité «Besace du guerrier» qui a un composant
Containerqui contient un tableau d'entités (le contenu de la besace). C'est comme avec des pointeurs sauf qu'on utilise ici les entités qui ne sont que de simples identifiants. L'avantage, c'est que ça se sérialise très bien.Après, pour les collisions par exemple, c'est un peu plus complexe, et ça ramène à la discussion du dessus. Dans l'idéal, le système qui gère les collisions n'a pas besoin de pointer sur les entités directement, il peut être assez autonome. Pourquoi ? Parce que l'état d'une entité par rapport aux collisions, c'est sa position et sa vitesse. En particulier, toutes les données physiques (formes, caractéristiques) sont des données statiques. Quand on modifie la vitesse (ou la position), on prévient le moteur physique, puis au moment où le système qui contient le moteur physique se met à jour, il fait sa petite simulation. Et à la fin, on met à jour les positions et les vitesses de toutes les entités. C'est une vision simplifiée mais ça donne une idée. Le moteur physique fait ses simulations dans son coin et le système se charge de faire la passerelle entre les entités et le moteur physique.
[^] # Re: Système à entité
Posté par barmic . Évalué à 2.
C'était ma question :)
Je suis pas d'accord avec ça. Tu peut vouloir gérer plus de choses. Le poids et la forme peuvent très bien évoluer, c'est justement ce que tu expliquait l'an dernier avec les balles qui acceptent des inputs. Tu crée des contraintes avec ces données statiques (qui peuvent potentiellement nuire à l'évolution du jeu).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
J'aurais dû dire «sont des données statiques pour l'instant». Mais tu as entièrement raison. Le truc, c'est de savoir ce qui va évoluer au cours du jeu ou pas. Si ça bouge, alors on le met dans un composant, sinon c'est une donnée statique. Et une donnée peut passer d'une catégorie à l'autre et dans ce cas, il faut modifier le ou les composants adéquats.
[^] # Re: Système à entité
Posté par pepp . Évalué à 2.
Je ne comprends pas trop pourquoi tu t'embêtes à essayer de séparer arbitrairement ce qui est statique du reste. Le fait que la masse ne change pas n'est pas lié au fait que la propriété 'masse' appartienne au composant 'physique'.
La logique que j'utilise pour mes composants c'est simplement d'y mettre toutes les entrées/sorties d'un système - au moins on voit clairement ce que manipule un système. J'y stocke aussi les états intermédiaires quand ils sont nécessaires au fonctionnement du système (par ex, le temps écoulé pour un système qui gère du morphing).
Ensuite pour la sauvegarde/restauration, ne sont sauvées que les variables d'entrées/sorties (les autres pouvant être recalculées).
[^] # Re: Système à entité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'imagine que ce qu'il peut y avoir une série d'entité (statique) issue de fichier de configuration, et d'autre de la sauvegarde du jeu.
"La première sécurité est la liberté"
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Ce n'est pas arbitraire, ça a du sens du point de vue de l'application globale et d'un jeu en particulier.
Si. La question c'est : «est-ce que tu vas devoir sauvegarder la masse parce qu'elle change pour chaque entité ou est-ce que l'information de masse va venir d'un fichier de config pour toutes les entités ?» Dans le premier cas, il faut la mettre directement dans le composant, dans le second, elle est dans un fichier de config. Ça change la manière de charger et de sauvegarder si on est dans un cas ou dans l'autre. Et après, tu as l'intermédiaire, c'est-à-dire qu'un type d'entités peut partager un ensemble de configurations possibles que tu vas identifier dans un composant (avec un enum ou un entier par exemple).
C'est ce que je fais aussi, mais par exemple, mettre tous les tuiles du fond de cartes dans des composants, c'est con. Outre le fait que c'est sous-optimal pour plein de raisons, ça n'a rien à faire là. Et pourtant, le système qui gère l'affichage, il mange des composants avec des sprites donc il pourrait manger des tuiles.
[^] # Re: Système à entité
Posté par pepp . Évalué à 1.
Je veux bien savoir lequel ?
Ben, tu peux aussi définir tes entités dans un fichier texte - c'est comme un fichier de config sauf que tu n'as pas de cas particulier : un composant = toutes les données nécessaires au système.
Vu d'ici je dirais :
* une entité avec un composant d'affichage pour afficher le fond de cartes
* N entités avec les composants de gameplay pour les tuiles qui en ont besoin (et en option un composant d'affichage)
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Il s'agit simplement de mieux modéliser ton application et de mieux comprendre les interactions entre les différentes parties. Si tu comprends mieux ce que tu fais, tu mieux utiliser des paradigmes plus fins et donc plus optimisés.
Tu peux. Mais ce n'est sans doute pas la meilleure façon de faire, à mon avis.
Ton entité pour le fond de carte, elle ne te sert à rien. Parce que tu ne vas pas la sauvegarder, donc tu vas devoir la traiter de manière particulière parmi toutes les entités. Donc tu crées une exception pour rien puisque tu pourrais traiter le fond de carte à part et traiter toutes les entités de la même manière (on sauvegarde toutes les entités sans exception). Je ne vois pas l'intérêt.
[^] # Re: Système à entité
Posté par pepp . Évalué à 2.
Tu ne réponds pas à ma question. Je me doute bien que tu le fais pour une raison, mais je ne comprends pas laquelle.
Un brin affirmatif comme réponse. Je trouve au contraire qu'un fichier texte c'est un compromis intéressant : plus souple qu'avec du code/binaire mais un peu moins rapide.
Elle sert à afficher la carte. Ça parait déjà pas mal.
Ensuite je pense que les problématiques de sauvegarde sont secondaires : quelle est le problème de sauvegarder une entité statique ? Si c'est la taille du fichier de sauvegarde, n'importe quel algo de compression te ferait gagner beaucoup.
Et justement non, utiliser une entité pour afficher le fond de carte ne crée pas d'exception : tout ce qui est visible est une entité avec un composant Affichage.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Pour l'instant, l'avantage énorme que je vois, c'est que la sauvegarde est triviale à faire si tu as bien séparé avant.
Oui mais ça veut dire que tu sauvegardes plein de choses inutiles. Si je pousse le raisonnement à l'extrême, tu vas te retrouver à sauvegarder tous les assets du jeu.
Ce qui est le plus difficile, ce n'est pas d'afficher un truc, c'est de faire une sauvegarde du jeu.
[^] # Re: Système à entité
Posté par bagage . Évalué à 0.
Tu ne sais pas faire la différence entre valeur et pointeur ? À l'extrême, tu vas sauvegarder le nom de l'asset utilisé par l'entité, pas l'asset lui même (qui se trouve déjà dans les ressources de ton jeu). Pousser un raisonnement à l’extrême OK, mais faut un minimum qu'il tienne la route si tu veux convaincre.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
OK, prenons une carte à base de tuiles. Pour l'instant, j'ai généré des cartes de taille 512x512 (mais la carte finale sera sans doute plus grande). Pour chaque tuile, tu as besoin des informations suivants : quel est le tileset (je te le fais à un entier, un indice dans un tableau de tileset), et les coordonnées sur ce tileset (deux entiers). Donc trois entiers par tuiles. Mettons que tu optimises le codage et tu t'en sors à 64 bits, donc 8 octets. Tu en as pour 2Mio pour toutes tes tuiles. Tu les mets dans ta sauvegarde ou pas ? Non, bien sûr. Est-ce utile de les mettre dans des composants ? Et bien pour mon jeu, absolument pas. Aucun intérêt. Je peux gérer ma carte à part sans problème (et même ça m'apporte des avantages parce que je peux dessiner les couches dans l'ordre que je souhaite et de manière optimisée).
[^] # Re: Système à entité
Posté par bagage . Évalué à 1.
Et comment restitue ta carte au prochain chargement de ta sauvegarde, si elle n'est pas contenue dans la sauvegarde ? Il y a un moment où si tu veux garder la cohérence de ton monde (le personnage était à la tuile X,Y, etc.), il faut aussi que le monde (== la carte) soit restauré. Qui dit restauré … dit sauvegarde ?
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Non. Elle vient d'une autre source que la sauvegarde, justement. C'est ce que j'ai appelé des données statiques. En l'occurrence, la carte, elle est chargée à partir d'un fichier TMX qui n'existe qu'en un seul exemplaire (et pas un par sauvegarde).
[^] # Re: Système à entité
Posté par pepp . Évalué à 1.
Donc si j'ai bien compris, ces questions de statique/dynamique/config/entité/etc te bloque au niveau architecture :
Supprimer cette séparation arbitraire (statique = config, dynamique = entité) te faciliterait la vie selon moi, mais apparemment tu y tiens pour la sauvegarde.
Du coup, je vais poser une question plus directe sans suggestion de réponse pour te laisser élaborer : quel est le problème que tu essayes de résoudre par rapport à la sauvegarde ?
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Non, ça ne me bloque pas, ça me force à penser correctement.
Que la sauvegarde et surtout le chargement soit facile. J'ai un jeu qui va nécessiter de sauvegarder tout un tas de trucs (où en est le perso dans la quête X, quels sont les objets laissés sur place que le perso peut vouloir récupérer plus tard, …) et avoir un système de sauvegarde/chargement facile va aider énormément plutôt que de devoir faire le travail de savoir ce qu'il est nécessaire de sauvegarder ou pas suivant chaque entité et composant.
Les systèmes à entités permettent une sauvegarde facile si on fait attention, pourquoi je me priverais de cet avantage en dérogeant du paradigme parce que ça a l'air plus facile ?
[^] # Re: Système à entité
Posté par pepp . Évalué à 5.
Bon ok, on ne voit pas du tout les choses sous le même angle.
Mon point de vue (éprouvé sur quelques jeux finis, c'est pas uniquement de la théorie) : tout est entité. Oui le fond de carte est une entité, les éléments de l'interface, etc. Et charge au code qui crée ces entités de spécifier s'il désire les voire sauvegardée ou s'il les recréera tout seul.
De ton côté si j'ai bien saisi, l'importance c'est d'avoir une sauvegarde/chargement facile.
De là à affirmer que "tu penses correctement" (ce qui sous-entend quand même que moi non) et que "tu ne déroges pas du paradigme" (avec le même sous-entendu) me semble quand même un brin culotté - j'attendrai de pouvoir ton jeu (fini) pour voir si tu as raison.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Je ne prétends pas détenir la vérité absolue. J'essaie de pousser un concept au bout. Et le concept, il ne vient pas de moi, il a été décrit par d'autres et j'essaie de m'y tenir. Je ne doute absolument pas qu'on puisse faire autrement et que ça marche. Et je ne doute pas qu'il existe de multiples variantes qui fonctionnent également.
[^] # Re: Système à entité
Posté par pepp . Évalué à 2. Dernière modification le 17 septembre 2014 à 20:08.
Je veux bien des liens vers ces autres, histoire de comprendre leur démarche.
De mon côté l'inspiration principale c'est cette série d'articles.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Tout à fait, ça fait partie des liens que j'ai donné au premier épisode. Mais on n'a sans doute pas la même lecture de ces articles. Et on ne fait peut-être pas les mêmes types de jeu.
Il y a aussi cet article de Richard Lord qui se réfère aussi à ces articles et qui dit :
Si je ne m'abuse, c'est plus ou moins ce que je m'évertue à dire depuis le début.
[^] # Re: Système à entité
Posté par pepp . Évalué à 2.
On ne doit pas avoir la même lecture en effet :-)
Pour rejoindre le thread plus bas, je n'ai jamais lu :
Mais bon, tant mieux si ça fonctionne pour toi comme ça - mes questions étaient surtout destinés à voir si tes réponses allaient me faire changer ma manière de faire. Pour l'instant je ne suis pas convaincu, donc je reste sur mon plan : tout est entité (même le fond de carte :p)
[^] # Re: Système à entité
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Surtout que les données statiques peuvent être vu comme une sauvegarde d'une partie des entités, et ensuite on peut charger la sauvegarde qui référence les entités "statiques".
"La première sécurité est la liberté"
[^] # Re: Système à entité
Posté par barmic . Évalué à 4.
Ce qui me surprends dans ta démarche c'est que :
De plus la complexité ne me paraît pas si démesurée, un système par type de composants à sauvegarder.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
J'essaie d'épurer le concept, d'en tirer la substantifique moelle. Je ne pense perdre aucun avantage pour l'instant, mais j'explore une façon de faire qui pourrait au contraire offrir plus de clarté et de possibilités. Je ne dis pas que ça va réussir et que c'est la bonne manière de faire. Peut-être que je vais me planter complètement, mais je pense que ça vaut le coup d'essayer. Et pour l'instant, comme je l'ai dit, je suis mitigé. Dans cette optique, je réfléchis beaucoup aux liens entre les systèmes à entités et la gestion des événements qu'on retrouve dans quasi toutes les implémentations, y compris la mienne. Je me dis que ce n'est pas un hasard, il y a quelque chose à creuser, quelque chose de plus profond que «on ne peut pas tout faire avec un système à entités».
Un RPG sans sauvegarde, comment dire… Pour beaucoup de jeux, c'est effectivement soit inutile, soit trivial. Pour un RPG, ça ne l'est pas et c'est même assez central, ça fait aussi parti du gameplay (sauvegarde possible tout le temps ou sur un point de sauvegarde ? ça change la physionomie du jeu). Ce n'est pas la vitesse de sauvegarde qui m'intéresse (si ça met 0.1s ou 2s, ça ne me fait ni chaud ni froid), mais savoir quoi sauvegarder et réfléchir aux liens avec les systèmes à entités.
[^] # Re: Système à entité
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Pourquoi?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Système à entité
Posté par rewind (Mastodon) . Évalué à 2.
Ben par définition des composants. Après, j'essaie de creuser les concepts, donc je tâtonne, ce n'est pas toujours évident.
# Page de DPS
Posté par reynum (site web personnel) . Évalué à 3.
Vraiment pas mal la page et surtout les liens qu'on y trouve. C'est chouette l'idée d'option jeu vidéo à l'université.
Bon courage pour la suite, ça fait un bout de temps que je n'ai pas compilé Akagoria quand j'aurais re-déménagé je me remettrais à faire des tests ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: Page de DPS
Posté par rewind (Mastodon) . Évalué à 4.
Ce n'est pas vraiment une option, c'est un club, donc pas de notes, pas de pression, juste du plaisir. Mais ça fonctionne très bien, mieux qu'espéré ! On attendait entre 15 et 20 étudiants, et on en a plus de 60. Du coup, on va lancer 5 projets de jeu vidéo !
Prends ton temps, il n'y a pas eu de changement sur Akagoria depuis un moment.
[^] # Re: Page de DPS
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Faites du bon suivi, VLC a commencé comme ça.
"La première sécurité est la liberté"
[^] # Re: Page de DPS
Posté par rewind (Mastodon) . Évalué à 3.
Ouais enfin, déjà avoir des jeux jouables à la fin, ça sera une bonne nouvelle. C'est l'objectif : finir les jeux. Après, si les jeux vivent leur propre vie, très bien. Si les étudiants veulent l'améliorer l'année suivante, pourquoi pas. Bref, on va avancer et voir ce qui se passe.
[^] # Re: Page de DPS
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
VLC était tenu par une association de centrale. Cela fait un suivi sur le long terme. Cela évite le truc pas fini.
"La première sécurité est la liberté"
[^] # Re: Page de DPS
Posté par barmic . Évalué à 4.
Attention à la licence !
N'hésite surtout pas à nous faire part de ce qui sortira de la Dead Pixel Society, des fois qu'un jeu intéressant mais abandonné par les étudiants soit repris par une communauté ou que le fait de voir que son jeu est appréciés par d'autres pousse les étudiants à continuer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Page de DPS
Posté par rewind (Mastodon) . Évalué à 6.
Ils ont eu droit à une mini-formation sur ça à la première séance (dispo sur le site) ! Après, je vais veiller à ce que tout soit carrés à ce niveau là.
On a fixé les projets mardi dernier, ça s'annonce bien, les étudiants sont motivés. J'espère que les 5 projets arriveront au bout (et je vais tout faire pour ça). Et oui, j'en reparlerai parce que c'est une expérience très intéressante, même humainement.
[^] # Re: Page de DPS
Posté par BAud (site web personnel) . Évalué à 1.
url ?
ça n'a l'air de rien, mais mettre tout le monde d'accord sur une licence libre est important, cela devrait être fait au départ (même si c'est un peu pénible, cela fait partie du jeu…).
Pour aller plus loin : http://faq.tuxfamily.org/CommunicationLibreGame/Fr (commentaires les bienvenus, il y a quelques poncifs assénés, pouvant demander quelques détails même si c'est complet pour le domaine).
[^] # Re: Page de DPS
Posté par rewind (Mastodon) . Évalué à 2.
ici
Entièrement d'accord.
Je vais mettre un lien sur cette page depuis le site du club, ça peut servir ;)
[^] # Re: Page de DPS
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 20 septembre 2014 à 09:18.
excellent ta présentation, clair et synthétique en 2 pages !
Pour la peine, j'ai rajouté un lien sur http://faq.tuxfamily.org/CommunicationLibreGame/Fr#Le_choix_d.27une_licence
Sinon, au besoin nous avons une plateforme d'hébergement de jeux dans une VM Linux : http://faq.tuxfamily.org/Games/Fr cela est un peu auto-géré et fonctionne la plupart du temps :-)
[^] # Re: Page de DPS
Posté par rewind (Mastodon) . Évalué à 3.
Il manquerait presque une page expliquant ce qu'est une licence logicielle (pour faire le lien entre les deux premières pages).
[^] # Re: Page de DPS
Posté par BAud (site web personnel) . Évalué à 2.
oui, éventuellement ;-) au passage cela permettrait de glisser que c'est plus simple dans le libre que avec du propriétaire, vu qu'il y a des licences clairement identifiées et octroyant des libertés, plutôt que toutes les clauses, dont certaines léonines, que l'on peut trouver dans les CLUF, à vous dégoûter de tout jeu fraîchement acheté légalement…
# Système à entités et interface avec des librairies existantes
Posté par Pazns . Évalué à 1.
Bonjour ! Je m'adresse ici notamment à @rewind , mais évidement tout le monde est invité à m'éclairer =) .
Je m'intéresse en ce moment aux systèmes à entités, et je me heurte à plusieurs problèmes que je ne me souviens pas avoir vu évoqués dans ces articles de ce journal de bord sur Akagoria.
Il est probable que j'ai mal compris certains aspects d'un système à entités =P
Je rajoute que je conçois le système à entités moi-même, pour pouvoir mieux en comprendre les mécanismes.
En premier lieu, comment gérer la surcouche "matérielle" entre les composants de son propre système à entités et une bibliothèque externe ?
Dans mon cas, j'utilise Ogre3D, moteur de rendu 3D.
Voici un exemple :
Un SceneNode (un nœud dans l'espace) et une Entity (comportant notamment texture et mesh) sont produits à partir d'un SceneManager, d'une part.
D'autre part, on aura besoin d'effectuer une opération du type "sceneNode.attach(entity)" pour reproduire correctement les mouvements du nœud sur l'entité graphique.
On doit pouvoir également attacher des nœuds entre eux.
La relation de dépendance entre la composante spatiale et la composante graphique est nette, tout comme la dépendance entre ces deux-là est le SceneManager, et enfin celle possible entre deux nœuds.
Cependant, ça parait un peu étrange de fusionner ainsi deux composantes assez différentes dans le principe. Par exemple on aura à modifier l'animation actuelle d'une entité graphique, sans avoir à s'occuper de son nœud spatial.
On peut aussi imaginer le cas d'un objet intangible mais situé dans l'espace (une zone, par exemple) qui n'a aucune utilité d'informations graphiques ou physiques.
Est-ce que je prends le problème de travers et devrais fusionner ces deux objets ?
J'ai l'impression que rapidement je finirais par obtenir un énorme composant "OgreComponent" avec tout dedans. Après tout pourquoi pas…
Mais même ainsi je n'échappe pas au problème de l'antériorité, ou dépendance logique en d'autres mots. Comme suit :
Une boite de collision produite par la bibliothèque Bullet (moteur physique) n'a a priori pas de sens si elle est un composant d'une entité qui ne comporte pas de composant avec des coordonnées spatiales, donc qui n'existe pas de façon tangible. Ce serait comme essayer d'appliquer la gravitation à une quête.
Peut-on ignorer ce cas de figure, ou est-il raisonnable de penser qu'un composant doit être accompagner d'informations d'antériorité qui doivent être satisfaits pour permettre son existence ? Est-ce hors-sujet pour un système à entités ?
On a pourtant bien ce genre d'informations dans les systèmes, dans le prototype : la liste des composants qu'une entité doit avoir pour être traitable par ce système. Et donc également dans les composants et les entités, puisque ceux-ci sont donc typés (dans mon cas c'est un typage à l’exécution, manuel à base de std::string).
Enfin, dernier thème, toujours au sujet des composants :
J'illustrerai ce chapitre avec ma preuve de fonctionnement que voici :
J'ai 400 petits cubes sur un même plan horizontal, en un quadrillage carré. Sont appliqués deux traitements : le rendu graphique, et une oscillation verticale décrivant une onde sinusoïdale.
(Pratique pour tester la solidité du programme en augmentant fortement la quantité de cubes, par exemple.)
On sait que le traitement pour le sinus est dans un système des dizaines de fois par seconde.
Mais qui doit s'occuper de la "préparation" de ces cubes, c'est-à-dire notamment créer les objets Ogre à l'intérieur, puis placer correctement tous les cubes selon une scène pré-déterminée d'un fichier de sauvegarde ?
Qui doit s'occuper du nettoyage lorsque les composants seront déconstruits (fuite mémoire, notamment) ?
Si un composant n'est qu'une structure de donnée sans logique (dans la limite du C++), qui doit s'occuper de ce genre de traitements préparatoires et terminaux ?
Un système ? Mais qui l'appellera et quand ? A priori on ne peut pas insérer pareil système préparatoire dans le circuit de la boucle infinie de l'application.
Par extension, c'est tout le thème du "traitement ponctuel" qui est en jeu.
Mettons que deux objets qui réagissent l'un avec l'autre se rencontrent (de l'eau + du feu = de la vapeur).
Comment implémenter ce genre de traitement de façon efficace ?
Un système qui parcourt l'intégralité des objets du jeu pour effectuer un calcul de proximité, ça serait a priori très lent.
J'ai sans doute dû omettre un point important dans le thème de la communication entre éléments d'un système à entités, je suppose.
J'ai du mal à voir comment implémenter le concept de "chose à faire ponctuellement".
Comment dire à un système de modifier un composant *précis *de telle manière *une seule fois ?
Je sais que cela fait beaucoup pour un seul message, mais ces questions me tournent dans la tête depuis un moment déjà, cela devient quelque peu fatiguant =P
Cordialement.
[^] # Re: Système à entités et interface avec des librairies existantes
Posté par rewind (Mastodon) . Évalué à 2.
En préliminaire à ces nombreuses questions, je pense qu'il y a une erreur à ne pas commettre : faire rentrer tout dans un système à entité. Et plus particulièrement, je pense qu'il n'est pas possible (ou souhaitable) d'utiliser un système à entité en conjonction avec un moteur de jeu. Parce qu'un moteur de jeu impose souvent une manière de faire qui n'est pas celle des systèmes à entités. Il existe des moteurs de jeu fondés sur les systèmes à entités (comme Unity), et ceux-ci utilisent le concept pleinement. Dans le cas d'Ogre, je crois qu'il va être difficile de le faire entrer dans un système à entité. Ou alors, il faut reprendre quelques classes de bases et refaire les classes haut niveau avec un système à entité, mais tu vas te retrouver à dupliquer du code existant par ailleurs.
Ceci étant dit, je vais essayer de répondre à tes questions.
Comme indiqué, c'est difficile voire non-souhaitable de le faire, à partir du moment où la bibliothèque externe est assez haut niveau (comme un moteur de jeu complet). En revanche, pour des bibliothèques bas niveau (comme les moteurs physiques, ou les bibliothèques multimédias), c'est un travail d'encapsulation assez classique.
Tu prends le problème à l'envers. Il est compliqué de faire rentrer un cube dans un cercle.
Alors là, je vais te citer un passage d'un article de référence qui dit : «Do Cameras shoot people? Do Bullets accept input from the player? No?» Et en fait, la réponse peut être oui. Donc en gros, les systèmes à entités permettent d'appliquer n'importe quel comportement à n'importe quel entité. Donc pourquoi pas appliquer la gravitation à une quête ? (Bon, ok, dans ton cas, je ne vois pas bien ce que ça voudrait dire). Mais plus concrètement, un object qui a une position n'a pas toujours un corps physique, mais l'inverse n'est pas vrai. Donc évidemment, si une entité a un corps physique, elle doit avoir une position. Et oui, tu peux faire cette supposition. Comme tu le soulignes après, un système n'agit pas sur n'importe quelle entité, il prend en compte le fait qu'une entité possède ou pas un certain nombre de composants.
Ça peut être un système, ça peut être à l'initialisation. Généralement, le mot-clef qui va avec ce genre de chose pour les systèmes à entités, c'est «archétype». Un archétype, c'est une fonction qui va générer une entité d'un certain type en lui ajoutant tous les composants qui vont bien. Ces archétypes peuvent être appelé de n'importe où, y compris depuis un système (puisque c'est là que se situe tout le code). Après, la manière dont est créé l'entité dépend du type d'entité. Oui, il faudra peut-être aller lire un fichier de configuration, ça ne change pas grand chose.
On a vu la naissance, maintenant la fin de vie. C'est un problème différent. Et oui, on peut tout à fait gérer cette fin de vie avec un système spécifique. Dans le tutoriel que j'avais écrit, ça faisait partie des exercices laissés au lecteur. Je conseillais d'ajouter un composant
Lifetimeavec un booléen indiquant si l'entité est en vie et une fonction à appeler pour détruire l'entité (la fonction inverse de l'archétype). Avec ce composant, on crée un système qui va s'occuper des entités qui possède ce composant. Et à chaque tour, il va appeler les fonctions de destruction sur les entités qui ne sont plus en vie. Après, les autres systèmes vont se contenter d'ajouter un composantLifetimeà une entité s'ils veulent la voir mourir, ou alors il vont positionner le booléen de telle sorte qu'elle meure (cette deuxième possibilité est intéressante dans le cas d'une entité à durée de vie limitée mais dont on connaît la durée de vie à l'avance).Personnellement, dans ce cas, je ferais appel au moteur physique. C'est lui qui gère les interactions entre entités avec un corps physique. Il sait le faire de façon efficace et normalement, il prévient quand il y a une collision (c'est le cas de Box2D en tout cas).
Là, le problème est un peu plus large. Et là, ma réponse, c'est que dans toutes les implémentations des systèmes à entités, il y a un systèmes d'événements en parallèle. Ce système d'événements sert justement à «faire une chose ponctuellement». Un système peut alors déclencher un événement et ceux qui sont intéressés par cet événement peuvent alors agir en conséquence.
[^] # Re: Système à entités et interface avec des librairies existantes
Posté par Pazns . Évalué à 0.
Merci de cette réponse.
Je vais essayer de creuser un peu plus dans ces voies.
Par contre, une chose :
Ogre3D n'est pas un moteur de jeu !
C'est seulement un moteur de rendu 3D, certes complexe et d'une certaine lourdeur. Il est impossible de faire un jeu uniquement avec lui.
La "difficulté" à le relier à un système à entités vient du fait que par sa nature même il impose une certaine organisation des données autour du spatial et du graphique, inévitablement.
Par contre, maintenant que j'y pense, Ogre 2.0 (à venir d'ici 6 mois, je suppose ; il semble y avoir pénurie de développeurs sur le projet Ogre3D, c'est un peu triste) devrait changer la conception de certaines briques importantes, donc le SceneManager. Je ferais mieux d'y jeter un coup d'œil avant de continuer, du coup.
[^] # Re: Système à entités et interface avec des librairies existantes
Posté par rewind (Mastodon) . Évalué à 2.
Oui, il me semble avoir entendu dire qu'il y avait un gros refactoring sur Ogre pour le faire plus Data Oriented, ce qui pour le coup, faciliterait grandement son utilisation dans un système à entités.
[^] # Re: Système à entités et interface avec des librairies existantes
Posté par Pazns . Évalué à 1.
À noter que cette version 2.0 est d'ailleurs normalement déjà disponible et fonctionne, même si à considérer comme instable. Le principal reste maintenant des bugfixes à ce que j'ai compris.
Je verrai bien ce qu'il en est.
# Remerciements
Posté par Sébastien Rombauts . Évalué à 2.
Je prends enfin le temps de réagir à cet article…
Un grand merci à nouveau de prendre tout ce temps pour partager avec nous cette aventure, technique et humaine !
Je pense que tous ceux qui ont un jour essayé de faire leur propre jeux vidéo (ou projet informatique perso) doivent se retrouver dans tes réflexions sur la motivation, le temps qui file toujours plus vite, le fait de passer un temps fou sur les détails ou les sujets périphériques ou connexes… En tout cas je m'y retrouve à 100%
Merci aussi de toujours sourcer autant tes articles… et merci de m'avoir citer ; c'est (étonnamment ?) toujours très motivant d'être remercié, surtout dans le domaine du développement open source.
À ce sujet, je note une petite faute sur mon prénom ;)
[^] # Re: Remerciements
Posté par rewind (Mastodon) . Évalué à 2.
C'est aussi la seule chose qu'on peut faire en remerciement du temps consacré. Et ça me paraît tout à fait normal de citer ceux qui contribuent.
Ha oui, il va falloir attendre qu'un modéro repasse dans le coin (mais c'est pas gagné, la news a maintenant un certain âge).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.