Les étapes de la création d'un jeu : votre avis

[sharyma]

Bonjour tout le monde !
J'ai commencé il y a quelques jours un blog sur les jeux en ligne, axé sur leur création. J'ai notamment rédigé un billet concernant les différentes étapes de la conception d'un jeu. Cependant ces étapes ce sont les miennes, la manière dont je procède moi, et je serai curieuse de savoir si vous aviez des méthodes de travail différentes !

Voici les miennes :
AVANT
• imaginer le jeu
• faire le tri
• élaboration du cahier des charges
• MCD
• UML

PENDANT
• développement du jeu
• illustrations
• mise en page

APRES
• version alpha
• version béta
• ouverture


Je précise que je me suis basée sur la conception d'un jeu amateur, et que je ne traite pas du tout (dans ce listing) de choses comme les échanges entre les membres de l'équipe, ou encore le choix du framwork, l'utilisation d'un système de versionning etc.

Voyez-vous d'autres étapes ?



L'article du blog : comment créer un jeu en ligne : les étapes

[Sephi-Chan]

Je trouve cette liste un peu légère, de même que l'article qui va avec. Désolé de dire ça mais on n'y apprend pas grand chose au final.

À mon sens, le premier défaut est de ne pas montrer l'aspect itératif du développement d'un jeu. Aucun jeu ne sort dans son état final : il arrive avec un lot de fonctionnalités réduites, puis il s'étoffe au fil des versions. Chacun de ces cycles implique une nouvelle phase de recherche, de tris, de développements, de tests et de mise en production.

Concernant la phase de conception, j'ajouterai l'élaboration d'un fil rouge que toutes les fonctionnalités serviraient, histoire de ne pas avoir un jeu qui part dans tous les sens. Je pense également qu'il est capital d'intégrer les mécanismes de rentabilité au plus profond du jeu, pour que ça ne fasse pas pièce rapportée.

Enfin, je me passe totalement d'UML, je trouve que ça n'apporte rien.

Je pense également qu'il est important d'ajouter des tests automatisés, pour que l'application ne régresse pas au fil du développement.

[Argorate]

Si tu es seul programmeur, tu peux te passer du MCD & UML, tu gagneras du temps...

Sauf si tu n'as pas une bonne mémoire et un manque de projection.

Et il manque la plus importante de toute les étapes aussi...

dans "APRES" empresse toi de rajouter : "de longue heure à maintenir, corrigé et améliorer le jeu, tout en gérant la communauté !"

[sharyma]

Sephi-Chan :

Je ne comprends pas trop ta réponse...

-> on n'y apprend pas grand chose : pour toi qui sait maitrise déjà le sujet oui, mais mets-toi à la place d'un "gamin" qui veut créer son jeu... à mon avis il n'a aucune idée de la quantité de travail que cela demande et n'aurait même pas pu citer la moitié des étapes dont j'ai parlé. Donc je ne pense pas que cet article soit inutile, tu ne fais juste pas partie de la cible, c'est tout ^^

-> le fait qu'aucun jeu ne sorte dans un état final, je suis totalement d'accord, mais en quoi est-ce que cela fait partie des principales étapes de création d'un jeu ? Dans ce récapitulatif, je parle uniquement de ce qui est fait avant l'ouverture, pas après. Ca, ce sera l'objet d'autres articles.

-> pour le fil rouge, ce n'est pas une étape en soit mais une composante du développement, du moins à mon avis. Peut-être me trompes-je ?

-> pour la rentabilité, j'ai bien indiqué qu'il s'agissait d'un jeu amateur (donc sans aucune structure juridique derrière et donc pas le droit de gagner de l'argent avec son jeu) ! De toute manière, personnellement je l'incluais dans les premières étapes, à savoir la rédaction du cahier des charges etc.

-> concernant l'UML okay, chacun son point de vue. Personnellement je ne m'en suis pas servie pour mes premiers jeux mais je l'utilise pour celui sur lequel je bosse actuellement (enfin de manière très simplifiée, je liste juste les classes, indique leur genre et les méthodes qu'elles contiennent, et précise si elles héritent ou non d'autres classes) : bien que ce soit rébarbatif et long, je trouve que cela permet d'avoir plus de recul sur son projet et de mieux le visualiser. Et au final, on gagne du temps.

-> tout à fait d'accord pour les tests automatisés, pour moi ils se placent dans la partie alpha/béta, mais tout le monde ne procède pas ainsi. Pour tout avouer, je n'en ai encore jamais fait (même si j'en saisis bien l'intérêt et que je me dis qu'il faut que je m'y mette), du coup je n'ai pas osé l'évoquer car je ne pense pas être en mesure de rédiger un article dessus par la suite.


Après comme c'est marqué dans l'article, je ne dis pas que tout le monde fait comme moi, je présente juste ma manière de faire, qui n'est pas forcément la meilleure. Mais si j'ai créé ce poste c'est justement pour avoir des retours de personnes expérimentées et donc d'avoir des avis différents ^^
Et je précise que cela n'est qu'un récap, toutes les étapes (ou presque) auront un ou plusieurs articles qui leur seront dédiées afin de bien faire comprendre au futur créateur ce qu'il "doit" faire


En tout cas merci pour ton retour !




Argorate :
oui c'est sûr pour le "après" mais en fait je ne voulais pas traiter cette partie dans le récap (une erreur de ma part ?), je voulais vraiment mettre l'accent dessus via un autre article ^^
Perso je trouve le MCD indispensable, sinon on a vite fait de faire une structure sql bancale :/ Mon premier jeu je l'ai fait sans, ben je me rends compte maintenant qu'il y aurait énormément d'améliorations à faire de ce côté-là... Bon après ça dépend des personnes et des projets, je suppose

[Argorate]

Je préfère la pratique aux MCD, ainsi plus le temps passe moins je fais d'erreurs de conception (même si j'en fais toujours sans doute )
Après, c'est plus où moins toujours les même cas qui revienne.
Si ce n'est les cas spécifique où tu as un choix a faire. (mais pour ces cas là, a mon avis regarder la structure de la table suffit à comprendre comment tu as modélisé (évidemment si vous êtes plusieurs a coder, c'est différent, j'entends bien, je parle quand tu es solo)).

