Actions et passage de tour

[Monsieur]

Entièrement d'accord, mais c'est moins coûteux / pose moins de problème qu'un script cron lancé à intervalle régulier ?
J'imagine que dépasser un certain nombre de joueurs, aucun personnage ne se retrouve sans interaction, le script devenant moins coûteux du coup, non ?

[MadMass]

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 ?

Dès que l'information est nécessaire en fait. Si le joueur est susceptible d'être croisé sur la carte, alors dès qu'un autre joueur affiche la carte, tu recalcule la faim du joueur et tu regarde si il est vivant ou non.

Je vais prendre un exemple : sur ogame, le joueur accumule des ressources avec le temps. Il peut être espionné par un joueur ennemi, qui peut ensuite l'attaquer pour le voler. Ici, lors d'un espionnage, les ressources du joueur sont recalculées car il y a interaction ^^

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

Imaginons qu'un joueur puisse gagner 5 points d'action toutes les demies-heures, limitées à 240 points d'action au total (c'est à dire 24 heures). Toutes les demies-heures, il sera crédité de 5 PA qui augmenteront son total de points d'actions disponibles si il n'a pas atteint 240.
Chaque action consomme des PA : se déplacer 3pa, attaquer 5pa, etc. Il peut donc utiliser ses PA dès qu'il les reçoit (et lancer une attaque toute les demies-heures), ou les accumuler et lancer 10 attaques d'un coup qui lui consommeront 50 PA de son total qu'il aura accumulé
C'est ça l'idée : joueurs réguliers et joueurs occasionnels ne sont pas trop séparés, car ils peuvent au final faire un même nombre d'actions sur 24h, mais celles-ci sont justes différemment réparties dans le temps.

" 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 ?

L'idée n'est pas mauvaise, en fait tu substitue du temps à des points d'action
Ce qui peut être chouette, c'est de "cacher" les points d'action derrière des mécanismes plus RP : fatigue, mana, etc. C'est à creuser bien sûr, je n'utilise pas ce système pour mon jeu :p

Entièrement d'accord, mais c'est moins coûteux / pose moins de problème qu'un script cron lancé à intervalle régulier ?
J'imagine que dépasser un certain nombre de joueurs, aucun personnage ne se retrouve sans interaction, le script devenant moins coûteux du coup, non ?

En fait le script par tâche cron pose plusieurs soucis :
- Il peut entraîner d'énormes montées en charge : déjà parce que plus il y aura de joueur, plus il sera coûteux en ressources système lorsqu'il s’exécutera. De plus, il fera un grand nombre de requêtes SQL sur un très court intervalle de temps, ce qui va ralentir toute utilisation de la SQL, y compris pour les joueurs, qui auront des latences voire des timeout au chargement de leurs pages lors de l'appel du script. Enfin, les joueurs pouvant prédire le lancement du script, les joueurs peuvent être tentés de spam f5, ce qui va encore plus accentuer la charge. Au final le jeu est au mieux ralenti, au pire le SQL tombe
- Il peut entraîner de nombreuses erreurs, surtout si le moteur de stockage SQL gère mal les écritures concurrentes. Si par exemple un joueur affiche une page pendant l'exécution du script, il peut recevoir des données fausses car en cours de modification. Si la moitié des joueur a été mise à jour et pas l'autre, alors que le joueur affiche une page, sa page affichera beaucoup d'informations bizarres car pas à jour


Cependant il y a toujours moyen de rendre la chose possible.
Moi pour mon jeu, je fonctionne en tours de 5 mn avec une action par tour. Pour éviter ces soucis, le script de passage de tour met à jour une variable en base de donnée, qui empêche la génération de pages pendant le changement de tour. Concrètement, si le joueur affiche une page pendant l'exécution du script, celle-ci ne sera pas générée (au moyen d'un sleep en php), et ce n'est que lorsque le script aura fini que les pages seront à nouveau générées. Ca implique une brusque charge à la fin du script de tour car les pages de tous les joueurs sont générés sur quelques secondes mais ça reste gérable, car le script de tour ayant fini il n'y a plus d'écritures, et certains serveurs web comme ngix gère bien ces situations

[Monsieur]

Je te remercie pour tes solutions techniques !

Il peut donc utiliser ses PA dès qu'il les reçoit (et lancer une attaque toute les demies-heures), ou les accumuler et lancer 10 attaques d'un coup qui lui consommeront 50 PA de son total qu'il aura accumulé

Est-ce que permettre cela peut entraîner des déséquilibres au niveau du gameplay ? Si il est remarqué qu'il est plus rentable d'attendre, tout les joueurs vont attendre de tous dépenser d'un coup, ce qui n'est pas vraiment un problème car ça respecte les contraintes. Mais si il est plus rentable de dépenser au fur et à mesure, les joueurs qui sont obligé de tous dépenser sont perdants.


