Cahier des charges PHP

Ce cahier des charges a pour but de répertorier les différents "modules" qu'il faudra coder pour que le jeu puisse fonctionner. Ce sujet est en cours de rédaction et sera épinglé dès qu'il sera terminé.

Base de donnée d'objets
La base de donnée d'objets répertorie tous les objets du jeu, qu'ils soient matériels ou pas (une traversée de Djel'Fa en chariot ou un massage peuvent être considérés comme un "objet" et inclus dans la base). La base de données d'objets doit inclure un moteur de recherche et classer les objets par type et sous-type (par exemple arme - Hache). On doit pouvoir faire une recherche "Hache" ou sélectionner un type particulier.

Chaque objet sera présenté par les éléments suivants :
- Une icône de 50x50 pixels (réalisée par nos pixel-artistes)
- La description de l'objet
- L'encombrement ou poids de l'objet (valeur numérique).
- Le prix de base de l'objet, en Or, argent et cuivre
- Le bonus apporté par l'objet (caractéristiques ou compétences)
- Le score de difficulté pour fabriquer l'objet
- Les ingrédients nécessaires pour fabriquer l'objet
- (facultatif) : Les objets pour lesquels l'objet en question est utile (par exemple le clou sert à fabriquer le bouclier en bois, etc...)
- (facultatif) : Le nombre d'objets de ce type possédés par le personnage si le joueur est connecté avec ce dernier. Par exemple si le joueur va sur la fiche d'objet "clou", il voit combien il en a dans son inventaire.
- Un système simple d'ajout ou de modification d'objet

Fiche de personnage
Chaque joueur doit disposer d'une fiche de personnage sur laquelle seront listées toutes les informations importantes concernant son personnage. Cette fiche doit inclure plusieurs onglets :
- L'inventaire, listant l'or et tous les objets possédés par le personnage (en rapport avec la base de données d'objets)
- La description du personnage : Histoire, descriptions physiques et mentales, réputations (chiffrées) aux diverses factions, lieu dans lequel il se trouve, fatigue, blessures, la ou les factions auxquelles il appartient
- Un onglet listant les savoir-faires et les objets que sait fabriquer le personnage
- Un onglet "notes", où le joueur pourra récolter des rumeurs par exemple, des informations, ce qu'il veut...
- Les caractéristiques et compétences du personnage, chiffrées, ainsi que ses éventuels sorts/techniques
- Une gestion des "permissions" d'accès aux informations du personnage, certaines informations ne doivent être accessibles qu'aux admins ou MJs, d'autres qu'aux membres d'une même faction, d'autres qu'aux joueurs dont les personnages ont une certaine Acuité, d'autres qu'aux joueurs dont les personnages sont dans le même lieu.
- Un système de modification ou d'ajout de compétences (ces dernières n'étant pas encore définitivement fixées).

Calculateur d'actions

Le calculateur d'actions doit être en rapport avec le profil (caractéristiques/compétences) du personnage ainsi qu'avec son inventaire. Le calculateur d'actions sera utilisé par le MJ pour calculer de façon semi-automatique le résultat d'une action. Comment ça se passe concrètement ?

- Action du personnage 1 : Niveau de la compétence du personnage + Niveau de la caractéristique associée à cette compétence + Avantage de situation (ajouté manuellement par le MJ) + facteur chance (1D5 : -2, -1, 0, +1, +2 aléatoirement)+ bonus/malus éventuels apportés par les objets de l'inventaire ou les blessures (possibilité du MJ d'ajouter manuellement des bonus/malus auxquels n'aurait pas pensé le système)
- Riposte personnage 2 : Idem. Ou score "passif" d'Environnement au montant défini par le MJ. Facultatif : Affichage "automatique" des tables de score d'environnement à côté pour faciliter la vie du MJ dans le choix du score à atteindre.

Calcul de la différence de points automatique > Puis au MJ de trancher en définissant textuellement l'impact de ce calcul sur le jeu. Facultatif : Affichage des tables de résolution d'actions à côté pour faciliter la décision du MJ.

Le MJ devra donc choisir une compétence dans la liste des compétences existantes, l'ordinateur associera lui-même la caractéristique associée en allant chercher les données dans la fiche de personnage. De même, les bonus d'inventaire seront ajoutés au calcul. Le MJ devra pouvoir modifier ce score manuellement. Le calcul est là pour faciliter le boulot du MJ qui devra adapter ce calcul brut à chaque situation.

Système d'évènements automatiques

A discuter

MJ et Gestion des messages
Dans les messages en-jeu, le MJ doit disposer d'une zone séparée dans laquelle seront effectués les divers calculs de résolution d'action (invisibles aux joueurs). Il doit disposer également d'une zone "à part" collée à chaque message où il fournira au joueur la résolution textuelle de son action en cours : "Voilà ce qu'il se passe..." ; il faudra que le MJ ait la possibilité de ne s'adresser qu'au joueur du message pour lequel il fait la résolution, ou qu'à certains intervenants du message, ou qu'aux personnes ayant déjà participé au sujet. Il faudra donc des balises spécifiques simples d'utilisation pour déterminer qui peut lire les messages si une lecture sélective s'impose.

Il faudra également un système d'ajout d'objets simple. Par exemple lors de la fouille d'un corps d'un marchant assassiné par deux joueurs jouant des voleurs : Que le MJ puisse : Soit distribuer directement les objets dans les inventaires des joueurs ; le plus simple étant une balise "ajout" peut-être. Soit créer un mode "butin" où il indique quels objets sont trouvés et qui peut les ramasser. Les joueurs pourraient alors ramasser les objets librement, mais uniquement ceux concernés par le butin. Il y aurait alors un texte en rouge qui s'afficherait : "Objet" ramassé par "joueur1".
En balises ça pourrait donner : [Butin=joueur1,joueur2][Or]x10,[Epee mediocre],[petite pierre taillée]x2[/butin] . Cela afficherait un truc du genre : Butin : 10 pièces d'or, 1 épée médiocre, 2 petites pierres taillées. Les 2 joueurs qui peuvent ramasser le butin cliqueraient sur le butin pour ramasser un objet ; cela indiquerait "voulez-vous ramasser cet objet ? Oui/non". Une fois ramassé, il y aurait écrit : "Tel objet a été ramassé par tel joueur". Le butin ne serait visible que par les joueurs indiqués dans le butin.

Fonctionnalités secondaires

- Numérotation des messages en-jeu : Les messages "roleplay" de chaque personnage (faits dans les zones de jeu) devront être numérotés automatiquement de 1 à x, sans prendre en compte les messages "HRP", hors-jeu.

- Lien vers les messages suivants/précédents : Uniquement pour les messages en-jeu, chaque message devra mener via un lien vers le message précédent et également vers le message suivant, afin de pouvoir suivre de manière fluide l'histoire d'un joueur sans chercher ses messages.

- "Tchats" de zone : Que chaque zone dispose d'un tchat sur lequel les joueurs présents dans la zone puissent discuter. Il est certaines discussions qui ne requièrent pas un MJ et qu'il est préférable de ne pas écrire noir sur blanc (à confirmer et débattre avec l'équipe)

- Zones différentes : Un personnage ne doit voir que les messages écrits dans la zone où il se trouve, et dont le dernier message du sujet remonte maximum à 1 semaine d'intervalle du moment où il est dans la zone (et évidemment il peut voir aussi tous les sujets auxquels il a participé). Un personnage n'est pas omniscient

- Action "se déplacer" : Le jeu sera séparé en diverses zones correspondant aux divers lieux de l'univers. Le personnage doit pouvoir faire l'action "se déplacer" qui l'amènera dans une autre zone. Il ne doit pouvoir agir qu'une seule fois par message et devra à ce moment là décrire textuellement son action (où il va, comment, puis ce qu'il fait dans la zone concernée).

- Rumeurs : Que lors des actions importantes les MJs puissent écrire des "rumeurs" : Une rumeur juste, une rumeur amplifiée, une rumeur déformée, une rumeur fausse pour chaque évènement par exemple. Selon un algorythme encore à définir, le joueur pourrait (en payant des coups à boire dans une Taverne par exemple) récolter automatiquement (sans l'intervention d'un MJ) certaines rumeurs.

- Ramasser une annonce : Les annonces donnant lieu à des quêtes dans des lieux précis (taverne par exemple : Avis de recherche de criminels) pourraient être récupérés automatiquement par le joueur en cliquant sur "ramasser une annonce". Une copie de cette annonce serait alors ajoutée dans son inventaire.

(note : Pas fini et susceptible d'être modifié. Merci de me prévenir en cas d'oubli ou si vous pensez que tout ça peut être mieux présenté différemment)

N'hésitez pas à apporter des précisions à ce sujet. J'ai besoin de construire rapidement un Cahier des charges php clair et complet car j'ai peut-être trouvé un codeur PHP compétent et il ne faut pas le décevoir

C'est une immense opportunité pour nous, merci donc de m'aider à clarifier ce qui n'est pas clair, à entrer plus dans les détails, à me proposer des choses que j'aurais oubliées. En vous remerciant.

J'ai réalisé un début d'organisation du profil pour vérifier que je n'oubliais rien. J'ai fait des schémas. Merci de me dire comment vous trouvez cette organisation (je précise que ce sont des schémas donc l'important c'est le contenu et l'organisation, pas l'aspect qui peut évoluer) et surtout si vous pensez que j'ai oublié quelque chose.

Comme vous pouvez le voir le profil compte plusieurs onglets et je n'ai réalisé le schéma que pour 2 onglets pour le moment.

Le profil

Spoiler:

L'inventaire

Spoiler:

Ah oui tu veux vraiment tout automatiser ... Je pensais pas que c'était à ce point là ...

Tu crois pas que ça fait trop ? A mon avis, ça fait trop ... Ça ne ressemblera plus du tout à un forum du coup ...

Genre ça :

Citation :

- Zones différentes : Un personnage ne doit voir que les messages
écrits dans la zone où il se trouve, et dont le dernier message du
sujet remonte maximum à 1 semaine d'intervalle du moment où il est dans
la zone (et évidemment il peut voir aussi tous les sujets auxquels il a
participé). Un personnage n'est pas omniscient

Et si un joueur veut lire le RP d'un autre ? Car c'est ça le RP sur forum aussi.

Je me met à la place de quelqu'un qui arrive et qui découvre ça ... c'est assez compliqué.

C'est vrai que certaines actions qui me semblent complexes ( calculateur d'action ) sont semi-automatiques, mais il y a beaucoup de malus, bonus, compétences, +1, -1 ... ça risque de décourager dès le premier abord.

Et à partir de là on se demande ( toujours à la place de celui qui vient d'arriver ) : c'est un forum de RPG ?

Je suis pas contre l'idée hein ^^ mais on s'éloigne quand même beaucoup du forum RPG " classique " si je puis dire. On perd un certain charme qu'a le RP classique c'est-à-dire de se déplacer au fil des RP, de voir son combat être gagné ou non parce que l'on écrit bien, et non plus pour seulement des données chiffrées ( je dis pas un niveau 1 contre un niveau 4 mais bon ... ). On perd une certaine part de hasard, de surprise. Tout est " codifié ". Après c'est mon point de vue

Je voulais juste savoir, tu compte faire ça comment ? En parallèle avec ce forum, en lien direct, en le remplaçant ... ?

Citation :

Le score de difficulté pour fabriquer l'objet

Je comprends ce que ça veut dire, et c'est pas bête, mais on perd la dimension " RPG " dont je parlais. Ca devient des chiffres, alors qu'on pourrait simplement dire " A tel niveau tu peux faire ça, ça et ça, A tel autre ça ça et ça ". C'est un peu la même chose, mais c'était juste pour illustrer ce que je disais.

Et sinon ...

Citation :

Système d'évènements automatiques

Euh ... je comprends pas bien ce que c'est

Bon j'y vais de mes quelques précisions.

Citation :

Ah oui tu veux vraiment tout automatiser ... Je pensais pas que c'était à ce point là ...

Tu crois pas que ça fait trop ? A mon avis, ça fait trop ... Ça ne ressemblera plus du tout à un forum du coup ...

Sois plus clair. Qu'est-ce que je veux automatiser et qui te gêne exactement ?

Citation :

- Zones différentes : Un personnage ne doit voir que les messages
écrits dans la zone où il se trouve, et dont le dernier message du
sujet remonte maximum à 1 semaine d'intervalle du moment où il est dans
la zone (et évidemment il peut voir aussi tous les sujets auxquels il a
participé). Un personnage n'est pas omniscient

En effet, je me suis posé la même question que toi Leelou. D'un autre côté, pour une meilleure immersion dans l'univers il faut que le joueur ne soit pas omniscient. Les joueurs seront amenés à s'opposer, à découvrir des secrets, etc... Il faut que les informations et les allées et venues des joueurs restent confidentielles ! La solution qu'on pourrait envisager c'est de rendre visibles par tous uniquement les messages ayant plus d'un mois et demi. Ainsi le mode "lecture" serait possible mais on ne pourrait lire que les péripéties qui appartiennent à l'histoire, bref des faits dont tout le monde aura fini par entendre parler s'ils sont importants. Et on garde le suspense, les joueurs adverses ne peuvent pas savoir où ils vont trouver le joueur "machintruc" en lisant ses messages. Qu'en pensez-vous ?

Citation :

C'est vrai que certaines actions qui me semblent complexes ( calculateur d'action ) sont semi-automatiques, mais il y a beaucoup de malus, bonus, compétences, +1, -1 ... ça risque de décourager dès le premier abord.

Attention, tout le système de calcul d'actions et d'automatisation ne concerne en aucun cas les membres ! C'est le principe du JDR : Le joueur raconte les actions de son personnage, il fait du rp. Et le MJ quantifie tout ça et utilise le système de jeu pour résoudre de manière logique et objective ses actions. On est ici dans un cahier des charges PHP, donc tous les détails "crus" sont apportés, mais le joueur ne sera pas confronté à ces calculs barbares ! Lui il recevra une explication détaillée de l'issue de son action et des évènements autour de lui, et il y répondra alors de façon "rp"

Citation :

On perd une certaine part de hasard, de surprise. Tout est " codifié ". Après c'est mon point de vue

Justement on ne perd pas la part de hasard. Le hasard (symbolisé par un D5) a une part importante dans l'issue des actions, ainsi que le "bonus de situation" qui apporte un avantage non négligeable à l'un ou l'autre des camps. Ce bonus dépend fortement du talent que va montrer le joueur à exploiter par écrit une situation donnée, donc de son imagination et partiellement de son talent littéraire

Citation :

Je comprends ce que ça veut dire, et c'est pas bête, mais on perd la dimension " RPG " dont je parlais. Ca devient des chiffres, alors qu'on pourrait simplement dire " A tel niveau tu peux faire ça, ça et ça, A tel autre ça ça et ça ". C'est un peu la même chose, mais c'était juste pour illustrer ce que je disais.

Un petit conseil, lis attentivement le système de jeu avant de le mettre en doute ; d'abord, on ne va pas remettre en cause un système accepté par tous depuis plus de 6 mois. Ensuite, ce message est fait pour monter le cahier des charges du codage php à réaliser, pas pour discuter des détails du fonctionnement déterminé pour le jeu. Je peux seulement te dire que je ne vois pas pourquoi un joueur de nv 5 dont les qualités sont le combat et la stratégie devrait savoir fabriquer des potions de guérison. La difficulté de l'objet est logique : Un objet est plus ou moins difficile à fabriquer. Le MJ doit pouvoir déterminer à chaque action si cette dernière est réussie ou non par le joueur. Ce calcul encore une fois n'est pas visible du joueur. Il peut en partie jouer "les chiffres" et exploiter le système s'il le désire, mais il peut aussi la jouer purement rp et ne pas du tout s'en préoccuper. Le système de jeu et de résolutions d'actions concerne le MJ, encore une fois. Pour en savoir plus sur le moyen dont on détermine si un objet fabriqué est réussi ou raté, encore une fois je t'invite à lire attentivement le système de jeu.

Citation :

Système d'évènements automatiques

Ca par contre c'est encore à discuter. Je me demandais s'il ne serait pas intéressant, dans le cadre des déplacements du personnage, d'implanter des évènements aléatoires préalablement listés et détaillés sur lesquels tomberait le joueur. Quel intérêt ? Avant tout alléger la charge de travail du MJ qui pourrait ainsi gérer plus de joueurs et s'investir mieux dans les parties qui nécessitent vraiment son investissement. Bien entendu, ces évènements seraient ensuite repris et gérés par le MJ, et le MJ pourrait et devrait bien entendu créer d'autres évènements par lui-même dans les aventures des joueurs. Ce système d'évènements aléatoires ne s'enclencherait que lorsque le joueur se déplace d'un lieu à un autre, serait inévitable, et interviendrait avant que le joueur poste : Ainsi il devrait réagir face à cet évènement. Bien entendu parfois aucun évènement particulier ne viendrait rythmer l'évolution du jeu lors des déplacements.

Merci de ne pas s'éloigner du sujet et de rester dans l'optique de la construction du cahier des charges PHP (cela s'adresse à toi Amélie ). Si vous avez d'autres questions à soulever, n'hésitez pas à ouvrir un nouveau sujet.

Citation :

et qu'il est préférable de ne pas écrire noir sur blanc (à confirmer et débattre avec l'équipe)

C'est-à-dire ?

Sinon j'ai tout compris ( c'est bien Amélie )

Euh Amélie cite des phrases entières stp sinon je galère à comprendre ta question ^^

Citation :

- "Tchats" de zone : Que chaque zone dispose d'un tchat sur lequel les joueurs présents dans la zone puissent discuter. Il est certaines discussions qui ne requièrent pas un MJ et qu'il est préférable de ne pas écrire noir sur blanc (à confirmer et débattre avec l'équipe)

Un exemple simple : Plusieurs joueurs se rencontrent dans une zone. Au hasard, le quartier marchand d'une ville. Ils veulent alors se mettre d'accord sur un prix. Plutôt que d'échanger chacun 25 messages en-jeu qui n'auraient aucun intérêt, ils peuvent la jouer directement par rp sur le tchat afin de se mettre d'accord sur un prix. Ce qui n'empêche pas qu'ils devront squand même décrire leur marchandage. Ca peut servir pour des joueurs qui voudront se partager un butin, pour des joueurs qui devront se concerter avant de décider quelle action ils entreprendront, pour toutes les discussions qu'il est plus intéressant de résumer sur le message plutôt que de discuter dans le détail dans 25 messages monolignes. Bref, ça permet aux joueurs de se mettre (ou pas) d'accord, tout en restant dans le jeu et en la jouant "rp" sur un tchat.

Oooooki ^^ Je pensait que c'était une histoire de couleur du texte, je n'avais pas bien lu la phrase. Ç'est une bonne idée, ça permet d'éviter les HRP plus longs que le RP ou les MP à tout bout de champ ^^

Pour les évènements automatiques, est-ce qu'on peut en créer seulement lors des déplacements ? Ce serait peut-être intéressant de faire les évènements aléatoires aussi sur les cases ( si c'est possible ). Au bout de X temps qu'on est sur une case par exemple, il y a au hasard un évènement aléatoire ... ou non. Euh ... est-ce que c'est clair ?

De la même manière, il pourrait y avoir des évènements aléatoires selon le nombre de personnes. Quand il y a tel nombre de personnes sur une case, il y a un évènement aléatoire qui les concerne tous ... ou il ne se passe rien.

Bonsoir,

je vais exposer ce que j'ai décidé de faire pour la forme de la V2. Brisecous a été clair sur ce qu'il voulait comme présentation pour le forum de la V2. Nous allons donc abandonner la structure classique du forum que vous connaissez tous (du moins en apparence). Nous voulons que l'organisation du forum et son design soit le plus prenant possible pour les joueurs et c'est pourquoi j'ai décidé de coder un forum à partir de 0 (ou presque) pour être libre dans l'organisation de celui-ci (donc pas de phpbb3).

Les MJs auront à leur disposition un pannel de gestion pour leur simplifier au maximum les "calculs" et autres estimations... et ainsi ils pourront se concentrer sur le RP (d'ailleurs, toutes ces automatisations ont pour seul et unique but de mettre en avant le RP).

Amélie, tu pourrais développer ton idée, j'ai un peu de mal à te suivre (schémas?).

Ça va être intéressant, j'ai déjà fait un forum en partant de 0 mais jamais réussi à faire aussi complexe que xooit ou autre plateforme qui utilise des BB.

Donc si je comprend bien, c'est comme faire un site en entier ? Ça risque d'être long si on veut de la qualité ^^

Bon, je ne suis décidément pas douée avec Paint ^^

Un petit schéma, j'espère que tu comprendras ^^. Ce serait la même chose pour le temps. Mais là c'est histoire que le joueur ne reste pas 100 ans sur une case sans que rien se passe ^^

( Faut cliquer sur la miniature )

Au fait, si mon idée est nulle, dîtes-le moi tout de suite que j'arrête de faire mes magnifiques schémas ^^

Ok merci

Amélie Santhan a écrit:

Pour les évènements automatiques, est-ce qu'on peut en créer seulement lors des déplacements ? Ce serait peut-être intéressant de faire les évènements aléatoires aussi sur les cases ( si c'est possible ). Au bout de X temps qu'on est sur une case par exemple, il y a au hasard un évènement aléatoire ... ou non. Euh ... est-ce que c'est clair ?

De la même manière, il pourrait y avoir des évènements aléatoires selon le nombre de personnes. Quand il y a tel nombre de personnes sur une case, il y a un évènement aléatoire qui les concerne tous ... ou il ne se passe rien.

Alors : Pour le temps sur les cases, je pense que ce n'est pas possible. D'abord parce que le "temps" en-jeu n'est pas le même que le temps hors-jeu. Une bataille de 4 h pourra très bien prendre 15 jours selon les dispos des MJs/des joueurs. Ensuite, il ne faut pas oublier que si le joueur est sur une "case" (on parlera plutôt de lieu que de case), il est normalement pris en charge par un MJ. Ce qui signifie qu'un scénario, une trame sont en cours. On ne peut pas faire démarrer comme ça aléatoirement un évènement. Ou alors, que le MJ (ou même le joueur avec certaines limites) soit libre d'activer lui-même le générateur d'évènements pour qu'il se passe "quelque chose".

Même problème pour les évènements selon le nombre de personnes. Logiquement, les personnes concernées seront toutes en train de vivre un scénario. on ne peut pas au milieu de 3 scénarios potentiellement différents faire intervenir un évènement aléatoire qui va tout casser.

En revanche, on peut "forcer les rencontres". Je m'explique. Un joueur est en un lieu est vit un scénario. On peut considérer que dès lors que deux personnages sont dans un lieu ils se rencontrent (même si théoriquement un lieu comme une ville est très vaste) dans la même optique de "forcer les rencontres". Le MJ va alors intégrer le nouveau-venu dans la trame scénaristique du premier, quelle qu'elle soit. Cela pourra donner lieu à une rencontre, à une adversité, ou bien chacun continuera son chemin sans plus d'intéraction. Ca, ça pourrait être intéressant. Mais il ne faut pas que le scénario soit "brisé" par des évènements aléatoires qui tombent comme un cheveu dans la soupe.

On peut mettre en place des évènements aléatoires lors des déplacements car alors le joueur n'est pas dans une trame scénaristique précise, vu qu'il vient d'arriver dans le lieu. Mais à part dans ce cas précis où un évènement aléatoire permet au MJ de gagner du temps et au joueur d'avoir un peu plus d'imprévu, en dehors de ce point précis je pense qu'il ne faut surtout pas automatiser plus les scénarios qui doivent rester aux mains des MJs. Le but est d'automatiser le système justement pour que les MJs s'occupent plus des scénarios et des joueurs, pas le contraire ^^.

Que pensez-vous de ces deux points :
- "Forcer les rencontres" lorsque deux joueurs sont dans un même lieu
- Créer un système d'évènements automatiques utilisable par le MJ via un "clic" et qui s'enclenche automatiquement uniquement lors des déplacements ?

Forcer les rencontres? Mouais... Les rendres possibles mais pourquoi les forcer? On pourrait laisser le choix au joueur arrivant sur le lieu de décider ou pas de prendre part à certain scénario. Cependant, on pourrait aussi faire en sorte que des événements importants sur un lieu particulier feront forcément intervenir les joueurs arrivant sur ce lieu. Une émeute de grande ampleur dans telle ou telle ville ne pourra pas passer inaperçu aux yeux des joueurs.

Des événements aléatoires lors des déplacements? Ouais mais si ces événements sont variés et propres à chaque lieu. Si c'est pour avoir 5 événements différents, ça deviendrait très vite lassant.

Je pense que ça ne doit pas être trop compliqué de faire des évènements automatiques variés.

Par exemple :

Evènement 1 : Attaque de bandits > 5% de chances > Définition aléatoire du nombre d'ennemis et de leur force (1 à 5)
Evènement 2 : Marchand au chariot enlisé > 5% de chances


Ainsi même si on a peu d'évènements (mais on peut en faire plus bien entendu), il se passe plus souvent "rien" (mais le MJ peut et doit créer bien entendu des évènements non automatisés) et donc on n'a pas d'évènements trop répétitifs.

Le fait de forcer les rencontres découle de discussions précédentes qu'on avait eu sur le fait que G&H était un jeu qui se jouait à plusieurs, en groupes, et sur le fait qu'il n'était intéressant ni pourle MJ ni pour le joueur de faire jouer un joueur qui resterait tout le temps dans son coin (obligation de créer 1 scénario entier pour un seul joueur, manque d'interactivité...). Donc dans ce cas, "forcer les rencontres" serait un bon moyen de faire se regrouper les joueurs. L'avantage c'est qu'on peut automatiser un peu ça pour que le joueur sache où et comment poster et que le MJ ait juste à inclure le nouveau-venu dans la trame. La question donc c'est est-ce qu'on le fait de façon automatique (et systématique), ce qui a certains avantages, ou pas ?

