http://www.kamron.net/french/prog/joelastar.php

Je me rend compte avec le temps que l'auteur a juste sur presque tout dans son article. En particulier, la partie 'aller on recommence'.
J'en suis déjà pour ma part au troisième recommencement (changement de type de jeu, changement de méthode de programmation, et re-changement du principe) et cette fois ci, je vais foncer (quitte a en refaire un autre plus tard )

La partie sur les idées ne s'appliquent pas, pour moi, au jeu par navigateur. Si un jeu n'évolue plus, je pense que c'est la mort définitive du jeu.

Je ne sais pas ce que vous en pensez (sur l'article et éventuellement, ce que je pense ), a vous

C'est vrai que le raisonnement est globalement bon.

La partie sur les idées ne nous concerne pas vraiment en effet.
Mais il est vrai qu'il faut à un moment savoir s'arrêter, si par exemple on créer une association de création de jeux par navigateur, il est intéressant de passer à un autre jeu, si le précédent est suffisamment abouti pour tourner seul. Cela dépend également du type de jeu. Certains n'ont besoin de presque rien une fois lancés.

Développer des mini-applications pour se faire la main est une façon de dégrossir le travail que je trouve très bonne. Je l'ai moi-même appliqué pour apprendre à me servir de telle ou telle technologie, apprendre à faire telle ou telle opération. Ça permet d'être plus à même de le faire à nouveau dans le cadre d'un vrai projet.


Sephi-Chan

Quant à moi je suis d'accord avec 100% de l'article. Contrairement à vous je pense que son passage sur les idées à mettre de côté est on ne peut plus vrai.
Il est très important de savoir fixer des limites, des spécifications fonctionnelles claires et précises concernant la v1. On ne doit pas s'en écarter, et aller au bout. Si en cours de route on a de nouvelles idées - et on en aura forcément - il est important de les mettre de côté, les noter sur un post-it intitulé "pour v2+".
Une fois que la v1 sera sortie, stabilisée, et que le jeu aura trouvé son essence de vie, alors on pourra commencer à relire ces idées pour les ajouter (ou se rendre compte qu'elles étaient idiotes) et annoncer à grands renforts de stickers très "web 2.0" la nouvelle version et le cycle commence...

Je plussoie avec vigueur et vaillance naholyr ! Les phénomènes sociaux inhérents aux jeux multi-joueur font qu'on ne garde pas forcément le contrôle total sur son jeu (copinages, ambiance, jargons, etc.) et les idées gardées de côté peuvent s'avérer soit inutiles soit en totale contradiction avec "l'esprit" du jeu après quelques temps en production. Je pense que cet article devrait avoir sa place (après autorisation de l'auteur) dans le wiki de JeuPHP.

Article très intéressant

Par contre, je ne vois pas beaucoup de jeuPhp opensource...

C'est vrai que ce serait pourtant une bonne source d'inspiration/aide. Toutefois je comprends que peu le fassent, moi-même je ne sais pas si j'oserais, quand on voit la masse de variantes de Ugamela, ça n'encourage pas à ouvrir son code.

Si je viens à bout de Seelies, ça m'ennuierai bien que quelqu'un le sorte quelques semaines plus tard à sa sauce. Même si un tel clone ne ferait pas le poids (je peux être sûr que la personne qui se livre à ce genre de chose n'aura pas mes idées d'améliorations), je sentirais le travail de l'équipe de création bafoué.


Sephi-Chan

Oui et puis quel intérêt de sortir un jeu 2 fois, puisque ce dernier est accessible partout dans le monde?

Ce qu'il faudrait en OpenSource c'est des trucs peut etre un peu plus général, qui laisse la place à la création de l'univers.
Au niveau conception site web il y en a déjà, peut etre que certaines chose sont aussi recurente sur les jeuphp, par exemple l'utilisation de map, des mods pour mieux integrer un jeu dans un forum, un systeme de gestion d'alliance

Mais bon faire des trucs général qu'il faudra certainement remanié pour l'appliquer dans des cas précis je ne sais pas trop ce que çà peut donner!

Le seul intérêt est celui cité par Sephi-Chan, mais là ce qu'il faudrait c'est plus un code source bateau bien organisé, avec eventuelement un code source assez simpliste d'un jeu trés simple (et donc pas trés intérréssant en tant que tel)
Compliqué le jeu ce serait condamné la partie educative d'une tel source, et donc çà servirais plus à grand chose...

Un article intéressant, a ma grande surprise, je me retrouve dans pas mal de point (commencer petit, amélioré ce qui existe déjà, garder des idées, en jeter d'autre...).

Par contre, je suis pas trop d'accord avec l'open source, même si mon jeu/source est vachement crade, j'y tient beaucoup, sa me ferais mal au cœur d'en voir produit à la chaîne façon forumactif...

je suis d'accord aussi avec l'article, y compris l'open source.

je pense qu'en open source, je ne mettrais pas tout : toute la partie admin pour surveiller la triche, ça doit rester secret pour éviter de contourner les indicateurs.

je suis prêt à utiliser un script open source / rendre mes scripts open source, si :
_ il y a tous les éléments de base
_ c'est codé en objet, PHP5
_ c'est documenté en français
_ il y a des tests unitaires

A+

Pascal

Heureux de voir que je ne suis pas le seul à avoir peur que mon travail (ou celui de l'équipe) soit bafoué par de vils photocopieurs !

Concernant l'Open Source, j'ai bien l'intention de faire un making of de Seelies (si le jeu voit le jour), ce sera encore plus instructif qu'un code source seul !


Sephi-Chan