Garder le Cap ?

[Argorate]

Oui, j'ai un bloc note contenant la liste des choses qui me reste a faire (j'essaie de découpé au mieux). Vu de loin, il reste pas grand chose, mais bon ça représente un peu. Tout ce qui est arbre tech et effet des technologies en mon cas^^ C'est l'une des dernières grosse tache je pense.

[QuentinC]

Tout vient avec le temps, c'est normal de viser trop haut, tant que tu ne sais pas évaluer avec précision un développement. En débutant on fais souvent
son cahier des charges avec ce que l'on veux faire alors que plus tard tu feras un cahier des charges aussi en fonction de ce qui est réalisable techniquement,
tout en prenant en compte le temps nécessaire, le budget...

J'ai une idée je pense assez précise de ce que je veux faire sauf pour certains points, mais même. Je viste peut-être un peu trop haut, j'ai peut-être trop d'idéals.

Ceci dit, je ne pense plus être au stade de débutant (je ne suis pas un expert pour autant). J'ai débuté le php en 2005, sans site du zéro.

La communication est souvent la base de la motivation. Discuter avec des gens, pas forcement des développeurs, mais aussi simplement des joueurs, te permet
de sortir la tête du projet et d'avoir des avis plus objectifs.
De plus l'échange d'idées est plus important que seul. Et puis cultiver le secret ne sert à rien.

Ah, ben alors c'est peut-être bien là mon tort. J'ai parfois peur/honte d'expliquer/montrer ce que je fais à d'autres. 1 - parce que je ne suis pas absolument certain de finir / aboutir à quelque chose de concret, 2 - parce que mon truc c'est de la merde / c'est pas original / ça n'intéresse personne tant que ce n'est pas fini. A noter que ça, ça ne s'applique pas qu'aux jeux php, je fais aussi pas mal de java à côté et c'est pareil.

C'est pour cela qu'il faut un cahier précis et défini à l'avance. Si tu as dès le départ un cahier des charges et un zoning de la finalité du site, il n'y
a aucune raison de ne pas finir, quand on connait à l'avance les objectifs et leur temps de réalisation.

Je ne prends pas spécialement de notes sur ce que je dois faire. En quelque sorte, ça me fait ch*** puisque j'ai tout dans la tête et que je fais mon truc tout seul (le temps passé à écrire ça, c'est du temps qu'on ne passe pas à réfléchir/coder sur le jeu). Quelle est l'utilité d'écrire ce genre de choses si ce n'est destiné à personne sinon soi-même ? Je sais pertinament que je ne vais peut-être même pas le relire, ou bien très longtemps après pour me dire que finalement, c'était pas si stupide ma super idée.

Il faut aussi savoir dire stop et sortir un produit même si il manque des fonctions. Un site n'est jamais terminé, c'est un élément fluctuant qui comporte
des mises à jour.

Là tu touches un autre point qui me concerne aussi, le côté perfectionniste: je n'ai pas envie de montrer aux autres un truc qui ne me paraît pas fini. J'ai probablement tort, je rate certainement des occasions d'obtenir des conseils/remarques/critiques qui pourraient être fort à propos.

La tranche d'âge des jeux veux cela ! Et ça fait aussi parti de la vie du site.
Faire vivre le jeu et la communauté, à mon sens, prend plus de temps que le développement de départ. C'est ce que je disais sur le sujet sur les forums,
c'est à double tranchant, et de toute façon tu auras toujours une minorité de joueurs qui pensent que tu es contre eux et pourriront l'ambiance.
Tant que ça reste une minorité, un ban et ça repart !

