03-12-2016, 01:59 PM
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]](http://image.noelshack.com/fichiers/2016/48/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 :'(
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 :
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 :'(