Le truc c'est que lorsqu'on le fait " automatiquement ", c'est vrai que ça laisse plus de temps pour MJ, puisque qu'il n'a qu'à le reprendre pour la suite. Mais je préférais tout de même que ce soit le MJ qui le fasse d'un simple " clic " parce que :
- Pour les joueurs qui ne se crée pas d'évènements importants, qui se contentes de voir, manger, dormir ... cela permettrait au MJ de l'obliger à agir dans son RP, puisque l'évènement serait " forcé "
- Pour les joueurs qui, au contraire, agissent beaucoup dans leur RP, les MJ pourraient leur donner des évènements moins souvent. C'est une question un peu de cas par cas presque, en fonction de chacun.
Par exemple : Monsieur X poursuit un bandit. Il se déplace de case. Le MJ s'apercevra qu'un " évènement " est déjà en cours: inutile de lui en rajouter un autre.

Bon je pense qu'on peut laisser tomber cette idée de système d'évènements automatique. C'est quelque chose qui va rendre le codage plus complexe et qui n'apporte rien de plus. Rien n'empêche les MJs d'avoir dans un coin une liste d'évènements pré-rédigés qu'ils peuvent réutiliser en les adaptant à chaque situation. Pas plus long pour le MJ, y'a assez de choses à coder, et puis on pourra toujours rajouter un module plus tard si on voit que ça peut être utile. En l'état, c'est vraiment pas la priorité et on a assez perdu de temps en discussions dessus.