Concernnant la tranche d'âge, j'en faisais aussi partie (j'avais 17-18 ans, j'en ai 21 maintenant). D'ailleurs, peu après la fermeture de mon jeu, j'ai sombré un an et demi dans ogame. Qu'on m'en préserve, j'ai donné tous mes comptes depuis.
IL faut dire aussi que du côté des ban, je n'avais pas de système fiable (je modifiais le mot de passe des bannis directement dans phpmyadmin), donc ils revenaient de toute façon toujours, tellment qu'à la fin ils m'ont fait craquer et un beau matin, j'ai tout détruit par un drop database de désespoir. L'erreur a donc été technique aussi de ne pas avoir prévu suffisament de moyens de lutte contre ce genre d'énergumènes qui passent leur temps à faire les malins. Bien sûr, c'était extrêmement facile de tricher car mes connaissances de php étaient bien moins bonnes que maintenant, mais quand même.

[Argorate]

Je suis un peu comme toi ^^

J'aime pas montrer un produit en "construction", alors sans refaire le débat, ça a des avantages et désavantages... (la pression qu'il pourrait y avoir a présenté un projet sur le point de finir, décevoir certains en leur montrant quelques chose de bancal.)
J'avoue aimé quand les choses me semblent parfaites (même si au final il y aura des bugs qui seront passés au travers du filet - et j'ai hâte de voir quel type de bug je n'ai pas rencontré moi même justement).

Cependant, j'ai appris a m'organiser un peu, a écrire (pas mal par rapport a se que je pensé pouvoir faire, mais pas trop car comme toi j'ai beaucoup d'éléments qui sont resté dans ma tête) et je pense qu'au final ça aide bien!

[Sloop]

La communication est souvent la base de la motivation. Discuter avec des gens, pas forcement des développeurs, mais aussi simplement des joueurs, te permet
de sortir la tête du projet et d'avoir des avis plus objectifs.
De plus l'échange d'idées est plus important que seul. Et puis cultiver le secret ne sert à rien.

Ah, ben alors c'est peut-être bien là mon tort. J'ai parfois peur/honte d'expliquer/montrer ce que je fais à d'autres. 1 - parce que je ne suis pas absolument certain de finir / aboutir à quelque chose de concret, 2 - parce que mon truc c'est de la merde / c'est pas original / ça n'intéresse personne tant que ce n'est pas fini. A noter que ça, ça ne s'applique pas qu'aux jeux php, je fais aussi pas mal de java à côté et c'est pareil.

C'est drôle car si tu mettais par écrit (pas tout) ce que tu penses, tu t'y retrouverais plus facilement ET ... tu aurais une idée plus précise de chaque chose, y compris les points obscurs.
Si des outils comme Balsamiq Mockups se sont développés, c'est qu'il y a une raison. Ils permettent justement de passer par une phase "conceptualisation" avant une phase "réalisation".

[Anthor]

Ceci dit, je ne pense plus être au stade de débutant (je ne suis pas un expert pour autant). J'ai débuté le php en 2005, sans site du zéro.

Tout dépend combien de temps tu y passes par jour et ton rendement. Si tu y passais 8h par jour depuis 5 ans, non tu n'en serais plus un, mais tu finirais surement tes projets.

Je ne prends pas spécialement de notes sur ce que je dois faire. En quelque sorte, ça me fait ch*** puisque j'ai tout dans la tête et que je fais mon truc tout seul (le temps passé à écrire ça, c'est du temps qu'on ne passe pas à réfléchir/coder sur le jeu). Quelle est l'utilité d'écrire ce genre de choses si ce n'est destiné à personne sinon soi-même ? Je sais pertinament que je ne vais peut-être même pas le relire, ou bien très longtemps après pour me dire que finalement, c'était pas si stupide ma super idée.

Ne cherche pas plus loin à savoir pourquoi tu n'avances pas ou ne finis pas tes projets ^^ Là où tu te trompes, c'est qu'à la phase de codage tu ne dois plus réfléchir ^^
Tu trouves que c'est une perte de temps mais d'un autre côté tu ne finis pas de projets, c'est un peu paradoxal !

Là tu touches un autre point qui me concerne aussi, le côté perfectionniste: je n'ai pas envie de montrer aux autres un truc qui ne me paraît pas fini. J'ai probablement tort, je rate certainement des occasions d'obtenir des conseils/remarques/critiques qui pourraient être fort à propos.

