Evènements et joueur déconnecté

[Roworll]

Récemment, je me posais la question de savoir comment gèrer efficacement, dans le cadre d'un RPG online, les évènements qui arrivent aux personnages lorsque les joueurs sont déconnectés.

Prenons un cas simple.
Un personnage marchand voyage de la ville A vers la ville B histoire de commercer un peu. Le voyage prend 2H de temps réel.
Le joueur lance donc son action et peut tranquillement se déconnecter pendant que son personnage "voyage".

Supposons maintenant que la route empruntée soit dangereuse et infestée de bandits et que, comble de malchance, le personnage soit attaqué à mi chemin.

Quelles solutions envisageriez-vous pour régler ce problème ?
- Faut-il faire jouer ces évènements lorsque l'action de "voyage" est validée ?
- Faut-il le faire plutôt lorsque le joueur se reconnecte ?
- Faut-il permettre au joueur de paramétrer certains comportements automatiques (if brigands > 5 then fuite)

Bref, quelles sont vos idées sur la question ?

[Ter Rowan]

Quelles solutions envisageriez-vous pour régler ce problème ?
- Faut-il faire jouer ces évènements lorsque l'action de "voyage" est validée ?
- Faut-il le faire plutôt lorsque le joueur se reconnecte ?
- Faut-il permettre au joueur de paramétrer certains comportements automatiques (if brigands > 5 then fuite)

Bref, quelles sont vos idées sur la question ?

perso je m'oriente vers la solution comportementale mais je ne veux pas gérer la notion de "temps réel", c'est d'ailleurs ce qui m'intrigue "le voyage prend 2H de temps réel"

Est ce que cela veut dire que pour profiter pleinement du gameplay je dois me connecter à chaque fin d'action (pour optimiser le "temps réel")
genre :

un voyage de deux heures
puis une heure d'artisanat
puis - mince je me suis connecté trop tard - une heure de perdue

parce que dans cette situation j'aurais probablement une réponde du type => à la reconnexion du joueur, on réalise l'action de combat, puis fonction du résultat et fonciton du "temps perdu" (réel ou pas ça dépend de ce qu'est un combat) état d'avancement sur la route (ou bien arrivée du personnage a bon port)

[Argorate]

Personnellement je n'ai pas d'action "temporelle" dans mon jeu. Je ne n'aime pas ce principe, trop contraignant. (la plupart des gens ont autre chose a faire que venir clicker et devoir attendre 2h pour voir le résultat et enclencher une autre action...)
Mais bon le débat n'est pas là,

donc en admettant que je gère les événements de la sorte, je pense que je marcherais à la probabilité.
Tu as une probabilité de 15% d'être attaqué par un bandit durant ton voyage par heure.
Donc la résolution de cet événement ce fait au chargement de la page: SI 1h est passé, on fait un tirage et en fonction de la proba il se réalise et on l'affiche ou non.
Si lorsque le joueur se reconnecte plusieurs heures sont passés, alors tu n'a plus 15% de malchance, mais je répète ce tirage autant de fois que d'heures passés...

Ensuite pour se qui est de la résolution automatique: j'accepte de laisser le choix au joueur de dire s'il veux "contre-attaquer automatiquement" ou non (=> fuite), mais pas plus. Si on s'embarque dans une IA trop complexe, a quoi bon venir jouer? (mais la aussi c'est une autre discutions, qu'on avait déjà eu avec certain dans un autre topic d'ailleurs).

[Roworll]

La gestion temporelle des évènements est de toute manière très proche des systèmes à Points d'Action.
Une fois grillés ses PA, on a plus qu'à attendre. Idem pour les tours par tours. Une fois le tour fini, il faut attendre le prochain.

J'essaye en fait de réfléchir à un concept ou le joueur peut organiser ses périodes de 'non jeu'.
Prenons le cas d'un artisan.
Il consulte ses commandes, prépare ses fournitures, organise son cycle de production et lance la fabrication.
C'est cette phase de fabrication qui durera donc X temps alors que le reste (la préparation ) requiert une activité de la part du joueur.

