rewind a écrit 3425 commentaires

Tu peux générer un tableau de pointeur vers les composants et les index vers chaque type de composants. Quand un composant est inactif, il est à null. Avec quelques templates bien placés, tout ça peut être calculé à la compilation et bien compact.

Ça me paraît complexe comme tu le dis. Il faut que j'y réfléchisse plus calmement. De toute façon, avec l'implémentation actuelle, ça marche assez bien pour l'instant. J'optimiserai mes structures quand ce sera nécessaire. Dans l'immédiat, je peux remplacer quelques std::set par des std::unordered_set ou des boost::flat_set, ça ne coûte rien.

En effet, selon l'architecture proposée (certes ce n'est qu'un exemple, mais quand même), un Avion ne roule pas. Or, c'est faux. Si on assume qu'un véhicule a forcément des roues, on peut du coup facilement considérer que la classe Véhicule définit une méthode roule() qui peut être abstraite ou non (si on suppose qu'une voiture ne roule pas comme une moto).

C'est un exemple pédagogique. J'aurais pu prendre le traditionnel Forme/Rectangle/Losange avec le Carré qui vient jouer le trouble-fête.

Pour le problème de rendre un véhicule volant, pourquoi ne pas utiliser une interface "Volant" (avec une méthode vole()) qu'implémente chaque classe concernée ? Avion devient un Véhicule (roulant) implémentant l'interface Volant, on a réglé le problème de façon propre.

En C++, il n'y a pas d'interface. Donc tu es obligé dans ce cas de faire de l'héritage multiple. En plus, tu verras en lisant la suite de l'article qu'ici, on va plutôt placer les données au centre du jeu, et pas les comportements (ce qu'est une interface).

Intéressant. Tu enseignes où ? :)

Si tu cliques sur le bon lien dans la dépêche, tu trouveras facilement ;)

Personnellement j'ai l'approche inverse, je pense qu'on devrait penser au jeu vidéo pour les projets, justement parce que les problèmes n'y sont pas spécifiques et qu'on y retrouve pas mal de problèmes qui existent ailleurs. Et en plus de ça, c'est fun, ça motive les étudiants.

Ce n'est pas contradictoire. Je donne déjà pas mal de projet de jeux vidéos pour les projets semestriels au niveau licence 3. Dans mes souvenirs de ces dernières années, mes étudiants ont déjà fait : les Colons de Catane, Doodle Jump, Loups garous de Thiercelieu (sur IRC), Rampart et j'en oublie sans doute un ou deux.

Quand c'est un projet semestriel en binôme, on n'a pas le temps de bien approfondir les choses et donc on reste cantonné à des jeux assez simples. Avec un club, on peut faire un plus gros jeu avec une grosse équipe (ce qui implique l'utilisation de certains outils) et sur toute une année plutôt qu'un semestre.

Ça tombe bien, dès l'introduction je dis : «on va commencer par un peu de technique et parler des systèmes à entités. C'est un nouveau paradigme de programmation»

Après, c'est pas moi qui ai décidé de l'appeler «système à entités». Personnellement, j'aurais trouvé un nom plus rigolo genre «paradigme des petits pois carottes» : pour faire une entité (le plat), on juxtapose plusieurs composants (petits pois et carottes) et on peut en ajouter dynamiquement des composants (steak haché et moutarde) et on a des systèmes (digestifs) qui permettent de transformer tout ça.

C'est exactement ce que j'ai appelé la mauvaise manière d'implémenter les systèmes à entités ;)

Mais oui, on peut faire comme ça. Mais non, je ne ferai pas comme ça.

Sans compter qu'un tableau de composants, et de la composition, pour ma part, c'est différent.

Les entity systems sont une variante du pattern role model!

Ça ressemble mais je pense que ce n'est pas pareil. Déjà dans la présentation, les role model sont présentés comme un pattern orienté objet. Je pense réellement que les systèmes à entités forment un nouveau paradigme, ce n'est pas juste un pattern de plus.

Une remarque à propos de l'implémentation: les "stores" pourraient être optimisés en utilisant des tableaux associatifs moins dynamiques ( http://www.boost.org/doc/libs/1_54_0/doc/html/container/non_standard_containers.html par exemple) puisque avant le lancement du jeu, on connaît tous les composants qu'une entité pourra avoir.

Oui mais pendant le jeu, on va créer et détruire des entités assez souvent, donc il faut voir si le coût d'insertion et de suppression est prohibitif ou pas. Bon, c'est vrai qu'en utilisant std::set, j'ai pris le premier truc qui m'est tombé sous la main et qu'en fait, on n'a pas besoin d'ordre donc un std::unordered_set serait sans doute plus adapté. Après, il y en a plusieurs qui ne jouent pas tous le même rôle donc à voir. C'est vrai qu'à certains endroits en y repensant, on pourrait utiliser autre chose. Je vais y réfléchir ;)

