Comment gérer la complexité d'un jeu?

[joshua]

Voilà, je commence la série de questionnement qui permettront de rédiger des articles clairs et exploitables pour les arrivants.

Donc première question: la complexité d'un jeu.

Un jour une idée germe en vous, et vous vous décidez à en tirer la substance pour créer quelque chose de complet.
Seulement, au début du projet il est difficile de savoir comment on va faire, si on saura faire, ....
Etes vous plutot du genre a tout faire au préalable sur papier, a faire de l'uml, a partir des petites briques de bases sans rédiger ou alors vous lancez vous dans le code sans filet?

N'hésitez pas à décrire votre méthode ainsi que vos petits secrets, et ce que vous pensez devoir être la bonne méthode.

[gtsoul]

Je dissocie le fonctionnel (le concept pur) du technique (son application).

Dans le fonctionnel, on peut décrire :
_ l'ambiance, le bg
_ les règles métiers

J'ai un concept d'arène en tête (pour un jdr), je sors un papier et je couche tout ce que j'ai à dire.
Je fais un croquis de l'arène, elle est en bois, avec des pieux autour de la fosse pour empêcher les combattants de sortir.
On pourra y rentrer quand on voudra et on se verra attribuer une prime de survie.
En tuant les autres on ramasse leur inventaire dont leur prime.
On ne peut en sortir que par la mort, où l'on droppe son inventaire

Ensuite, je m'intéresse aux abus possibles. Donc là je discute avec quelques personnes, y'a toujours un roliste qui traine ou au pire prenez votre coloc'. Il faut maintenant avoir un avis extérieur sur la chose et la critiquer à mort.[/i]

