Bonjour,
je suis en train de réfléchir à un système efficace.
en effet pour ceux et celles qui connaissent OGAME TRAVIAN... qui sont des jeux jouables par navigateur, un système d'actions est intégré.

Pour le résumer.
on a deux joueurs J1 et J2
quand J1 lance une action sur J2, il crée un évènement sur la base de données donc en gros "J1 ACTION SUR J2 INITIÉE A 12H ET TERMINE A 18H"

pour ce système je propose d'avoir une liste d'évènements et en fonction du joueur qui se connectera après 18h lancera automatiquement tout les évènements le concertants et ils affecteront automatiquement les données de J1 et J2

Mais dans ce système si J3 se connecte et lance une action sur J2 pour 18H alors lorsque J2 se connectera il mettra a jour les deux évènements donc les données de J1 J2 et J2.

Donc à très grande échelle un joueur pourrais a lui seul mettre à jour les données de milliers d'autres.

la question que je me pose est: Est ce la bonne méthode? et en existe t'il d'autres?

de J1 J2 et J3. pardon

Tu as pas 36 solutions, soit c'est le serveur qui calcule, avec les inconvénients que ça peut comporter au niveau de la charge.

Soit tu fais calculer aux joueurs, par P2P y comprit, mais tu t'exposes aux risques de tricheries.

A toi de voir

Merci pour ta réponse.

Le problème c'est que si je prévois d'avance des crons pour mettre à jour les données je perds la notion de "temps réel" on en reviens donc a une simulation asynchrone ou chacun joue chaque jour et a un slot de temps régulier on update tout le monde.

Ou chaque joueur pourrait lors d'une action programmer une nouvelle tache que le serveur exécuterai au moment souhaité.

(ce système me semble assez lourd pour le serveur)

Donc on revient à la solution ou les joueurs mettre à jour aux mêmes les données. Donc la question maintenant c'est comment être efficace et comment éviter la tricherie?

Il existe nombre de methodes afin de limiter la tricherie client sans pour autant augmenter drastiquement la charge serveur (une d'entre elles est presentee ici http://alban.apinc.org/blog/2008/01/13/98-comment-tricher-sur-gtetrinet-et-comment-empecher-l-adversaire-de-tricher/ ) . De plus, faire le truc en flash/shockwave/silverlight limiterait aussi le risque de tricherie.

Ah, et evidemment, la meilleure solution est de faire gerer ca par le client, ca evite la charge serveur.

(sur du temps reel, bien entendu) Oui promis, j'arrete les triple posts =D

"# faire le truc en flash/shockwave/silverlight limiterait aussi le risque de tricherie."

Genre tout est crypté? j'ai déja essayé d'editer des scores de jeu flash avec artmoney, un machin qui permet d'éditer des valeurs directement en ram. Jamais reussi sur des jeux en flash...

Il est possible de décompiler le flash, et d'autant plus facile avec silverlight (ça prend 10 secondes tout au plus le temps de télécharger le fichier ), pour limiter ça on utilise l'offusquation du code, mais un mec qui en veut y arrivera. Il faut définir à l'avance à quel point on accepte la tricherie.

Bossant sur un jeu en Silverlight, nous avions besoin du temps réel pour faire du tour par tour... Nous avons migré ça côté client d'une part, et d'autre part nous avons limité les concepts de jeux pour que la tricherie ne donne pas l'avantage dans une partie. Enfin nous allons offusquer le code un maximum.

Nous avons déterminé que avec tout cela, le jeu ne serait pas vraiment perturbé par la tricherie (minorité de cas, difficulté accru pour décoder le code et ne perturbe pas trop le jeu)

On parle de calcul ou d'actualisation des données là ? (parce que J1.PV -= 1000, je suis pas sur que ça améliore quoi que ce soit de le balancer au client)

Je reviens sur le problème initial, tu sais qu'en laissant les évènements s'accumuler jusqu'à la connexion du joueur, tu risques la fin du monde en cascade (en gros, résolution de toutes les files d'évènement pouvant être atteintes depuis le joueur)... Mais pourquoi diable veux-tu d'un bordel pareil ? Ce n'est pas comme si tu pouvais t'affranchir de la résolution d'évènements en ne récupérant que la fin, tu es obligé de résoudre l'intégralité de la file pour respecter tes contraintes de précédence. Le schéma "pas de calcul tant que ce n'est pas demandé" ne s'applique pas ici.

Ensuite, le p2p c'est marrant pour un client lourd afin de créer des grappes de joueurs plus ou moins autonomes... mais quel est l'intérêt dans un webgame ? (Question ouverte, je ne connais pas trop le sujet)

Enfin, l'obfuscation (c'est un anglicisme, et offuscation... ça veut pas vraiment dire la même chose) ou l'assombrissement du code, je préfère rester sans avis...