En tant qu'enseignant-chercheur en informatique, je trouve qu'une option jeux vidéos, c'est trop. Et d'ailleurs, j'exècre les formations d'informatique orienté jeux vidéos, ce sont des attrape-nigauds. Parce que finalement, on retrouve dans les jeux vidéos tous les problèmes qu'on a ailleurs, il y en a assez peu qui sont spécifiques aux jeux vidéos. Le jeu vidéo permet en revanche une immersion assez rapide dans la partie «métier», parce qu'en développant un jeu vidéo, on doit forcément s'intéresser à tout un tas d'autres disciplines (comme tu le soulignes), chose qu'on fait rarement normalement.

En revanche, avoir un club gamedev, ça oui, je pense que c'est une bonne idée (et je l'envisage de plus en plus sérieusement pour là où j'enseigne), parce que ça permet un excellent complémente de formation tout en s'amusant et en n'ayant pas la sanction de la note à la fin. Et oui, on peut associer d'autres disciplines : je n'ai qu'à traverser la rue pour être à l'école des beaux arts ;)

N’est-ce pas là le cas typique où il faut appliquer le principe de « composition plutôt qu’héritage » ?

Oui et non. Tu peux regarder What is an entity system framework for game development? qui montre comment on passe d'un truc orienté objet à un système à entité. Au milieu, ça ressemble à «composition plutôt qu'héritage». À mon sens, la simple composition ne suffit pas. À un moment, tu voudras ajouter un composant dynamiquement à ton entité et si tu utilises de la composition, tu ne pourras pas. Par exemple, imagine un composant Lifetime qui dit combien de temps il reste à vivre à une entité. Le héros n'a pas ce composant par défaut. Mais s'il se fait empoisonner, on peut lui ajouter dynamiquement un composant Lifetime et hop, c'est bon.

Mais, effectivement, contrairement au système à entités présenté ici, de par l'essence de la POO, l'accent est toujours mis sur le comportement (les messages), alors que, apparemment, d'après ton article, la programmation des jeux nécessiteraient plus une approche centrée sur les données.

Oui, dans un jeu, l'important, c'est le contenu, et ça paraît assez logique que ça se retrouve dans le paradigme. Disons pour être plus précis que dans la POO, les données et le comportement sont définis au même endroit (dans une classe) alors qu'avec un système à entités, on sépare bien les deux : les données dans les composants, les comportements dans les systèmes. Ce qui permet de décorréler les deux et donc de ne plus subir la hiérarchie de classe comme expliqué au début. Mais du coup, ça donne une plus grande importance aux données, parce qu'on va définir nos entités par leurs composants, donc leurs données, et plus par leur comportement, leurs méthodes.

Du coup les données qu'un système utilise sont prédéfinies au moment de la conception du jeux ?

Oui, il vaut mieux.

Ma question reviens à demander comment on fait de la "généricité" ?

Tout dépend ce que tu appelles de la généricité. Mais je dirais que dans le cadre d'un jeu où tout est à peu près connu et borné, on n'en a pas réellement besoin.

Pour quelles raisons ? Tu connais déjà le langage ? Certaines librairies sont plus faciles d'accès (j'entends dans le choix du système à entités).

Oui je connais déjà le langage, et sa version 2011 est vraiment sympa à utiliser. Dès qu'on commence, on peut difficilement s'en passer. Ensuite, le C++ étant le langage dominant pour les jeux vidéos, il existe tout un tas de bibliothèque plutôt bien foutu pour tout un tas d'usage (j'aurai l'occasion d'en reparler dans les prochains épisodes). Et puis même pour les trucs génériques, il y a du choix genre Boost. Donc, ça ne se discute même pas, je n'ai même pas réfléchi à utiliser un autre langage, c'est C++ et rien d'autre.

Maintenant, pour les systèmes à entités, il existe des implémentations dans plusieurs langages dont Java, ActionScript, Ruby, C#, et sans doute d'autres que je ne connais pas.

Ok, je me suis mal exprimé. Tu dis que 51 ne devraient pas avoir raison contre 49 (ce qui est le cas dans un référundum), ce qui est bien l'argument auquel je répond.

Je suis fondamentalement contre le tirage au sort. Je me demande bien comment cette idée a pu arriver jusque là, c'est vraiment un signe de mauvaise santé de notre démocratie. Pour moi, le tirage au sort, c'est la négation du choix, c'est l'antithèse de la démocratie et de la république.

