rewind a écrit 3442 commentaires

Merci pour ces précieux conseils que j'avais déjà lus sur plein de sites et que j'avais bien notés. L'un des sites disait (et je trouvais ça fort pertinent) que la qualité première d'un développeur de jeu, c'était de finir le jeu. Et comme je me connais, j'ai lu tout ce qu'il y avait autour (et qui recoupe complètement ce que tu dis).

Ce que tu décris, c'est ta version finale (1.0). Je vais être clair tout de suite: Tout seul, sans expérience dans le dev de jeux vidéo, tu n'atteindra jamais cette version avant de longues années.

Ça tombe bien, j'ai pas prévu de finir en quelques mois. Je me donne deux à trois ans. Et pas pour faire un truc super, juste un truc de base à peu près jouable. Du coup, je me prépare pour un effort de moyen terme, pas pour un sprint. Je connais mes capacités, mon temps libre, ma motivation. J'ai bien pesé tout ça avant de me lancer sinon, je n'aurais pas commencé.

Une carte qui tient dans une fenêtre (donc pas de scrolling), trois sprites différents pour le terrain, une sorcière, une fiole de poison et un chat. Pas de menu, pas de dialogue, pas de notion de RPG (niveau, inventaires, ..)

En fait, ça je l'ai déjà (sauf la fiole de poison et le chat mais j'ai le scrolling). Et je compte bien le montrer dans un prochain article (et donc le mettre sur un dépôt accessible). Et ça sera effectivement une version 0.1. C'est aussi l'idée de ces articles, ne pas montrer le jeu une fois fini mais aussi les étapes intermédiaires et toute la conception (y compris les échecs). Et pouvoir lire les commentaires pour éventuellement mieux définir les étapes suivantes.

Il y avait d'ailleurs un des articles que j'ai lu et qui disait : au début, notez tout ce que vous voulez mettre dans le jeu, puis rayez 90% des choses et ça ira. Donc, on va considérer que les quelques idées qui sont dans cet article sont les 10% restants. Pour le reste, on verra.

Pour l'instant, si rien n'est sorti, c'est que j'ai un problème fondamental : je n'arrive pas à trouver un nom pour ce jeu :D

Tu veux vraiment être cité à chaque épisode, hein, avoue :P

En tout cas, merci pour ce lien que je vais ajouter à ma liste et que je ressortirai le moment venu.

Je partage l'avis de ce début de fil :

Des gens avec des idées et pas un rond, y'en a plein.

Oui, ils ont des beaux graphismes, ça aucun souci. Mais pour l'instant, ces graphismes sont destinés à un concept de jeu unique déjà défini. C'est ça qui est dommage. Mais après, je ne leur jette pas la pierre. Comme je l'ai dit, d'habitude, c'est les codeurs qui pratiquent de cette manière envers les graphistes.

Sauf que une particularité c'est le départ multiple, les chemins multiples (on peu être méchant, gentil, …).

Dans mon cas, je trouve qu'il y a déjà suffisamment de difficultés, inutile d'en ajouter plus. Un bon petit scénario linéaire, avec quelques quêtes annexes, ça ira très bien.

Où donc ?

Ici. Où tu dis d'ailleurs qu'il ne faut pas dénigrer les autres, or c'est exactement ce que tu fais avec Phonon.

Si le grand public ne le fait pas, je n'ai pas à vouloir le faire, c'est ça ? Pour être cohérent, il faut alors supprimer le tiling de Kwin, ça m'étonnerait que le grand public s'en serve des masses.

KDE n'a jamais prétendu être grand public uniquement. C'est à toi d'être cohérent.

Est-ce que ça suffit pour dire que la «partie multimédia (de KDE) laisse considérablement à désirer…» ? Je ne crois pas non.

Un exemple tout bête : tu ne peux pas ouvrir une vidéo avec Phonon par SMB ou SFTP sans télécharger le fichier localement.

C'est vrai que le grand public (puisque c'est la cible que tu désignes un peu plus haut) ouvre des vidéos de 1Go par SFTP tous les jours… C'est juste une blague ton argument.