Un aventurier peut pour sa part se préparer à l'aventure, racheter du matériel puis partir en à la chasse aux sangliers pendant 6 heures histoire de récupérer des peaux et de la viande à revendre aux artisans et commerçants du coin.

Voila donc l'idée de base. Donner l'impression que son personnage vit même lorsque le joueur n'est pas connecté. Reste donc le soucis des évènements survenant pendant ce mode déconnexion.

Ceci dit, cette idée est peut être carrément moisie. Dans ce cas, d'autres approches et/ou pistes sont les bienvenues.

[NicoMSEvent]

Je pense utiliser un système comme ceci pour les événements devant arriver dans le futur (a un instant précis), en m'inspirant des gros système oracle.
Une table contenant la liste des processus à lancer, et l'heure de démarrage. La seule différence est que cette liste est consultée avec un cron sous oracle, et que moi je préfererais utiliser une action de n'importe quel utilisateur (je considère mes monstres gérés de manière automatique comme autant d'utilisateurs -> voir plus loin dans ce post).
Lorsque n'importe quel utilisateur consulte une page : Si l'heure de l'action n'est pas encore passée, on ne fait rien. Si l'heure est passée, on retire la tache a lancer de la liste, et on la lance (en tenant compte des bonus liés au temps : par exemple : fin de construction d'une ferme : la ferme va produire entre le moment où elle sera terminée, et le moment où le script est lancé).
Je n'aime pas dépendre d'un cron, où d'autre systèmes extérieur quand j'ai la possibilité de ne pas le faire.
La seule fois ou j'utilise un cron, c'est pour la vie des monstres (reproduction, et voyage de groupes de raid) parce que ça me parait trop compliqué à administrer en différé, et comme ils sont souvent imprévisibles, leurs actions ne sont pas définies a l'avance.

[Ter Rowan]

je comprends mieux

globalement le système de points d'action est :

Le joueur se connecte, réalise des actions une par une, chacun consommant (entre autres) des points d'action, mais entre chaque, une résolution fait que le joueur peut "réagir"

alors que ton système "temporel" (faudrait lui trouver un petit nom) est :
le joueur se connecte, planifie des actions, chacune se déroulant l'une après l'autre consommant (entre autres) du temps réel futur, mais, entre chaque (ou au cours), une résolution fait qu'il peut arriver autre chose au personnage et là intervient ta question.

outre l'intérêt d'impression de vie parallèle, j'y vois aussi la résolution d'un problème que je me pose de cohérence des actions entre joueurs. En effet si X interagit avec Y (attaque, vol, commerce, formation....) avec les histoires de point d'action, il faut que X soit au même endroit que Y , mais le moment peut être différent (X a consommé tous ces points d'action pour arrivé sur Y alors que Y, dans le même tour car pas encore connecté, peut encore se déplacer) Dans ton système c'est beaucoup plus cohérent

maintenant je dirais que l'inconvénient de ce système c'est la complexité d'obtenir les interactions de manière ludique. Autant se donner rendez vous à un moment si il n'y a pas grand chose d'autres à faire (donc se dire attendre longtemps quelqu'un n'est pas important, rien n'est perdu) peut être amusant, mais dans un jeu qui serait centré sur des actions de joueurs, cela donnerait probablement l'impression de perdre beaucoup de possibilité d'action. Autant c'est pertinent pour une embuscade (je ne peux attaquer que ceux qui passent là où je suis) autant ça doit être vite frustrant pour des échanges commerciaux, etc..

A bien mesurer donc,je ne pense pas qu'on puisse sans analyser plus globalement ton GP dire si c'est moisi ou excellent. Y a un potentiel, mais c'est à double tranchant.

