+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : pistes pour un monde persistant (/showthread.php?tid=4357)
Pages :
1
2
pistes pour un monde persistant - tactac - 19-09-2009
bien le bonjour,
je recherche des pistes pour développer un système (en php) permettant de gérer un monde persistant . J'entends par là que ce monde peut évoluer en temps réel comme par exemples
- la construction de la route en (x,y) doit être finie à 22h30h25s
- l'attaque doit avoir lieu à 04h33mn15s entre J1 et J2 avec respectivement les armées A1 et A2
- la mine subit une augmentation de sa production de 10% à 17h22mn01s
- etc....
Le système recherché doit donc analyser en permanence les évènements du monde et pour chacun le traiter ( faire_combat(J1,J2,A1,A2) ou augmenterProduction(Joueur,Mine,10) etc...) au bon moment c'est à dire à l'heure exacte de l'évènement.
Je partais sur un système de script php qui tourne en tâche de fond et qui parcourt une table d'évènements. Ce script se mets en sommeil (sleep()) jusqu'au prochain évènement, se réveille et traite tous les évènements et les supprime de la table des évènement; puis se rendort jusqu'au prochain.
Je viens vers vous pour connaitre votre point de vue sur cette technique et vous demander comment vous feriez dans ce cas là?
merci à tous
RE: pistes pour un monde persistant - Sephi-Chan - 19-09-2009
Effectivement, pour qu'un système persistant et en temps réel soit possible, tu as besoin d'implémenter le design pattern Observer (avec des écouteurs, des écoutables, etc.).
Le problème, c'est que pour mettre ça en pratique techniquement, tu auras besoin d'un moyen de synchroniser le serveur avec le client pour que le serveur puisse envoyer des données au client puisque dans certains cas, c'est le client qui écoutera le serveur (pour savoir ce qui se passe). On utilise généralement le long polling pour faire ça (on a pas mal de discussions qui en parlent sur le forum).
De plus, plus ton temps réel sera fidèle, plus tu auras besoin d'une machine puissante pour la résolution de plusieurs événements dans des intervalles de temps courts.
Sephi-Chan
RE: pistes pour un monde persistant - My Hotel - 19-09-2009
Sinon, ne pourrais tu pas simuler un real time? C'est à dire tu actualise à chaque page demandée par l'utilisateur. Comme ca, les mises à jour sont faites à chaque actualisation de page, le joueur croit qu'elle a été faite à l'heure exacte prévue.
Désolé de pas détailler : ipod touch
RE: pistes pour un monde persistant - tactac - 19-09-2009
Merci pour vos réponses
(19-09-2009, 06:59 PM)Sephi-Chan a écrit : Effectivement, pour qu'un système persistant et en temps réel soit possible, tu as besoin d'implémenter le design pattern Observer (avec des écouteurs, des écoutables, etc.).
Le problème, c'est que pour mettre ça en pratique techniquement, tu auras besoin d'un moyen de synchroniser le serveur avec le client pour que le serveur puisse envoyer des données au client puisque dans certains cas, c'est le client qui écoutera le serveur (pour savoir ce qui se passe). On utilise généralement le long polling pour faire ça (on a pas mal de discussions qui en parlent sur le forum).
De plus, plus ton temps réel sera fidèle, plus tu auras besoin d'une machine puissante pour la résolution de plusieurs événements dans des intervalles de temps courts.
Sephi-Chan
Le pattern singleton me semblait plus adapté à un gestionnaire d'évènements temps réel mais je vais réfléchir de nouveau à ce fameux observateur
Je ne connaissais pas le long polling. Après quelques recherches, j'ai l'impression que :
- en php ca ne peut se faire car il faut un serveur/conteneur (à la java)
- la requête http n'est pas fermée et est donc existante : imaginons plusieurs centaines de requêtes dans cet état, apache (ou le serveur web) est capable de gérer toutes ses requêtes endormies sans sourciller?
(19-09-2009, 09:18 PM)My Hotel a écrit : Sinon, ne pourrais tu pas simuler un real time? C'est à dire tu actualise à chaque page demandée par l'utilisateur. Comme ca, les mises à jour sont faites à chaque actualisation de page, le joueur croit qu'elle a été faite à l'heure exacte prévue.
Désolé de pas détailler : ipod touch
oui c'est l'idée concurrente du temps réel. Je ne sais pas encore si elle peut permettre de gérer tous les évènements possibles surtout sur les relations entre les joueurs notamment avec des PNJ.
Sans doute qu'il faut utiliser les deux méthodes :
- le temps réel pour les combats et autres évolutions du monde
- l'actualisation par connexion pour les ressources, fin de construction de tel et tel batiment, route terminée etc....
Le temps réel est gourmand en cpu et demande une réactivité importante. Ne pas le surcharger en info à analyser va donc dans le bon sens de l'optimisation.
La simu-temps réel (actualisations à la consultation) n'est utilisée que pour ce qui n'est pas partagé par tous les joueurs (contrairement aux combats par exemple).
Enfin...je raisonne à haute voix.... ^^
RE: pistes pour un monde persistant - Sephi-Chan - 20-09-2009
Singleton… Mouais. Dans une optique de "Oh, un événement !? Notifions-le aux personnes connectés et exécutons les scripts nécessaires !", Observer me semble adapté.
Ouais… Ça n'est pas du tout du temps réel, en fait.
C'est du fake (ça n'est pas une critique).Tu peux faire du long polling quel que soit le langage. Mais effectivement, le serveur risque de ne pas aimer. Heureusement, il existe des serveurs plus adaptés qu'Apache (et qui peuvent cohabiter à côté). Certains sont spécialisés là dedans (Ajax Push Engine), d'autres ne sont pas conçus pour mais restent excellent en la matière (Nginx, par exemple).
Sephi-Chan
RE: pistes pour un monde persistant - tactac - 20-09-2009
En fait, si je comprends bien on a a faire a deux modèles:
- pattern observateur associé au long polling (ou server push)
- un singleton "script" qui traite les evt quand cela est nécessaire et le client lui doit venir chercher l'info(httprequest)
le premier cas nécessite un serveur web adapté au push/long polling tandis que la seconde voie est plus facile a mettre en œuvre pour un projet débutant sans moyen mais les joueurs ne sont avertis au moment même de l'evt car il doit en faire la demande (le combat vient d'avoir lieu donc le client demande au serveur le résultat).
Le résumé est il objectif?
Tu as des liens pour des exemples de push/long polling en php stp? Merci
RE: pistes pour un monde persistant - QuentinC - 22-09-2009
Que penser d'une actualisation implicite uniquement lrosque nécessaire ?
Par exemple, j'ai besoin d'un objet User pour le joueur X, j'actualise immédiatement tout ce qui le concerne avant qu'on puisse utiliser cet objet pour faire autre chose.
A mon avis ça n'empêche pas qu'on puisse modéaliser les combats de cette manière.
RE: pistes pour un monde persistant - tactac - 22-09-2009
(22-09-2009, 06:00 AM)QuentinC a écrit : Que penser d'une actualisation implicite uniquement lrosque nécessaire ?
Par exemple, j'ai besoin d'un objet User pour le joueur X, j'actualise immédiatement tout ce qui le concerne avant qu'on puisse utiliser cet objet pour faire autre chose.
A mon avis ça n'empêche pas qu'on puisse modéaliser les combats de cette manière.
tout à fait. Mais je crois avoir trouvé une backdoor pour cette technique : imaginons une page web qui regroupe des statistiques sur les combats. Le joueur X ne participe à aucun combat ni de près ni de loin mais consulte les statistiques. En utilisant la technique du "j'actualise lorsque quelqu'un demande quelque chose", lors que le joueur X affiche la page des stats alors le système doit analyser tous les combats à faire et les effectue. J'ai peur que cela puisse prendre un bon bout de temps si de nombreux combats sont à traiter.
En généralisant, l'effet "pervers" de cette technique est que l'on peut se retrouver à traiter un volume "important" de transactions (et changements d'état des objets) en un seul instant.
En y réfléchissant, il faudrait sans doute un mixte entre les deux grandes stratégies :
- actualisation au besoin : à utiliser pour ce qui concerne uniquement les évolutions du compte du joueur
- actualisation au moment de l'évènement : à utiliser pour ce qui concerne l'ensemble du monde persistant.
En gros, on aurait ainsi réparti les exemples suivants :
- construction d'un bâtiment, évolution des ressources etc... : actualisation au besoin, ie. lorsque le propriétaire du compte affiche l'état de son village par exemple
- combats, etc... : actualisation au moment, ie. un process en tâche de fond traite une file d'évènements toutes les secondes (et se mets en veille le reste du temps).
En parallèle, soit l'utilisation de la technique du long polling soit un coup de Ajax (chaque minute) permettra au client de se tenir informé des nouveautés du monde persistant en "quasi temps réel".
Je réfléchis un peu tout haut là, et je tente de rassembler les idées....
ca vous semble cohérent?
RE: pistes pour un monde persistant - QuentinC - 23-09-2009
Ah, pas faux. Par contre je ne vois pas du tout comment faire un script qui puisse s'exécuter en permanence en tache de fond.
l'idéal, ce serait qu'il se mette en veille jusqu'au prochaîn évènement après en avoir traité un. Mais pour ça, il faut une petite application à part entière. C'est faisable en Java, pour les autres langages comme ruby ou php je sais pas, mais ça requiert un environnement dédié de toute façon.
ET puis je ne suis pas certain qu'un tâche cron suffise.
Ce serait intéressant de savoir comment s'y prennent ogame pour gérer les arrivées de flotte et les combats. Pas pour copier, mais pour se faire une idée. JE me demande s'ils font partie de la première ou de la seconde catégorie, ou s'ils ont fait un mix des deux.
RE: pistes pour un monde persistant - Anthor - 23-09-2009
La première. Largement suffisante et sans backdoor.