Y a pas que la technique

[Kalan]

Non, je ne cite pas Loetheri, je le caricature pour me faciliter la vie ;-). Mais je sais qu'il ne m'en voudra pas (hein ? :-) ). Dans ce qu'il dit, il n'y a pas d'erreurs : l'idée existe en effet depuis longtemps, les gens ont peu de temps pour les autres et des initiatives ont lieu ça et là sans que rien ne se centralise. Et bien moi, je préfère m'appuyer sur une communauté existante et qui a l'air ouverte et dynamique (ca c'est la brosse à reluire pour vous les gars ;-) ) et tenter d'apporter ce que jeu peux pour que ca change :-). D'autres suivront, d'autres pas. Pas besoin de fédérer 100% des gens, le tout est d'apporter quelque chose qui servira. Ceux qui n'y crois pas changeront d'avis ou se planteront :-) (et je ne veux pas entendre de truc du genre "c'est qui ce con qui est aussi sur de lui :-) ).

Quant au document de 100 pages qui entraine un délai dans la réalisation, tout dépend de la richesse et de la complexité du projet; mais ca ne me choque pas et ca remettra le developpement à sa juste place : une "simple" traduction du besoin éclairé en un langage compréhensible par la machine.
Sur un projet pour lequel je me suis fadé les spécifications il y a quelques années (pour la DGAC), il y a eu en tout plus d'une centaine de jours pour plusieurs centaines de pages ! Et malgré ça, on a rencontré des difficultés en cours de réalisation : des choses pas assez précises, des malentendus etc...
Tout ca pour dire que si l'on cherche à "professionnaliser", il faut se comporter en professionnels et reprendre les méthodes éprouvées, et ca ne passe pas que par l'adoption de modèle de développement (objet, MVC etc.)

Mais là où Loetheri a parfaitement raison, c'est que les débats à outrance sur des forums ne font pas avancer les choses :-). J'ai palabré 3 ans avant de participer à la fondation de la "fédération" dont il a parlé et, si ca a eu un intérêt indéniable les 2 premères années parce que ca a apporté nombre d'arguments et d'idées, la dernière fois, c'était stérile car il n'y avait que répétitions et préjugés.
A propos de la "bonne" manière de prendre un projet par le bon bout, il n'y a pas débat. L'ingénierie a ses méthodes, quel que soit le domaine d'application, et ne pas vouloir en tenir compte, nier leur indéniable nécessité, c'est soit manquer d'expérience, soit carrément... pas malin (pour ne froisser personne ;-) ).

[Loetheri]

@naholyr

T'es fou de dire des trucs pareils on pourrait croire que tu cites Loetheri

Reste gentil avec Kalan ^^ Tu n'es pas obligé de l'insulter de la sorte

@Kalan
Je te pardonne sans effort.

