25-02-2011, 08:44 PM
Ce sera mon premier "vrai" post sur le fofo.
Je suis actuellement dans la problématique de résolution d'actions. Je pense qu'il ne faut pas choisir forcément une solution mais plutôt voir comment plusieurs solutions peuvent fonctionner ensemble pour répondre aux besoins du jeu tout en gardant une bonne expérience utilisateur.
Pour ma part je dirai que la résolution de certaines actions/mis à jour à l'appel d'une requête HTTP est viable pour des petits traitements (calculs de ressources, résolutions de constructions, de combats...). Ces actions (sous réserve de votre jeu) ne demandent pas d'énormes ressources serveur.
Un autre système de résolution avec un "daemon" ou un "cron" peut s'occupper d'autres actions plus lourdes à traiter et qui ne nécessitent pas d'être instantannées. Avec une bonne gestion de l'affichage il est compréhensible de faire patienter un peu le joueur (cf: eRepublik pour ceux qui ont déjà testé)
Je ne suis qu'au début de ma réflexion mais ce genre d'architecture (que j'utilise de façon professionelle dans d'autres langages que php) est viable.
La gestion du stack d'actions, des annulations éventuelles d'actions ou des impacts entre actions doit faire partie de l'intelligence de l'application (à savoir votre code) et donc cela restera très indépendant des choix techniques (requêtes http, cron, daemon...). La problématique se posera de toute façon.
Voila pour ma contribution, l'article sur les processus php est super intéressant merci
Je suis actuellement dans la problématique de résolution d'actions. Je pense qu'il ne faut pas choisir forcément une solution mais plutôt voir comment plusieurs solutions peuvent fonctionner ensemble pour répondre aux besoins du jeu tout en gardant une bonne expérience utilisateur.
Pour ma part je dirai que la résolution de certaines actions/mis à jour à l'appel d'une requête HTTP est viable pour des petits traitements (calculs de ressources, résolutions de constructions, de combats...). Ces actions (sous réserve de votre jeu) ne demandent pas d'énormes ressources serveur.
Un autre système de résolution avec un "daemon" ou un "cron" peut s'occupper d'autres actions plus lourdes à traiter et qui ne nécessitent pas d'être instantannées. Avec une bonne gestion de l'affichage il est compréhensible de faire patienter un peu le joueur (cf: eRepublik pour ceux qui ont déjà testé)
Je ne suis qu'au début de ma réflexion mais ce genre d'architecture (que j'utilise de façon professionelle dans d'autres langages que php) est viable.
La gestion du stack d'actions, des annulations éventuelles d'actions ou des impacts entre actions doit faire partie de l'intelligence de l'application (à savoir votre code) et donc cela restera très indépendant des choix techniques (requêtes http, cron, daemon...). La problématique se posera de toute façon.
Voila pour ma contribution, l'article sur les processus php est super intéressant merci
BA-17 : 17 years before apocalypse !, le jeu dans l'univers du défunt wargame AT-43