Le Jdr Online, Plusieurs questions

Voilà, à l'aide d'une équipe composée de 8 membres (1 graphiste 2D + 2 graphiste 3D + 2 codeurs flash/php + 3 rpgistes) nous nous sommes lancés dans la construction dans un jdr online afin de tester nos capacités et d'offrir aux internautes un jeu ou ils trouveront plaisir et amusement.

Seulement plusieurs questions me tracasse.
Quel est le temps pour construire un jeu de role?
Devenons nous attendre que tous soit réunit pour le sortir en béta? (graphismes etc...)
Que devons nous préparer à l'avance pour que le jeu marche bien?

Merci de répondre à toutes ces questions

2 ans et demi que nous sommes sur le notre et c'est pas fini!

Oui mais tu ne l'as pas ouverte au bout de deux ans il me semble ^^
D'ailleurs bravo pour ton jeu, j'y ais moi même joué, et le role play est excessivement bien fait

Je serais tenté de répondre : ça dépends

Vu ton équipe, je suppose que vous avez tout de suite mis en place une structure, vous avez une timeline, etc ? Je dirais que si ce n'est pas le cas vous devriez vous y mettre. Avoir une bonne analyse et des milestones bien claires ça aide énormément. Vu le grand nombre de personnes impliquées, je compterais 3 mois minimum pour avoir quelque chose de bien clair. Contrairement à ce que pensent les gens en général ce n'est pas du temps perdu. Au contraire, vous avancerez nettement plus vite ensuite.

Ensuite le temps de développement dépends de votre temps libre (impressionnant hein comme réponse ) et de la façon dont vous gérez le tout. Encore une fois c'est extrèmement variable. Allez, à la louche, disons qu'après 6-12 mois vous pourriez avoir une version jouable et représentative du jeu final.

Sinon, oui, attend d'avoir une version quasi finale pour sortir ta bêta publique. De toute façon, ta bêta doit servir à tester, autant tester sur une base saine qui représente vraiment ce que sera ton jeu.

Enfin, lis utilement le post de Nuilok au sujet du développement d'un jeu. Il y a nottament un lien (Kamron) très intéressant dans ton cas.

en post ouverture le projet nous a pris 6 mois avant l'ouverture de la beta.

(tu as joué à TdT? Qui étais tu?)

moi j'ai mis directement en ligne , car au début , je voulais juste m'amuser à faire un petit jeu pour qqes amis , finalement j'ai continué à developer pendant deux ans et ce n'est toujours pas fini

l'avantage de mettre en ligne tout de suite c'est que les joueurs peuvent venir tout de suite et rester si on fait des mises à jour reguliere

l'inconvenient c'est qu'on se fait incendier dans les critiques vu que le jeu n'est pas terminé ( en plus ca avait pas mal cafouillé au début ( supression de comptes , failles etc ... ))

avec l'experience , si je me lance dans un nouveau jeu , je pense qu'il vaux mieux faire une petite version béta privée limitée à 10-20 joueurs de confiance histoire de developer le jeu sereinement et ensuite , ouvrir une beta publique pour voir comment le jeu gere une masse plus importante de joueurs et puis une fois qu'on juge que le jeu est tout à fait jouable , je pense qu'il faut l'ouvrir au public

Effectivement l'article de kamron est bon, simple, et tellement vrai

Pour ce qui est du temps de développement, c'est extrêmement variable, mais comme ça a été dit plus tôt, faut pas oublier de prendre le temps de tout poser au clair au début : si on a des objectifs mals fixés, on va être tentés de les modifier en route, ou de se rendre compte que c'est pas faisable/ pas intéressant. Surtout à plusieurs, ce qu'on a pas écrit clairement, est-ce que les autres l'ont compris pareil ?

Evidemment les outils qu'on utilise vont énormément jouer dans cette phase, si on n'y connaît rien en PHP est-ce que c'est vraiment dans ce langage qu'on doit faire son jeu ? Et si oui, faut peut-être se faire la main sur des "petits" projets. Ca rejoint l'article de kamron sur les mods : c'est moins glorifiant, mais le moteur d'un jeu est un outil comme un autre, et il a déjà fait ses preuves.


Pour la bêta, je suis plutôt de l'avis de Xaero : Une bêta privée donne déjà de bons résultats, et on maîtrise bien ses testeurs, on peut leur dire "Je viens de finir cette fonction, faites moi planter tout ça !" Et on peut constituer un noyau dur qui gravitera toujours autour du jeu, avec toujours des bons conseils, et une vue plus objective du jeu, quand on est la tête dans le guidon on peut perdre de vue certaines choses.

Moi par exemple, dans l'euphorie de grosses avancées de prog je me suis lancé dans un système d'inventaire assez poussé (à la diablo quoi, et vu mon niveau en prog...), et j'y passe évidemment beaucoup beaucoup de temps, alors que franchement c'est pas ça qui va changer l'intérêt du jeu.

Donc voilà, le dernier conseil que je donnerais, du haut de ma ridicule expérience, ce serait d'aller à l'essentiel, de pas s'attarder sur des trucs pas importants. Parfois on peut avoir envie de voir tel ou tel truc (souvent des choses graphiques d'ailleurs) alors que c'est pas ce qui compte : Si les effets visuels des sorts apparaissent un peu plus tard, voire pendant la bêta, ça va pas dégoûter grand monde.