Autre question : Est-ce qu'un jeu a déjà tenté un arrêt la journée ? Les joueurs peuvent discuter, voir même commercer, mais ne peuvent chasser et attaquer que entre 18h et 0h par exemple ?
Je revois le problème du passage de tour qui revient tout les jours à 18h, les gens frustrés de ne pas pouvoir jouer en journée, et on peut même imaginer l'inverse : une personne qui peut jouer en journée mais pas en soirée !
Plutôt que de stopper le jeu, imaginons plutôt juste stopper la récupération des points d'actions en journée. On ne gagne des points que entre 18h et 0h. Ça a déjà été envisagé ? Quelqu'un y a déjà réfléchi ? Ça change quoi ?


Pour le plaisir de réfléchir, creusons un peu l'idée du chronomètre :
Chaque joueur a un chronomètre, avec un plafond de 24h. Chaque action coûte du temps. En solo, on pourrait très bien imaginer que le temps du jeu passe en même temps que le joueur en dépense.
Par exemple, le joueur se connecte, il possède 24h, et dans le jeu est il 8h du matin. Il peut choisir de partir chasser pendant 4h. Il est donc 12h dans le jeu et il revient de la chasse. Il peut choisir de préparer ce qu'il a chassé, de manger, de partir explorer les alentours ... le temps du jeu pouvant avoir un impact sur ses actions : il peut se mettre à pleuvoir en début d'après-midi, et il peut être déconseillé d'explorer sous un déluge. Il peut être également plus difficile de chasser une fois la nuit tombée, ou on peut avoir un bonus de repos.
Le joueur, en quelques minutes et quelques clics, aura donc fait vivre 24h à son personnage.
Et c'est là que ça devient intéressant : et en multijoueur ? Sans interaction avec le temps du jeu, le temps du joueur n'est que des points d'actions. Cela ne pose pas de problème également de réaliser des actions en groupe, du moment que chaque membre du groupe a assez de temps.
Mais si l'ont souhaite avoir une interaction avec le temps du jeu ? Qu'il y est un matin, une après-midi, un soir, une nuit ?
Chaque joueur a un chronomètre, le temps du jeu est relatif au temps qu'il dépense. Comment régler les problèmes lié au décalage ? Si un joueur qui pour lui est le matin attaque un joueur qui pour lui est le soir ? Et pour les actions de groupe ?
Vous avez des idées, des solutions à proposer ?

[MadMass]

Là on entre vraiment dans le coeur de la définition du jeu, il faut tracer une ligne claire en tenant compte du fait qu'on ne pourra jamais satisfaire tous les joueurs ^^
Il est certain que permettre d'utiliser un grand stock de PA sur un court temps entraînera, si ce n'est un déséquilibre, au moins des stratégies de la part de nombreux joueurs. C'est d'ailleurs une mécanique de jeu à part entière qui doit être étudiée de façon à ce que la conséquence de ces actions ne soit pas trop lourd en matière d'équilibrage.
De toute façon dans la mesure où il s'agit de deux ensembles de joueurs radicalement différents, il faut forcément y voir deux façons de jouer différentes et un système capable de les contenter tous les deux. Il faudrait idéalement qu'il soit possible de tirer bénéfice d'accumuler ses points d'actions pour jouer d'une certaine manière, tout comme il faut ajouter des avantages qui contrebalancent lors de l'utilisation en continu des PA reçus.
Par exemple, au hasard, il serait possible de favoriser l'accumulation de PA sur les actions agressives, et favoriser l'usage continu sur les déplacement ? Ce n'est qu'un exemple je ne sais pas comment est construit ton jeu :p

