Discutons du Planning/Todo

Bien, bonjour encore, je me suis mis à jour, je participe.

Mon job dans la vraie vie, c'est m'occuper de projet. Je viens de commencer donc j'oserais pas vous dire que je suis bon.

Bref. Ce que je propose dans ce topic, c'est de discuter rapidement des première étapes du projet, les identifier, les ordonner et les assigner à chacun.
Je parle des toutes premières étapes, qui vont conditionner le reste dans les différents domaines.

Je propose d'organiser ca de la manière suivante: on énonce la tache, l'explique, et donne sa chronologie. Choisissez un nom cours pour que les suivants puisse la commenter facilement.

Je commence.

première programmation

Quand? Primordial.

Quoi? nos valeureux programmeurs devraient se rendre compte des diffcultés, et nous faire un feedback de tout ca, pour que le projet soit plus concret. Cela comporterait, sans interface graph: un login, un déplacement d'un pion, un envoi de message, une création/intervention dans un forum. Ca a l'air tout con, mais à mon avis ca sera déjà un pas énorme.

Qui? Tous les programmeurs


premiers graphiques


Quand: APRES que la première programmation soit terminée
Quoi: Mettre un point bleu sur le truc qui se déplace, un fond au forum, à la page de login, bref mettre qqch (de moche, fait sous paint en 30 sec), pour voir comment les choses se gèrent.

Qui: graphiste, pour qu'ils sentent les limitations, programmeurs, parcequ'ils font tout.


Situation de l'univers

Quand? pendant que les programmeurs bossent

Quoi: décider le cadre du ju. je pense qu'il y a une sérieuse réflexion a avoir quant à l'insérer directement dans apo ou pas.

Qui: tout le monde, sauf les programmeurs qui ont mieux à faire, et qui n'ont pas le temps d'ailleurs.



Concepts de jeu

Quand : apres la première prog

Quoi: en fonction de ce qui a été possible, et des difficultés, définir un premier mode de jeu très simple.

Qui: programmeurs et tout le monde.



Voilà pour mois les premières étapes. Si vous etes d'accord, on peut les lancer tout de suite, et au fur et à mesure des discussions,ajouter des taches, pour avoir un bel organigramme, et etre efficace.

Bon, j'ai donné toute ma dose de sérieux de la journée. J'attends vos réactions.

Heps je suis contre
Je m'explique pour la partie programmation,

si jamais le design prévoit que le menu est ici ou là, ça peut même changer toute la programmation des sessions et des choses à lancer avant chaque page, le login, la vérification tout ça... Or si je programme avant, il faudra surement tout changer après

Si j'ai le design, je peux tout intégrer rapidement sur le système de login dès que possible.
Simple, le système de login se fait en ... 10-20 minutes à tout casser... allez on compte 1 heure avec l'intégration design... (cela dit je suis assez occupé dans la semaine)

Sinon un déplacement d'un pion ? kézako ?
une création/intervention dans un forum ? quel forum ? externe ?
je fais pas l'interne avant pas mal de temps puisque on n'en connait pas encore les features.

Amicalement,

ah, enfin une réaction.

Malheureusement je n'ose pas croire qu'on va tout concevoir, et commencer à programmer un produit fini. C'est le cassage de gueule assuré, à mon avis.

Si il y a des étapes simples, tant mieux. Autant les maitriser et les éprouver très tot, ca fera de bonnes bases.

Pour les menus, on aura jamais une architecture définitive. Il y aura des menus auquels on va rajouter options puis d'autres, puis d'autres, etc... Et si c'est moche et que ca ressemble à rien, tant pis. "Tu" remettras au propre à la fin. Et ca permettra encore une fois de se faire les dents sur les différentes tentatives. Et de toute facon, quand on aura une realease, la suivante sera en préparation. Dis moi si je me trompe

Pour le déplacement d'un pion, je veux dire: aller d'un point système/planète à un autre.

Pour le forum: un forum interne au jeu. Il en faudra, et pas question ded passer par les forums tout fait comme celui ci, il va falloir le construire complètement. Et je place ca tot, car les possibilités du jeu dépendent des possibilités réelles des programmeurs.

