Actions et passage de tour

[Monsieur]

Bonjour,


Tout d'abord je vous pris de bien vouloir m'excuser, je pense que ce sujet a déjà dû être traité un nombre incalculable de fois, et je suis intéressé par tout lien pouvant m'aider sur ces questions. Egalement dans le cas où je me tromperais de catégorie.


Ma question repose simplement sur une réflexion à propos d'un jeu par navigateur non-existant, de type RPG, multijoueur, dans lequel l'avantage n'est pas donné à ceux qui se connecte fréquemment.
C'est simplement une réflexion pour le plaisir de chercher et de trouver des solutions (ce que je pense trouver chez les utilisateurs de ce forum ).


Le jeu consiste à incarner un personnage. Ce personnage peut réaliser des actions (chasser, manger, se déplacer, se déplacer en groupe, chasser en groupe, attaquer à un autre personnage, ...). Si il ne mange pas, il meurt.


1ère contrainte : comment savoir qu'un personnage doit mourir de faim ?
Première solution : avoir un passage de tour fréquent qui vérifie la condition de vie de chaque personnage, et dans le cas échéant le tue.
Y-a-t-il d'autres solutions moins évidentes ?

2ème contrainte : Un joueur qui se connecte fréquemment ne doit pas avoir d'avantage sur celui qui se connecte rarement (si le jeu permet de chasser toutes les heures, si je ne me connecte que le soir je suis défavorisé par rapport à ceux qui peuvent se connecter en journée).
Première solution : Un nombre limité d'actions par tour, avec un tour assez long, au moins une journée.
Y-a-t-il d'autres solutions moins évidentes ?

3ème contrainte : un joueur ne doit pas avoir d'avantage à être le premier à se connecter après le passage de tour (avantage à l'attaque, unique animal à chasser ...).
Première solution : Des actions simultanées.
Y-a-t-il d'autres solutions moins évidentes ?


Avec ces solutions, on se retrouve avec un jeu par tour simultané, avec un tour d'au moins une journée.

1er problème : On imagine déjà des soucis de résolution de tour : que doit-il se passer si le personnage que j'attaque se déplace, part chasser, part chasser en groupe, attaque un autre personnage, m'attaque également ... ? Et si c'est moi qui me fait attaquer alors que je me déplace, pars chasser, ... ?
Et si j'indique que je me déplace en groupe mais que les autres non ? Comment je l'indique d'ailleurs ?

2ème problème : Comment gérer le déplacement ? Si on ne peut faire qu'une action par jour, l'action de se déplacer peut correspondre à une journée de marche, les cases de la carte valant donc une journée de marche de diamètre. Mais comment gérer un déplacement à cheval qui permettrait plusieurs déplacements par exemple ?

3ème problème : On aimerais également que les actions soit interactives (Par exemple, chaque chasse est différente, on peut vouloir demander au joueur si il attaque vraiment le premier animal rencontré ou si il préfère chercher un autre animal). Cet interaction aurait lieu à la première connexion du joueur chaque tour ?

4ème problème : Et si il y a plus d'une action possible par tour ? Il doit y avoir un ordre ? quelles sont les implications ?


J'espère que vous pouvez m'aider et prendre plaisir à chercher avec moi !


Merci !

[niahoo]

1. La faim

Là pas trop le choix, basiquement ton perso aura un score de "non-faim" compris par exemple entre 0 et 100.

Toutes les X secondes, tu mets à jour tous les scores de tous les personnages en leur enlevant des points. Mettons qu'un humain meure de faim au bout de 1 semaine sans manger et qu'on veuille un temps de jeu réaliste, à toi de calculer les secondes pour que, de 100, on tombe à zéro au bout d'une semaine. Si on veut un gameplay plus contraignant, on peut réduire cette durée à 24 heures par exemple, pour rendre le jeu un peu plus dynamique.

Tu peux également faire varier le nombre de points enlevés selon des formules mathématiques : plus le score et bas, et plus on en perd. Il sera donc plus intéressant de rester proche du maximum (100) plutot que de se contenter d'être "au dessus de 0". Tu peux également prendre en compte des attributs de personnage comme la "résistance", la "force" ou même un niveau de compétence en magie pour définir combien de points sont retirés.

