Un jeu semi-asynchrone

[Bob le Pointu]

Bonjour, bonsoir.

Depuis quelques temps j'étudie les façons d'optimiser les tâches gourmandes, comme par exemple le chargement d'une carte, au sein des jeux asynchrones en PHP.

J'ai l'intuition qu'il est possible de créer, en marge de l'application principale mais liée à elle, un serveur, autonome, qui serait en charge de la gestion de l'univers:

- La carte
- Les objets présents sur la carte
- Les personnages
- Les actions temporisées
- La gestion du «temps»

Pour cela, je pense utiliser une communication basique à base de sockets UDP (même si UDP n'est pas parfait puisque dans notre cas, c'est une communication à sens unique. C'est toujours ça)

Mais avant d'aller plus loin, j'aurais aimé avoir votre avis, éventuellement vos retours d'expérience à ce sujet.

Très sincèrement,
Merci.

[OncleJames]

Tu entend quoi par

un serveur, autonome

?

Une sorte de server interne comme un chat qui serait toujours actifs, et qui répondrai à chaque socket ?

Si c'est dans cette optique, sa peut être sympatouche, mais si le jeux comporte beaucoup de membre, tu risque pas de surcharger énormément le serveur par les mouvements / Attaques / Interactions / .. ?[/quote]

[Sephi-Chan]

Je ne comprends pas vraiment l'intérêt de la question.

En gros, dans ton idée, tu voudrais déléguer les grosses dépenses de ressources à un second serveur. Tu aurais alors sans doute un premier serveur sous exploité, et d'ailleurs, le second aussi, probablement.

Quel serai l'intérêt de tout ça ?


Sephi-Chan

[Bob le Pointu]

@Onclejames
Exactement, un programme qui serait une sorte de démon.
Actuellement je travaille sur un très gros site qui utilise ce système. Le serveur reçoit environ 60 requêtes par seconde. Il a un peu de mal, c'est vrai, mais globalement ça passe. Comme je ne pense pas atteindre un jour les 60 requêtes par secondes, ça devrait aller.

@oxman
J'utilise aussi les scripts lancés par crontab, qui me conviennent assez bien. L'idée du serveur autonome lancé en permanence est d'éviter de charger à chaque accès à une page un gros tas de données.

@Sephi-chan
Je ne suis pas non plus vraiment convaincu, c'est pourquoi je viens demander conseil.
Je pense que tu as bien compris le système, sauf peut-être la notion de serveur qui peut prêter à confusion. D'un côté un serveur web, de l'autre un serveur personnalisé, les deux sur la même machine.

Je cherche juste à savoir si cette solution est bonne ou mauvaise, selon les contextes.

[Sephi-Chan]

Chacun voit midi à sa porte.

Moi je dis plutôt qu'au lieu d'avoir un serveur qui rend l'âme et qui effectue des tâches de manières non optimales, ils en auraient 2 qui se tournent un peu les pouces, car ils sont chacun exploités convenablement et de manière optimale.

C'est pas vraiment optimal de payer 2 serveurs pour les sous-exploiter. C'est contre productif. Je pense que la plupart des jeux, s'ils sont développés de manière optimisée, peuvent tout à fait tenir sans mettre à genoux le serveur sur lequel ils tournent quand un grand nombre d'utilisateurs sont en ligne.

Je cherche juste à savoir si cette solution est bonne ou mauvaise, selon les contextes.

À mon sens, un deuxième serveur doit être envisagé seulement si le premier est régulièrement exploité à plus de 85%.


Sephi-Chan

[Bob le Pointu]

Non, c'est ce que je disais, il y a un malentendu sur le terme de serveur.

Remplaçons-les par programmes, logiciels, ou démons.

[OncleJames]

Je pense qu'actuellement aucun jeuphp ne propose cette technologie, donc c'est dur à dire si c'est exploitable ou pas.

De ma vision, j'y avais pensé, mais je me suis assez vite retourné vers une solution plus classique.

Si cela t'interesses j'ai une base de moteur autonome, sur lequel on accede en Ajax.

[Bob le Pointu]

Si cela t'interesses j'ai une base de moteur autonome, sur lequel on accede en Ajax.

Je te remercie, mais j'AJAX utilise des requêtes HTTP, on revient donc au point de départ. Du moins il me semble.


oxman, oui, c'est suffisant.

Mais si ça peut être mieux, interessant d'un point de vue technique, pourquoi s'en passer ?

[OncleJames]

Je me servais d'Ajax dans le but de detecter l'appuis sur des touches, ou l'écriture dans une fenetre (chat), les fonctions qui traitais par la suite sont entièrement en php.

Tu seras tout de même obligé de passer par du Javascript ou Ajax pour gérer les évènements ( OnClick, OnChange, .. ) ^o), sinon je vois pas trop comment démarrer les fonctions suite aux actions utilisateurs.

[Asherah]

Depuis quelques temps j'étudie les façons d'optimiser les tâches gourmandes, comme par exemple le chargement d'une carte, au sein des jeux asynchrones en PHP.

le xmlhttprequest ne t'es pas utile?
ca t'epargne pourtant le rechargement de la map a chaques requetes.
Sinon si je devais faire un jeu avec une vrai map je m'orienterais plus vers du Flash.
Je n'ai pas étudier la question ceci-dit mais ca peut etre interessant.
Mais c'est vrai qu'ensuite tu ne pourras "limiter" que dérisoirement le nombre de requetes sur ton serveur, au mieu tu pourras les optimiser pour que celles-ci s'éxécute au mieu et plus rapidement ou éviter de faire 3 SELECT au lieu d'un, ou encore utiliser un itérateur au lieu de faire un while bourrin, mais bon, ca n'empecheras pas le nombre de personnes qui appeleront ta page ou appeleront des informations BDD connexion etc.., si tu es populaire.