Avantages et inconvénients de l'analyse

[Argorate]

Pour ma part je dirais que perdre du temps à expliquer a quelqu'un se qu'est un UML, comment en faire un, et qu'il l'applique pour son projet est une simple perte de temps...

Il n'y en a tout simplement pas besoin, Cela se fait dans la tête et évolue au fur et à mesure...
Pour ceux qui ont des difficultés à le voir dans leur tête, alors il y a peu de chance qu'ils parviennent à aboutir leur projet, s’ils sont seul ou que avec des gens dans le même cas. (Bien sur y a tjs des exceptions )

Sinon pour se qui est de la motivation, c'est dans la tête, tout se qui est dans la tête est contrôlable, la motivation bien que difficile est totalement dépendant de la force de votre esprit. Si vous dites que vous allez le faire, il ne tien qu'a vous de le faire, bref ça, ça ne s'apprend pas, c'est a chacun de trouver sa détermination. Le mieux étant de constater par soit même l'avancement de son propre jeu, et donc il faut rapidement commencer à programmer et surtout pas rester sur papier très longtemps…

Ensuite pascal, « Il faut jeter 50 % des idées dans la V2, tous les éléments secondaires qui n'aident pas à atteindre les objectifs. »
Je n’aime pas cette optique, mais ce n’est qu’une question de choix fonction de sa motivation :

Soit on sort une V1 banale avec un game play de bases, déjà vu 100 fois et on rajoute progressivement les nouveautés -> Dans se cas votre jeu fera peut être une bonne impression au final, mais beaucoup moins que si vous codez 95% de vos idées et d’entré de jeu on a quelque chose de qualité et de remarquable…

Après chacun fait comme il veux

[pascal]

je suis d'accord pour l'UML, la plupart du temps on n'a pas besoin de ça car les concepts sont simples.

Ensuite pascal, « Il faut jeter 50 % des idées dans la V2, tous les éléments secondaires qui n'aident pas à atteindre les objectifs. »
Je n’aime pas cette optique, mais ce n’est qu’une question de choix fonction de sa motivation :

Soit on sort une V1 banale avec un game play de bases, déjà vu 100 fois et on rajoute progressivement les nouveautés -> Dans se cas votre jeu fera peut être une bonne impression au final, mais beaucoup moins que si vous codez 95% de vos idées et d’entré de jeu on a quelque chose de qualité et de remarquable…

d'entrée de jeu on a un projet qui ne sortira jamais, car trop compliqué.

on peut aussi coder une V1 qui marche, la garder en cercle fermé et rajouter les éléments de la V2 pour enfin en faire un jeu public, si le projet existe encore.

mais chacun fait comme il veut au final

A+

Pascal

[Argorate]

Dans se cas là, se que tu appel V1 (a cercle fermé), j'appel ça une Beta (voir Alpha), et là effectivement je te rejoins...
Mais après la complexité n'influe pas si on est déterminé et qu'on avance, après ce n'est plus qu'une histoire de temps, et souhaitons le nous, c'est ce qu'on procède en excès...

[keke]

Pour ma part je dirais que perdre du temps à expliquer a quelqu'un se qu'est un UML, comment en faire un, et qu'il l'applique pour son projet est une simple perte de temps...

Il n'y en a tout simplement pas besoin, Cela se fait dans la tête et évolue au fur et à mesure...
Pour ceux qui ont des difficultés à le voir dans leur tête, alors il y a peu de chance qu'ils parviennent à aboutir leur projet, s’ils sont seul ou que avec des gens dans le même cas. (Bien sur y a tjs des exceptions )

Je ne peux pas être d'accord avec ça. Y'a des gens très bien, très intelligent qui ne parviennent pas à conceptualiser des diagrammes UML sans les écrire. Tout comme y'en a qui n'ont aucun réflexe sur Counter Strike, aucune patience sur des Diablo Like, aucune stratégie sur des Warcraft-like ... Si toi, Argorate, tu y arrive très bien, c'est un sacré avantage que je partage. Mais pour d'autres ce point est plus délicat et dans ce cas une aide est nécessaire.

Bref, à chacun ses pistes de progression ^^

kéké dont sa copine n'est pas capable de lire une carte routière sans la tourner dans tous les sens ...

[Kroc]

Bonjour et bonne année !

Comme certain, je ne suis pas du tout d'accord avec Argorate.