C'est plus clair?

Réagissez, ca me semble important.

Il faut rajouter une étape premier design avant première programmation, je pense : on doit réfléchir à ce que sera à peu près le design avant de programmer ces petites choses.

Pour la programmation en bloc, ça peut se résoudre en faisant des petits modules adaptables : attaque, recherche, espionnage, déplacement, messages d'alerte et autres puis la liaison entre tous (effets de la recherche sur les autres domaines, effet du déplacement sur l'attaque, de l'attaque sur l'espionnage ect... ).

Il faudra, je pense, un maximum travailler par modules, car c'est beaucoup plus simple de changer une partie du jeu, comme ça (si on voit qu'il faut la changer, parce qu'on rencontre un problème... ou parce qu'on veut encore l'améliorer). Ca donnera davantage de facilités à concevoir une version ultérieure, en plus (clarté avec les modules bien différenciés).

oz a écrit:

Pour le déplacement d'un pion, je veux dire: aller d'un point système/planète à un autre.

Pour le forum: un forum interne au jeu. Il en faudra, et pas question ded passer par les forums tout fait comme celui ci, il va falloir le construire complètement. Et je place ca tot, car les possibilités du jeu dépendent des possibilités réelles des programmeurs.

C'est plus clair?

Réagissez, ca me semble important.

Heu... On a pas encore définit le fonctionnement des planète, ni même des bases plus simples, il faut faire un diagramme du fonctionnement du site avant de programmer, c'est plus logique... on programme pas "à la barbare" un forum ou une construction logique de planètes, lol faut aussi que tout le monde soit d'accord pour le diagramme UML complet que je tenterai au passage de faire prochainement, mais il manque encore des choses, genre :
on demande quoi à l'inscription ? Pourquoi ?
Durée des sessions ?
le fonctionnement total du forum !!! on en a pas encore parlé que tu nous demande brusquement de le créer ! à partir de rien ! je ne fais rien sans diagramme ça va être clair, à la limite pour le login et l'insription je peux partir d'informations brutes, car il y en a peu. Le reste => UML.
Pourquoi ? Je vais vous expliquer 2 façons de programmer, une avec UML, l'autre sans :

SANS :

Code:

Donc je vais faire les vaisseaux, je crée une table mysql avec disons...  3 champs, ID, NOM, Caracteristiques...
je fais tout le script d'inscription...
Ah merde ! j'ai oublié que les vaisseaux avaient un propriétaire,
je vais l'ajouter dans mysql
*test de l'inscription" => Erreur
Merde j'ai oublié de corriger le script d'inscription...
*corrige*
Ah voilà ça a l'air de marcher... A merde j'ai oublié les coordonnées du vaisseau..

AVEC

Code:

Bon alors tout le monde a réfléchit sur le fait qu'il faut 5 champ dont un qui est en union avec la table des joueurs (le propriétaire)..
je le met dans la table
Je fais le script vite fait en suivant le plan sur le diag
Test => Ok
Fini.

De plus il ne faut pas être programmeur pour faire du UML c'est facile, donc tout le monde peut "programmer" et nous on interprête ça en 5 minutes...

Heu... je connais les ulm (même si ça ne nous est d'aucune utilité ici), mais pas les uml ? Quoi qu'est-ce donc que j'ouïe ici ?

UML (Unified Modeling Language en anglais, soit langage de modélisation objet unifié)

C'est un standard de diagramme très utilisé pour la programmation et les projets. je vous ferai un exemple d'ici peu, en attendant :
Cliquez ci !

(On utilisera un diagramme de cas d'utilisation pour savoir ce que les joueurs peuvent faire, un diag d'état-transition pour savoir ce que fait chaque action, ainsi que l'algorithme du script journalier par exemple...diag d'interaction pour ben les interactions avec le joueur, ce qu'il doit faire, voire celle entre joueurs, mais tout pourra être associé à un diagramme de classe, le plus utile pour nous (mais on les fera au début car ils sont peut etre plus difficiles que les autres et c'est plus l'aspect programmation)

Voilà...