Ce qui fonde notre démocratie et notre république, c'est que les citoyens choisissent des représentants en fonction de programmes qui auront été débattu auparavant de manière à éclairer leur choix. Ce choix permet de déterminer ce qui est l'intérêt général et les règles en cours font que le choix de 51 l'emporte sur les 49 autres. Je reviendrai dessus après pour Zenitram ;)

Dans le cas d'un tirage au sort, il n'y a plus de choix possible ! Croire qu'il n'y a qu'une seule politique possible, c'est ne rien comprendre à comment fonctionne ce monde : il y a toujours plusieurs choix. Et parfois, comme dans le cas actuel, il y a des décisions importantes à prendre (concernant l'écologie par exemple) qu'on doit prendre mais que certains partis politiques ne proposent tout simplement pas. D'où l'importance du choix. Je refuse de céder ma (maigre) part de souveraineté à un dé. Statistiquement, ça va aller. Sauf que dans le monde réel, il y a la loi de Murphy et qu'on n'est pas à l'abri de tomber sur une assemblée largement dominée par l'extrême-droite, chose impossible avec notre système actuel (même avec une proportionnelle) parce que l'extrême-droite est minoritaire.

Donc, absence de choix et risque de voir des absurdités statistiques : non merci pour le tirage au sort.

Maintenant, pour Zenitram qui répète souvent que la démocratie, c'est la dictature de la majorité, je répond : non. Le fait que 51 l'emporte face à 49, c'est une méthode de décision, pas une méthode de conviction. Ça signifie que les 51 n'ont pas forcément raison (et les exemples historiques ne manquent pas) et ça ne signifie pas que les 49 doivent se flageller et changer d'avis. Ça a des avantages et des inconvénients mais ça me semble être une méthode qui a fait ses preuves sur le long terme. Avoir des majorités qualifiés (genre 2/3) ne change rien au problème des minoritaires.

Il n'est pas au PS, il est apparenté PS. D'ailleurs, je crois me souvenir que le PS avait mis un candidat en face de lui la dernière fois.

Super ! En plus, il y a un installeur et on a accès à tous les outils, c'est chouette :)

Seul petit bug, il y a un "dirname" qui apparaît dans le fichier shell nanimstudio et qui est inutile. Je l'ai enlevé et ça marche bien chez moi. C'est nickel !

Et la capture d'écran n'est plus à jour du coup.

J'essaie d'éviter au maximum d'hardcoder la taille des textures dans le jeu. Généralement, je la récupère dynamiquement (il y a des fonctions pour ça en SDL et en SFML) si j'en ai besoin.

Si c'est bien le cas, c'est super, mais assez restrint, c'est pas tous les jeux où t'as besoin de faire des rotations hein (oui je sais, newton aventures..) et surement pas necessairement besoin d'appliquer la rotation à tous les tiles.

Et bien figure toi que je vais en avoir besoin, et je ne vais pas du tout redévelopper un clone de Newton Adventures. Avec la SDL, je devais faire tous les calculs (et honnêtement, j'étais pas loin de m'y perdre) et là, tout sera géré dans la lib.

Je ne pense pas que cette fonctionalité soit en mesure à elle seule de justifier l'utilisation de telle ou telle librairie, sauf cas particulier d'un jeu bien specifique, sinon c'est anecdotique. à mon sens il y a d'autres bonnes raisons de priviliegier sfml.

Non, c'est sûr que ça ne fait pas la décision. Mais c'est une fonctionnalité appréciable.

Si, je crois qu'il est encore seul. Mais sur le github, il intègre pas mal de pull request venant d'autres développeurs. Et dans le README, il y a un autre nom que le sien pour la partie Mac OS X apparemment.

Ha ben ce petit schéma va bien m'aider pour le rendu. Dans SFML2, l'auteur a pris le parti de ne pas utiliser le système OpenGL en pourcentage mais d'utiliser des pixels (je suppose qu'il calcule le pourcentage après). Du point de vue du développeur, c'est plus facile. De même ici, je vois que l'axe vertical est «inversé» par rapport à la normale, il faudra que j'y prête attention.

Et du coup ça se passe comment quand tu appliques des transfos (rotations, homothétie, … ) sur tes textures ? il faut bien calculer les changements sur les pixels, et comme chaque "objets" contient la même texture il ne faut pas la recharger en mémoire, mais il faut faire appel à plusieurs fonctions (peut être des shaders) à chaque nouvel affichage de cette texture en fonction de sa transformation.