Le concept est sympa, défouloir et grosbillesque ; il permet de canaliser l'énergie du nolife/farmer.
Cependant, il n'offre que peu de motivation pour le casual. En effet, si l'inventaire est droppé à la mort, il n'y a pas de récompense hormis celle d'avoir résisté longtemps.
Il faut éviter la "coopération cheateuse", 10 persos refilent leur prime et se suicident.
D'ou sort l'argent de la prime, c'est incohérent et ca ouvre une dépendance de plus, le perso doit avoir cette somme en rentrant dans l'arène, il faut qu'elle soit accessible à tous les budgets (plusieurs arènes/entrées?).
Prévoir une porte de sortie, mais qui ait une contrepartie (c'est trop la honte de fuir) pour permetttre aux vainqueurs de rester en vie (et être cohérent du point de vue rp). Donc on pourrait sortir en payant 2x la prime d'entrée.

Je réalise des allers-retours entre proposition et critique jusqu'à ce que j'obtienne un truc qui me plaise (cohérent, équilibré et avec le maximum d'interactions joueurs et un minimum d'interactions "bots"). Il est conseillé de laisser s'écouler quelques journées de sommeil entre 2 propositions pour repartir sur de nouvelles bases. Ne surtout pas oublier de noter ces entretiens.

Puis, je rédige les règles métiers proprement (cad avec valeurs numériques et conventions de nommage que je respecterai par la suite) :

_ Pour entrer dans une arène, il faut possèder sur soi une somme minimale, appelée "caution de rentrée", la caution n'est pas débitée à l'entrée (c'est une caution) ; mais lorsque que l'on meurt.
_ Lorsque l'on meurt, on perd tout son argent et la moitié de son inventaire (jet 50% pour chaque objet puis jet sur la quantité). Celui-ci reste au sol, dans l'arène. Il subit en outre des blessures sur plusieurs jours.
_ l'attribution des prime lors des meurtres n'est pas automatique, les combattants doivent ramasser eux-mêmes les objets à terre.
_ Le rapatriement du corps se fait à l'extérieur de l'arène.
_ Il y a 3 arènes, donc 3 caution de rentrée une à 10po, l'autre à 500po et une autre à 1000po
_ Dans chaque arène se trouve une sortie dont l'accès coute le double de la caution de rentrée. Cependant, le combattant peur ressortir sans blessure et en conservant son inventaire

Ensuite, vient la conception du code. Dans cet exemple, le jeu est déjà fait et je ne fais qu'ajouter des fonctionnalités ; mais cela est semblable dans le cas d'un projet from sratch.
Je recense les objets qui seront utilisés dans ce système, ne pas oublier les écouteurs (ou effectuer telle vérification) :
Définir l'arène, le combattant, les portes de sortie/entrée
Puis je les définis un à un en fonction de ce qui existe déjà :
L'arène est une région géographique close délimitée par des barrières infranchissables, elle possède un évenement unique : la porte de sortie.
Le combattant est un personnage standard, on utilise le moteur de combat habituel.
La porte d'entrée est un évenement de type teleport, son point d'entrée est l'extérieur de l'arène et sa sortie est l'intérieur de celle-ci. Sa condition d'utilisation est la vérification d'une somme portée correspondante à la caution d'entrée.
La porte d'entrée est un évenement de type teleport, son point d'entrée est l'intérieur de l'arène et sa sortie est l'extérieur de celle-ci. Sa condition d'utilisation est la vérification d'une somme portée correspondante au double de la caution d'entrée. La somme est déduite de l'inventaire lors de l'utilisation.

Puis on répartit le travail :

_ dev' : créer objets arène et portes
_ illustrateur : créer icone arène et portes
_ meuj' : créer une arène test, faire la comm' (affiches dans la ville, inscription dans faq, écrire description et support joueur)

Ca c'était la partie fonctionnelle, on passe maintenant au technique, le plus facile.

Enfin je code, donc diagramme objet puis code et enfin tests.
Finalement, on amène un candide et on lui fait essayer l'arène.


(évitez de piquer l'idée de l'arène, c'est un concept en cours de dév')

[Sephi-Chan]

Pour ma part je fais des petites listes des choses à faire sur feuille, j'utilise la marge pour noter les idées qui me viennent pendant l'écriture des idées plus "mures".

Ensuite, je recoupe ces idées pour les diviser en modules pour lesquels je fais des tables.

Puis viens le "précodage", étape où j'ébauche mon code en Français/PHP un peu comme ça :

if(le joueur 1 a attaqué){
$varxxx = xxxxxxxx
On ajoute xxxx dans la table xxxx.
}

Voila, voila!


Sephi-Chan

[NicoMSEvent]

de mon coté, j'agis un peu différament. Je créer plein de petits objets (de petites fonctions) qui seront mes outils. A partir de là, je me dis que je peux les assembler, et créer quelque chose de plus complexe.

Ce n'est pas une attitude très professionnelle, mais ça m'aide a me détendre. C'est un peu comme de l'art abstrait ^^

Blague a part, par exemple, petite fonction (non testée), qui permet de frapper avec une force mesurée sur quelqu'un. Frapper fort ferait en sorte qu'on derait moins précis.

Code :

$mon_joueur.Coup($puissance, $vers_joueur){
   $precision=$this['precision']/$puissance/$vers_joueur['esquive'];
   $degats=$this['force']*$puissance/$vers_joueur['armure'];
   if($precision>25){
      $vers_joueur['vie']-=$degats;
      return 1;
   }
   else return 0;
}

a partir d'ici, je me dit qu'il doit y avoir moyen de faire des combos, genre tant qu'on touche, on frappe de plus en plus fort...

Code :

$mon_joueur.combo($vers_joueur){
    $puissance=5;
    while( $this.Coup($puissance, $vers_joueur) )$puissance+=5;
}

etc...

[gtsoul]

hs : y'a le combi volkswagen qui a coté 2 fois
@NicoMSEvent : pourquoi tu utilises $this['force'] et pas $this->force ?

[NicoMSEvent]

mhhhh.... très bonne question...

ça va faire 2 heures que j'ai plus pris de café, il me faut un stimulant pour mon cerveau

[Sephi-Chan]

Ce n'est pas une attitude très professionnelle, mais ça m'aide a me détendre. C'est un peu comme de l'art abstrait ^^

Ou comme un pilon. iffle:


Sephi-Chan

[joshua]

Bon, étant l'initiateur dela question, je vais moi aussi répondre.

Donc je pars tout d'abord d'une idée. Bien souvent, cette idée est le résultat d'un manque. pour vous donner une image de ce que je suis en train de dire:
Imaginez que vous lisez un livre ou le héros après plein de péripétie meurt. Vous êtes déçu, car vous ne vouliez pas le voir mourir. Alors inconscienmment vous faites des associations d'idées: il est mort parce que l'auteur l'a voulu, mais moi je ne voulais pas qu'il meurt, et je ne suis pas auteur.
Conclusion; si je veux que ca se passe comme je le souhaite, je dois me mettre à écrire.

J'en arrive donc a mon idée de départ. Vous jouez a un jeu, et il vous semble trop simple, ou pas assez interessant a vos yeux. Vous commencez a imaginer ce que vous aimeriez voir dans ce jeu, comment vous l'organiseriez, les techno que vous utiliseriez....
J'essaie alors de tout mettre sur papier. Ensuite, je commence a coder sans rlire ce que j'avais fait, je fais du code en partant de briques elementaires avec du code objet MVC.
Une fois que j'ai fini la base, je remonte d'un niveau, mais toujours en ne me souciant pas du tout du HTML.

Enfin quand j'ai tout codé, je regarde a mélanger fonctions et design...

[icien]

Pour mon projet, j'ai d'abord écrit sur papier ce que je voulais faire tout en pensant à la faisabilité. Ensuite par rapport a tout ca j'ai posé (toujours sur papier) la base de donnée correspondante (en me basant sur la méthode merise que j'avais étudiée il y a longtemps). Une fois tout ça fait, j'ai réfléchi a comment j'allais l'organiser au niveau interface et je me suis tranquillement lancé dans le codage. Ensuite nous sommes entrer dans une phase de tests, modifiant des valeurs pour équilibrer le jeu (c'est un jeu de combat) et ajoutant des fonctionnalités, depuis cette période toute les modification sont discutées sur un forum et ensuite testées par une quinzaine de joueurs dans une partie complète.
De cette expérience, il en ressort que le plus dur dans ce type de jeu est de faire quelque chose d'équilibré, chaque modification d'un coté entrainant un déséquilibre de l'autre, mais on y arrive.

[denisc]

Perso, j'aime bien avoir beaucoup de choses écrites, en particulier la partie métier... Mais je fonc un peu dans le vide aussi ... Pas bon, mais ça permet aussi d'affiner les concepts, car on voit aussi les points noirs quand on arrive dans le codage!

Mon plus gros soucis est distinguer les classes et la BD sur le papier! Je suis plutôt DBA et code en majorité en C#, et M$SQL... Beaucoup de procédures stockées et triggers... Et là, j'avoue que développer en mySQL et PHP me pose souvent des soucis à cause des limites (en particulier en SQL!!!)