Par contre, je vais pour ma part conforter ma position quant à une telle action ^^ (Car oui, je n'aime pas courir dans le vide ;-)) : Tant qu'il n'y a pas d'objectifs et peut-être moyens clairs et précis, je ne saurais aider qui que ce soit dans quelque direction que ce soit.

[naholyr]

Pour parler clair, je pense que l'objectif clair et précis c'est de réaliser un genre de "tutorial" qui se situe AVANT la sempiternelle "vas voir sur le siteduzero"

Un guide qui reprendrait entre autres les points suivants :
- Se poser les bonnes questions à propos de son futur jeu
- Se situer dans le paysage existant
- Exprimer le besoin fonctionnel dans un document écrit
- En déduire le besoin technique
- Décrire précisément les règles du jeu
- Etc...
- Et bien sûr aborder les outils techniques (parce que ça reste à destination de techniciens) qui simplifient la gestion d'un gros projet : la conception objet, les frameworks, le versionning, les outils de gestion de planning, les éditeurs "avancés"...

Un guide qui permettrait au développeur de ne pas trop se tromper dans la phase préparatoire de son projet en se posant les bonnes questions dans le bon ordre

J'ai bon Kalan ?

[joshua]

Hé bien. Une bonne bande de jeunes gens motivés
Ca fait plaisir a voir
Moi en ce moment je (passe, perds, gaspille, use... au choix) mon temps a mieux maitriser les outils.
Ensuite, je le (passerai, gaspillerais, utiliserais, ... idem) a implementer correctement toutes les briques de bases symfony, tout en réflechissasnt a la conception de mon jeu. C'est un peu le calme plat ses derniers temps... Je serais donc tout ouïe

[pascal]

j'aime bien l'allusion à notre ( joshua, naholyr, d'autres, moi... ) lobbying pour le MVC, l'objet

c'est vrai que ça commence sur le papier / wiki, par un tas de notes décrivant le projet : les spécifications, et cette phase là est zappée de jeuphp, alors que c'est une phase technique, tout comme la programmation.

bref, je regroupe mes notes sur les jeux et on en discute dans un bar de lille un de ces jours, kalan ?

A+

Pascal

[Kalan]

Un guide qui permettrait au développeur de ne pas trop se tromper dans la phase préparatoire de son projet en se posant les bonnes questions dans le bon ordre
J'ai bon Kalan ?

C'est en effet ce à quoi je pensais. Je préciserais juste que ce n'est pas réellementune phase "préparatoire" mais bien la première étape d'un projet (mais je chipotte :-) ).
De plus, je pesne qu'en plus du'une sorte de Tutorial, il serait très utile pour chacun (très, peu oi pas du tout expériementé) d'avoir le retour sur expérience des créateurs de jeux ayant mis en place ce type de document. A force, et si chacun accepte de faire partager son expérience sans avoir "honte" des erreurs inévitablement commises, nos démarches seront de plus en plus efficaces.

[denisc]

tu peux me compter dans tes 4 ou 5 zigs

A+

Pascal

Il en resterai donc 3 autres que moi et Pascal???
On veut des noms

[denisc]

j'aime bien l'allusion à notre ( joshua, naholyr, d'autres, moi... ) lobbying pour le MVC, l'objet

c'est vrai que ça commence sur le papier / wiki, par un tas de notes décrivant le projet : les spécifications, et cette phase là est zappée de jeuphp, alors que c'est une phase technique, tout comme la programmation.

bref, je regroupe mes notes sur les jeux et on en discute dans un bar de lille un de ces jours, kalan ?

A+

Pascal

Perso, j'en suis à une bonne cinquantaine de pages wiki... Ca doit en gros faire 200 ou 250 pages à imprimer, rien qu'en blabla... Mais, désolé, ça reste dans le domaine privé jusqu'à nouvel ordre (surtout tant que je n'ai pas de moteur fonctionnel!)

[joshua]

moi, moi :p

[Zamentur]

idem,
Moi aussi j'ai passé beaucoup de temps sur les specification...
Ceux qui parle de quelques semaines à raison de 2h par jour me font rire: moi j'ai une specification d'une nouvelle version d'un jeu (donc avec des acquis) qui as mis 1 an à se creer et en equipe.

Et j'ai une autre specification d'un projet en pause, là aussi un projet communautaire qui est l'objet de 8 mois de reflexion...

Et donc je pense pas que diffuser ces specifications soit la meilleur des idées tant que les projet ne sont pas arrivé à termes! (Sans parler quel ne sont pas qu'à moi)

Celà dit j'adhere sur le fait que c'est important si l'on veut arriver à quelques chose de reussie
Je pense aussi qu'il faut aussi une conscience de la technique pour le faire, pour eviter d'ecrire des specification impossible, trop ambitieuse, ou inadapté.
C'est pour çà que je pense qu'un amateur qui ne sait meme pas encore programmer de façon basique aurrait plutot intérré à se lancer dans un petit projet tete baissé histoire d'acquerir un peu d'experience ou a se racrocher à un projet existant.