Je connais assez peu OpenGL mais voilà ce que me dit mon intuition.

Déjà avec les VertexArray de SFML2, tu précises pour chaque objet (vertex) des coordonnées sur la texture et des coordonnées sur l'écran (je simplifie, en réalité, c'est un peu plus subtil). Puis, pour l'ensemble, tu spécifies une texture et éventuellement une transformation (mais qui du coup s'applique à tous les objets). Du coup, cette fonctionnalité est assez restreinte mais elle est utile dans certains cas particuliers, dont les tile map. Dans ce cas, tu as bien une seule texture, une seule transformation, et tout un ensemble de petits carrés issue de la texture à mettre sur l'écran. Et avec SFML, tu fais tout ça en une seule opération OpenGL. L'avantage, c'est que tu peux préparer ta struture (tous tes vertices) une seule fois et demander uniquement l'affichage à chaque tour de boucle (avec la transformation appropriée qui peut changer à chaque tour).

Et bien puisque tu le demandes, voilà :

• pour la sauvegarde :
  • ça serait bien qu'il y ait une petite étoile dans le titre de la fenêtre quand on doit sauvegarder
  • ça serait bien de mapper CTRL+S sur la sauvegarde (et du coup, la première fois, il demande le nom du fichier)
• pour l'UI :
  • dans les panneaux "Images" et "Frames" (surtout "Frames" en fait), un petit bouton "Apply" ne serait pas de refus parce qu'on a du mal à savoir si la modification qu'on a faite a été prise en compte ou pas
  • je n'ai pas compris à quoi servait "Format" dans le panneau "Images"
  • je devine à quoi sert (u1,v1) et (u2,v2) (c'est pour sélectionner une partie de l'image, j'ai bon ?) mais je me demande bien quelle est l'unité employée, c'est un pourcentage, c'est ça ?

Voilà, ce n'est pas très important, l'outil est tout à fait utilisable en l'état.

Dans le cas de SDL et de SDL_RenderCopyEx, chaque dessin de tuile se traduit par un appel OpenGL même si toutes les tuiles partagent la même texture. Dans le cas de SFML, si toutes tes tuiles partagent la même texture, tu fais un seul appel OpenGL pour toutes les tuiles.

Ou ma première animation réalisée grâce à ce merveilleux outil qu'est nanimstudio ;)

Pour la première «release» d'une pré-démo version 0.0, j'aimerais bien intégrer les nanim dans le jeu (et comme le format est plutôt bien foutu, ça devrait aller assez bien), ainsi que quelques autres trucs et ensuite, je mets ça en ligne (disons dans deux-trois semaines). J'ai déjà le sprite qui bouge bien dans nanimstudio. Plus qu'à.

Qu'appelle-tu un sur-ensemble de SDL2? La SFML est basée sur OpenGL, pas sur SDL.

En terme de fonctionnalités, pas en terme de comment c'est implémenté. Dans le bout de code que j'ai en SDL, voici ce que j'utilise et l'équivalent en SFML :

• SDL_CreateWindow() : sf::Window
• IMG_Load() + SDL_CreateTextureFromSurface() : sf::Texture
• SDL_RenderClear() + SDL_RenderPresent() : window.clear() + window.display()
• SDL_PollEvent() : window.pollEvent()
• SDL_RenderCopyEx() : sf::Sprite

En fait, le seul truc que je n'ai pas vu côté SFML mais qui existe côté SDL, c'est l'ensemble SDL_SetTextInputRect, SDL_StartTextInput, SDL_StopTextInput.

Bon, résultat des courses, après avoir fait quelques essais avec SFML2, je l'adopte. Les arguments qui m'ont convaincu :

• elle est un poil plus haut niveau que la SDL2 et donc, il y a tout un tas de trucs bien foutus que je ne redévelopperai pas
• comme c'est un surensemble de SDL2, au pire, je peux revenir à SDL2 et redévelopper les bouts qui manquent
• le développement a l'air assez actif, donc je ne suis pas trop inquiet pour la pérennité de la bibliothèque
• tout est intégré de base (graphique, sons, texte, image, réseau) donc pas besoin d'aller voir ailleurs
• le code de la bibliothèque est plutôt bien fait, ce qui fait que je pourrai contribuer si jamais j'ai un souci

En plus, comme il n'y a pas encore de paquet Debian, j'ai du la compiler et l'installer à la main. Et bien, ça a été très vite fait : cmake, make, make install et en moins de 2 minutes, j'avais un truc prêt à l'emploi. Et comme les .pc sont fournis, c'est encore plus facile à intégrer au build system.