J'aime pas montrer un produit en "construction", alors sans refaire le débat, ça a des avantages et désavantages... (la pression qu'il pourrait y avoir a présenté un projet sur le point de finir, décevoir certains en leur montrant quelques chose de bancal.)

T'as aucun ami en développement ou hors sur qui tu peux compter pour ça ? Sephi a vu quelques dévs que peu ont vu, et surement inversement.
Si après tu préfères sortir quelques chose de bancal que de discuter avec un pote. ^^
Sans aller jusqu'à ouvrir une bêta ou une alpha, montrer quelques pages à 2/3 potes, ça n'a jamais tuer personne, et ça permet d'éviter bien plus d'erreurs que seul.

Il faut dire aussi que du côté des ban, je n'avais pas de système fiable (je modifiais le mot de passe des bannis directement dans phpmyadmin), donc ils revenaient de toute façon toujours, tellment qu'à la fin ils m'ont fait craquer et un beau matin, j'ai tout détruit par un drop database de désespoir. L'erreur a donc été technique aussi de ne pas avoir prévu suffisament de moyens de lutte contre ce genre d'énergumènes qui passent leur temps à faire les malins. Bien sûr, c'était extrêmement facile de tricher car mes connaissances de php étaient bien moins bonnes que maintenant, mais quand même.

Il y a un an, beaucoup d'outils me manquais aussi sur Tarschool, mais cela n'empêche pas de les ajouter au fur et à mesure, et d'améliorer les algorithmes de détection. Avoir un jeu en production ne veux pas dire qu'on ne touche plus au site. Et de toute façon les joueurs auront toujours plus de suggestions à vous proposer que ce que vous pouvez humainement coder !

[QuentinC]

Ne cherche pas plus loin à savoir pourquoi tu n'avances pas ou ne finis pas tes projets
Là où tu te trompes, c'est qu'à la phase de codage tu ne dois plus réfléchir

Oui mais alors, il faut vraiment tout décider à l'avance ?
Parce que c'est en voyant certaines parties fonctionner que je me dis ah tiens, faudrait que j'ajoute/améliore ça

Tu trouves que c'est une perte de temps mais d'un autre côté tu ne finis pas de projets, c'est un peu paradoxal !

En fait, c'est surtout parce que c'est terriblement ch*** à écrire plus qu'une perte de temps proprement dite. C'est comme écrire une doc, excuse-moi mais c'est très très ch****.
Expliquer qu'il va y avoir tel objet et qu'il permet de faire ça, on le sait déjà et on s'en rappelle. A ce moment-là autant faire d'une pierre deux coups, on rédige l'aide du jeu en même temps. C'est ce que j'essaie de faire pour mon jeu en cours: des notes qui feront directement office d'aide ou de FAQ.

Je ne discute toutefois pas sur l'utilité de noter les choses dès lors qu'on est plusieurs : on est de toute façon obligé pour être sûr que tout le monde a compris la même chose, là on est d'accord.

[Anthor]

Oui mais alors, il faut vraiment tout décider à l'avance ?
Parce que c'est en voyant certaines parties fonctionner que je me dis ah tiens, faudrait que j'ajoute/améliore ça

Tout peut-être pas, mais bien 90%. Généralement, au moment du codage, je sais exactement ce que j'ai à faire. Si tu trouves des choses à rajouter, alors ça part dans une liste, mais il faut d'abord finir ce qui est prévu.
Avec un zoning, tu sais déjà quels interfaces ne marchent pas, et c'est donc corrigé en amont.

En fait, c'est surtout parce que c'est terriblement ch*** à écrire plus qu'une perte de temps proprement dite. C'est comme écrire une doc, excuse-moi mais c'est très très ch****.

Je ne te contredirais pas ^^

Expliquer qu'il va y avoir tel objet et qu'il permet de faire ça, on le sait déjà et on s'en rappelle. A ce moment-là autant faire d'une pierre deux coups, on rédige l'aide du jeu en même temps. C'est ce que j'essaie de faire pour mon jeu en cours: des notes qui feront directement office d'aide ou de FAQ.