Pour ce qui est de la deuxième idée (récupérer les points au sein d'un créneau), je trouve ça moyen pour une raison qui me semble importante : c'est un jeu par navigateur. Et le jeu par navigateur est très différent des autres, car il se prête aisément à être joué en parallèle d'une autre tâche : en bossant, ou en se connectant rapidement à différents moments de la journée... C'est pas un jeu devant lequel on reste forcément planté durant des heures à la façon d'un jeu en client lourd du coup restreindre le gain de PA sur un créneau horaire réduirait l'intérêt dudit gain de PA, pour une grande partie des joueurs ça reviendrai à recevoir les PA une fois par jour. Je veux dire, tu te prive d'une partie de tes joueurs à cause de leurs horaires et de leurs habitudes de jeu, pour lesquels le gain de Pa de 18h à 0h reviendrait à tout recevoir en une fois car ils ne les utiliseront que le lendemain. On en revient au problème de départ, à ce moment là autant donner tous les PA d'un coup à minuit et laisser les joueurs les gérer durant leur journée, mais ça contrevient à certaines de tes contraintes, notamment d'avantager sérieusement ceux qui jouent à 0h05.

L'idée de rendre le jeu en temps réel me semble cool par contre, et c'est à mon avis bien plus compatible avec les habitudes de jeu des joueurs. Et puis tu peux prévoir des mécaniques pour "meubler" la nuit : faire dormir son personnage, etc.

EDIT : si tu ne connais pas déjà, dablog est vraiment sympa et prodigue de bons conseils niveau définition du jeu en lui-même : http://dablog.fr

[Anarion]

Bonjour,

Là on entre vraiment dans le coeur de la définition du jeu, il faut tracer une ligne claire en tenant compte du fait qu'on ne pourra jamais satisfaire tous les joueurs ^^

+1

Je me suis posé le même genre de questions que celles que tu évoques, Monsieur ; et à force d'y réfléchir, j'étais assez content du petit système auquel j'étais parvenu. Mais certains points ont semblé finalement ne pas convenir à une petite moitié des joueurs, pour des raisons de timing notamment, ou de déséquilibre entre ceux qui peuvent se connecter régulièrement ou ceux qui ne le font qu'une fois par jour ; des discussions ont été lancées en forum, et on a finalement choisi de modifier légèrement la fréquence d'attribution des points d'action et celle de libération des actions-clés, pour aboutir à un compromis qui semble équilibré.

♦ Dans mon cas, les points d'action sont attribués à la première action du joueur passé un délai donné. Chaque joueur peut jouer librement avec ses points d'action, les stocker et les dépenser dans un gigantesque combat ; les dépenser au fur et à mesure dans diverses actions ; ou grâce à une potion les transformer en ressources ; ou d'autres choses encore.

♦ Pour la question du chat de Shrödinger, je laisse effectivement l'état indéterminé, mais à ceci près que le joueur disparaît des classements essentiels, est éjecté des guildes, voit ses offres de commerce, potions, sortilèges, etc. effacés. De sorte que plus rien n'interfère.

♦ Quelques scripts sont lancés par ailleurs à certains moments de la journée pour déterminer les scores de conquête des guildes à un endroit donné. Et ce sont ces scripts qui mettent aussi à jour la table des joueurs de Shrödinger.

J'aime bien l'idée du chronomètre individuel, mais effectivement, à voir s'il faut la lier avec le temps global sur le jeu.
Changer l'environnement du jeu pour passer en mode "soir" lorsqu'il reste peu de temps, puis en mode "nuit" lorsque le temps est presque épuisé ?

Bon courage pour tout !

[Monsieur]

L'idée de rendre le jeu en temps réel me semble cool par contre, et c'est à mon avis bien plus compatible avec les habitudes de jeu des joueurs.

Qu'entends-tu par temps réel ? Sur le fait que le jeu évolue en fonction des points d'action dépensés par le joueur ? Je trouve le concept intéressant mais je ne vois pas comment l'associer avec du multijoueur malheureusement.

J'ai commencé à lire des articles sur dablog. je me suis, bien entendu, empressé de lire celui-ci :
Jeux asynchrones et points d'action
La fin de l'article est justement ce que je ne recherche pas ! Peut-on dire que c'est la faute du joueur qui aurait dû ne pas dépenser tout ses PA ?

Changer l'environnement du jeu pour passer en mode "soir" lorsqu'il reste peu de temps, puis en mode "nuit" lorsque le temps est presque épuisé ?

Quand tu dis environnement c'est par exemple les alentours que voit un personnage, et le mode nuit serait que ces alentours s'obscurcissent ? Où même l'IHM en général ? C'est une bonne idée !


Cette discussion amène ma réflexion sur deux tendances :
La première, celle d'un jeu "macro", en tour par tour, avec des actions programmées jouées simultanément au passage de tour. Le jeu est totalement asynchrone sans que ça ne pose aucun soucis : Le joueur n'a pas a se connecter fréquemment, il a le temps du tour pour discuter, faire des propositions commerciales, d'entraide, de bluff et qu'il programme ses actions au début du tour, en plein milieu de la nuit ou de la journée ou à la fin du tour ne change rien.

La deuxième, celle d'un jeu "micro", avec beaucoup de petites actions interactives et donc à résolution immédiate, mais également des actions asynchrones à plusieurs. Je suis juste perplexe sur l'équilibre du jeu (cumul d'actions, action lancée en milieu de nuit ...), et de savoir si il est possible d'avoir un environnement changeant mais relatif à chaque joueur (que chaque joueur puisse avoir un matin, une après-midi et un soir influençant ses actions, qu'il les joue toutes d'un coup ou bien au cours de la journée, sans incohérence avec les interactions entre joueurs).

[MadMass]

Non je parlais de l'idée de timer, qui fait qu'une heure en jeu correspond à une heure dans le monde réel ^^

[Monsieur]

Non je parlais de l'idée de timer, qui fait qu'une heure en jeu correspond à une heure dans le monde réel ^^

J'ai du mal m'expliquer alors

L'idée du chronomètre, c'est :
Un joueur peut se connecter IRL à 21h le lundi, avec un personnage qui lui a un temps relatif à 8h (le matin pour lui dans le jeu), et avec un chronomètre de 6h.
Le joueur va par exemple décider d'aller le faire chasser pendant 4h :
Il choisit l'action "partir à la chasse", le jeu interagit avec lui "vous tombez nez à nez avec un ours. C'est vraiment ça que vous voulez chasser ?", et 1 minute IRL plus tard (21h01), son personne a maintenant un temps relatif de 8+4=12h (il est midi pour lui dans le jeu), et un chronomètre de 6-4=2h (et, j'espère pour lui, du gibier tout frais dans l'inventaire !).
Le joueur se déconnecte, et se reconnecte le lendemain matin, mardi IRL, à 10h :
Depuis sa dernière connexion il s'est passé 24-21+10=13h, le chronomètre du personnage est donc à 2+13=15h. Mais le personnage lui même est toujours à un temps relatif de 12h (toujours midi pour lui dans le jeu).

Ce système permet à un joueur de faire vraiment vivre 24h à son personnage, et ce toute les 24h IRL, sans avoir à programmer des actions ou se connecter régulièrement (une fois par jour suffit). En solo ça marche très bien, mais c'est pas vraiment ce qu'on recherche dans un jeu en ligne !
La question est donc : Comment gérer le multijoueur ? c'est à dire comment les joueurs peuvent interagirent entre eux ?

[MadMass]

Ah ok ! Effectivement ce n'est pas adapté :p
Ben qui dit multijoueur dit que le temps continu à s'écouler lors de la déconnexion du joueur, logiquement. Le tout est de lâcher cette idée de temps relatif au joueur pour imposer un temps absolu au monde. A toi après de prévoir des options pour les temps où le joueur sera déconnecté : manger, dormir, se réfugier dans une auberge... Ca n'empêche pas de faire chasser le personnage pendant 4h, simplement si le joueur ne se connecte pas au bout de 4h, ben son personnage se tournera les pouces ^^
Il ne faut pas croire que ça puisse énormément désavantager certains joueurs hein, beaucoup choisiront une activité qui coïncide avec l'heure de leur prochaine connexion ou tu peux permettre au joueur de définir la durée de sa partie de chasse (entre 1 et x heures), et échelonner les gains en fonction du temps passé, c'est aussi une idée.

[Monsieur]

Oui, une solution à ce problème est d'avoir un temps absolu, mais le jeu devient alors un jeu de programmation.
Et concernant les actions interactives :
Si l'interaction est au début de la chasse, le joueur va recevoir le butin de chasse avant même de chasser. Il faut donc bloquer l'action en cours. Si le joueur se fait attaquer pour être volé entre temps, il ne faut délivrer qu'une partie du butin, et annuler la suite de l'action. Cependant, quand un joueur choisi de chasser, vu qu'il interagit au moment du choix de l'action, il connait son butin de chasse avant d'avoir commencé à chasser. Il peut donc vendre la peau de l'ours avant de l'avoir tué (sauf si on l'attaque pendant sa partie de chasse).

Si l'interaction est à la fin de la chasse, et que le joueur se fait attaquer pour être volé entre temps, le joueur n'aura pas interagit et on ne sait pas ce qu'il était enfaîte en train de chasser depuis des heures.



Sinon, un problème me vient pour le jeu "macro" :
Chaque joueur peut choisir des actions qui seront exécutées au passage de tour.
Lorsque je veux me déplacer, je peux par exemple indiquer ma case d'arrivée, et je dois donc la voir. Chaque joueur voit donc les cases alentours, et quand il choisi de se déplacer à pied, il choisi où il veut arriver.
Mais si le jeu implémente des montures, et que le joueur souhaite se déplacer à cheval, on fait comment ? Si le cheval va deux fois plus loin pour une même action, le personnage doit voir deux fois plus loin ? Pas très logique !

A sa première connexion après le passage de tour, le jeu sait qu'il avait choisi un déplacement, le joueur peut donc avancer case par case ? Ça casse le fait que toutes les action sont simultanées au passage de tour, sauf l'exécution du déplacement. Car si plusieurs joueurs ont décidé de se déplacer, le faire avant l'autre a un impact, puisqu'un joueur veut pouvoir suivre un autre pour l'attaquer par exemple. Si l'autre joueur se sait en danger, il va devoir attendre juste avant le passage de tour pour que l'agresseur n'ai pas le temps de jouer l'exécution de son déplacement. Et ça on ne veut pas.
D'autres idées de solutions ?