Bonjour,

Suite a une discussion palpitante sur la creation d'un jeu sur un autre thread , je me suis dit que ca serait interessant d'en creer un autre ( thread ) sur la conception, la creation et la programmation d'un jeu de A a Z ( excepte la publication, la distribution et la vente de celui-ci ).

Mise en situation : "Youppi, les gars, fesons un super jeu en 3D d'un sniper qui se promene et qui tire sur tout ce qui bouge, qui se premene en jeep et etc.. et etc.. On ferait ca en M++ pi ca nous prend full de monde ".

Bon, le M++ est un langage fictif que tout le monde connait qui ne veut que simplifier la discussion. Cet exercice se veut tres general et on peut y aller de nos idees meme si on n'y connait pas grand chose .

Alors, selon vous, comment procederons-nous?

_________________
---
Kaltar
Kaltar@yahoo.com
[...Reality is only a representation of your sense data which is always mixed with noise.]

Regarde le générique de n'importe qu'elle jeux...
Plusieur leader
Un dégats de programmeurs dans toutes les disciplines
Plusieur sound man
des acteurs
des dizaines millier de $$ en équipement
Des musiciens
des chefs d'équipes
des dessinateurs
des infographistes
des écrivains
des gros locaux
des penseurs
des tonnes de pizzas
des salles de repos et aires de jeux.
des testeurs etc etc etc
et j'en passe...

C'est un peu plate à dire, mais la procédure, dans la majorité du temps, se résume à ceci:

- Tout le monde est très motivé et est prêt à se donner à fond. Chacun mentionne ce qu'il est capable d'offrir.
- Quelques personnes offrent des esquisses bien jolies mais inutiles.
- Des idées qui semblent être géniales sortent. On définit des cadres comme le C++ comme langage de prog (la raison étant parce que tous les jeux sont supposément faits en C++). Des détails très innovateurs voient le jour des fois.. sans vraiment tenir compte de la faisabilité, mais ça semble être secondaire anyway.
- Tout le monde commence à se demander par où commencer.
- Tout le monde attend de voir par où ça va commencer.
- Quelques personnes depuis le début trainent déjà de la patte, les autres commencent à se décourager.

Habituellement ça s'arrête ici. Mais des fois ça va un peu plus loin:

- Une personne prend le lead et met de l'ordre dans tout ça.
- Chaque personne voit le leader définir des tâches. Tout le monde se dit que c'est pas intéressant de travailler dans un cadre aussi bien défini et lâche le projet. Tsé après tout, tout le monde fait ça pour le fun, ce qui veut dire que personne n'a le goût de faire les jobs plates, mais comme dans tous les projets, y'a de très gros bouttes plates qui sont nécessaires. Si personne les fait, ben y'a pas de projet.
- Le leader lâche le projet, faute de ressources.

Bizarre qu'on associe la création d'un jeu à de la programmation. C'est un peu comme si je disais que pour inventer des autos, il faut être mécanicien.

_________________
Procyon,
Modérateur de la section Trouvailles

HAHAHA

Merci pour vos reponses, je m'attendais pas a ca mais c'est mieux que rien. Pi c'est assez vrai dans ce que j'ai lu. Surtout pour la pizza.

Malheureusement, c'est vrai que ca va pas loin la plupart du temps( sinon tout le temps). Mais le pire, c'est de ne pas essayer parce qu'on se dit que ca marchera pas..

Peut-on esperer qu'un projet puisse demarer et continuer et meme finir? Pourtant ca s'est deja vu et ca se voit encore des projets auxquels les participants ne se voient quasiment pas.

C'est vrai aussi que ca prendrait de l'analyse dans la creation d'un jeu. Mais malheureusement, dans le domaine, il faut programmer dans un laps de temps tellement court, qu'il n'y en a pratiquement pas. Il faudrait bien qu'un jour, on voit naitre le metier d'"Analyste de jeux"...

_________________
---
Kaltar
Kaltar@yahoo.com
[...Reality is only a representation of your sense data which is always mixed with noise.]

Un analyste de jeu?

En fait, il faut tout d'abord un concepteur de jeu, et ca, ca existe déjà.

Ensuite, le ou les concepteurs rencontrent des analystes et des chefs de projets et ensemblent ils définissent le cadre du projet. Ils déterminent les différents besoins en ressources humaines, le budget, les plateformes, les différents outils, le but et les échéances.

Quand le plan est finalement sur la table et que tout le monde est satisfait, on enclanche le processus de développement. On engage des gens, on achète les outils et on développe. Pas juste la programmation, mais tout, graphisme, sons, différents programmes et modules utiles soit directement pour le jeu ou encore pour son équipe développement..

Pendant le développement, y'a des mises-à-jour constantes des données du projet selon les contraintes rencontrées; échéances mal évaluées, achat imprévu, bug irremédiable, sous-estimation ou sur-estimation de fonctionnalités, etc...

Alors en premier lieu, au lieu de penser à programmer et à savoir si c'Est mieux de faire son jeu en C++ ou en VB, il faudrait tout d'abord avoir passé plusieurs semaines à mettre sur papier le concept du jeu de A à Z, tout ce qui sera dans le jeu doit être d'abord sur papier, toutes les options, toutes les fonctionnalités doivent être définies et expliquées. Toutes les interactions entre les concepts du jeu doivent être claires.

Quand ça c'Est fait, il faut ensuite trouver quelqu'un qui saura évaluer comment ça peut être faisable. Quelqu'un qui pourra dire que telle ou telle chose devrait être éliminée ou remplacée par autre chose, qui pourra évaluer le temps de développement, qui pourra trouver les outils qui pourraient servir. Cette personne ou groupe de personne aura ensuite la tâche d'analyser le concept et d'en faire un dossier fonctionnel complet, ce qui décrira chaque élément du concept d'un point de vue informatique et qu'un programmeur sera en mesure de comprendre.

Ensuite, quand le dossier est prêt et accepté par tout le monde, on engage les ressources. Chacun se voit attribué une tâche précise et une échéance qu'il doit respecter pour ne pas nuire à la cohérence du groupe. Les programmeurs ont des modules précis à développer tels que définies par l'analyste, il doit les suivre à la lettre et ne pas déroger (ou pas de façon majeure) du plan prévu pour encore un fois ne pas nuire à la cohérence du projet.

Voilà en gros ce qu'il faudrait faire...

_________________
Procyon,
Modérateur de la section Trouvailles