Les rencontres aléatoires sur la route sont à garder ! Et pour ce que ça va compliquer dans le codage ...

Suffit de créé des évènement propres à chaque route et de les tirer au sort ensuite (avec la possibilité qu'il ne se passe rien of course).

Bon faudra créer suffisamment d'évènements pour que ça ne devienne pas lassant car trop répétitif, ça prendra certes un peu de temps, mais ça sera pas franchement dur à codé (après, je dis ça, mais je ne sais pas comment marche le random en PHP XD).

Je sais utilisé la fonction mt_rand()
Après il suffira de mettre un array avec un id différents pour chaque évènement et calculé un la probabilité de chacun d'entre eux, c'est pas trop trop compliqué normalement, mais ca va être un peu plus dur de l'intégrer

Ah bon ?

Une petite fonctionnalité à rajouter à la fonction Déplacement c'est chaud à faire ?

(Bien vu le tableau ^^, j'aurai fait un switch (enfin, en java je l'aurai codé comme ça xD) comme un con xD)

Après, je suis pas un expert (très loin de là xD) en PHP je dois bien l'avouer. Je ne connais pas la faisabilité de la chose è_é.

Enfin je pense que ca va être dur, après c'est pour moi, je ne suis pas un super codeur non plus

Les événements aléatoires sont à garder je pense aussi. Niveau codage c'est vraiment pas compliqué. Moi je ferais un fichier pour chaque "destination" avec des plages de valeurs de 1 à 100 pour chaque événement et on prendrait l'événement correspondant à la valeur retournée par la fonction random.

Après, comme je le disais, il vaut varier les événements pour que ça soit vraiment intéressant. A valider.

Tout à fait d'accord

Et aussi, que je soit fixé : je travail en équipe avec un/des autre(s) codeur(s) ou est ce que je bosse seul? Ca me derange de me charger du codage seul mais c'est pour savoir si on établit une norme de codage collective ou est ce que je peux coder selon mes propres "normes".