Mais bon ce n'est que mon avis^^

Et pour te répondre, ne pas parler du travail du "APRÈS" me semble une erreur, car si comme tu le dis la cible sont les "gamin" qui ne voit pas plus loin que le bout de leur né, alors tu auras beau leur apprendre tout ça, et ils y arriveront peut être a le réalisé, mais ils auront une belle surprise a l'arrivé : "et non c'est pas fini, au contraire ça ne fait que commencer !" ^^
beaucoup pourrait se décourager et finalement avoir perdu leur temps car ils n'avaient pas prit en compte ce facteur.

[Sephi-Chan]

-> on n'y apprend pas grand chose : pour toi qui sait maitrise déjà le sujet oui, mais mets-toi à la place d'un "gamin" qui veut créer son jeu... à mon avis il n'a aucune idée de la quantité de travail que cela demande et n'aurait même pas pu citer la moitié des étapes dont j'ai parlé. Donc je ne pense pas que cet article soit inutile, tu ne fais juste pas partie de la cible, c'est tout ^^

J'avais bien compris que je n'étais pas la cible, mais je trouve que le débutant qui veut savoir comment créer un jeu n'y apprendra pas de choses vraiment utiles. Soit il est débutant complet et les simples termes MCD et UML lui feront peur, soit il est un peu moins débutant et il a déjà accumulé des idées et les a présenté pour passer au développement.

Après, lancer le jeu avec des bugs et le faire tester par des copains/de la famille, c'est la suite logique et ça tient du bon sens.

Du coup je ne comprends pas trop à qui ça s'adresse.

-> le fait qu'aucun jeu ne sorte dans un état final, je suis totalement d'accord, mais en quoi est-ce que cela fait partie des principales étapes de création d'un jeu ? Dans ce récapitulatif, je parle uniquement de ce qui est fait avant l'ouverture, pas après. Ca, ce sera l'objet d'autres articles.

C'est capital, au contraire : il faut bien expliquer au débutant créateur qu'il va devoir sortir une première version qui ne contiendra pas tout ce qu'il souhaitait initialement.

-> pour le fil rouge, ce n'est pas une étape en soit mais une composante du développement, du moins à mon avis. Peut-être me trompes-je ?

Ce que je veux dire, c'est qu'il faut axer son jeu suivant un ou deux thèmes et qu'il faut que tous les mécanismes de jeu servent ce thème. Ne pas mettre des trucs parce-que-c'est-trop-cool-de-pouvoir-tout-faire. Si tu fais un jeu de survie dans un monde de zombie, c'est peut-être pas utile d'avoir des mécanismes pour élever un petit chien qu'il faudra nettoyer et dont il faudra ramasser les crottes.


Voilà, voilà, j'espère que mon propos est plus clair ainsi. L'initiative est très bonne, mais je pense qu'en l'état, l'article a un peu le cul entre deux chaises.

[Arius Vistoon]

il manque effectivement quelques truc..
Selon moi il faut savoir évaluer le projet (de manière itérative, scrumLand quand tu nous tiens) donc avec le cahier des charges technique et celui fonctionnel, il faut une estimation de chaque tache (dans sa globalité en amont et fine en aval).

Pour ce qui est d'UML, je considère que c'est indispensable mais ceci dit sur un petit projet cela peut faire perdre plus de temps qu'en gagner (NB : pour moi, l'uml avec notamment ces packages permet de savoir quoi développer en premier et quoi parallélisé et ce de manière optimum, quand aux schémas classiques ils permettent de développer la structure objet, la base de donnée et d'avoir une idée clair que quoi fait quoi par rapport a quoi...genre le truc que j'affiche dans mon bureau et dans ceux des développeurs...sans oublier les quelques diagrammes qui permettent sans effort de faire le cahier des charges fonctionnelles)