Mais basiquement, la faim se modélise par un score qui descend petit à petit, comme en vrai. Maintenant il y a probablement d'autres solutions, mais il faut savoir rester simple. Le mécanisme que je décris est le même dans le jeu "Don't starve" (littéralement : "ne meurs pas de faim").

2. L'avantage de ceux qui ont plus de temps de jeu.

Ici il existe énormément de possibilités. Celle qui est fréquemment utilisée est celle des points d'actions : toutes les X secondes, chaque personnage gagne X points d'action. Le joueur qui joue toute la journée les dépense au fur et à mesure, celui qui ne joue qu'une fois par jour peut les dépenser d'un coup.

On veille généralement à "caper" les points d'actions : par exemple, impossible d'en accumuler plus de 240. S'il en tombe 10 par heure, ça permet de ne pas pouvoir accumuler plus de points que l'on en gagne dans une journée.

Mais on n'est plus vraiment dans le concept de tour par tour.

Sinon la solution d'avoir un tour par jour est pas trop mal, mais dans ma proposition comme dans celle-ci, le joueur qui a du temps à consacrer au jeu sera rapidement limité : un seul tour par jour, c'est pas fun, et des points d'action qui arrivent lentement c'est pas terrible non plus.

Je pense qu'ici il vaut mieux offrir plusieurs challenges aux joueurs : les casual jouent dans un terrain adapté tandis que ceux qui ont plus de temps peuvent aller dans d'autres zones du jeu, ou les tours passent plus vite par exemple.

Dans tous les cas il y aura des mécontents. Sauf si tout le monde est content avec un seul tour par jour. ça dépend du jeu.

3. Les premiers à jouer le tour

Les actions simultanées c'est bien. Mais il faut adapter le gameplay. Ensuite, si un joueur voit une biche et clique sur "Attaquer/manger" et qu'au final un tirage au sort fait qu'il n'a pas eu sa biche, il va pas piger : il l'a vue et elle est restée là tout le temps du tour. Bon, si on explique bien le fonctionnement du jeu, ça fait partie des règles et pis voilà.

Pour l'avantage à l'attaque c'est une bonne solution.

Pour moi, le tour par tour c'est bien quand c'est chacun son tour : par exemple les échecs ou Worms. Ou des tours simultanés, mais quand on a quelques joueurs sur une partie : Frozen Synapse par exemple. Sur tout un serveur de jeu MMO ça me semble mois sympathique.

Mais si tu remplaces ton animal à chasser par un buisson de baies, alors s'il y a X joueur dessus après un tour, et bien les baies sont réparties en X parts.

Que ce soit une biche ou un buisson, il faudra que le jeu montre (visuellement donc) qu'il y a plusieurs joueurs dessus.

Les problèmes

Donc voilà, pour tous les problèmes mentionnés, je dirais que le gameplay choisi : tour long avec une seule action, quelque chose de très stratégique donc, très macroscopique. En revanche, le type d'actions que tu décris appartient au microscopique : manger, marcher, gérer un individu unique (ou en gérer plusieurs mais chacun individuellement), attaquer un autre individu. Cela ne correspond pas. Tu ne peux pas, je pense, proposer de marcher toute une journée ou bien ne pas marcher du tout.

Je dirais donc que les actions possibles ne sont pas du tout adaptées aux entités auxquelles elles s'appliquent(ouf !). Du moins pour du multijoueur.

[Ter Rowan]