Au delà de la question des sous, je pense que vous vous y prenez mal. Vous arrivez avec un concept complètement ficelé, et vous cherchez juste un gars qui va pisser du code. D'après la description, il n'y aura pas beaucoup de marge de manœuvre pour modifier le concept du jeu. Du coup, ce n'est pas très motivant, ça crée un déséquilibre entre l'éventuel codeur et vous, les artistes. Après, souvent, c'est dans le sens contraire que ça se passe, un codeur va chercher des artistes avec son concept ficelé et veut juste des mains pour dessiner ce qu'il veut. Si vous voulez un codeur, il faut pratiquer la coopération et la co-élaboration. Sans ça, ce sera dur à mon sens.

Oui, c'est sur http://www.charabia.net/ ! Je m'en suis servi il y a quelques temps, c'était très pratique et les essais philosophiques sont à mourir de rire. L'outil est en GPL et c'est bien du Java.

Ça, c'est la question piège ! Et honnêtement, je n'ai pas de réponse. Je n'ai pas vu d'autres applications des systèmes à entités que dans les jeux vidéo. Après, pour un site web, j'ai un doute sur l'application directe. Je pense qu'il faut adapter le concept, notamment par rapport à la base de données (qui va contenir les composants). Mais je n'ai aucun pointeur à donner.

Un simple test par rapport à la borne supérieur et à la nullité est suffisant, c'est souvent beaucoup plus efficace.

Surtout dans ce cas où la taille du tableau est connue à l'avance puisque c'est une constante.

C'est l'ordre dans le quel tu les enregistre dans le manager qui définit l'ordre d'appel. Ensuite c'est l'appel du preUpdate() de tous les systèmes, puis de update(), puis de postUpdate().

Pas exactement. Le constructeur de System prend en paramètre une priorité et, comme indiqué dans la doc, les systèmes avec une priorité petite seront exécutés les premiers. Dans le Manager, ça se traduit par un tri suivant la priorité avant l'initialisation de tous les systèmes.

Je crois que c'est comme ça que fonctionne Boost.Pool. Et oui, c'est une bonne idée pour allouer les composants. Après, comme toutes les entités n'ont pas tous les composants, tu auras sans doute plein de cases vides. Donc, je ne suis pas persuadé que ça soit si bien que ça. Actuellement, la lib utilise un std::set pour avoir la correspondance entre une entité et son composant, parce que c'est à l'utilisateur d'allouer ses composants comme il le souhaite. Après toutes les discussions qui ont eu lieu ici, je vais sans doute réfléchir à faire l'allocation des composants dans la lib.

Il ne faudrait pas que le destructeur et les méthodes faites pour être surchargées soient déclarées virtual ?

C'est bien le cas.

Je vois que tu ne les définis comme virtuels que dans les classes filles

