Ahoy tous ! J'espère que vous allez bien, et aujourd'hui je vais brièvement vous parler de développement de jeux-vidéos. Parce que c'est ce qui se fait pas mal ici, souvent sans vraiment suivre une méthodologie particulière (et c'est normal parce que nous sommes jeunes et souvent débutants en informatique).
Je ne suis pas un expert, et il y a beaucoup de contenus de qualité sur Internet qui parlent de tout ça mieux que moi : notamment The Art of Game Design de Jesse Schell, ou les différentes interventions à la Game Developer Conference (si ça vous intéresse, je tiens un document avec des commentaires sur les conférences que j'ai vues, histoire de retrouver facilement les conférences intéressantes). Je veux juste vous partager le peu d'expérience que j'ai acquise pour avoir vu de l'intérieur un studio à succès, fait quelques game jams, et lu les bonnes ressources.
La méthodologie traditionnelle du programmeur Casio
Alors, forcément on est tous différents dans notre manière d'aborder un projet, mais grosso-merdo le programmeur de jeux Casio suit les étapes suivantes :
Il a une idée ;
Il fait quelques dessins sur un carnet pour mettre son idée au clair ;
Il se met à coder et faire les graphismes en même temps au fur et à mesure des besoins.
Vous allez me dire : "et si ça marche ? On a tout plein de jeux corrects".
Alors mettons tout de suite les choses au point : je ne suis pas là pour critiquer, ou imposer une méthode, mais pour donner des conseils pour faire des meilleurs jeux en moins de temps. Cette méthodologie devient absolument nécessaire lorsqu'on travaille en équipe, puisqu'à ce moment un développement linéaire mené par la vision d'une seule personne devient impossible.
Nous allons voir ensemble comment, en suivant un cycle classique de développement de jeu (conception, prototypage, développement itératif, post-production), réussir particulièrement les phases de conception et prototypage. Le reste, ici, dépendra plutôt de vos compétences techniques et les tutos ne manquent pas sur le sujet.
Réussir la phase de conception
Avant de vous lancer corps et âme dans le production d'un jeu, il est important de mener une bonne phase de conception. Cette phase est aussi appelée phase de design, ou phrase de pré-production.
La pré-production, c'est tout le processus qui mène de vos multiples idées à un plan concret de ce que vous voulez faire. Pour du développement indépendant et avec peu de moyens, il est important de dégager un concept principal et de mettre tous les éléments du jeu au service de ce gameplay.
Les différentes questions à se poser dans le cadre de la pré-production d'un jeu pour calculatrices Casio sont donc les suivantes :
Quelle est l'expérience que je veux proposer au joueur ?
Quel est le concept central de cette expérience, et comment puis-je axer tout le jeu autour de celui-ci ?
En quoi mon concept est-il novateur, qu'est-ce qui va distinguer mon jeu de ce qui existe ?
Une fois que vous avez dégagé votre concept et avez une idée claire de ce que vous voulez faire, concrétisez-le de la manière suivante : Tâtez le terrain auprès du public cible du jeu. Vous pouvez mentionner l'idée sur le tchat et voir les réactions et les idées soulevées. Vous pouvez en parler à vos amis et camarades de classe.
Faites des dessins de comment vous imaginez votre jeu. Les dessins sont quelque-chose de concret, et même si c'est amené à évoluer, vous saurez ou vous allez.
Couchez sur le papier un résumé de votre concept en une phrase, et une description plus étendue d'une dizaine de lignes. Ça vous aidera à définir le cœur de votre concept.
Si la conceptualisation de votre idée vous voit perdre votre passion pour le jeu, abandonnez. Sans passion, vous allez vous faire du mal et faire un mauvais jeu. Ici, vous ne faites pas un jeu pour l'argent mais pour une communauté, et pour le plaisir d'exprimer votre créativité.
Sinon, au terme de ces étapes, vous pouvez commencer à prototyper.
Prototyper : une perte de temps ?
Alors, je vais vous arrêter tout de suite : je sais ce que vous vous dites ("oh là là pour un jeu sur calculatrice on va pas perdre son temps à prototyper"). Avant de vous expliquez comment bien prototyper, laissez-moi vous dire brièvement pourquoi c'est important :
Ça vous permet d'identifier sans trop d'efforts ce qui fonctionne et ce qui ne fonctionne pas, ce qui évite de passer du temps sur quelque-chose pour au final revenir en arrière parce que ça ne correspond pas à vos attentes.
Ça vous permet de fixer vos idées en faisant une version très imparfaite d'aspects précis du jeu, que vous allez plus tard réaliser avec à l'esprit plus de performances, de modularité, et de fonctionnalité.
Ça vous permet de sonder votre audience en fournissant les prototypes à quelques testeurs. Le prototype étant très imparfait, le testeur ne se focalise pas sur des détails mais sur le cœur de ce que vous voulez tester. Il a été montré que les tests sont moins pertinents sur des prototypes très polish que sur des prototypes bruts.
Bon, maintenant la question que vous vous posez est sûrement : prototyper quoi et comment ?
Pour réussir tous les aspects d'un jeu, il est important de les prototyper séparément. Si vous regardez un film avec un mauvais jeu d'acteurs et un scénario faible, il y a de grandes chances que vous ne soyiez même pas choqué par le scénario tant vous êtes horrifiés par le jeu d'acteur. C'est pareil dans le jeu vidéo (RIP les anims faciales de Mass Effect Andromeda).
Du coup, voilà quelques idées de ce que vous pouvez faire :
Un prototype gameplay : les sprites ne sont que de vulgaires rectangles mais vous insérez les mécaniques au cœur du gameplay du jeu final.
Un prototype graphismes : vous faites quelques assets, vous mettez ça ensemble pour regardez à quoi votre jeu devrait ressembler.
Un prototype histoire : vous testez les dialogues et choix que vous souhaitez proposer au joueur. Une très bonne idée est d'écrire toute la trame du jeu, les choix, etc. Pour cela je ne peux que vous conseiller un outil que je viens de développer pour mon usage personnel, étant en préprod d'un jeu fortement narratif : SuStoy Pro. L'outil est assez puissant et permet des branchements, des conditions et conséquences.
etc. Vous pouvez vraiment tout prototyper.
Si le gameplay comporte plusieurs mécaniques fondamentales, vous pouvez les prototyper séparément puis les intégrer ensemble. Si les mécaniques fonctionnent séparément et s'accordent bien, vous avez de bonnes chances de réussir un bon gameplay.
Un exemple que j'aime bien est cette vidéo de prototype d'Ori and the Blind Forest, à base de triangles et des sprites de pokemon :
Le jeu final ressemblant à ça :
Une fois ces prototypes conçus, testés, tweakés et retestés encore et encore, et lorsque vous êtes satisfaits de toutes vos mécaniques, vous pouvez commencer la production, sur laquelle je dirai quelques mots niveau méthodologie, sans aborder d'aspect technique, comme annoncé précédemment.
La production : par où commencer ?
La production est elle-même un processus itératif.
En tout premier lieu, soyez certains d'avoir fixé tous les aspects techniques avant de commencer le développement : librairies utilisées pour les jeux C/C++, structure du code. Faites des dessins à base de boîtes et de patates si nécessaire (la version gros projet ça s'appelle UML mais vous pouvez rester innocents quelques années avant de voir ça en école d'ingé).
Ensuite, créez la structure du code à vide mais de manière à ce que ça compile / s'exécute. Par exemple, si un morceau de code fait un calcul complexe, retournez une valeur bidon et implémentez le calcul plus tard. Faites évoluer cette structure vers un jeu ayant le gameplay de base. Implémentez le gameplay avec des graphismes basiques voir des formes géométriques, en ajoutant progressivement des fonctionnalités. Quand le gameplay a suffisamment de fonctionnalité et n'est pas amené à trop évoluer, vous pouvez réaliser les graphismes. En effet cela évite de perdre beaucoup de temps à faire des graphismes pour des morceaux de gameplay qui sont amenés à évoluer.
Lorsque le code est en place, vous pouvez réaliser une vertical slice : un morceau de jeu court mais quasi finalisé, qui donne un aperçu de ce que sera le jeu final. S'il y a des modifications à faire, faites-les maintenant.
Ensuite vous pouvez créer le contenu : le reste des graphismes, des niveaux, etc. Puis prévoyez du temps pour "polir" le jeu, afin d'optimiser l'expérience du joueur : résolution de bug, améliorations graphiques, optimisation du code. Même après publication du jeu, il y aura de la post-production à faire selon les retours des joueurs: résolution de bugs, updates.
Voilà, j'espère que cet article vous a plu, qu'il pourra vous aider niveau méthodologie. Je n'ai pas trop parlé de Game Design mais plus de méthodologie, alors voilà quelques liens vraiment utiles si vous voulez progresser un peu en Game Design :
L'appli Art of Game Design: Lenses qui fournit sous forme de fiches un résumé du bouquin de Schell, disponible sur le Play Store et l'App Store.
La chaîne YouTube de Doc Géraud, qui parle de Game Design en français.
Bon, c'était tout pour moi et j'attends vos réponses et réactions dans les commentaires !
Màj 2017-02-05: ajout des vidéos pour illustrer les prototypes.
Sympa ton article. C'est bien pensé pour le prototype dédié. Je n'y avais pas pensé et je pense que tu as raison sur ce point
Par exemple, si un morceau de code fait un calcul complexe, retournez une valeur bidon et implémentez le calcul plus tard.
Oui ! totalement d'accord. Et je rajouterai qu'une chose TRÈS importante est de surtout pas optimiser au premier jet. Il faut d'abord quelque un code qui fonctionne. Pour gagner du temps certes, mais aussi qu'on risque de passer à côté de la "bonne" optimisation.
Ninestars a écrit : Et je rajouterai qu'une chose TRÈS importante est de surtout pas optimiser au premier jet.
"Premature optimization is the root of all evil" – Donald Knuth
Sinon, oui, super idée d'article ! Je plussoie le Jesse Schell et l'appli associée, c'est vraiment une référence en la matière !
Tu as raison de mettre en valeur la phase de conception, je suis convaincu que c'est l'un des points cruciaux. Niveau prototypage, je dois admettre que je n'en ai toujours fait que légèrement. Je vais essayer d'y aller plus intelligemment dans mes prochains projets !
J'étais en train de prototyper, et je me suis dit "loul j'avais vraiment une méthodo de merde quand je faisais des jeux sur calto... oh wait!".
Concernant l'optimisation, attention à bien comprendre la phrase de Knuth. Il ne dit pas qu'on ne doit pas coder proprement sur un premier jet : il dit qu'on ne doit jamais faire d'optimisation dure. Par exemple dans le cadre des jeux-vidéos qui sont conçus pour plusieurs plateformes, il y a pas mal de morceaux de code spécifiques à une plateforme (par exemple pc, ps4 ou xbox one), qui en général sont extrêmement dépendants du code à un moment donné, donc qui tuent la modularité.
Mais dans un jeu vidéo, les ressources sont bien spécifiées et certains morceaux sont codés directement pour rentrer dedans. Par exemple on décide d'allouer 1ms à un effet visuel, la feature est codée, et éventuellement si ça rentre pas dans le temps alloué on fait sauter. Après tout est paramétré pour pouvoir faire des réglages en fin de projet (exemple : nombre de samples pour un raytracing pour du brouillard volumétrique).
Par exemple on décide d'allouer 1ms à un effet visuel, la feature est codée, et éventuellement si ça rentre pas dans le temps alloué on fait sauter.
Ooh, j'avais jamais vu ça comme ça. Intéressant ! Je devrais essayer de planifier le moteur graphique de mon projet jeu de cette façon. Ça me permettrait de contrôler bien mieux ce qui se passe.
Tu me donnes vraiment envie de faire des tests de jeux maintenant. C'est malin, j'avais pas prévu ça dans mon emploi du temps du week-end.
Du coup si tu nous parlais un peu des trucs que tu prototypes ? Même si c'est pas du Casio, je pense que ça intéresse à peu près tout le monde.
Alors en fait sur un projet de jeu dans le monde réel on établit ce qu'on appelle un budget. Le budget alloue les ressources, par exemple RAM, mémoire graphique, temps CPU, temps GPU, etc. Évidemment c'est pas aussi simple qu'une courbe temps alloué par rapport à la config, parce que les rapports entre les différents composants varient d'une config à l'autre, et un jeu aura du mal à vraiment s'adapter : selon les configs il sera CPU-bound ou GPU-bound. Certains des outils de débogage du jeu permettent le monitoring de l'utilisation des ressources, histoire de voir si on tient dans la plage de configs visée. Après on peut avoir des raisonnements du genre : "1ms GPU sur la config recommandée", et puis en dessous de la config recommandée dttf on n'arrivera pas à maintenir le framerate visé.
Concernant ce que je prototype, je tiens à dire que je suis encore en préprod sur mon prochain projet et j'avance pas très vite parce que je continue à me former sur UE4 en même temps. Je suis en train d'écrire le scénario, après j'implémenterai toute l'histoire et les dialogues dans l'outil que j'ai mentionné que j'ai conçu pour l'occasion. Ensuite je vais faire pas mal de tests graphiques parce que je ne sais pas encore trop si je me lance sur un effet cel shading, pâte à modeler, ou peinture. Ça va être un gros boulot parce que l'atmosphère est un des points clés de mon jeu. Niveau gameplay je ferai ça dans un niveau simple mais je réutiliserai sûrement le même code en version finale. Pour le level design, je vais faire ça avec des placeholders, et ensuite j'alternerai du graphisme et du level design.
En fait j'exclus pas de faire encore un plus petit projet avant de me lancer sur du gros.
Ninestars a écrit : C'est que tu as du jeu vidéo ton travail ?
Tu aurais des infos techniques/insolites sur les dessous de la création d'un jeu ?
Oui et non
J'ai travaillé 3 mois l'été dernier à Dontnod, c'était trop court pour voir un cycle de développement complet mais ça m'a un peu permis de voir les outils de travail et la méthodologie d'un studio qui bosse avec des méthodes Agile (comme 90% des studios).
J'ai pas mal d'infos insolites et de trucs marrants à raconter, même si je ne sais pas trop ce qui passe ou pas par rapport à la clause de confidentialité, ni ce que tu entends par "info insolite". C'est un studio avec une moyenne d'âge assez jeune, pas mal d'artistes et designers par rapport aux programmeurs vu qu'il n'y a pas d'engine maison, donc les gens sont assez divers et tous vraiment sympa. Les bureaux sont remplis de plantes, figurines et autres décorations, on bosse en flexitime, et globalement tout le monde fait du beau boulot.
Maintenant je commence mon master avec une année d'Erasmus en Finlande, et je fais du développement de jeux sur mon temps libre (celui qui n'est pas occupé à faire du ski de fond, du patin à glace ou aller au sauna).
Merci beaucoup d'avoir partagé ces idées avec nous, ça fait plaisir à lire, c'est instructif et très appliqué à notre milieu !
Concernant la phase de design, je mettrais entre parenthèse la dernière question : "En quoi mon concept est-il novateur, qu'est-ce qui va distinguer mon jeu de ce qui existe ?". Pour les débutants en manque d'inspiration, réaliser une adaptation est une première étape, le "dépassement" de l'original étant la seconde. Même si la production ne dépasse pas la source, c'est déjà excellent d'avoir sa propre version car on se rend compte des efforts et des ressources que cela exige. Après quelques rencontres d’entrepreneurs dans toutes sortes de milieux, on m'a souvent déconseillé de bannir l'existant du champ des possibles lors de la phase de design. Mais ce n'est qu'un détail, rien de fondamental.
A titre personnel j'ai eu tendance à beaucoup faire dans l'autre sens : prototyper puis construire le design au dessus. L'avantage c'est qu'on connait directement le potentiel et les limites techniques de ce qu'on va faire. L'inconvénient pour moi a souvent été la perte de la passion dont tu parles. La partie design me passionnais de façon inégale selon les projets, d'où le faible nombre de projets finalisés...
C'est une bonne idée de parler de l'UML ! Ca aurait été l'occasion de mettre un logo ou une illustration, les seules choses qui manquent à cet article.
Je suis parfaitement en accord avec la partie implémentation (comme les autres en fait ). La remarque de 9* parfait le tout.
Ne0tux a écrit : Concernant la phase de design, je mettrais entre parenthèse la dernière question : "En quoi mon concept est-il novateur, qu'est-ce qui va distinguer mon jeu de ce qui existe ?". Pour les débutants en manque d'inspiration, réaliser une adaptation est une première étape, le "dépassement" de l'original étant la seconde. Même si la production ne dépasse pas la source, c'est déjà excellent d'avoir sa propre version car on se rend compte des efforts et des ressources que cela exige. Après quelques rencontres d’entrepreneurs dans toutes sortes de milieux, on m'a souvent déconseillé de bannir l'existant du champ des possibles lors de la phase de design.
L'adaptation est un peu une exception du milieu Casio, et à vrai dire un portage de jeu jamais vu sur calculatrice peut être extrêmement novateur. De plus un jeu nécessite d'être repensé pour être joué sur calculatrice. Par exemple Fruit Ninja est une adaptation audacieuse d'un jeu tactile sur un support non tactilé. Même dans le "monde réel" on peut voir de très bons remakes qui ajoutent quelque-chose au jeu original, ou simplement le modernisent sur de meilleures technologies (j'ai bien aimé Tomb Raider 2013 qui n'est pas franchement innovant). Ce qui est gênant c'est la masse de jeux qui se contentent de surfer sur une vague, comme les nombreux MOBA LoL-like, ou les multiples FPS sans personnalité. Même les grosses franchises se répètent par peur de la prise de risque.
Ne0tux a écrit : A titre personnel j'ai eu tendance à beaucoup faire dans l'autre sens : prototyper puis construire le design au dessus. L'avantage c'est qu'on connait directement le potentiel et les limites techniques de ce qu'on va faire.
On peut évidemment faire des allers-retours entre design et prototypes. Mais techniquement il y a toujours une première phase de conception qui précède le prototype, ne serait-ce que dans la décision de ce que tu fais comme prototype. Prendre le temps d'augmenter cette phase de conception peut paraître ennuyeux, je le conviens, mais ça te permet de faire des prototypes plus dirigés, et de cadrer ton projet, ce qui évite le problème de commencer un prototype sur une idée de gameplay un peu cool, puis laisser mourir au bout de 2 jours parce que tu n'as pas la passion (ce qui a moins de chances d'arriver si tu pars d'une volonté de produire une certaine expérience.
Ne0tux a écrit : C'est une bonne idée de parler de l'UML ! Ca aurait été l'occasion de mettre un logo ou une illustration, les seules choses qui manquent à cet article.
Je l'ai à peine mentionné, ne comptez pas trop sur moi là-dessus
Euh ouais l'article est un peu lourd et textuel, j'ai bien une idée qui me vient à l'esprit, dites-moi si vous trouvez bien d'inclure ça dans l'article. C'est un prototype d'Ori and the Blind Forest :
Yep, tu peux l'inclure. Je pense que même si on ne connait pas le jeu c'est intéressant de voir que l'aspect graphique a totalement été mis de coté pour se concentrer uniquement sur le gameplay.
Et puis ça fera un peu de visuel à l'article.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
J'ai update avec une vidéo du prototype et une vidéo du jeu final. Btw le jeu (tout du moins l'édition spéciale) contient quelques vidéos intéressantes sur le prototypage et le développement du jeu.
Ninestars a écrit : Intéressant cette vidéo, je trouve que le jeu est bien dans cet état haha
Ouais enfin l'état final envoie tellement du pâté sur les murs aussi.
D'ailleurs il y a un vidéaste anglophone que j'aime bien qui a fait une analyse détaillée des mécaniques sur un morceau du jeu, c'est assez intéressant (d'ailleurs il parle pas mal de la mécanique qui est testée dans le prototype que j'ai montré) :
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 02/02/2018 20:10 | #
Sympa ton article. C'est bien pensé pour le prototype dédié. Je n'y avais pas pensé et je pense que tu as raison sur ce point
Citer : Posté le 02/02/2018 20:25 | #
Et je rajouterai qu'une chose TRÈS importante est de surtout pas optimiser au premier jet.
"Premature optimization is the root of all evil" – Donald Knuth
Sinon, oui, super idée d'article ! Je plussoie le Jesse Schell et l'appli associée, c'est vraiment une référence en la matière !
Tu as raison de mettre en valeur la phase de conception, je suis convaincu que c'est l'un des points cruciaux. Niveau prototypage, je dois admettre que je n'en ai toujours fait que légèrement. Je vais essayer d'y aller plus intelligemment dans mes prochains projets !
Citer : Posté le 02/02/2018 20:53 | #
J'étais en train de prototyper, et je me suis dit "loul j'avais vraiment une méthodo de merde quand je faisais des jeux sur calto... oh wait!".
Concernant l'optimisation, attention à bien comprendre la phrase de Knuth. Il ne dit pas qu'on ne doit pas coder proprement sur un premier jet : il dit qu'on ne doit jamais faire d'optimisation dure. Par exemple dans le cadre des jeux-vidéos qui sont conçus pour plusieurs plateformes, il y a pas mal de morceaux de code spécifiques à une plateforme (par exemple pc, ps4 ou xbox one), qui en général sont extrêmement dépendants du code à un moment donné, donc qui tuent la modularité.
Mais dans un jeu vidéo, les ressources sont bien spécifiées et certains morceaux sont codés directement pour rentrer dedans. Par exemple on décide d'allouer 1ms à un effet visuel, la feature est codée, et éventuellement si ça rentre pas dans le temps alloué on fait sauter. Après tout est paramétré pour pouvoir faire des réglages en fin de projet (exemple : nombre de samples pour un raytracing pour du brouillard volumétrique).
Citer : Posté le 02/02/2018 21:01 | #
Ooh, j'avais jamais vu ça comme ça. Intéressant ! Je devrais essayer de planifier le moteur graphique de mon projet jeu de cette façon. Ça me permettrait de contrôler bien mieux ce qui se passe.
Tu me donnes vraiment envie de faire des tests de jeux maintenant. C'est malin, j'avais pas prévu ça dans mon emploi du temps du week-end.
Du coup si tu nous parlais un peu des trucs que tu prototypes ? Même si c'est pas du Casio, je pense que ça intéresse à peu près tout le monde.
Citer : Posté le 02/02/2018 21:29 | #
Alors en fait sur un projet de jeu dans le monde réel on établit ce qu'on appelle un budget. Le budget alloue les ressources, par exemple RAM, mémoire graphique, temps CPU, temps GPU, etc. Évidemment c'est pas aussi simple qu'une courbe temps alloué par rapport à la config, parce que les rapports entre les différents composants varient d'une config à l'autre, et un jeu aura du mal à vraiment s'adapter : selon les configs il sera CPU-bound ou GPU-bound. Certains des outils de débogage du jeu permettent le monitoring de l'utilisation des ressources, histoire de voir si on tient dans la plage de configs visée. Après on peut avoir des raisonnements du genre : "1ms GPU sur la config recommandée", et puis en dessous de la config recommandée dttf on n'arrivera pas à maintenir le framerate visé.
Concernant ce que je prototype, je tiens à dire que je suis encore en préprod sur mon prochain projet et j'avance pas très vite parce que je continue à me former sur UE4 en même temps. Je suis en train d'écrire le scénario, après j'implémenterai toute l'histoire et les dialogues dans l'outil que j'ai mentionné que j'ai conçu pour l'occasion. Ensuite je vais faire pas mal de tests graphiques parce que je ne sais pas encore trop si je me lance sur un effet cel shading, pâte à modeler, ou peinture. Ça va être un gros boulot parce que l'atmosphère est un des points clés de mon jeu. Niveau gameplay je ferai ça dans un niveau simple mais je réutiliserai sûrement le même code en version finale. Pour le level design, je vais faire ça avec des placeholders, et ensuite j'alternerai du graphisme et du level design.
En fait j'exclus pas de faire encore un plus petit projet avant de me lancer sur du gros.
Citer : Posté le 02/02/2018 22:14 | #
C'est que tu as du jeu vidéo ton travail ?
Tu aurais des infos techniques/insolites sur les dessous de la création d'un jeu ?
Citer : Posté le 02/02/2018 22:25 | #
C'est que tu as du jeu vidéo ton travail ?
Tu aurais des infos techniques/insolites sur les dessous de la création d'un jeu ?
Oui et non
J'ai travaillé 3 mois l'été dernier à Dontnod, c'était trop court pour voir un cycle de développement complet mais ça m'a un peu permis de voir les outils de travail et la méthodologie d'un studio qui bosse avec des méthodes Agile (comme 90% des studios).
J'ai pas mal d'infos insolites et de trucs marrants à raconter, même si je ne sais pas trop ce qui passe ou pas par rapport à la clause de confidentialité, ni ce que tu entends par "info insolite". C'est un studio avec une moyenne d'âge assez jeune, pas mal d'artistes et designers par rapport aux programmeurs vu qu'il n'y a pas d'engine maison, donc les gens sont assez divers et tous vraiment sympa. Les bureaux sont remplis de plantes, figurines et autres décorations, on bosse en flexitime, et globalement tout le monde fait du beau boulot.
Maintenant je commence mon master avec une année d'Erasmus en Finlande, et je fais du développement de jeux sur mon temps libre (celui qui n'est pas occupé à faire du ski de fond, du patin à glace ou aller au sauna).
Citer : Posté le 03/02/2018 14:10 | #
Excellent, c'est le genre d'articles qui fera la base de la v5 !
Du coup j'ai ajouté ça à la liste des tutos de qualité
Citer : Posté le 03/02/2018 16:00 | #
Excellent, c'est le genre d'articles qui fera la base de la v5 !
Du coup j'ai ajouté ça à la liste des tutos de qualité
Merci. Si ça intéresse du monde, hésitez pas à évoquer des sujets, qu'on pourra aboder si je trouve le temps et la motiv
Citer : Posté le 04/02/2018 20:11 | #
Merci beaucoup d'avoir partagé ces idées avec nous, ça fait plaisir à lire, c'est instructif et très appliqué à notre milieu !
Concernant la phase de design, je mettrais entre parenthèse la dernière question : "En quoi mon concept est-il novateur, qu'est-ce qui va distinguer mon jeu de ce qui existe ?". Pour les débutants en manque d'inspiration, réaliser une adaptation est une première étape, le "dépassement" de l'original étant la seconde. Même si la production ne dépasse pas la source, c'est déjà excellent d'avoir sa propre version car on se rend compte des efforts et des ressources que cela exige. Après quelques rencontres d’entrepreneurs dans toutes sortes de milieux, on m'a souvent déconseillé de bannir l'existant du champ des possibles lors de la phase de design. Mais ce n'est qu'un détail, rien de fondamental.
A titre personnel j'ai eu tendance à beaucoup faire dans l'autre sens : prototyper puis construire le design au dessus. L'avantage c'est qu'on connait directement le potentiel et les limites techniques de ce qu'on va faire. L'inconvénient pour moi a souvent été la perte de la passion dont tu parles. La partie design me passionnais de façon inégale selon les projets, d'où le faible nombre de projets finalisés...
C'est une bonne idée de parler de l'UML ! Ca aurait été l'occasion de mettre un logo ou une illustration, les seules choses qui manquent à cet article.
Je suis parfaitement en accord avec la partie implémentation (comme les autres en fait ). La remarque de 9* parfait le tout.
Merci encore pour le partage et la qualité !
La Planète Casio est accueillante : n'hésite pas à t'inscrire pour laisser un message ou partager tes créations !
Citer : Posté le 05/02/2018 01:14 | #
Concernant la phase de design, je mettrais entre parenthèse la dernière question : "En quoi mon concept est-il novateur, qu'est-ce qui va distinguer mon jeu de ce qui existe ?". Pour les débutants en manque d'inspiration, réaliser une adaptation est une première étape, le "dépassement" de l'original étant la seconde. Même si la production ne dépasse pas la source, c'est déjà excellent d'avoir sa propre version car on se rend compte des efforts et des ressources que cela exige. Après quelques rencontres d’entrepreneurs dans toutes sortes de milieux, on m'a souvent déconseillé de bannir l'existant du champ des possibles lors de la phase de design.
L'adaptation est un peu une exception du milieu Casio, et à vrai dire un portage de jeu jamais vu sur calculatrice peut être extrêmement novateur. De plus un jeu nécessite d'être repensé pour être joué sur calculatrice. Par exemple Fruit Ninja est une adaptation audacieuse d'un jeu tactile sur un support non tactilé. Même dans le "monde réel" on peut voir de très bons remakes qui ajoutent quelque-chose au jeu original, ou simplement le modernisent sur de meilleures technologies (j'ai bien aimé Tomb Raider 2013 qui n'est pas franchement innovant). Ce qui est gênant c'est la masse de jeux qui se contentent de surfer sur une vague, comme les nombreux MOBA LoL-like, ou les multiples FPS sans personnalité. Même les grosses franchises se répètent par peur de la prise de risque.
A titre personnel j'ai eu tendance à beaucoup faire dans l'autre sens : prototyper puis construire le design au dessus. L'avantage c'est qu'on connait directement le potentiel et les limites techniques de ce qu'on va faire.
On peut évidemment faire des allers-retours entre design et prototypes. Mais techniquement il y a toujours une première phase de conception qui précède le prototype, ne serait-ce que dans la décision de ce que tu fais comme prototype. Prendre le temps d'augmenter cette phase de conception peut paraître ennuyeux, je le conviens, mais ça te permet de faire des prototypes plus dirigés, et de cadrer ton projet, ce qui évite le problème de commencer un prototype sur une idée de gameplay un peu cool, puis laisser mourir au bout de 2 jours parce que tu n'as pas la passion (ce qui a moins de chances d'arriver si tu pars d'une volonté de produire une certaine expérience.
C'est une bonne idée de parler de l'UML ! Ca aurait été l'occasion de mettre un logo ou une illustration, les seules choses qui manquent à cet article.
Je l'ai à peine mentionné, ne comptez pas trop sur moi là-dessus
Euh ouais l'article est un peu lourd et textuel, j'ai bien une idée qui me vient à l'esprit, dites-moi si vous trouvez bien d'inclure ça dans l'article. C'est un prototype d'Ori and the Blind Forest :
Citer : Posté le 05/02/2018 11:16 | #
Yep, tu peux l'inclure. Je pense que même si on ne connait pas le jeu c'est intéressant de voir que l'aspect graphique a totalement été mis de coté pour se concentrer uniquement sur le gameplay.
Et puis ça fera un peu de visuel à l'article.
Citer : Posté le 05/02/2018 12:43 | #
J'ai update avec une vidéo du prototype et une vidéo du jeu final. Btw le jeu (tout du moins l'édition spéciale) contient quelques vidéos intéressantes sur le prototypage et le développement du jeu.
Citer : Posté le 05/02/2018 20:27 | #
Intéressant cette vidéo, je trouve que le jeu est bien dans cet état haha
Citer : Posté le 05/02/2018 21:51 | #
Intéressant cette vidéo, je trouve que le jeu est bien dans cet état haha
Ouais enfin l'état final envoie tellement du pâté sur les murs aussi.
D'ailleurs il y a un vidéaste anglophone que j'aime bien qui a fait une analyse détaillée des mécaniques sur un morceau du jeu, c'est assez intéressant (d'ailleurs il parle pas mal de la mécanique qui est testée dans le prototype que j'ai montré) :