d autres problèmes encore (c'est plus pour rajouter des sujets que pour avoir des solutions)

je suis en groupe et le groupe avance... sauf que y en a un du groupe qui est à pied, l'autre a cheval, le troisième en brouette, bref ils n'avancent pas à la même vitesse

en plus de ça y en a un qu a trop mangé, l'autre qui meurt de soif bref, ils partirent 500 et s'en retournèrent #out of memory#



sinon il faut faire attention au sujet des "actions simultanées"
les exemples de niahoo sont pertinents (en particulier la biche) mais plus globalement, pour un rpg, quelle frustration que de devoir attendre le lendemain pour savoir ce qui s'est passé

pis encore : je peux faire trois actions.

action 1 : je décide d'aller sur la case d'à côté
action 2 : ben euh... ça dépend, y a quoi sur la case d'à côté ?
action 3 : ...

de fait pour un rpg ça me parait peu pertinent. Eventuellement séparer les actions en deux types :
les actions "individuelles" qui se réalisent quand le joueur est connecté (je clique sur le buisson, je ramasse les baies, au jeu de faire en sorte que ça n'influe pas sur la capacité des autres joueurs à ramasser les baies)
les actions "interactions entre joueurs" combat, commerce, etc... qui se réalisent en fin de tour

autant pour un jeu type diplomatie (d'ailleurs c'est le cas) on peut accepter que tout se réalise quand tous les joueurs ont donné leurs ordres autant pour un rpg ça me parait bof

[MadMass]

Oui je trouve que le concept de tour en l'état est bancal, il faut faire un choix en matière de game design. Ca me semble difficile de concilier toutes tes exigences avec un système de tours, étant donné ce que tu attends je serais plus de l'avis de niahoo (des points d'action).

Parce que le principe du tour, c'est que les joueurs n'effectuent pas d'actions, mais ils donnent des ordres. Même si le joueur se déplace et voit son personnage bouger, les conséquences de ce déplacement ne seront valable qu'à compter la fin du tour courant. Et comme dit plus haut, il peut être difficile de prévoir le tour suivant, ce qui fait qu'un joueur régulier rongera son frein avec des tours d'un jour, il ne pourra rien faire...
De même, il est possible de faire des tours plus courts et de permettre de planifier des actions, mais le soucis, c'est que si le joueur n'a pas de visibilité sur la situation du prochain tour, ça va casser. Comme dit, on ne peut pas prévoir de bouffer dans 2 tours lorsqu'on ignore si la biche sera bien tuée le tour suivant. Quand aux actions relatives aux joueurs j'en parle même pas, c'est le bordel.

Bref personnellement je vois le tour comme une contrainte (mais une chouette contrainte) car ça rend le jeu un peu plus exigeant, et ça met un peu la pression au joueur qui doit faire des choix. Mais étant donné ce que tu cherches, à savoir ne pas faire de distinction entre le joueur régulier et l'occasionnel, ça semble difficilement conciliable avec du tour par tour.

[Monsieur]

Vous avez raison. Un jeu au tour par tour simultané avec une action par tour, c'est parfait pour un jeu de stratégie, mais pas pour un RPG.

Du coup, une 4ème contrainte est de ne pas avoir justement à attendre la résolution de l'action.
On se retrouve donc avec un jeu par action.
Comme ces actions sont plus d'un niveau micro que macro, il convient de pouvoir en faire plusieurs par jour.

Cela entraîne-t-il des problèmes sur la 1ère contrainte ?
De la même manière, un script se lance pour mettre à jour la faim, la fatigue ... et vient également donner les actions aux joueurs ?
J'imagine qu'il peut y avoir des effets de bord, tel que plusieurs joueurs qui appuient frénétiquement sur la touche F5 pendant l'exécution du script pour être le premier à récupérer une action est profiter de l'avantage de l'attaque par exemple. On retrouve donc la 3ème contrainte.
Y-a t-il des solutions ?

Comment marier le fait d'avoir plusieurs actions avec la 2ème contrainte ? Que les actions soit cumulables, avec pour plafond le nombre d'actions par jour. Quels sont les effets de bord ?
Y-a t-il des solutions ?

[MadMass]

Le mieux à faire dans le cas d'un système d'actions est de se baser sur un timestamp. Tu enregistres le dernier timestamp où le joueur a reçu des points d'actions, puis lorsqu'une interaction avec celui-ci est faite (connexion, attaque ennemie, que sais-je) tu recalcule les points d'actions que tu lui dois depuis la dernière fois.
En fait je ne vois pas bien ta problématique du "spam de touche f5". Ces mécaniques sont de toute façon server-side, et il est une très mauvaise idée de faire un script qui met à jour les points d'action de tout le monde qui soit appelé par un joueur lorsqu'il charge une page. Y'a deux options : la tâche cron qui lance un script pour distribuer des points d'action toutes les x minutes, ou le fait de recalculer les points d'actions de chaque joueur que lorsqu'il y a de l'activité chez celui-ci.
Soit dit en passant, calculer dynamiquement le nombre de point d'actions permet une économie de ressource car ces calculs sont répartis dans le temps; et donner les points d'action à tout le monde d'un coup, ça fait beaucoup d'écriture sur la base de donnée + beaucoup de joueurs qui spamment f5 à la fin du timer, ce qui crée de la charge inutile.
Je ne cerne peut-être pas bien le soucis, dis-moi si je suis à côté de la plaque ^^

[Monsieur]

Le "spam de touche F5" c'est dans le cas où il faut rafraîchir la page pour voir si on a reçu une nouvelle action depuis, donné par un script lancé par une tâche cron.
Mais effectivement, calculé le nombre d'action dû à partir du timestamp de chaque joueur est surement mieux que d'avoir un script qui incrémente le compteur de tout le monde. Le script lancé par une tâche cron est plus utile pour vérifier les conditions de vie de chaque personnage j'imagine.

De plus, comme tu le dis, si les actions sont basé sur le timestamp du joueur, chacun en a un différent. Il n'y a donc pas de course à celui qui clic le plus vite : un joueur va avoir son action peut-être 5 min avant, ou 5 min après l'autre joueur.

Le fait d'avoir des actions cumulables peut déséquilibrer un jeu également j'imagine ? A quoi doit-on faire attention ?

[MadMass]

Je ne vois pas la nécessité de vérifier les conditions des personnages par un script on recalcule que ce dont on a besoin lorsqu'on en a besoin, sinon ça peut créer des soucis si les stats des personnages sont ajustées par un script cron alors qu'un joueur entreprend une relation en lien avec ces caractéristiques.
Pour le spam f5, tu n'as qu'à afficher un compte à rebours avant le prochain gain de PA, ça limitera grandement. Et vu que c'est par timestamp, aucun risque qu'on puisse tricher en spammant.
Pour les points d'action généralement c'est un pool de points d'actions qui s'accumulent, et le joueur peut les utiliser à loisir. Pas d'actions cumulables, juste le choix de tout utiliser d'un coup ou non.
Ceci dit, suivre le modèle classique n'est pas forcément bon, il faut innover en matière de game design ^^

[Monsieur]

Si lorsque la faim d'un personnage atteint 0 il meurt, "recalcule que ce dont on a besoin lorsqu'on en a besoin" : Sans script cron, le calcul doit être fait à chaque fois que le joueur fait quelquechose, ou bien qu'un autre joueur voit ce personnage ?
Si le calcul n'est fait que lorsque le joueur se connecte ou effectue une action, un personnage qui n'est plus joué restera vivant à jamais. Je me trompe ?

"Pas d'actions cumulables, juste le choix de tout utiliser d'un coup ou non." : Peux-tu détailler s'il-te-plait ?

" il faut innover en matière de game design ^^ " Entièrement d'accord ! Tu as des exemples de systèmes d'action non classique à me donner ?

A l'instant j'imagine un chronomètre en état de marche pour chaque joueur. Il aurait pour valeur max 24h. Toute action coûte du temps qui décompte le chronomètre. Si le chronomètre ne contient pas assez de temps, l'action est irréalisable et le joueur doit attendre. J'imagine ne rien inventer ?

[Xenos]

Théorie quantique: tout ce qui n'est pas observé reste dans un état indéterminé dont on se fiche éperdument.
La question de savoir si "le personnage restera en vie et ne mourra jamais s'il n'est plus jamais joué" n'a pas plus de sens que de se demander si le chat de Schrödinger est vivant: si personne ne joue le personnage et s'il n’interagit avec rien (au sens très large: le croiser sur la carte est une interaction, lire le journal dans lequel devrait paraitre son bulletin de décès est une interaction, etc), alors son état est indéterminé et on s'en moque.

D'où le "calcule ce dont t'as besoin au moment où t'en a besoin", le reste est un calcul inutile: inutile de calculer l'état d'une chose si elle n'est pas observée.