Non, dans System, j'ai bien un destructeur virtuel et les méthodes init, preUpdate, update, postUpdate qui sont virtuelles. Après, dans le .cc, tu n'es pas obligé (et même je crois que c'est interdit) de mettre le mot-clef virtual. Ce qui compte ici, c'est bien le .h et dans le .h, c'est bien virtual.

Typiquement, le lien entre les deux composants va se faire dans un système (qui va gérer l'animation si je comprends bien). Ton système va considérer toutes les entités qui ont à la fois Animation et Modèle, et donc tu auras accès au deux pour déterminer quel est la bonne frame dans l'animation. Normalement, dans Animation et Modèle, tu n'auras que des données et rien d'autres.

Sans doute mon traumatisme sur mes cours de mécanique quantique (pas du tout essentiel mais il est obligatoire pour un diplôme d'ingé pour dire qu'on a un peu de théorie universitaire, et très très ennuyeux).

L'autre fois, j'ai entendu quelqu'un qui disait qu'à l'école, on n'apprenait que des choses qui ne servaient à rien. Et je partage tout à fait cette analyse. Effectivement, la mécanique quantique ne t'a jamais servi, comme à 99% de ceux à qui on l'a appris. Tout comme la philosophie en terminale, tout comme plein d'autres choses. Mais le but de l'école, c'est de former des citoyens capables de comprendre et d'appréhender le monde qui les entoure, y compris dans leur travail, mais également quand il faudra débattre et trancher des sujets de société. Avoir appris la génétique, ça ne fait pas de moi un généticien (tout comme ton cours de mécanique quantique n'a pas fait de toi un chat de Schrödinger), mais ça permet de comprendre quand on parle d'OGM.

Un étudiant qui fait ça, c'est un bon étudiant! Ben oui, c'est un étudiant qui sait chercher ce qu'il faut pour répondre à la demande de la manière la plus rapide possible, il sait chercher, réutiliser (le libre n'est-il pas la réutilsiation de ce qu'on fait d'autres?)

S'ils faisaient les choses de manière intelligente, oui ça irait. Mais ce n'est pas comme ça que ça se passe. Le workflow de l'étudiant feignant, c'est : je tape un mot clef sur Google, je vais sur la première réponse (qui vient souvent du Site du Zéro), je copie colle, je compile, et si ça marche pas, je recommence avec la deuxième réponse, etc.

Après, si l'enseignant demande une chose qu'on peut copier-coller, ben c'est son choix…

Gérer une liste chaînée, par exemple, tu peux trouver à peu près un millier d'implémentation sur le web, il n'empêche qu'il faut l'avoir pratiqué au moins une fois dans sa vie pour bien comprendre comment ça fonctionne. C'est ce qu'on demande à nos étudiants, ce n'est pas la mer à boire.

Toi, ça fait longtemps que tu n'as pas mis les pieds dans une université. Déjà première chose, les «universitaires» sont généralement ceux qui travaillent à l'université, pas ceux qui y étudient qu'on appelle plutôt «étudiants».

Il reste certes le domaine de la recherche ainsi que celui de l'enseignement, mais voila, il faut être clair la dessus (et être clair qu'il y a moins de places pour le boulot de ce type que de places d'université).

Moi je suis très clair là dessus : l'université fabrique et transmet le savoir, elle n'a pas vocation à former des salariés prêt à l'emploi. Cependant, il y a des filières dites professionalisantes (Licence Pro) qui ont cette vocation (et qui le font plutôt bien). Après, je considère que c'est aussi aux entreprises d'assurer une partie de la formation de leurs salariés, en particulier des jeunes salariés. L'université leur apprend les généralités, les entreprises adaptent les étudiants à leur cœur de métier. C'est une vue de l'esprit assez simpliste de croire que l'université pourrait former à des métiers vu la quantité de métier disponible. Rien qu'en informatique, il y en a une tétrachié. Donc, on donne à nos étudiants une formation qui leur permet par la suite de continuer à se former tout seul ou dans leur entreprise parce qu'on leur aura donné les bases essentielles et la théorie nécessaire pour comprendre la mise en pratique.

bon, il me semble quand même que depuis quelques temps, les IUT et IUP permettent de parler plus de la pratique, ça va mieux la dessus.

Les IUP sont en train de tous disparaître (en gros depuis la réforme LMD) et une grosse majorité des étudiants d'IUT va ensuite… à l'université ou dans des écoles d'ingénieurs. C'est fou hein !

La théorie est essentielle (pour certaines professions), mais ce n'est pas incompatible avec le fait qu'elle soit ennuyeuse. Je ne vois pas pourquoi tu opposes ces deux mots.

Je ne vois pas pourquoi la théorie devrait être ennuyeuse et la manière dont l'expression est employé dans l'annonce a quelque chose de très péjoratif, un peu comme ton discours.

En lisant l'annonce du changement de nom, il y a un passage que je n'ai pas du tout aimé.

L’esprit des cours ne change pas : on doit pouvoir apprendre en s’amusant, sans prise de tête et sans théorie ennuyeuse. C’est absolument essentiel à nos yeux. Nous pensons même que nous sommes capables de faire entrer cet état d’esprit qui vous plaît au sein des écoles et des universités !

La théorie n'est pas ennuyeuse, elle est essentielle si on veut comprendre ce qu'on fait, et pas juste appliquer les recettes du Site du Zéro d'OpenClassrooms. Et les universités n'ont pas besoin qu'on leur apprenne comment transmettre le savoir ! Les écoles non plus. Je n'aime pas du tout cette manière de voir les choses et de dénigrer l'enseignement supérieur.

Ce site constitue pour moi une référence pour apprendre a programmer facilement. Certain critiqueront cette dernière phrase mais pour moi qui ai majoritairement appris par moi-même ce site a été un formidable tremplin.

Je dirais que sur le Site du Zéro, on trouvait tout et son contraire et le pire côtoyait le moyen, voire de temps en temps le bon. Pour un enseignant en informatique, le Site du Zéro, c'est une plaie, c'est la source d'approvisionnement préféré en copier-coller des étudiants feignants.

Il y a d'ailleurs de fortes changes que j'utilise ta librairie ;)

N'hésite pas à faire remonter tes besoins pour l'améliorer !

Je trouve ça quand même dommage, pouvoir passer à un rendu console ou 3D facilement, c'est chouette :)

Oui, mais tu vois, tu n'auras pas les mêmes besoins pour chaque rendu. Entre un ou plusieurs caractères pour le rendu console, un sprite pour le rendu 2D et un modèle 3D pour le rendu 3D, si tu dois définir et sauvegarder les trois en permanence, tu en as deux inutiles en permanence. Et il y a certainement d'autres choses à prendre en compte : les collisions en 2D et en 3D, c'est pas exactement pareil. Donc, ce n'est pas juste une histoire de rendu, ça peut avoir une influence. Après si on reste dans un seul domaine, genre en 2D ou en 3D uniquement, là, on pourrait sans doute faire des choses, mais est-ce bien utile ?

Justement, ça fait pour moi partie du rendu. Et je pensais que c'était pas simple de séparer les deux actions en SFML mais ça fait quelque temps que j'y ai pas touché et tu as l'air sûr de toi donc ça doit être faisable. Juste que ça me parait overkill de séparer le rendu en deux systèmes, j'ai du mal à voir ce que ça apporte.

Pour moi, ce sont deux choses bien séparés. D'ailleurs, typiquement, tu as deux composants pour ce genre de chose et tu peux très bien imaginer des entités qui ont l'un et pas l'autre. Une entité qui a une position dans le monde mais qui est invisible (donc pas de position à l'écran), c'est assez courant. Et à l'inverse, des élements d'interface graphique qui vont avoir des positions sur l'écran mais pas dans le jeu (genre un score, un nombre de vie), ça existe aussi. Les deux sont nécessaires.

