Histoire d'éxécution ?...

[Anthor]

On va dire que vous avez tous raison, et que je ne sais pas ce que je fais. Ca fera plaisir à certains qui savent tout, et ca mettra fin à ce débat ridicule.

dit l'homme qui demandait de l'aide et était le seul à ne pas avoir de problèmes de conceptions.

EDIT: Tu sais tu peux rajouter des éléments à chacun de tes posts pour dire que ce que tout le monde te dit depuis le début est faux, mais les gens réponde à TA problématique par rapport à ce que TU demandes.
Je te maintiens que je n'ai pas besoin de faire des requêtes toutes les secondes pour une famine en plus...

[Unkof]

Je te maintiens que je n'ai pas besoin de faire des requêtes toutes les secondes pour une famine en plus...

Ben moi non plus, et j'ai réglé mon problème.

Merci à NicoMSevent pour l'indice, ca a confirmé ce que je pensais au départ ....

[Allwise]

J'étais parti dans la voie du socket, avec un serveur en PHP et l'utilisation de flash côté client. Je ne peux pas te faire de retour car faute de temps j'ai mis mon projet de côté, juste te dire que c'est faisable, léger à mettre en place. Ma modeste classe server tient en 250 lignes de code ( c'est la classe mère, faut l'hériter pour en faire quelque chose de concret ). Et je pense que c'est une solution plus que viable... Quand j'aurai du temps et que je reprendrai mon projet, je te montrerai

[Zamentur]

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() 

[nicodd]

@l'op :
A partir du moment ou tu as toutes tes infos concernant un joueur à un temps t, tu peux avoir ses infos à n'importe quel temps t+x, pour peu qu'il n'y ai pas eu d'interaction avec d'autres joueurs.
A chaque interaction, tu mets à jour les deux joueurs au temps de l'interaction, et tu modifie les données selon ce qui s'est passé, je ne vois pas ce qui te pose problème.

Edit : Il doit en plus y avoir moyen de programmer ca joliment avec une fonction récursive.

[Unkof]

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!

Dis pas ca, on va te dire que c'est une erreur de conception !! ... lol. Blague à part, j'ai opté pour ce mode, parce que je sais que ca marche, qu'il permet de gérer beaucoup de monde, et que le serveur ne tombera pas parce qu'il aura tout d'un coup 150000 requetes à rattraper parce que des gars ne se seront pas connecté pendant 3 mois. Enfin bref, tu connais la musique, je ne vais pas te faire un dessin, parce qu'au moins tu sais de quoi il s'agit ...

Je n'ai pas utilisé le socket pour la raison que tu as évoqué, après mes recherches, ce que j'avais lu à droite et à gauche, la seule solution à priori "viable" est le shockwave, et c'est pas ma tasse de thé. Je voulais développer un jeu en Php/mysql, et un jeu de stratégie style Travian, mais qui réponde plus à mes attentes. Très franchement, je ne vois pas l'intérêt de développer ce style de jeu en autre chose que du Php. Après évidemment, ca dépend des connaissances de chacun, et de l'expérience de chacun, mais de MON point de vue, faut utiliser du Php, c'est le plus simple tout en étant très puissant.

Pour ce qui est des astuces que je trouverai sur le forum, c'est sûr, j'en trouverai et j'en utiliserai. Je n'ai pas la prétention de dire que j'écris le meilleur code au monde (on a tous nos habitudes), que je suis parfait, et que les autres sont des rigolos. L'expérience m'a appris au fil des années qu'on fini toujours pas trouver un meilleur code et/ou une meilleure méthode que la sienne. Le tout étant simplement d'en tirer un lecon, et de continuer d'apprendre.

Depuis le temps que je programme le jeu, c'est effectivement un peu trop tard pour changer le fonctionnement "global", mais cette première version est mon premier vrai jeu php, je sais qu'il y aura plein de choses à améliorer, et ce sera fait pour la version 2, si la première version attire un peu de monde ou pas ... ^^

Quoi qu'il en soit, merci pour "l'éclairage" et les idées ...

Allwise:Malgré le fait que je ne ferai pas du socket, je veux bien voir ce que t'avais fait. Ca peut servir pour d'autre jeux, et la relation socket de php vers un client flash m'interesse, même si je n'ai pas encore fait de tests. C'est quand tu veux, je suis preneur . Même si tu ne reprends pas ton projet, si tu veux me montrer ca, c'est avec un grand plaisir, là c'est sûr, j'apprendrais quelque chose, et je sais aussi que j'en ferai quelques chose (j'ai un truc que je voudrais dév qui va utiliser une techno comme ca, mais ca rien avoir avec mon jeu php actuel). C'est quand tu veux

Nicodd:Effectivement, c'est toujours possible avec une fonction récursive, mais ce n'est pas viable, à cause du grand nombre de joueurs possible, et à cause des nombreuses interactions. J'avais commencé un algo papier, avant même d'écrire une seule ligne de code pour le jeu, et en ayant tous les paramètres à gérer, on s'apercoit vite que ca devient une usine à gaz avec des problèmatiques de temps de gestion pouvant devenir tellement important qu'ils finiraient forcément par amener le serveur sur des timeout. Sans parler du fait que c'est du code plutôt lourd à faire évoluer, surtout quand t'y touches pas pendant un moment, et que tu reviens sur ton code 3 ans après pour apporter des modifs à ton jeu.

Tout ca pour dire au final, que ce n'est peut être pas la meilleure solution, mais que c'est celle que j'ai adopté, en connaissance de cause, et que ca fonctionne relativement bien quand on gère bien ses transactions.