UML n'est certes pas utile pour un petit projet ou s'il commencer par l'apprendre, car le but c'est de gagner du temps.
Mais ca permet d'appréhender / concevoir du code d'un plus haut niveau (ou avec plus de recul). En ce qui me concerne je perdrait beaucoup a me passer d'un papier, d'un crayon et de quelques schémas (UML ou autre). Bref c'est comme la carte routière : tant que l'on n'a pas fait le chemin, c'est bien pratique et pour certain (moi) indispensables.

Cela se fait dans la tête et évolue au fur et à mesure

Au passage, une vue d'ensemble et les idées claires évite de faire trop évoluer le projet. D'ailleurs, un projet (ou juste l'architecture) qui évolue est la principale cause d'échec.

De même pour la motivation, on en a ou en a pas... C'est vrais mais quand on sais/pense que c'est le point le plus important d'un projet amateur, certain conseil peuvent être utile.
Partir de suite et tout seul sur le gros projet de ses rêves demandera beaucoup plus de motivation qu'un projet moins ambitieux a plusieurs.
mes idées:
- ne pas être seul. avoir quelques testeur avec qui en discuter est déjà pas mal. en discuter sur ce genre de forum est bien aussi.
- avoir rapidement quelque chose de testable / montrable. pour soi, mais aussi pour en discuter avec d'autre.
- ne pas être trop ambitieux (c'est toujours plus long que prévu) quitte a prévoir une architecture évolutive.
- avoir une bonne vision de l'avancement du projet (une vision d'ensemble avec schéma est utile ici). régler rapidement le point bloquants.

[keke]

Partir de suite et tout seul sur le gros projet de ses rêves demandera beaucoup plus de motivation qu'un projet moins ambitieux a plusieurs.
mes idées:
- ne pas être seul. avoir quelques testeur avec qui en discuter est déjà pas mal. en discuter sur ce genre de forum est bien aussi.
- avoir rapidement quelque chose de testable / montrable. pour soi, mais aussi pour en discuter avec d'autre.
- ne pas être trop ambitieux (c'est toujours plus long que prévu) quitte a prévoir une architecture évolutive.
- avoir une bonne vision de l'avancement du projet (une vision d'ensemble avec schéma est utile ici). régler rapidement le point bloquants.

Cela se résume à avoir de l'expérience dans la gestion de projet ... et malheureusement, aucun outils (papier, crayon, diagramme, logiciel ...) ne remplacera l'expérience. Par ailleurs, bien que je suis d'accord avec Kroc, il me semble qu'au départ, il est souvent plus facile d'être seul sur un projet ... en effet, un projet en groupe est plus délicat à gérer pour certaines personnes (majoritairement dans le cas de Geeks et des Nerds).

kéké

[Allwise]

Pour moi l'analyse est très importante dans un projet, qu'elle se présente sous forme de diagrammes UML, de schémas persos ou de notes. Parce que d'une part, tout ce qui se passe dans la tête à un moment donné, il vaut mieux le figer quelque part pour ne pas l'oublier... Là je parle surtout des idées. Et d'autre part, si on conceptualise pas notre projet de manière abstraite, on risque de se planter dans le développement et de faire marche arrière, d'omettre des trucs importants, de faire quelque chose de moins modulaire / évolutif qu'on ne l'aurait voulu...
De toute façon, si on ne fait pas l'analyse a priori, on la fait pendant le développement du projet dans sa tête... C'est juste plus simple et plus rapide de corriger un schéma que de corriger tout son code source quand on s'aperçoit qu'il y a une couille dans le potage
Pour les petits projets qui tiennent à quelques classes et quelques fichiers, ou pour ceux qui se font toujours plus ou moins de la même façon ( ex : un site web ), on peut lésiner sur l'analyse.

Sachant que de mon point de vue, avant d'envisager de faire une anlyse correct, il faut maitriser les différentes problématiques liès à la programmation d'un jeu.
Comment faire l'analyse d'un système de gestion de membre si on ne sait pas ce qu'est une session?

En principe, on fait une analyse et après on la traduit en code dans un langage ou dans un autre, mais on ne devrait pas se soucier des spécificités d'un langage au moment de l'analyse, parce que celle-ci est censée être bien plus abstraite.
Si on ne sait pas ce qu'est une session, ben c'est mal barré :haha:

Et puis passer par l'étape chiante de l'analyse, c'est faire preuve d'une motivation certaine

[Zamentur]

Sachant que de mon point de vue, avant d'envisager de faire une anlyse correct, il faut maitriser les différentes problématiques liès à la programmation d'un jeu.
Comment faire l'analyse d'un système de gestion de membre si on ne sait pas ce qu'est une session?

En principe, on fait une analyse et après on la traduit en code dans un langage ou dans un autre, mais on ne devrait pas se soucier des spécificités d'un langage au moment de l'analyse, parce que celle-ci est censée être bien plus abstraite.
Si on ne sait pas ce qu'est une session, ben c'est mal barré :haha:

Et puis passer par l'étape chiante de l'analyse, c'est faire preuve d'une motivation certaine

Bon la citation que tu fait de moi est un peu sortie de son contexte, ou mon but était d'appuyer sur les besoins de montrer simplement tous les aspect de la création d'un premier jeu au travers d'un tuto.

C'était evidement un exemple caricatural.

Cependant je tient à réagir sur le fait que quand on fait une analyse on la fait souvent de manière orienté vers un langage ou du moins un type de langage. Par exemple avec le couple javascript&HTML/PHP il serait impossible de batir l'hypothése " il est possible d'avertir les autres joueurs en 1 seconde de ce qu'a fait un autre joueur". A moins de connaitre beaucoup de langage, on fait aussi souvent le choix de rester dans ce qu'on connait. Donc dire que l'analyse ne dépend aucunement du langage c'est à mon sens une hérésie.

NB : j'ai édité mon message que j'avais du laisser en plan hier soir

[Allwise]

Sachant que de mon point de vue, avant d'envisager de faire une anlyse correct, il faut maitriser les différentes problématiques liès à la programmation d'un jeu.
Comment faire l'analyse d'un système de gestion de membre si on ne sait pas ce qu'est une session?

En principe, on fait une analyse et après on la traduit en code dans un langage ou dans un autre, mais on ne devrait pas se soucier des spécificités d'un langage au moment de l'analyse, parce que celle-ci est censée être bien plus abstraite.
Si on ne sait pas ce qu'est une session, ben c'est mal barré :haha:

Et puis passer par l'étape chiante de l'analyse, c'est faire preuve d'une motivation certaine

Bon la citation que tu fait de moi est un peu sortie de son contexte, ou mon but était d'appuyer sur les besoins de montrer simplement tous les aspect de la création d'un premier jeu au travers d'un tuto.

C'était evidement un exemple caricatural.

Cependant je tient à réagir sur le fait que quand on fait une analyse on la fait souvent de manière orienté vers un langage ou du moins un type de langage. Par exemple avec le couple javascript&HTML/PHP il serait impossible de batir l'hypothése " il est possible d'avertir les autres joueurs en 1 seconde de ce qu'a fait un autre joueur". A moins de connaitre beaucoup de langage, on fait aussi souvent le choix de rester dans ce qu'on connait. Donc dire que l'analyse ne dépend aucunement du langage c'est à mon sens une hérésie.

NB : j'ai édité mon message que j'avais du laisser en plan hier soir

L'hypothèse que tu déclares impossible à bâtir est loin de l'être. Par exemple, elle est utilisée sur facebook par leur système de notifications et de messagerie instantanée. Côté client, une requête asynchrone est lancée via javascript.
Côté serveur, la requête tombe sur une boucle qui renvoie une réponse en cas de notification / message... Au bout d'environ une minute, s'il n'y a rien à notifier, le thread sur le serveur s'arrête et repart aussitôt ( à la demande de la requête ajax qui est renvoyée ).

Ensuite, il me semble que l'AS3 gère les sockets, et permettrait d'établir une connexion continue sur un serveur ( à vérifier ).
Rien d'hérétique là-dedans, si ?

Puis de toute façon, j'y connais pas grand chose en jeux web, mais j'ai cru comprendre que ceux qui n'utilisent ni Flash, ni Java, donc ceux qui utilisent Php / Javascript, peuvent difficilement être des jeux en temps réel ( corrigez-moi si je me trompe )... Alors c'est sûr qu'avant même de penser au côté technique du truc, faut prendre ce paramètre en compte.

[wild-D]

Puis de toute façon, j'y connais pas grand chose en jeux web, mais j'ai cru comprendre que ceux qui n'utilisent ni Flash, ni Java, donc ceux qui utilisent Php / Javascript, peuvent difficilement être des jeux en temps réel ( corrigez-moi si je me trompe )... Alors c'est sûr qu'avant même de penser au côté technique du truc, faut prendre ce paramètre en compte.

terre-des-éléments c'est du php/javascript pur.
ben même si à la base y a bien un compteur de PA, c'est pensé comme du "jeu temps réel" pour le PvP sur MZ (espère pas laisser ton perso trainer "dehors" longtemps sans te faire dégommer; si tu réagis pas rapidement t'es mort).

edit: après on peut toujours se demander si le choix technologique est le plus adéquat