+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Débuter et gérer son projet (https://jeuweb.org/forumdisplay.php?fid=60)
+--- Sujet : Spécifications - Etude de cas (/showthread.php?tid=1798)
Spécifications - Etude de cas - Kalan - 02-10-2007
En référence au sujet "Y a pas que la technique", je prends le risque des quolibets :-) et poste ici ce qui m'a servi de "spécifications" pour la réalisation de Gloire et Pouvoir.
Ce document date d'Octobre 2000 et était ma première réalisation dans le monde du jeu.
Il n'est pas à prendre en exemple de ce qu'il faut faire; mais peut être un bon support d'analyse et de discussion de ce qu'il aurait du être.
En effet, l'analyse est par trop superficielle, je me suis lancé dans le codage avant même de l'avoir terminé. Je ne me suis pas posé des questions assez essentiuelles et j'en ai subi pas mal de conséquences.
Un énorme travail a été fait au cours des 7 dernières années pour redresser le cap :-).
Document de travail
RE: Spécifications - Etude de cas - Kalan - 02-10-2007
Rapidement, les premiers éléments manquant à ce document :
- Le type de jeu n'est pas correctement défini :
à la lecture du passage :
Citation :Chaque pays est décomposé en un nombre fini de territoire, une fois que l’ensemble des territoires d’un pays possède un seigneur, un nouveau pays (voisin) sera « ouvert ».On pourrait comprendre qu'il s'agit d'un jeu à univers persistant pouvant croitre en fonction de l'arrivée des joueurs.
Mais rien ne précise comment les joueurs peuvent être intégrés. La gestion Anciens joueurs (puissants) / Débutants (faibles) n'est absolument pas réfléchie
La conséquence : Gloire et Pouvoir est très rapidement devenu un jeu à partie fermée !
Comme vous voyez, l'impact est majeur : parti d'une idée d'univers persistant, le manque de réflexion a engendré l'impossibilité, d'un point de vue gameplay, de rester la-dessus.
- Les quêtes et les campagnes
Ces notions ont été à peine abordées dans le document. Remises à plus tard pendant plus d'un an d'exploitation du jeu, je les ai finalement abandonnées n'ayant pas prévu leur mode de gestion.
La conséquence est importante : la mise en place de l'esprit "Roliste" est bien plus difficile à atteindre.
Gloire et Pouvoir cherche à se positionner à la croisée des chemins entre Risk/Diploacy et le jeu de rôle.
Mais déjà, les 2 premières imprécisions/erreurs donne du fil à retordre à la cré"ation d'une ambiance "jeu de rôle" : pas d'univers persistant, pas de Quêtes/Campagnes support au jeu de rôle.
Il y a beaucoup d'imprécisions et je laisse tout un chacun y aller de ses remarques.
Notez que si le document était de qualité, chacun d'entre vous, après lecture, devrait être en mesure de rélaiser le jeu.
Or, il se trouve que ce document (très mauvais, soyez en sûr) est trop sujet à interprétation.
Il serait utile pour tous et pour chacun d'y aller de ses critiques.
Après un bon passage à tabac de ces spécifications, nous devrions être en mesure de faire ressortir les éléments qui nécessitent d'être analysés lors de la création d'un jeu.
RE: Spécifications - Etude de cas - pascal - 02-10-2007
Kalan a écrit :Il serait utile pour tous et pour chacun d'y aller de ses critiques.
Après un bon passage à tabac de ces spécifications, nous devrions être en mesure de faire ressortir les éléments qui nécessitent d'être analysés lors de la création d'un jeu.
je vais t'en mettre plein les dents... enfin, plein les spécifications !
A+
Pascal
[ c'était mon intervention inutile du jour ]
RE: Spécifications - Etude de cas - Harparine - 02-10-2007
Je vais lire ton truc aussi
RE: Spécifications - Etude de cas - joshua - 03-10-2007
pascaltje a écrit :[ c'était mon intervention inutile du jour ]
La seule aujourd'hui? tu me décois, là :p
d'habitude tu fais mieux
RE: Spécifications - Etude de cas - Byleth - 03-10-2007
Bizare, j'arrive pas à lire ton PDF...
RE: Spécifications - Etude de cas - pascal - 03-10-2007
re,
voici ce que je remarque :
_ il n'y a pas de schémas : je ne parle pas de la DB, confidentialité oblige, mais de processus, de possibilités, de trucs avec des flèches pour expliquer
_ le coté "générique" n'est pas abordé : la gestion des régles, les news, la messagerie entre joueurs... est-ce pour ne pas alourdir le document, ou un oubli, ou pas l'objet du document ?
_ la fin du doc décrit des données + fonctions ( = classes ), mais on n'a pas les interactions, ni de schémas. quid d'UML ou autres ?
et aussi :
_ une spéc contient une présentation du jeu
_ effectivement, j'ai compris que la taille du "monde" était fonction du nombre d'inscrits
_ en lisant ces 20 pages, j'ai une idée de ce qu'est le jeu, sans avoir lu les 50 pages de régles
_ je ne vois rien du style "avec ça, on va accrocher le joueur", comme si le seul but du jeu était celui présenté. pas de buts annexes ?
sur ce, je file me préparer du chili :
_ maïs, haricots rouges, steak haché, tomates, tabasco, gingembre
_ faire mijoter le tout
_ manger la moitié ce soir
_ manger le reste au plus tôt demain soir
A+
Pascal
RE: Spécifications - Etude de cas - Globe - 03-10-2007
Personnellement je définis assez bien ce que je veux sans en faire des pages et des pages.
Je définis d'abord dans ma tête ce que je veux, j'analyse les possibilités et surtout je prévois un code entièrement modulable, par exemple pour un jeu de gestion je prévois un système permettant d'ajouter des nouveaux types de batiments, d'unités, de ressources via la base de données, désavantage : les pages ne sont pas optimisées et la base de donnée est très solicitée. Ensuite je fais des tas de schémas d'interactions sur papier, pour connaître toutes les inter-dépendances de mon système. Ensuite finalement je fais mes spécifications par ordinateur, je tape le concept, et je rédige en bon français tout ce qui fera le code. Ainsi on peux dire que je code mais en français, je dis par exemple ou je mettrais telle condition, telle insertion SQL... Et je me met à coder. En partant d'une base de données de scripts que j'ai fait je peux ainsi terminer un projet très rapidement sans m'y perdre. Je connais dès le départ la quantité de boulot. Cependant mes projets sont personnels donc je n'ai pas à m'inquiéter de l'impact et des impératifs de temps, tous mes projets publics stagnent indéfiniment par manque de temps, de courage et d'organisation. J'ai donc des spécifications suffisantes pour des projets de petite envergure.
RE: Spécifications - Etude de cas - Kalan - 04-10-2007
pascaltje a écrit :re,
voici ce que je remarque :
_ il n'y a pas de schémas : je ne parle pas de la DB, confidentialité oblige, mais de processus, de possibilités, de trucs avec des flèches pour expliquer
En effet, les ordres et le séquencement des phases n'ont pas été analyser en terme d'interaction. De fait, tout un tas d'effet de bord ont été mis à jour par les joueurs et le moteur a subi un très grand nombre de "réglages" pour éviter certains débordement.
Ainsi, par exemple, le système de combat prévoyait que l'attaquant combatte les unes après les autres les "garnisons" en place. A chaque combat gagné, le chevalier gagnait de la renommée. Et bien une astice est apparue : un joueur placait des dizaine de garnison de 1 seul homme. Son complice venait donc attaquer cette terre et gagnait une dizaine de combat sans risque tout en profitant d'un grand nombre de points de renommée.
L'analyse appronfondie aurait immédiatement relevé ce problème.
pascaltje a écrit :_ le coté "générique" n'est pas abordé : la gestion des régles, les news, la messagerie entre joueurs... est-ce pour ne pas alourdir le document, ou un oubli, ou pas l'objet du document ?A l'époque, jen'envisageais pas qu'il y ait plus d'une dizaine de joueurs. Il faut rappeler qu'à cette époque, le "PHP" naissait à peine en France. Tout se passait par mail et les cartes n'étaient même pas colorisées pour montrer les possessions de terres. Même le site était en fait des pages HTML statiques générées dynamiquement par le programme arbitre. Je les upoloadais ensuite :-).
Mais il est clair que, pour un jeu de diplomatie/stratégie/role, il n'y a aucune réflexion sur les mode d'échange entre les joueurs et SURTOUT sur le moyen d'impliquer les joueurs dans l'ambiance.
pascaltje a écrit :_ la fin du doc décrit des données + fonctions ( = classes ), mais on n'a pas les interactions, ni de schémas. quid d'UML ou autres ?Cette partie du document n'a jamais été finalisé. Il s'agit là d'un premier jet largement complété par la suite mais non formalisé.
Concernant UML, c'est un langage de représentation particulier qui est associé à la méthodologie objet (OMT). Ca devient plus ou moins un standard; mais la méthodo n'est qu'extrêmement rarement utilisée complètement.
Personellement, je n'emloie pas OMT et n'utilise pas UML. Il y a d'autres façon de travailler qui ont aussi fait leur preuve.
pascaltje a écrit :et aussi :Clairement, ce document ne retient que des idées rapideement jetées sur le papier. On voit bien que rien n'a été sérieusement réfléchi.
_ une spéc contient une présentation du jeu
pascaltje a écrit :_ effectivement, j'ai compris que la taille du "monde" était fonction du nombre d'inscritsOui; mais sans la description du système lui-même, le développement du jeu par toi, moi ou un autre donnerait sans doute un résultat différent.
_ en lisant ces 20 pages, j'ai une idée de ce qu'est le jeu, sans avoir lu les 50 pages de régles
pascaltje a écrit :_ je ne vois rien du style "avec ça, on va accrocher le joueur", comme si le seul but du jeu était celui présenté. pas de buts annexes ?Comme dit précédemment, en 2000, je n'envisageais pas que :
- ce jeu perdurerait et aurait "autant" (tout est relatif) de joueurs
- l'activité des jeux en ligne alternatifs connaitrait cette expansion.
Je ne me suis donc pas poser toutes ces questions :-)
[/quote]