Quand commencer le développement

[niahoo]

Yo,

j'ai un projet qui mûrit depuis très longtemps dans ma tête, et je me suis décidé à tout noter sur un blog wordpress pour éviter de re-concevoir sans cesse les mêmes idées.

ça permet de poser les bases, de mettre en évidence les idées moisies et d'en avoir de bonnes.

Maintenant j'ai une idée un peu plus précise des mécanismes globaux et de ce qu'il va falloir développer en termes de fonctionnalités.

Alors j'aimerais savoir, avant de balancer les 1000 lignes de code qui vont servir de base à toutes les classes, ressources, avant de créer le modèle de données : Comment faites vous pour savoir si votre projet est assez mûr pour vous décider à coder ? ( je précise, je développe seul pour le moment ) Comment choisissez-vous les idées que vous allez implémenter et celles qui n'ont pas besoin d'être précisément définies pour commencer ?

merci

[php_addict]

et je me suis décidé à tout noter sur un blog wordpress pour éviter de re-concevoir sans cesse les mêmes idées.

pourquoi sur un blog? ca c'est un truc que je ne comprends pas, mettre en ligne ses idées, pourquoi pas le faire sur papier ?

perso moi j'ai tout fait à l'arrache je me fais la doc du projet en meme temps que je code, je sais c'est mal mais je ne suis pas pro et un peu bordelique...

j'imagine que c'est du php/mysql ? si tu parles de classes c'est du POO ? le top c'est de develloper sur la meme config que ton future hebergeur (dédié?) car tu peut avoir des surprises.

utilise tu un framework? ou quel patern (MVC, etc... ?) ?

le mieux c'est de coder module par module: cible un point precis et code (j'ai sais rien , par exemple la carte)

ce ne sont que des avis d'un amateur galérien qui avant d'attaquer son projet ne savais meme pas ce qu'etait le MVC, les framework, etc...

[Foxglove]

Comment faites vous pour savoir si votre projet est assez mûr pour vous décider à coder ? ( je précise, je développe seul pour le moment )

Dans mon cas, ce n'est jamais vraiment assez mûr. Quand je commence la programmation, je découvre systématiquement des problèmes que je n'avais pas identifiés au moment de la conception. Mais quand il me tarde trop, quand j'ai l'impression que les modèles et algorithmes que je fais sont cohérents et n'avancent plus, je me lance.