Ca va vite dans les jeux: les niveaux de Newton Adventure font 64x64 cases, soit déjà plus 4000 objets, alors qu'on est très loin de la taille des cartes d'un rpg.

Et combien d'objets «bougent», c'est-à-dire ont un mouvement ? Typiquement si tu fais la détection de collision à la main, pas besoin de croiser l'ensemble de 4000 objets (soit 16000000 de tests), il suffit de partir des quelques objets en mouvement (donc un sous-ensemble assez petit des 4000 objets) et de les croiser avec l'ensemble des 4000 objets. Et là, j'ai déjà un algorithme plutôt naïf qui permet de ne pas effondrer les perfs tout de suite.

en ce moment la mode est d'ajouter un éclairage dynamique sur des graphismes 2d classiques

Tu as des liens sur cette question ? Ça m'intéresserait de voir ça.

Tu bases tout sur SFML, ce que je trouve un peu dommage, pour moi un des avantages de ce paradigme c'est de séparer proprement le rendu du reste, pour pouvoir faire plusieurs implémentations du système rendu (Tu pourrais donc avoir une version SDL, une version SFML et une version console des mêmes balles rebondissantes en recodant uniquement le rendu).

Oui, j'utilise des classes de SFML (en fait une seule, Vector2f) par souci de simplicité. Je pourrais en effet recoder cette classe et faire une copie à chaque tour. Mais autant être simple et utiliser le bon type. Il me semble que ça ne sert à rien de se dire qu'on va utiliser plusieurs rendus quand on n'en utilisera qu'un seul. Oui, ça serait possible mais ce n'est pas un exercice qui m'intéresse plus que ça. Du coup, je m'autorise à reprendre des types de SFML.

Je saisi pas bien ce besoin d'avoir un composant avec les coordonnés réels, pour moi c'est interne au rendu, et donc le système rendu devrait directement travailler avec le composant position. En plus en SFML ce genre de chose se gère avec un viewport, ce que tu vas avoir du mal à faire si tu sépare rendu et traduction des coordonnés.

Au contraire, SFML gère très bien la traduction entre coordonnées de l'univers et coordonnées de l'écran grâce à une View. Dans l'exemple, j'ai fait la traduction moi-même mais c'était pour l'exemple. Après, on peut déléguer ça à SFML (il suffit juste de définir la View qui va bien).

Comme dit plus haut c'est triste cet entier à mettre à la main dans toutes les classes :-(

Meunon, ça s'automatise tout ça.