JeuWeb - Crée ton jeu par navigateur
Comment ne jamais finir un projet de jeu - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Débuter et gérer son projet (https://jeuweb.org/forumdisplay.php?fid=60)
+--- Sujet : Comment ne jamais finir un projet de jeu (/showthread.php?tid=7730)

Pages : 1 2

Comment ne jamais finir un projet de jeu - Thêta Tau Tau - 03-12-2016

Je viens de passer 2 heures à rédiger une réponse à un post sur jvc, concernant le sujet mainte fois abordé des projets avortés.

Bien que pas mal de choses aient été déjà dites sur jeu web, je me suis dit que ça pourrait vous intéresser, donc je reposte ici.

--------------------

Depuis 8-9 ans que je m'intéresse au développement de jeux vidéo, j'ai rien fini, y compris depuis un an où je suis au chômage et où je voulais tester une reconversion en dev indé. J'ai des dizaines de GDD à moitié écrits, certains faisant plus de 50 pages. J'ai des dizaines de protos avortés pour diverses raisons (code foireux, projet trop gros, jeu pas ludique etc.). Même fonctionnement que l'auteur : une phase d’excitation, une phase "oulàlà, c'est plus compliqué et moins bien que prévu" et une phase de découragement.



Le projet obèse.


Le soucis numéro un, je pense, c'est l'ambition. Si on fait du dev de jeux vidéo, c'est parce qu'on est passionné de jeux vidéos, et qu'on veut apporter quelque chose de nouveau, de mieux que ce qui existe. Sans compter qu'en temps que débutant, on a conscience que de 1% du travail à accomplir. Du coup au début on veut faire un jeu AAA (wow, skyrim etc.) "en mieux", et on se rends compte que c'est impossible.
Dans un deuxième temps on se base sur les jeux à succès "faits par une ou deux personnes dans leur garage". Le hic c'est que les personnes en question on déjà de la bouteille, et on souvent passé plusieurs années sur leur jeu, et viennent généralement d'un pays avec une "culture de l'échec" (ex: USA) ce qui n'est absolument pas le cas en France, et pas non plus mon cas (je suis à la fois trop perfectionniste et trop pessimiste).
Du coup pour un premier jeu je pense qu'il faille viser le plus simple possible, mais s'y tenir et aller jusque au bout, quitte à faire un jeu qui n'intéressera pas grand monde et ne rapportera pas grand chose (si on veut le monétiser).
L'intérêt du/des premier(s) jeu n'est pas seulement le jeu en lui même, mais surtout le gain d'expérience qui servira pour les jeux suivants. Notamment le fait de voir toutes les phases du développement permet de mieux estimer la faisabilité d'un autre projet.


Le projet codé selon les règles de l'art... ou pas


La qualité du code, je ne pense pas qu'il faille lui accorder trop d'importance non plus (au risque de pas aller dans le même sens que les autres post de ce topic). Ca peut sembler pourri comme conseil, mais à vouloir faire le meilleurs code possible, on se retrouve à ne rien coder du tout. Perso j'ai appris à me servir d'une demi-douzaines de langages (C,C++, php, js, python, lua, C#) et une chiée de frameworks/moteurs/outils divers (cakephp, synfony, jquery, meteor, bootstrap, react, love, xna, unity et j'en passe), et j'ai passé plein de temps à réécrire et à réréécrire mon code. Alors certes ça m'a apporté de l'expérience, je suis bien meilleurs dev aujourd'hui qu'il y a 8 ans, mais en terme de productivité c'est zéro.
Ce qu'il faut se dire c'est que même si le code d'un jeu est horrible, tant que ça marche, on s'en fout. Les joueurs ne voient pas le code de toute façon. Après certes il arrive un stade où le code deviens impossible à maintenir mais :
-1/ Sur les petits projets, on aura fini le jeu avant d'atteindre ce stade (par ex sur mon projet actuel, dont je parlerais plus bas, j'en suis 400 lignes de codes seulement, et ça m'étonnerais fortement de dépasser le millier).
-2/ Plus on a de l'expérience, plus on arrive à pondre du code maintenable, et plus on arrive à gérer du code pourri.
-3/ Les moteurs de jeux / frameworks fournissent une architecture solide sur laquelle se baser. Surtout quand on est débutant, on a tendance à faire n'importe quoi quand on part de zéro (même si pour le coup, un framework c'est un poil difficile à comprendre quand on est débutant).
Après pour modérer un peu mes propos, ça fait presque 10 ans que je programme, dont 2 ans de travail, donc même mon code fait "à moitié à l'arrache" reste à peu près clair. Si je remonte à mes débuts, c'est vrai que j’arrivai rapidement à un code ingérable. Donc ouais les débutants doivent quand même prendre le temps de faire du code potable, mais il ne faut pas tomber dans l'excès non plus (passer son temps à améliorer le code existant plutôt que d'avancer).


Le projet joli sur le papier mais qui reste sur le papier


Un autre piège, dans le quel je suis tombé plein de fois, c'est de trop planifier. Pour le coup je ne suis pas d'accord avec pas mal de post sur ce topic.
On trouve plein de conseils sur le web sur comment faire un game design document détaillé par exemple.
Dans les faits (vécus plusieurs fois), un GDD complet, ça fait plusieurs dizaines de page (voir centaines selon le jeu), ça prends énormément de temps et ça ne sert pas forcément à grand-chose vu que le développement d'un jeu est hautement itératif, cad. Qu'on passe son temps à tout changer et rechanger, surtout au début d'un projet, et surtout si le projet est innovant.
Le pire c'est que si on se lance à l'arrache dans la rédaction d'un GDD, c'est qu'on a tendance à oublier que l'intérêt de ce document, c'est aussi de réduire les risques, et qu'on se retrouve à complexifier le projet avant même de l'avoir commencé.
Pour moi le GDD n'est pas un outil pour débuter un projet, mais un outil qui viens plus tard, quand on a déjà un prototype, que le gameplay est plus ou moins stabilisé, et qu'un veut passer au développement de la version finale, surtout si ça implique d'élargir l'équipe.
La méthode que j'essaye d'appliquer (pas la seule ni la meilleure) c'est la rédaction d'un document court (quelques pages), sorte de mini GDD pas trop détaillé, qui met l'accent sur la faisabilité. Puis faire un prototypage le plus rapide possible, sans graphismes et sans prise de tête sur la qualité du code (parfois même sans rien coder avec des bouts de papier et des dés quand c'est possible). Puis identifier les soucis et passer à l'itération suivant en reprenant le document.


Le projet qu'il est trop zoli


Un autre gros soucis, c'est que pour qu'un jeu soit un minimum "cool", on se retrouve à avoir besoin d'une tonne d'assets : sprites, sons, musique, particules, filtres graphiques etc. dont la quantité explose rapidement. Par ex si on veut faire un RPG, aussi minimaliste qu'il soit, on se retrouve à avoir besoin de centaines de sprites (personnages, ennemis, armes, armures, bijoux, potions...). Et c'est le cas dans presque tous les genre de jeux. Certes on peut rogner, par exemple en n'affichant pas les objets équipés, mais ça aura moins de gueule, et on se retrouvera de toute façon à un point où on ne peut plus rogner.
C'est ce problèmes d'assets qui me bloque le plus actuellement, parce que je suis une quiche en graphismes, mais que je suis quand même assez regardant sur la qualité (pas question d'utiliser des sprites en pixelart mal faits par exemple).
Je pense que lors de la conception du jeu, il faut au moins autant réfléchir à la faisabilité en terme d'assets qu'à la faisabilité en terme de programmation.


Mon projet perso


Du coup en prenant en compte tous ces soucis, je me suis demandé quel est le projet le plus simple possible (en fonction de mes compétences), qui puisse quand même être monétisé.
Déjà on oublie les jeux PC (steam etc.). Les jeux multi aussi (j'ai passé plein de temps sur des projets de jeux "web"). Du coup reste les mini jeux sur mobile et portails de jeux web.
Parmi eux, j'ai cherché les jeux les plus simples possible, particulièrement du côté graphique (parce que c'est ce qui me bloque le plus), mais qui attire quand même des joueurs. Je suis tombé sur les jeux dits "waiting game", aussi appelé "idle" ou "incremental".
Un exemple parmi d'autres :

[Image: 1480758714-screenshoot.png]

Pas très impressionnant n'est ce pas? Cependant quand on regarde le nombre de vues (visible sur le screenshoot en bas), on voit que le rapport temps de travail / nombre de joueurs est plutôt bon, surtout pour quelqu'un comme moi qui bloque sur les graphismes.
Du coup c'est sur un jeu dans le style que je me suis lancé depuis une dizaine de jours , avec des technologie que je maitrise bien (HTML5). C'est pas vraiment très palpitant comme projet mais au moins c'est faisable en relativement peu de temps, même si je me rend compte que malgré tout, j'avais encore sous estimer certains aspects... Et une fois fini je me lancerais sur un jeu un peu... plus intéressant...

Désolé pour le pavé.

D'ailleurs je rajouterais que pour la productivité, les forums c'est pas top non plus :'(

RE: Comment ne jamais finir un projet de jeu - Murthy - 03-12-2016

Excellent ! Très bon résumé et je suis quasiment certain que ça doit concerner un très grand nombre d'amateurs du domaine. Personnellement, j'ai eu l'impression que tu parlais de moi. ^^

Edit : Et merci pour ce partage d'expérience !

RE: Comment ne jamais finir un projet de jeu - Sephi-Chan - 03-12-2016

Très bon résumé !

Tu pars donc sur un incremental game ? Sont-ils si simples qu'on le pense ? J'ai l'impression que la complexité est cachée et qu'il faut un paquet de mécanismes à balancer au joueur au fur et à mesure.

L'avantage, par contre, c'est qu'on peut ajouter une composante multijoueur à ce genre de jeux.

Ma nouvelle vie de prof me tient assez loin du développement de mon projet, mais j'ai quand même espoir un jour de sortir quelque chose ! :p

RE: Comment ne jamais finir un projet de jeu - Xenos - 03-12-2016

Très intéressants comme retours, merci du partage (tiens, un autre "essayeur" de l'année en indé pour finir ses projets) Smile

Perso, je n'aurai quand même pas mis l'ambition en premier obstacle, mais plutôt le mélange entre hobby et profession. Dans et hors du monde des codeurs (je pense surtout à celui des graphistes/artistes), j'ai souvent vu des amateurs mélanger ce qu'ils font pour le plaisir (pour passer du temps pour soi, comme un Sudoku) et ce qu'ils font pour gagner de l'argent, pour vendre (pour "être utile aux autres" on va dire, puisque ces autres nous payent ensuite). Vivre de sa passion quelle qu'elle soit, c'est avant tout une question commerciale, de monétisation (et absolument pas une question de qualité de ce qu'on fait par passion).

Je suis ensuite complètement d'accord avec les "projets obèses" (ce n'est pas pour rien que le jeu AAA qu'on veut "refaire en mieux" a nécessité 50 personnes pendant 3 ans), avec l'inutile recherche de perfection dans la mécanique interne (j'ai eu la même tentation infructueuse...), avec l'effet d'être au fond du gouffre quand on réalise son projet, et avec le fait que le code n'est qu'un tout tout petit morceau d'un jeu web.

J'avais un peu résumé certains points dans l'article sur la démotivation et l'abandon. Je verrai pour l'étoffer avec tes retours, si tu m'en donne la permission.


[PS après le message de Sephi: je serai curieux aussi d'avoir tes retours sur l'incremental game. Perso, je n'ai jamais accroché en tant que joueur, mais je dirai que du côté créateur, cela évite de passer trop de temps dans le code au profit du temps pour les assets, la diffusion, le CM, etc (un peu comme Dracca, qui ne m'a pas demandé des tonnes de code pur, et qui est finalement le jeu le plus aboutit de ma liste)]

RE: Comment ne jamais finir un projet de jeu - Thêta Tau Tau - 03-12-2016

(03-12-2016, 04:31 PM)Sephi-Chan a écrit : Tu pars donc sur un incremental game ? Sont-ils si simples qu'on le pense ?
J'ai l'impression que la complexité est cachée et qu'il faut un paquet de mécanismes à balancer au joueur au fur et à mesure.

C'est juste que ma "référence", cad. ce que j'ai cherché à faire pendant des années, c'est des MMO de stratégie par navigateur (on va dire ogame-like pour simplifier, même si je n'aime pas ce terme).

Et en gros, un ogame-like, ça ressemble quand même vachement à un incremental, sauf qu'il faut gérer la triche, les performances, le multijoueur, la persistance de l'univers etc. Du coup les incrementals par contraste c'est simple.

Après oui c'est vrai que les mécaniques à balancer au fur et à mesure, pour l'instant j'en suis encore à mécanique au singulier ><

Mais bon mon objectif c'est surtout de garder un délai de développement court (genre 2 mois). Si le jeu n'est pas terrible, tant pis, mon but c'est de le finir et de le publier (avec monétisation).

C'est un peu ça que je voulais dire en parlant de "culture de l'échec". Même si je ne gagne que 200€ en 2 mois (par exemple), ben j'aurais pas payé mon loyer, mais cet "échec" m'aura permis de m'améliorer.

Citation :J'avais un peu résumé certains points dans l'article sur la démotivation et l'abandon. Je verrai pour l'étoffer avec tes retours, si tu m'en donne la permission.

Vas y.

RE: Comment ne jamais finir un projet de jeu - niahoo - 03-12-2016

Trimps Smile

Perso je suis un gros fan du genre. Je te conseille d'aller sur reddit /r/ingremental_games , tu as les posts Mind Dump Monday et FeedBack Friday où tu as pas mal de bonnes idées qui passent.

RE: Comment ne jamais finir un projet de jeu - Argorate - 05-12-2016

Je suis d'accord Smile

RE: Comment ne jamais finir un projet de jeu - QuentinC - 14-12-2016

Bonsoir,

Je me reconnais aussi dans certains des aspects évoqués.

Si je compte tous les projets informatiques (pas jeux uniquement) que j'ai un jour démarré en tant qu'amateur (non professionnel), j'en ai effectivement abandonné 95% souvent pour une des raisons citées, et spécialement celles-ci:
* Écrire des pages et des pages de théorie sur le fonctionnement du jeu pour finalement se décourager en se disant que c'est hyper compliqué et que ça ne marchera jamais
* Coder tout le moteur du jeu, avoir un truc qui pourrait fonctionner pas trop mal, et se décourager au moment où on se rend compte qu'il y a tout le contenu hors code à faire: images, sons et musiques bien sûre, mais aussi map, level design, quêtes, scénario, équilibrage...

Pour cette dernière raison j'ai une expérience révélatrice: vers 2009-2010, j'ai voulu créer un mud. On pourrait dire que c'est un MMORPG à l'ancienne, les principes de jeu sont globalement les mêmes (personnage, compétences, quêtes, kill mob, groupage, donjons), mais c'est un jeu textuel où on interréagit avec le monde en tapant des commandes.
L'idée était séduisante, ça permet de faire un RPG totalement accessible et ne pas avoir à s'amuser avec des images, des sons et des interfaces compliquées; on a juste du texte. Ce qui m'arrange bien car je suis mal barré en ce qui concerne le graphisme.

Eh bien, je me suis démotivé le jour où je me suis rendu compte que le moteur de jeu était plus ou moins fini, et qu'il faudrait maintenant créer le monde en lui-même: carte, lieux, PNJ, quêtes, scénario, histoire. Parce que c'est marrant d'avoir une map de test avec deux trois mobs bidon à killer, mais c'est autre chose quand il s'agit de construire un vrai monde qui intéressera les joueurs, avec des vraies quêtes qui ont un sens.

Donc, à mon avis, règle importante si on veut maximiser les chances d'aboutir un jour: ne pas choisir un type de jeu où il y a beaucoup de contenu. Le top c'est que les joueurs eux-mêms puissent créer du contenu (en plus ça donne le sentiment de s'approprier le jeu).
En tout cas pensez-y si vous êtes comme moi !

RE: Comment ne jamais finir un projet de jeu - Xenos - 15-12-2016

Ouep, le contenu du jeu, c'est ce qu'un créateur de jeu est censé faire, alors que trop souvent, le codeur se limite au moteur (mieux vaut participer au développement d'un CMS ou d'un autre projet du genre dans ce cas).

Y'a un peu le même problème côté graphistes (sur dA par exemple): les amateurs créent tout un tas d'assets, de design, de concept art, de background etc, mais y'a pas la colle du code pour tenir tout cela... ^^

RE: Comment ne jamais finir un projet de jeu - Yohann - 18-02-2017

Sympa ton résumé, je pense que ça concerne beaucoup de monde.

De mon côté ça se passe comme ça aussi et même pire. J'ai commencé certains projets que je n'ai jamais fini car la démotivation ça va plus vite que la motivation.
Et surtout bien souvent j'ai une idée de projet en tête, ça me plaît pas mal et puis quand vient le moment de commencer à coder ... plus d'envie. Du coup le projet reste uniquement dans ma tête car je n'ai même pas la motivation de commencer...

Je ne sais pas si certains sont dans le même cas mais après une journée de travail dans le code ou dans le graphisme (dans l'informatique en général), c'est difficile d'arriver à trouver la motivation pour continuer à bosser sur des projets personnels dans le reste de la journée.

De plus, quand on a une vie de famille avec des enfants, il faut accorder du temps à tous le monde et là ça devient encore plus difficile de faire quelque chose