19-11-2009, 01:29 AM
(17-11-2009, 10:44 PM)Allwise a écrit : J'arrive toujours pas à trouver la logique dans ce système qui consiste à faire exécuter un script par un utilisateur qui met à jour les données de tous les utilisateurs, y a un truc qui doit m'échapper.
Pourtant c'est vachement courant, quand on a plus de 20 joueurs mettre à jour l'évolution du monde à chaque demande de page est plus simple que de mettre à jour des bout de monde!
Surtout quand le tout est fortement connecté.
Ça solution est d'ailleurs bonne puisqu'elle fonctionne, c'était juste un problème de transaction ce qui est très courant.
Moi sur Ragol j'avais la même chose un script qui se lançait à chaque ouverture de page et qui me garantissait une mise à jour. Les seul fois ou le système a été problématique c'est quand le serveur est tombé en panne 6 mois et qu'il avait un retard colossale, mais c'est valable aussi pour un cron.
En fait il faut un système de détection des pannes, pour çà il suffit de regarder la dernière connexion...
En plus avec de nombreux joueur et un flux régulier on peut se permettre de mettre le script d'évènement global à la fin du script en prenant soin d'utiliser une redirection. De cette façon le joueur n'attend pas la résolution des évènements (qui peuvent le concerner d'ailleurs) et obtient tout de suite sa page. A la page suivante il a l'affichage de la modif, ce qui ne constitue pas un décalage si les joueurs sont nombreux...
Ceci dit on peut aussi imaginer un script qui tourne en tout le temps , avec un système de réveil par les affichage au cas ou il s'arrête.
Sinon je suis d'accord qu'utiliser la connexion par socket c'est cool aussi, quand on veut aller plus vite, plus précisément au lieu d'avoir un chemin de lancement maj, demande client, calcul, réponse serveur on a juste calcul serveur, envoie au client de l'info.
C'est plus performant mais on le paye car il faut utiliser une technologie moins accessible au développeur et dans le cas de ShockWave Flash(qui est la seul vrai solution) du fait d'utiliser une technologie propriétaire.
Enfin bref, je comprend Unkof! Cependant je pense aussi qu'il y a plein d'astuce dans le forum qui pourront sans doute lui permettre d'éviter une part des calculs du script evenementiel.
Notamment, l'exemple avec les bâtiments, avec les données qu'on a ici, je le traiterai de cette façon:
la table batiment
batiment(#id,type, id_joueur, debut_construction)
type_batiment(#type,duree,...)
Une vue batiment_fonctionnel qui serait la restriction des bâtiments ayant atteint leur date de construction.
Code PHP :
<?php
CREATE VIEW batiment_fonctionnel AS SELECT b.id,b.type,b.id_joueur FROM batiment as b INNER JOIN type_batiment as t ON (b.type=t.type) WHERE debut_construction+duree<UNIX_TIMESTAMP()
Enfin bref voilà l'idée et avec çà on a plus besoin de script pour regarder si il y a un bâtiment à construire.
Alors évidement c'est discutable dans le sens ou çà fait un SELECT à chaque fois qu'on fait recours à la vue... Bref à chaque fois il doit se taper l'ensemble du calcul, même si c'est pas énorme
Une autre solution consiste donc à faire un unique UPDATE plutôt qu'une transaction.
Code PHP :
<?php
UPDATE batiment as b INNER JOIN type_batiment as t ON (b.type=t.type) SET construit=1 WHERE debut_construction+duree<UNIX_TIMESTAMP()