08-05-2011, 11:52 AM
@ Jean-Baptise.
Le système permet de créer des files indépendantes (autant qu'on veut) qui tournent en parallèle et de notifier en temps réel la fin d'une construction.
Ton système de cron doit être codé dans ton jeu, les tâches qui s'occupe de la résolution de la queue également. Il n'est pas plus simple car le cron effectue bêtement les tâches, qu'il y ai des résolutions à faire ou non. Ce n'est pas plus léger, ni plus performant.
Et c'est encore pire pour la résolution des actions "au besoin". C'est la technique pauvre : celle qui fait une opération longue au chargement d'une page, ce qui rend la requête longue HTTP et qui fait attendre l'utilisateur. C'est facile mais mauvais à tout point de vue : peu performant et l'expérience utilisateur est nulle vu que ton joueur attend qu'une page se charge (et même 1 ou 2 secondes ça se sent).
Avec l'emploi d'un server indépendant et qui gère très bien le temps, tu dilues ça dans le temps et tu profites de l'asynchrone : c'est bien plus performant et agréable pour l'utilisateur. Ta machine ET tes joueurs te remercieront.
Alors que le serveur que je propose lance simplement un timer, comme tout développeur sait le faire en Javascript. C'est trivial et performant.
Ensuite, le développeur du jeu implémente une page de callback (qui sera appelée par le serveur de queue quand une action sera terminée, pour permettre au site de faire ce qu'il veut (mises à jours de la base de données, push au joueurs). La complexité que tu dénonces, c'est juste l'installation de Node…
De plus, je propose 2 formules à ma solution :
Le temps réel apporte beaucoup dans un jeu, autant en terme de possibilité de gameplay que d'expérience utilisateur. C'est trop bête de se murer dans le Web d'il y a 10 ans. Autant exploiter les possibilités de maintenant.
Le système permet de créer des files indépendantes (autant qu'on veut) qui tournent en parallèle et de notifier en temps réel la fin d'une construction.
Ton système de cron doit être codé dans ton jeu, les tâches qui s'occupe de la résolution de la queue également. Il n'est pas plus simple car le cron effectue bêtement les tâches, qu'il y ai des résolutions à faire ou non. Ce n'est pas plus léger, ni plus performant.
Et c'est encore pire pour la résolution des actions "au besoin". C'est la technique pauvre : celle qui fait une opération longue au chargement d'une page, ce qui rend la requête longue HTTP et qui fait attendre l'utilisateur. C'est facile mais mauvais à tout point de vue : peu performant et l'expérience utilisateur est nulle vu que ton joueur attend qu'une page se charge (et même 1 ou 2 secondes ça se sent).
Avec l'emploi d'un server indépendant et qui gère très bien le temps, tu dilues ça dans le temps et tu profites de l'asynchrone : c'est bien plus performant et agréable pour l'utilisateur. Ta machine ET tes joueurs te remercieront.
Alors que le serveur que je propose lance simplement un timer, comme tout développeur sait le faire en Javascript. C'est trivial et performant.
Ensuite, le développeur du jeu implémente une page de callback (qui sera appelée par le serveur de queue quand une action sera terminée, pour permettre au site de faire ce qu'il veut (mises à jours de la base de données, push au joueurs). La complexité que tu dénonces, c'est juste l'installation de Node…
De plus, je propose 2 formules à ma solution :
- S'il a un serveur dédié/VPS, il peut prendre le code de mon PQS (Production Queue Server) et le lancer très simplement sur son serveur. Son jeu reste très simple : il envoie des requêtes HTTP quand il lance une construction et il en reçoit une quand une construction s'achève. Toute la partie timing est effectué du côté PQS en profitant des performances de NodeJS sur cette partie.
- S'il n'a pas de serveur dédié, il peut utiliser le PQS (Production Queue Service) sans rien avoir à installer, il devient par contre dépendant de mon service. Là aussi, son code reste très simple, pas d'extra (à part l'envoie et la reception de la requête HTTP) ;
Le temps réel apporte beaucoup dans un jeu, autant en terme de possibilité de gameplay que d'expérience utilisateur. C'est trop bête de se murer dans le Web d'il y a 10 ans. Autant exploiter les possibilités de maintenant.