EDIT :
j'ai prit le temps de lire ton article du coup, je rejoins ce que dis Sephi-Chan.
Avec en plus, le fait que je ne ferais pas d'étape de tri (jamais ! ou du moins pas comme c'est dit). Il y a forcement une étape de tri mais cette étape est a chaque itération et de doit pas mettre des idées a la poubelle (elle doit juste les ordonnancer en lot de sortie/version du jeu). Car une idée pas bonne maintenant, peut etre bonne plus tard (par contre une idée jugée pas bonne maintenant et jetée aux détritus risque de jamais resurgir...en l'état, et là on regrette de ne pas l'avoir gardé).

[Math]

Bonjour,

Je trouve qu'il manque l'étape crucial pour se positionner par rapport au marché. Qui fait un jeu sans connaitre ce qui existe déjà dans le même domaine? (Si tu veux faire quelque chose de novateur)
De même la veille technologique doit se prolonger tout du long de la conception.

En gros le coté marketing ne se résume pas qu'à la publicité et au jolie design. Vive le positionnement! (désolé j'avais besoin de me lâcher après cette journée...)

[sharyma]

D'accord, merci pour ces retours, je comprends mieux les points faibles de mon article et je vais le retoucher.

Il reste juste un point : le but est bien de présenter un récap des choses à faire de l'imagination du jeu à son ouverture, je trouve vraiment que ce qu'il y a après (donc mise en garde sur le fait qu'il ne s'agit pas d'un produit final etc) n'ont rien à faire dans ce récap-ci, mais trouveraient plutôt leur place dans un autre article. Quoiqu'il en soit, il est évident que c'est un point très important que je me dois d'évoquer.
Mais du coup, je me suis relue afin de mieux comprendre vos critiques, et je me dis que ma 9ème étape (à savoir faire connaître le jeu & le maintenir) n'a pas sa place non plus dans l'article, car justement, ce n'est pas son objectif.

Je vous ferai signe lorsqu'il sera modifié


Et n'hésitez pas à continuer de critiquer cet article ou, plus généralement, à expliquer comment vous procédez pour créer un jeu.




EDIT : je viens de lire ta réponse Math. Je rappelle que mon article se situe dans le cas d'un jeu amateur, créé par passion. Le but n'est pas forcément de faire un jeu novateur mais de faire ce qu'il nous plait, et tant pi s'il y a des milliers de jeux qui fonctionnent de la même manière !
Par contre, dans le cas d'un projet professionnel, il va de soit que cette étape est cruciale et détermine tout le projet.

[Aikannaro]

C'EST NUL! :fache:
Non! Pas taper! :malade::cogne:

Bref, je suis un de ceux que tu nomme "gamin" et pour moi je pense que ton topic est intéressant. Le seul truc c'est que je lis ça et je me dis.. Ok mais ça c'est quoi? Comment on fait ça? Pourquoi on fait ça?
Trop de questions quoi.

A ta place je mettrais un petit plan comme tu as fait et j'étofferai après en petit paragraphe, quitte à mettre des liens vers d'autres topics du forum qui explique la création MCD. "C'est quoi un MCD? :$". Voir même mettre des liens sur chaque partie comme vers le forum développement (au cas où une personne ne sait pas utilisé tout ses boutons de sa souris ou la barre de scrolling.

Personnellement je verrais un truc du genre:

AVANT
• imaginer le jeu
C'est une étape importante où il faudra que vous imaginez tels ou tels partie du jeu sans intéressé vraiment à la partie programmation. Créez vous une histoire, un monde bien étoffé et mettez tout sur papier pour ne rien oublier!

• faire le tri
C'est bien de s'imaginer plein de truc. Mais faut pas qu'un joueur ne comprenne rien du tout d'un monde sortie directement de la tête d'un fou. Synthétisez, triez les informations du jeu. Prenez que le minimum. Vous pourrez toujours étoffer votre jeu quand celui ci sera opérationnel
• élaboration du cahier des charges
Bla bla [lien création d'un CDD]
• MCD
Bla bla. C'est quoi un MCD? :$ Ba c'est bla bla. [Lien création d'un MCD (si y'a)]
• UML
...

PENDANT
...

Enfin voilà quoi un sujet plus construit, plus développer que les noobs comme moi puisse lire et comprendre.

Je n'ai pas encore eu le temps de fouiller le forum en fond et en large donc je n'ai que peu d'informations encore et ce sujet pourrait m'aider énormément.

Sinon Merci pour ce topic qui part d'une bonne intention je pense

PS: Ce que j'ai mis dans la quote c'est surement n'importe quoi c'est juste un exemple :$