19-09-2009, 11:17 PM
Merci pour vos réponses 
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?
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.... ^^
(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.... ^^