Bref, pour moi, cron (je ne suis pas expert, donc je peux méconnaitre certains trucs). Tu ne peux pas amaigrir la résolution d'évènements, je pense que le p2p n'est pas adapté aux jeux web (sauf client lourd téléchargé, mais je ne considère plus vraiment ça comme un jeu web), et tu préfères étaler la charge plutôt que de faire une omelette sur la paroi de ton serveur entre 18 et 20.

Plop,
J'aime bien le concept d'evenement dans ce systeme. Ca amene de la programmation rigolote.
Personellement, je resolverais tous les evenement au moment ou ils arrivent. Ca evite les problemes de coherence.
2 approches me semblent alors utilisable:
1/
Tu résouds les actions a chaque hit sur le jeux.
Quand une page est récupéré sur le site du jeu, tu vérifie s'il y a des evenements qui auraient du se passer depuis le dernier hit. Si oui, tu les traites.

2/
Tu résouds les actions aux moment exact ou ils doivent arriver.
Pour cela, pas forcement de cron, qui retire la notion de temps réel. A la place, un processus lourd qui fait les traitement qui vont bien. Apres tout, si tu peux faire un cron, tu peux faire un processus lourd. Comment communiquer entre ton serveur web et ton processus de gestion des evenements: un pipe unix me semble tout a fait adapter.

Tiens, tu me fiches un doute godrik, cron est-il uniquement cyclique ?
( Au pire, du temps réel, ce n'est rien d'autre que du tour par tour vachement accéléré =D )

Héhé je vois qu'il y a du monde sur un sujet qui en fait semble pouvoir être pris de différentes manières.

En tout cas au niveau de mon appli je veux au max éviter le flash pour une raison super simple. Je trouve que sous linux ça bouffe trop de proc et je comprend pas vraiment pourquoi.
De plus les "geeks" qui jouent a ce genre de jeux sont pour la majeur partie sur des systemes UNIX (quand je vois le nombre de personnes sur Hyperiums, Travian et cie à la fac j'hallucine)

On parle bien du calcul des données la réactualisation c'est assez simple à gérer.

Pour Travian on a bien ce système de temps réel et je me demande vraiment qu'elle architecture réseaux est réellement utilisée pour ça.

Un autre système que j'ai pu voir c'est un système de "tick" donc on a des crons qui s'exécutent à intervalles réguliers.
exemple : pour récupérer de l'argent un à 1 update toutes les 8heures
pour vérifier s'il y a un combat ou pas un à 1 update toutes les 30 minutes.
Donc si un mec balance une action le jeu lui dit que cette action sera exécuter dans N tick en raison de la distance entre le joueur et son adversaire.
Là on a selon moi un système plus hiérarchisé et moins bourrin.

Sinon godrik ta deuxième solution semble intéressante.
Donc on aurait à priori un Processus donc globalement une appli qui va s'occuper de mettre en temps réel les informations en attente et qui va exécuter les actions au bons moments.

Je me demande comment communiquer avec ton serveur web avec un pipe :s

Apache est capable d'envoyer des infos sur sa sortie standard? Infos qui pourrait être récupérées sur l'entrée d'un process qui fera les traitements?

Tu veux utiliser quels langages et technos en gros ?

Je veux rester sur une base simple php / mysql voir oracle si mysql ne tient pas la route pour ce genre de chose.
serveur apache sur un serveur dédié (unix/linux)

(ca c'est la base. Actuellement je suis encore sur la partie game concept. Je ne code pas du tout (pour le moment) et je réfléchis aussi à comment répondre aux problèmes techniques qui se poseront (donc je post sur ce forum ) )

Donc avec php tu peux travailler avec des sockets si ça peut t'intéresser. Après je connais pas du tout le fonctionnement de la chose :/

Pour la BDD, PostgreSQL est une bonne alternative a MySql et Oracle

Je sais les utiliser dans d'autres langages donc ca ne posera pas de problèmes les socket et ça me semble être une bonne idée pour lier l'appli à un vrai serveur de jeu.
(j'avais fait en TP une appli avec des servlets qui se connectaient à un serveur FTP donc d'un point de vue fonctionnement cette méthode je la connais)

Un tutorial sur le site du zéro propose aussi de faire un chat avec sockets php + ajax, ça peut etre interessant

Par contre si on a en même temps 1000 joueurs en ligne on a donc 1000 socket d'open. Ca semble pas super pour le serveur.

(je trouve ce problème vraiment intéressant en fait d'un point de vue technique)

de toutes manières, pour avoir 1000 joueurs en ligne en même temps, même si ce n'était que du html statique il te faudrait déjà un gros serveur.

Pour un serveur bien écrit sous unix, un socket ouvert ce n'est vraiment pas une grosse charge. C'est surtout la qualité du protocol que tu utilise qui compte.