sinon pour revenir à la question si j'ai bien compris plus haut, alors réaction préprogrammer sans attendre la connexion du joueur, histoire de ne pas perdre le temps "réel" d'attente entre l'événement et l'action du joueur (d'autres actions programmées seraient alors potentiellement perdues)

[QuentinC]

L'idéal serait de gérer les évènements dans une file prioritaire : à chaque chargement de page, on regarde la file des évènements impliquant le joueur.

Pseudo-code :

Code :

file = récupérer la liste des évènements impliquant le joueur
tant que file pas vide, faire
évènement = prendre premier élément de file
si évènement.date > maintenant, quitter la boucle
mettre à jour paramètres continus
traiter évènement
fin tant que
mettre à jour paramètres continus

L'avantage c'est que non seulement on est sûr de traiter correctement tous les évènements sans jamais avoir besoin de cron, mais en plus on peut aussi gérer le cas où un évènement passé génère un autre évènement plus récent mais quand même déjà passé (ça peut vite être problématique parfois, suivant la structure adoptée). Le gros problème c'est que 1/pas de structure toute faite en php pour stocker des séquences auto-triées, et 2/lourd à récupérer et à sauvegarder.

EDIT : l'inconvénient n°1 n'est apparament plus vrai depuis php 5.3.0 (cf. php.net, classe SplPriorityQueue).... mais on fait comment si comme moi on est coincé à php 5.2.6 pour probablement encore très longtemps ?

[NicoMSEvent]

en fait, la pré-programmation d'évènements est faite en fonction de ce qui est prévisible. Tout ce qui est géré par le système est prévisible.
Par contre, les actions des joueurs sont imprévisible (de même que les monstres, si l'IA est suffisamment complexe)
Donc, a chaque action de joueurs, je mets a jour les événements qui doivent l'être. Si il n'y a pas d'interaction humaine, je laisse les événements suivre leur cours.

[barst]

D'abord un question : les évènements devant agir sur le PJ pendant que l'utilisateur est déconnecté, sont-ils l'oeuvre de PNJ ou d'autres PJ ou des 2?

Car autant tu peux mettre des évènements aléatoires sur des types d'action (ex : action=voyage => évènement=attaque de brigand) qu'il est plus difficile de gérer les actions des autres PJ.
Si le voyage de ton PJ traverse un territoire en guerre ? ou il passe au milieu d'un combat, d'une faction ennemi ?
Est-ce plus crédible de dire que les autres PJ ne l'ont pas vu passé ?

En fonction de ce que tu veux, la gestion est bien différente.
Si uniquement des PNJ peuvent intervenir alors tu gères ces évènements soient à la validation de l'action soit à la reconnexion du joueur.

Si par contre tu inclus les PJ, cela sous-entend que les PJ continuent à vivre et à évoluer même quand l'utilisateur est loin et donc tu es obligé d'inclure des comportements par défaut à tes PJ.

[Argorate]

La gestion temporelle des évènements est de toute manière très proche des systèmes à Points d'Action.
Une fois grillés ses PA, on a plus qu'à attendre. Idem pour les tours par tours. Une fois le tour fini, il faut attendre le prochain.

J'essaye en fait de réfléchir à un concept ou le joueur peut organiser ses périodes de 'non jeu'.
Prenons le cas d'un artisan.
Il consulte ses commandes, prépare ses fournitures, organise son cycle de production et lance la fabrication.
C'est cette phase de fabrication qui durera donc X temps alors que le reste (la préparation ) requiert une activité de la part du joueur.

Un aventurier peut pour sa part se préparer à l'aventure, racheter du matériel puis partir en à la chasse aux sangliers pendant 6 heures histoire de récupérer des peaux et de la viande à revendre aux artisans et commerçants du coin.

Voila donc l'idée de base. Donner l'impression que son personnage vit même lorsque le joueur n'est pas connecté. Reste donc le soucis des évènements survenant pendant ce mode déconnexion.

Ceci dit, cette idée est peut être carrément moisie. Dans ce cas, d'autres approches et/ou pistes sont les bienvenues.

Là dessus il y aurait matière à discuter.
Pour moi ce sont deux systèmes bien distincts.
L'un oblige plusieurs passages par jour et a intervalle plus ou moins régulier alors que l'autre exige au minimum une visite par jour...

Le principe est donc loin d'être le même: encore une fois, dans l'un on peut enchainer les actions et les combos tandis que dans l'autre cas on est bloqué (plus ou moins longtemps) dès la première action "importante"... (Ce qui en matière de stratégie réduit pas mal de chose de mon point de vue, mais ça à la a limite, ça dépend de la conception du jeu.)