Informatique

Quel est le bon workflow pour faire un jeu-vidéo solo ?
Mine de rien, ya pas mal de choses à créer et puis c'est long. Je sens bien que je suis pas du tout optimale dans ma façon de faire alors je me demande, comment vous y prenez vous ?

Création de placeholder pour les graphismes Programmation des fonctionnalités de base Level design Graphismes définitifs Audio UI Polish ?

Decouper par disciplines (graphipsmes, programmation, audio, ui, etc.) n'a pas bcp de sens, car sauf exception il faut un peu de tout pour qu'une fonctionnalité devienne fonctionnelle. Donc il faut travailler de facon iterative par groupes coherents.

On parle de "tranches verticales" (vertical slice), c'est à dire que tous les domaines (mécaniques, graphiques, sons etc.) doivent progresser en même temps et que le jeu doit autant que possible être jouable à chaque étape. Avoir une version jouable en permanence permet de se rendre compte des problèmes du jeu le plus vite possible. Et ne pas faire des assets trop en avance évite d'avoir à les jeter si les besoins changent.

La vertical slice n'est pas liée á l'evolution du developpement ou á la progression des fonctionnalités. C'est un jalon important censé capturer l'intention du projet, en illustrant le jeu sur une tranche representative de l'experience utilisateur finale. C'etait tres populaire dans les annees 90-2000, oú c'était une condition de "greenlight" avec les editeurs ; mais est ajd abandonné, car souvent contre-productif, et inadapté aux jeux videos modernes avec plusieurs facettes orthogonales de gameplay. Cela peut cependant rester un outil interessant pour un petit projet mono-gameplay. Mais cela ne constitue pas une methodologie de developpement en soi.

Il faut se pencher sur les paradigmes et philosophies "Lean" pour trouver des propositions concretes de developpement iteratif adapté au jeu video. Considerer les fonctionnalités en groupes coherents, priorisr les objectifs intermediaires en fonction de tout un tas de facteurs (niveau de risque, complexité, gameplay, etc.), et recalibrer regulierement avec les connaissances et evolutions recentes.

Pour moi, ce qui a toujours bien fonctionne, c'est de faire un "produit minimum viable" en tout premier (un heritage de la methodologie Agile, en quelque sorte, pour rebondir sur ce que @refeuh mentionne).

Cela a plusieurs aspects positifs:
- Cela te force a te focaliser sur ce qui sera le "coeur" de ton jeu - si ses elements de base reduits a leur plus simple expression restent fun et relativement unique, alors tu as quelque chose de solide.
- Cela te permet de demontrer que tu as les capacite internes de construire ce que tu design...
- Cela te permet de reduire le "scope" de ce que tu construit, et reduit la prise de risque
- Cela te permet d'arriver rapidement a une base jouable, qui sera le point de depart de l'aspect iteratif
- Cela te donne un element facile a demontrer et partager en vue de recruter, financer le futur developpement, etc...

Hello (c'est bien pour commencer hein ? )

Pour faire un jeu, il faut considerer toutes les etapes en amont de la technique. Evidement ca depends de ce que tu veux faire, mais je considere que tu pars de zero. Donc le depart, c'est trouver une bonne idée et des mecanismes (concept) et puis les detailler pour voir si ca donne un truc sympa, ensuite faire un proto (ce qui a été appellé "produit minimum viable") et puis mettre des graphismes sympas et faire un niveau leché pour tester la chaine de prod (ce qui a été appelé "vertical slice"), et puis faire la prod, puis des tests, puis beta tests....
C'est en effet tout en ensemble de choses assez longues.
Je peux te pointer mon vieux making of du monde des ronrons, mais qui au niveau logique de conception tiens toujours : http://christophekohler.epizy.com/RonronsMakingOf/LeMondeDesRonrons_MakingOf_Intro.htm

(hey salut lux ... )

Je suis tombé sur une vidéo récente sur le sujet, que je trouve assez bien foutue :
https://www.youtube.com/watch?v=QndxP3Qcnd0

Hello (c'est bien pour commencer hein ? )

Tellement fatiguée que j'en oublie les rudiments de la politesse, honte à moi : Salutations à tous donc

Merci pour vos réponses, tout s'éclaire ! (même si, n'étant pas encore dans le monde du travail, je ne suis pas sur de cerner ce que vous entendez par "méthodologie Agile / Lean", mais je vois l'idée)

Et du coup, dans tout ça, vous mettez où l'étape : "Faire tester son jeu à d'autres joueurs" ? Quand on a la base du gameplay posée + des bons graphismes pour pas faire peur au joueur je suppose ?

C'est en effet tout en ensemble de choses assez longues.

Plus je progresse dans la création de jeux, plus je découvre de nouvelles disciplines et détails auxquels il faut penser. C'est un tapis sans fin ce truc
Merci pour vos liens, je m'en vais regarder ça tout de suite

Et bien ca depends de ce que tu veux faire tester.

Un bon jeu, meme avec des graphs pourris, restera un bon jeu. Car les mecanismes principal sont ce qui va apporter du "game play" et du plaisir de jeu. Si tes mecanismes sont nuls, ton jeu sera nul, meme si c'est le plus beau jeu du monde.

souvent dans les developpement professionnel, il y a un premier proto qui est fait pour faire tester les mecanismes. C'est tout fait en" block", sans vraiment de graphisme. Et la tu peux faire tester (en interne). Faut pas confondre avec les beta testeurs qui n'arrivent qu'a la fin. Perso je conseille de tester souvent, et trés tot. Si tes idées sont nulles, autant les couper/changer rapidement. C'est ca être agile.

Les tests il faut en faire beaucoup et le plus tôt possible. Quand on travaille sur un projet c'est compliqué de prendre du recul et du coup on passe souvent à côté de problèmes importants.

Mais dans la pratique faire tester un prototype moche et bancal c'est compliqué, parce-que ça n'intéresse personne et qu'en plus il faut que les testeurs arrivent à se projeter et à voir le potentiel derrière le prototype plutôt que le prototype lui même, et aussi qu'ils soient suffisamment honnêtes pour critiquer et pas juste faire des compliments creux. Les échanges de tests entre devs c'est ce que j'ai trouvé de mieux, j'en ai fait quelques uns sur des forums et sur discord. Il y a aussi le reddit destroy my game qui a ouvert récement.

Et la tu peux faire tester (en interne). Faut pas confondre avec les beta testeurs qui n'arrivent qu'a la fin.

Oh ok, effectivement, je crois que je confondais avec les beta testeurs, je comprends mieux

Mais dans la pratique faire tester un prototype moche et bancal c'est compliqué, parce-que ça n'intéresse personne et qu'en plus il faut que les testeurs arrivent à se projeter et à voir le potentiel derrière le prototype plutôt que le prototype lui même, et aussi qu'ils soient suffisamment honnêtes pour critiquer et pas juste faire des compliments creux.

Ouais, c'est ce que j'avais cru voir. Merci pour les pistes de solutions !

Merci à tous pour vos réponses