rewind a écrit 3425 commentaires

OK, je comprends mieux. Il s'agit de définir un ensemble de fonctionnalités minimales et les tâches (et éventuellement sous-tâches) qui y sont associées.

J'avais lu je ne sais plus où que c'était un piège à éviter : faire un moteur de jeu. Et qu'en fait, il fallait faire un jeu plutôt qu'un moteur en pensant qu'on fera le jeu plus tard. Parce qu'au final, on faisait le moteur sans jamais faire le jeu.

Réutiliser les briques des autres. Je pense particulièrement à Tiled qui est quand même vachement bien fait.

Oui, clairement, Tiled est un très bon logiciel et le format est pas mal du tout.

Les traductions, c'est assez infernal. Il vaut mieux y penser très tôt.

Tu as des conseils à ce sujet ? Je me suis toujours dit que ça devait être un peu galère, parce qu'on ne doit pas pouvoir utiliser ce bon vieux gettext.

Quoiqu'il en soit, je suis potentiellement très intéressé (bien que, ayant repris les études, j'ai moins de temps qu'avant).

Si tu veux contribuer (une fois qu'il y aura un code auquel contribuer), ce sera avec plaisir. Sinon, vu que tu as déjà fait ce genre de jeu, tu peux aussi partager ton expérience, dire ce qui a marché, ce qui n'a pas marché, etc. En tout cas, moi ça m'intéresse ;)

C'est pour ça qu'il est important de prototyper son jeu très tôt, à grand coup de carrés, de cercles et de code crade s'il le faut. Et continuer à pouvoir tester régulièrement toute les améliorations, parce que tant qu'une feature du jeu n'a pas été joué, on a jamais vraiment moyen de savoir si cette feature respectera vraiment son rôle de rendre le jeu plus amusant.

Ha ben ça, c'est fait, et ça sera bientôt public ! Ils sont tellement beaux mes carrés :)

un menu principal avec une GUI pour régler la résolution, le volume des effets sonores et de la musique, configurer les touches…

J'y pense. Est-ce que ça n'est pas mieux géré par une GUI plus classique, genre en Qt. Via un launcher qui sert aussi à la configuration par exemple. L'inconvénient, c'est que ça devient difficile de modifier dans le jeu mais c'est peut-être plus simple non ?

la gestion des manettes.

On peut décider de tout faire au clavier ? ;)

de bons réglages par défaut (genre pas zsqd pour le déplacement sur un clavier qwerty…).

Alors ça, j'y ai pensé tout de suite et j'ai immédiatement mis les flèches pour bouger.

les scripts pour releaser des binaires et des installateurs.

De ce côté, je crois que je suis assez mauvais. Fournir un CMakeLists.txt et des instructions de build, ça je sais faire. Mais pour releaser des binaires, je dois avouer que je ne sais pas faire. En plus, à partir de quel niveau de finition tu conseilles de releaser ? Est-ce que releaser des versions primitives ne risquent pas de faire fuir les potentiels joueurs qui croiront que c'est un jeu fini ?

Pour l'exemple voici la bible de Plee the Bear (qui n'est pas fini).

C'est super complet et super détaillé. Je ne sais pas si je suis capable à l'heure actuelle d'avoir ce niveau de détail.

Ensuite nous nous servons de cela pour poser nos jalons, en commençant par décider d'un horizon de livraison (deux fois 3 mois pour Andy's Super Great Park). Toutes les deux semaines nous nous posons la question « que voulons-nous voir dans le jeu dans deux semaines ? ». Nous notons toutes les réponses dans des tickets de Trac et nous nous mettons au boulot.

Je pense avoir moins de vision à long terme sur mon temps de dev que toi, malheureusement. Je peux avoir des semaines très chargées où je n'aurai le temps de rien faire. Et d'autres où je vais pouvoir avancer beaucoup. Disons que par période de deux semaines, c'est jouable et encore.

Tu devrais commencer par faire une maquette sous la forme d'un storyboard (avec un logiciel de dessin simple ou même du papier/crayon). Le but est de définir le cœur du jeu.

Le cœur du jeu ici, ça va être le scénario (dont j'ai pour l'instant une vague idée), mêlé à l'ambiance humoristique. Ou alors, je ne comprends pas bien ce que tu appelles le cœur du jeu.

Avec ce premier jet, tu pourras en déduire les "histoires" (vocabulaire scrum désolé) obligatoires pour une version jouable et les autres.

Qu'appelles-tu des "histoires" ? Ce sont des sortes de chapitres du déroulé du jeu, c'est ça ?

Ça peut faire l'objet du prochain épisode.

Tu fais ça comment ? Tu indiques juste le contenu ? Tu indiques aussi le temps estimé ? Tu peux montrer un exemple ?

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.