Se rappeler un objet les premières semaines, ça va, se le rappeler plusieurs mois après quand on va te soumettre un bug, que tu auras des centaines de fichiers, ce sera plus dur. Surtout que généralement, tu auras fait le suivi du jeu, et que tu auras bosser sur d'autres parties.

Après tu n'es pas obligé d'écrire un roman ! Une description d'une ligne, et le retour sont suffisant ! Si en plus tu utilises le typage sur les arguments, n'importe quel IDE digne de ce nom te donnera le tout en temps réel.
Ce qui t'évite d'ouvrir le code pour savoir quoi mettre dedans.

Après l'aide/FAQ, c'est autre chose !

[Sephi-Chan]

Je ne suis pas vraiment pour la rédaction de documentation. Par contre, quelque chose qui m'aide énormément, c'est le dessin de mes pages de jeu (cf. mon message plus haut dans la discussion).

Une autre chose qui m'aide beaucoup consiste à donner un nom à une tâche et lister ce que je vais faire : créer telle vue, implémenter telle méthode, créer telle route, bouger tel code dans un helper, etc. Comme je me distrais vite et que j'ai parfois du mal à me concentrer, ça m'évite bien des moments de flottement.

Par contre, je préfère 1000 fois le dessins sur un bloc plutôt que le dessin sur des logiciels comme Balsamiq Mockups ou GoMockingBird.
Quant au zoning, je préfère le faire directement en HTML/CSS plutôt qu'avec Photoshop.

Quand je développe, j'ai mon cahier à côté. Je suis un gros maniaque des ActiveBook, d'Oxford et des blocs Idéa. Quand ma mère m'a ramené ça du boulot, j'étais aux anges. Et depuis j'ai une consommation assez énorme de cahier et de bloc notes.

Je m'arrange toujours pour avoir un environnement de travail impecable. Avec toujours de quoi noter.


Sephi-Chan

[Plume]

La rédaction d'une documentation est inutile pour les langages avec lesquels on peut générer une documentation à partir des sources tel PHP, Java, haXe, ...

Je ne connais pas tous les langages mais je ne doute pas qu'il y en ait plusieurs autres qui proposent une syntaxe dans le même intérêt. Quand on fait un retour après plusieurs temps sur un code, on est content de trouver un truc succinct, clair & concis qui ne nous oblige pas à parcourir tout le code mais qui nous permet de savoir où on va quand même

[Colmea]

Je suis d'accord avec ce qui a été: il ne faut pas négliger la préparation sur papier.
J'étais comme toi aussi: rien d'écrit, tout dans la tête.
Mais comme certains l'ont dit, écrire ton projet sur papier (ou d'autres manières de présenter son jeu) permettent de structurer et d'organiser ta pensée. De plus tu sais exactement ce que tu dois faire.
A ce propos, je ne suis pas d'accord avec toi sur le fait que la créativité vient en codant. Justement, il faut la contenir au maximum et éviter de rajouter des choses pendant qu'on code.
Selon moi, la meilleure façon est de définir au départ une version 1, une version beta avec le minimum de fonctionnalités, de décrire tous les modules et fonctionnalités dans un cahier des charges, et de s'en tenir jusqu'à ce que cette première version soit en ligne !

Ou sinon on est parti pour rajouter 10 000 fonctionnalités au fur et à mesure de nos envies du moment (qui en plus, ne sont pas très objectives sans un certain recul) et qui sont le plus souvent mal intégrées au projet parce qu'on a pas pensé à toutes les relations.

D'un côté je dis ça, mais c'est la règle que je me suis fixé et que j'ai le plus de mal à suivre. C'est difficile de se tenir à une petite-version-de-rien-du-tout-qui-est-pas-extraordinaire et la tentation est forte d'ajouter une nouvelle fonctionnalité par-ci par-là.