Voilà voilà, j'espère que ça aide un peu, c'est les problèmes que j'ai affronté, donc c'est pas forcément ce qui te posera problème à toi.

En tout cas bonne chance !

La particularité des projets perso (solo ou en groupe) est que l'on est à la fois maîtrise d'ouvrage (ceux qui disent ce qu'ils veulent) et maîtrise d'oeuvre (ceux qui réalisent).

A première vue ça peut paraître plus simple... mais en fait non (vous l'aviez pas vue venir celle là).

Même si c'est un exercice contraignant lorsqu'on piaffe d'impatience de réaliser son jeu (ou quoi que ce soit d'autre d'ailleurs), il faut vraiment séparer les étapes, en particulier chronologiquement :
1. maîtrise d'ouvrage : dire (et écrire) ce que vous voulez que votre jeu fasse dans les grandes lignes (le cahier des charges), puis une fois ce travail fait, formaliser en détaillant les fonctionnalités découlant du cahier des charges (les spécifications fonctionnelles).
2. maîtrise d'oeuvre : décliner les spécifications fonctionnelles du point de vue de leur mise en pratique technique (les spécifications techniques) et seulement ensuite réaliser le projet en se basant sur les spécifications techniques (dev, tests, etc...).

Bon, ça c'est en théorie... en pratique il faut surtout éviter de faire l'étape 1, puis 2 en partie, puis 1 sur un petit bout, puis 2 en changeant des choses, puis re-1, etc... c'est une histoire sans fin.

Tant pis si on s'apperçoit qu'il y a quelque chose à changer en cours de route : il faut aller jusqu'au bout de l'étape 2 sans revenir sur l'étape 1.

En revanche, une fois le cycle terminé, il est possible et généralement souhaitable (à moins d'avoir du premier coup réalisé le jeu parfait ) de relancer un nouveau cycle dont le but va être de faire évoluer l'existant.

Il est aussi tout à fait envisageable de prévoir un projet découpé en plusieurs lots (tranches) ayant chacune leur cycle de réalisation et étant intégrées (assemblées) une fois toutes terminées... mais ça c'est une organisation un peu plus complexe puisque les cycles de chaque lot peuvent se dérouler à la suite, en même temps ou en déphasage (l'étape 2 du lot 1 en même temps que l'étape 1 du lot 2 par exemple). Bref...

Et bien je vous remercie pour toutes ces aides, qui je l'espère me seront précieuses.
Pour le moment j'ai formé un briefing ou plutôt cahier des charges pour chaque tache.
- Briefing role play afin de connaitre ce que nous avons fait, ce que nous devons faire, mais principalement, ou nous allons

- Briefing Codage afin qu'ils sachent les options du joueurs, de la map, tout ce qui leurs sera nécéssaire pour coder sans se poser telles et telles questions (souvent le plus dur, car il faut connaître vraiment tout ce que nous souhaitons faire dans le jdr :s)

- Briefing graphiste afin qu'ils comprennent les étapes à suivre, l'ordre, et surtout l'environnement et le type de batiments, races que nous souhaiterons admirer sur la carte.

- Briefing du site pour connaître la "gueule" et l'ingéniosité du site représentant le jdr.
(plutôt difficil aussi).

Je pense que ces Briefings suffisent, si non, expliquez pourquoi svp.
Maintenant je suis d'accord avec vous sur le point d'ouvrir une béta qu'avec un maximum de 15 joueurs afin de tester les bugs, les failles, et tout simplement le jeu

Merci une nouvelle fois pour tout, et je vous enverrais le lien lorsqu'il sortira afin que vous vous disiez "Ah tient!! j'ai en partie aidé à la construction de ce chef d'oeuvre ".
Dragon étoile, je me nomnais Barbarian il me semble, un Orc, demandes à Niom il doit surement se rappeller de moi héhé.

Moi ça me paraît pas mal comme préparation, j'aimerais être aussi organisé

Bonne continuation

hum... si je relançais maintenant...

arf je crois que je ferais pas

mais un truc important aussi, le marketing

bouh le vilain mot.

En gros définir qui va enregistrer le site sur les milliers d'annuaires, comment bien définir les mots clefs, etc...

Si je peux ajouter mon point de vue et mon experience, je suis coordinateur et initiateur du jeu IDEO depuis maintenant 2 ans.

Le jeu a ouvert depuis quasiment un an et nous avons mis 9 mois a le faire (comme un petit bébé)

Personnellement, nous avons commencé juste avant les vacances d'eté et comme nous ne partions pas trop, ca a permis de bien booster et de demarrer sur des chapeaux de roue.

Nous sommes 5 depuis le début quasiment:
Un programmeur
Un gameplayeur/Backgroundeur
Un Game Designer
Un conseiller en dev
Un chef de Projet

Le + dur etant de trouver des graphistes mais on arrive a pas mal se debrouiller avec des freelances qui font des travaux ponctuels.

Bon courage !

Les maitres mots pour qu'un projet comme ca mene son terme sont COHESION et COMMUNICATION