Voici quelques points du programme auquel il faut faire attention : la gestion des actions des joueurs (incluant la gestion des combats si tu en as), la résolution des actions simultanées (A et B sont à une case de distance, A bouge à gauche, B bouge à droite, qui est bloqué ?), la gestion du déplacement (quand il n'est pas immédiat), la gestion des erreurs, etc. Ce sont juste quelques exemples, mais s'il y a des points qui ne sont pas clairs parmi ceux-ci, ça pourrait être critique, et je te conseillerais d'y réfléchir davantage.

Comment choisissez-vous les idées que vous allez implémenter et celles qui n'ont pas besoin d'être précisément définies pour commencer ?

Cette partie est la plus facile à mon avis. La première méthode consiste à créer la partie ludique du jeu rapidement. Par exemple, tu commences par les combats (qui sont souvent intéressants pour le joueur). Puis, tu ajoutes les déplacements, puis les quêtes, etc. Dans cette première méthode, tu programmes les pages les plus intéressantes d'abord, et les autres ensuite. La deuxième méthode consiste à créer le jeu en partant de l'écran de connexion, puis le déplacement du joueur, puis le combat. Dans cette deuxième méthode, tu programmes ton jeu dans l'ordre des pages visitées par le joueur. De mon côté, je préfère faire comme ça.

Par contre, quand tu programmes les combats (par exemple), il ne faut surtout pas être exhaustif. Tu ne vas pas programmer l'épée de feu +5 et le bouclier azur +3. Tu programmes des choses basiques uniquement. Ajouter des dizaines objets d'attaque et de défense, c'est une perte de temps à ce niveau. C'est le cas aussi si chaque objet permet de faire des actions particulières. Par exemple, comme tout le monde sait, le bouclier azur +3 permet de gérer deux fois de suite à chaque tour. Il ne faut pas le programmer tout de suite, mais il faut que tu l'aies prévu dans ta gestion des actions et dans la gestion du combat. Programme un ou deux objets avec des pouvoirs particuliers pour t'assurer que le système général marche, et restes-en là. Le contenu complet viendra tout à la fin de la programmation.

Pour résumer, il faut vraiment partir de choses simples. Avoir une étape qui consiste à faire une page avec un login, puis une page avec un login et un mot de passe, puis une page avec un message d'erreur, c'est pas une mauvaise idée. Il vaut mieux découper en petits bouts que vouloir faire un gros bout qui sera trop compliqué à réaliser d'un bloc.

[niahoo]

pourquoi sur un blog? ca c'est un truc que je ne comprends pas, mettre en ligne ses idées, pourquoi pas le faire sur papier ?

pour pouvoir écrire dessus de n'importe ou, dès qu'une idée fait BLUB dans le neurone !

en MVC oui par contre le framework je vais me faire le mien sur mesure. Mais ça nécéssite déjà de se décider à coder ou non, d'où ma question !


@Foxglove: ok, mais c'est tendu car tout est lié, le combat par exemple prends les déplacements en compte, le craft prend en compte la position des bâtiments par rapport aux ressources donc c'est chaud de trouver le point de départ !

( Pour l'épée de feu +5 machin truc, vous mettez ça dans le code, ou vous avez une table dans la DB avec les bonus pour chaque type d'arme ? )

En fait ton post me fait penser à préciser ma question :

Comment penser à ce à quoi on n'a pas pensé et qui est nécéssaire avant de commencer le développement ?

( ouais c'est chaud )

[Dark-Slade]

euh désoler de paraitre pour un compte mais si je pose pas la questions je saurais jamais se que c'est , qu'est ce que le MVC et framework ? :o vous pouvez me mp pour répondre au lieux de floodez ce beau topic

[niahoo]

pour le MVC tu trouveras les meilleurs réponses ici : Modèle Vue Controleur

pour les frameworks, le plus simple c'est ce site

voilà !

[Dark-Slade]

Merci

[Globe]

Passer du concept à la réalisation est toujours un point difficile. Après tout va dépendre de comment tu veux entreprendre la création de ton jeu. Si comme Foxglove approche le problème tu veux faire tester le jeu très vite tu commences par les parties vraiment ludiques, si au contraire tu veux avoir une base solide pour ton jeu je pense qu'il vaut mieux développer au fur et à mesure les modules qui vont faire la base du jeu. Si tu veux un RPG il faut à mon avis avoir déjà réfléchi à la manière dont les combats vont survenir, et surtout à ton interface. A force de développer je trouve qu'on à tendance à ne plus penser comme un joueur. Pour ça je conseille de définir sur papier ou sous formes de tableau l'apparence de chaque page ce qui va te donner une référence non pas par rapport au code mais par rapport à la manière dont ton jeu va se jouer. La question principale avant de taper dans le code pour moi c'est "Est-ce que je sais à quoi va ressembler mon jeu fini ?". Les questions de gameplay sont pour moi les plus sensibles alors que le code y'a que toi qui s'en soucie le joueur s'en moque éperdument. Une fois que le jeu est défini je pars sur la structure des tables et ça c'est également un point de vue essentiel, si l'interaction entre tes tables change à chaque fois que tu rajoutes un bout de code tu n'as pas fini de pédaler dans la semoule. Et une fois que tout ça est fait je dirais de programmer étape par étape par rapport à ce que le joueur va voir, si il arrive sur la carte tout d'abord tu programmes la carte, si il commence par construire un bâtiment tu commences par ça. C'est très rare dans un jeu que dès les premières secondes le joueur combat (mis à part dans les tutos mais pour moi ça c'est à faire tout à la fin). Pour un STR par exemple je vais commencer par login, profil, ressources, construction de batiments, construction d'unités, développement de technologies, commerce, attaques, création de guildes... Si tu n'as pas défini préalablement quelle table va permettre de savoir si le joueur possède tel bâtiment pour produire tel unité tu vas te prendre la tête. Enfin bref ce n'est qu'un point de vue d'un noob que je te propose mais c'est comme ça que je m'y prendrais.

[niahoo]

Hmm alors oui, je suis plutot d'accord avec toi, mais je connais déjà plus ou moins l'ordre dans lequel je vais développer, ce que je ne sais pas définir c'est si je peux me lancer ou non !

Je crois que je vais faire l'architecture du serveur et de la base de données sur papier cet aprèm, mais pour la première ligne de code ça va encore être long

[Warshadow]

Comment faites vous pour savoir si votre projet est assez mûr pour vous décider à coder ?[...] Comment choisissez-vous les idées que vous allez implémenter et celles qui n'ont pas besoin d'être précisément définies pour commencer ?

Le meilleur moyen que j'ai trouvé actuellement, c'est de montrer le tout à d'autres gens. L'idéal étant que ceux-ci travaillent sur ce même projet, afin qu'ils soient réellement impliqués. Il y aura toujours des milliers de détails auxquels tu n'auras pas pensé, des contre-sens, des impossibilités techniques, etc. Une personne extérieure aura beaucoup moins de mal à les voir que toi.

Ensuite, je crois personnellement qu'il ne faut pas attendre beaucoup pour développer. Mais pas pour se lancer directement dans le gros du projet, juste pour se préparer, tester des choses, vérifier la faisabilité techniques de certains éléments.

Par exemple, pour Fightly : j'ai commencé à rédiger un game concept, pas complet du tout, mais posant quelques bases. J'ai ensuite recruté trois personnes, et depuis une semaine qu'ils le commentent, ce document a été largement amélioré. Nous avons réfléchi à plusieurs sur les meilleurs choix à faire, ils ont mis en avant quelques erreurs que j'avais faites, etc.

De plus, en même temps que j'ai rédigé le Game Concept, j'ai fait des essais techniques : par exemple, afficher une carte composée de cases hexagonales en PHP / HTML, tester les déplacements d'unités en JS, essayer les WebSockets, etc. Tout ceci ne servira pas forcément directement au projet, mais au moins j'ai acquis des connaissances très utiles pour la suite. Et ça permet aussi de voir des problèmes avant qu'ils n'arrivent en plein milieu de la phase de développement.