Y a pas que la technique

[Kalan]

Bonjour,

je suis un "p'tit nouveau" sur JeuPHP mais j'écume le monde des jeux alternatifs (vous appelez ça jeux PHP) depuis le début du siècle (woaw ! On dirait les paroles d'un vieillard ;-) ).
Je dirige des projets informatiques de puis une bonne dizaine d'années souvent orientés gestion ou processus d'entreprise.

Tout ca pour dire, que quel que soit le projet, l'importance de la phase de spécifications (décrire en détail ce que doit faire le système) et de conception (décrire comment fera le système) sont essentielles.

Transposé dans le monde du jeu, on parle de "gameplay" pour les spécifications. Et, d'expérience, c'est bien plus compliqué de faire un dossier de gameplay cohérent qu'un dossier de spécifications pour un projet de gestion quel qu'il soit.

Il se trouve qu'ici, j'ai vraiment l'impression que la plupart des intervenants viennent avec des questions techniques ou de programmation sans avoir précisément défini ce qu'ils veulent faire. Ils ont en effet une idée plus ou moins précise; mais rien n'est détaillé, écrit noir sur blanc.

En tant que professionnel de la gestion de projet et amateur depuis 7 ans des jeux en ligne, ca me choque !
Tant d'énergie, de compétences voire de talents qui risquent TRES fortement de finir aux oubliettes parce que le système ne repose que sur des idées qui n'ont pas été formalisées.

La section "professionnalisation" propose de bonnes bases pour la phase de conception; mais il manque, à mon avis, les conseils et peut-être des modèles, de définition du gameplay. Elements à mettre en oeuvre AVANT la conception.

Je me doute que beaucoup ne voudront pas exposer le système auquel ils pensent de peur de se le faire "voler" (même si c'est une erreur); mais le type de questions à se poser et la NECESSITE de répondre à chacune d'elles de façon précise peut être débattu et finalement exposé.

Un "plan-type" définissant ce qui doit figurer dans le dossier pourrait être rédigé et proposé. Ceux qui ont finalisé un jeu pourraient mettre à disposition le document sur lequel ils se sont appuyés et les erreurs et/ou manques qui se sont révélés au cours du développement, leurs impacts.

Nous pourrions discuter du contenu et le critiquer de manière constructive tout ca pour que chacun puisse bénéficier du retour d'expérience de tous.

Bref, capitaliser nos expériences respectives pour toujours améliorer nos méthodes et nos jeux, inciter à adopter une attitude professionnelle pour nos jeux amateurs.

Si ca intéresse du monde, je peux même commencer en proposant les spécifications que j'avais faites pour Gloire et Pouvoir (si je les retrouve :-) ) et appuyer sur les énormes lacunes qu'elles contiennent, ce que ca a signifié en termes de travail de "sauvetage" et les impacts que ca a encore aujourd'hui, presque 7 ans après.

Qu'en dites vous ?

[blackduty]

Oui, il y a aussi Ebl... euh

Parfaitement d'accord sur l'importance de la cohérence du gameplay. C'est d'ailleurs pour cela que j'ai recommencé a formuler l'intégralité de mon projet...

PS: Une nouvelle section ? En regroupant avec l'idée d'Isenduil sur comment faire un Roleplay cohérent ?

[joshua]

tu preches un convaincu... Un jeu, c'est avant tout un cahier des charges très complet et beaucoup de reflexion.
Ca prend du temps.... On ne se lance pas dans le code tete baissée.... mais beaucoup ignorent ce conseil ^^

[Zippo]

L'idée me parrait interessante, mais en effet beaucoup de gens garde jalousement leur idées, surtout si ils savent que ça mettra plusieurs mois a monter et si une personne qui maitrise mieux le domaine du devellopement veux le doubler il n'hésitera pas. C'est vrai qu'il n'y a pas non plus que des méchants voleurs de projet mais ça rend pas les choses facile.

Donc si j'ai bien compris on viendrais exposer nos idées et il y aurait des membres compétents qui regarderons si on si prend bien ou pas, c'est ça ?

[Galaan]

Je suis d'accord... En theorie.

Dans la pratique, c'est beaucoup moins vrai. On decide de se lancer dans un projet ou la seule vrai motivation c'est la passion qui anime le(s) codeur(s). Or la passion, il faut l'alimenter.
Si on consacre une ou deux heures pas jour sur son projet, arriver a un resultat aboutit sur papier peut prendre plusieurs semaines, et je pense etre optimiste. Si je prend en compte mon experience personelle, j'avais decider d'etre serieux et de faire les choses biens. J'ai renonce au bout de deux heures... J'avais pas fini un paragraphe que deja j'avais de nouvelles idees que je ressentais le besoin de le reecrire. Bilan, en deux heures je n'avait rien fait.
J'ai decide de plonger et de coder le moteur directement. Au bout de deux heures, j'ai vu se disputer le premier match entre deux bots. Et la... Ma motivation s'est decuple et je savais que j'allais aller au bout !
Cela dit, je reste convaincu que si j'avais consacre un peu plus de temps sur l'analyse et la recherche (le fameu R de R&D) au debut de mon projet j'aurais evite quelques grosses coquilles que je me trimballe encore jusqu'a aujourd'hui. Mais, est-ce que mon site aurai vu le jour ?

Galaan

[joshua]

On a déja essayé quelque part de faire un cahier des charges type mais ca a dérapé si je me souviens bien... Car bien souvent le concept de depart est un peu fouillis et on s'y perd....
Mais si tu as le courage, je vote pour toi ^^

[Kalan]

En fait, il ne faut pas rêver. La "peur" de se faire piquer ne idée sera la plus forte.
Alors ce qui serait intéressant c'est d'expliquer la démarche en donnant des exemples.
Une fois que le jeu est sorti, on n'a plus peur de se faire piquer l'idée :-). Donc on peut proposer sa phase de définition du gameplay et on a le recul pour décrire ce qu'il y manquait et les conséquences que ca a eu.

[joshua]

interdit de rep en meme temps :p
Mais je susi d'accord, apres coup c'est plus simple

[Harparine]

J'aime beaucoup ton idée et je suis également un fervent partisan du "travail papier" (même si dans les faits, je passe plus de temps sur mon gameplay que ma modélisation). Si vous partez sur une sorte de "cahier des charges type", j'essaierai aussi de faire avancer les choses avec ma propre expérience. D'ailleurs, je crois que naholyr avait déjà posté un document très intéressant et structuré sur son gameplay sur les zombies...

[gottferdom]

Je suis tout à fait d'accord avec ce qui est dit, ayant moi même été programmeur (dans des domaines plus spécifiques), c'est une partie très très importante.
Mais ce qu'il ne faut pas se cacher, c'est que d'après ce que j'ai pu voir ici la plupart des demandes d'aide viennent de gens qui ne savent même pas ce que veut dire programmer, ils veuillent apprendre sur le tas (et encore, quand il ne demande pas 15 codeurs pro pour les aider) et pense qu'on réalise un jeu comme on fait une simple page web avec 2 tableaux. Le cahier des charges je suis même pas sur qu'ils sachent ce que c'est.. ils n'ont surement aucune idée de comment realiser un projet, quelles etapes peuvent etre importantes, etc.
Et le travail papier est a mon avis proche de 0%.
Donc je doute que ces personnes là ne viennent lire une methodologie complète, parce ce qu'ils veuillent c'est avoir un truc tout fait, tout de suite, sans avoir a se casser la tête en fesant des algos ou autre.

Par contre, pour l'infime pourcentage qui reste, ce que vous proposez peut etre très très interressant et vraiment utile ! Très bonne idée