Map, PhP ou Flash?

ouh non.
un acces a un fichier, c'est pas comme une requete sql.
ce se fait en 1/4 de milliardieme de secondes.
et meme en pleine charge il n'y en a pas tant que ca et ce sont pour 95% des écritures d'un seul octet.

une requete sql EST un accès à un fichier.

Ben, si je ne m'abuse, le fichier est essentiellement utilisé en lecture, donc pas de problème de concurrence.

Mais effectivement, si la carte est amenée à être constemment modifiée, ce système peut s'avérer handicapant...

javascript et socket... m'etonnerait

en y repensant, java permets aussi de faire de tels choses peut etre même plus efficasse et plus souple que flash. Avec des possibilités surement bien plus grandes encore... mais faut une machine java coté client pis c'est lourdle java.

php permets d'ouvrir des sockets aussi. J'ai testé cela en faisant un petit chat socket/php/flash/sql ... alias plein de trucs c'est simple joli et cela marche

pour faire du pseudo socket pas chere...

il y a aussi la possibilité de jouer a minimus ... ok je m'expliques

une requête toutes les 10/20 secondes (y a pas foule non plus j'ai dis pseudo )
mais une requête minimaliste.
simple interrogation de "quelqu'un a bougé dans le coin?". qui est un simple

<?
//connect
sql="select tavubouger from perso where idperso='$moi'";
//row machin
//deconncte
echo"$tavu";
?>
si oui on réinterroge la carte du coin sinon ben on continue de compter jusqu'a 20
il suffit ensuite de créer les champs optimisés dans sa base et la requête de mise à jour lors des déplacements pour avoir un pseudo socket pas chére.

et c'est faisable en javascript avec XmlHttpRequest

heu, je suis peut-être pas bien informé mais, si je ne m'abuse, c'est Flash qui gère le socket du coté client dans une applic flash-php et pas php. Et en plus, dans ce que tu nous cites, il n'y a rien qui gère le socket au niveau du serveur. Tu es certain que ce n'est pas du http que tu fais avec ton chat ?

Pour travailler avec des socket, le top est un serveur java et un client Flash.
Pourquoi Flash comme client et pas java ?
- pas besoin de plug-in java chez le client (le plug-in flash est beaucoup plus répendu)
- interface graphique en java =
- gestion du XML en flash =

Un peu HS, désolé

@vys :

c'est bien plus que ca :

carte SQL : putmap(x,y,val) : appel en php a la primitive sql execute "update carte..." -> appel au service mysql (protocole couche ip ou named pipe) -> interpretattion de la requete SQL-> localisation de la donnée -> mise à jour du fichier via primitive système.

carte binaire : putmap(x,y,val) ->mise à jour du fichier via primitive système.

c'est ça que je voulais dire.

@nono :
tres honnetement je pense que meme sur un jdr comme ideo ou 3000 personnes bougent en même temps (et donc updatent la map), il n'y aurait pas de problèmes de concurrence d'acces. Dans la mesure ou ils n'écrivent pas 20ko a chaque fois dans la map ! le temps d'accès au fichier reste infinitésimal par rapport au temps de traitement complet du script (gd,c/s,...). Les erveurs de fichier sont faits pour ca !
(ps : si tu pouvais abrteuver ma curiosité et m'expliquer comment vous gerez votre temps réel ca m'intéresse foncièrement)

Je pense que ca interesse tout le monde de savoir comment vous gérez le temps réel

Bon, sinon, effectivement, je pense que c'est probablement le plus rapide, en fichier a plat binaire.

Par contre, je me demande si je vais pas faire un systeme mix, c'est a dire la map en elle meme, purement en fichier a plat, et les joueurs, objets (batiments, mines...) en BDD.

cela permet de faire des recherches plus rapide dans une base, tout en y stockant moins de choses, sachant qu'il n'y aurras pas d'objet ou personnes sur chaques case ^^.

Ca permet meme de pouvoir séparer encore certaines données dans des tables différentes...

je dirais meme que ca permet de charger des plus grandes parties de map coté client, puisqu'au final elle change pas.
Et n'avoir acces qu'au données principales plus rapidement.
Ou peut etre un fichier a plat, selon comment on auras besoin de gerer les données ^^

Sauf erreur de ma part ce qui prend le plus de temps en manipulation de fichier ce n'est pas la lecture ou l'écriture mais l'ouverture du fichier : c'est là que des BDD professionnelles (je ne sais pas pour MySQL) ont une carte à jouer grâce à leur système de cache qui permet de rattraper la perte de performance due aux différentes couches.
Après ça dépent aussi de l'OS, du système de fichier... c'est pas simple.

Mais bon, il me semble quant même que ta solution reste la meilleure puisqu'adapté spécifiquement à ton besoin.
A mon avis il faut juste vérifier (ce que tu as peut-être déjà fait) que les ouvertures/fermetures à répétition impliquent des temps de réponse proportionnels et non pas exponentiels au nombre d'accès

A la condition implicite me semble-t-il qu'il y ait bijection entre un emplacement virtuel sur la carte et un emplacement physique dans le fichier (c'est à dire qu'il n'est pas nécessaire d'utiliser des méta-informations contenues dans ledit fichier pour retrouver le(s) bit(s) correspondant à un emplacement donné de la carte et vice versa).
Tout dépend de ton besoin (on en revient toujours là).

coté client oui, mais coté serveur non.

la version dont je parle ici ne fonctionne que par socket (pas sur le port 80 pour faire simple) donc non c'est pas du http

ensuite j'expliquais un truc permettant d'avoir un comportement proche du socket avec du http.

oui je sais jamais été claire moi

@keitarosan et grouik:
bien sur qu'il faut un systeme mixte.le binaire est une donnée a plat, non structurée, donc adaptée uniquement a la parte VISUELLE. le binaire ne contient que des cases quoi...Il est tres adapté a un besoin d'affichage car la seule chose qu'on veut faire dedans c'est lire et ecrire des suites de cases, bien entendu on ne peut pas fairede "recherches" au sens sql dans le fichier. Je ne l'utilise pas pour autre chose que les affichages. Et bien entendu j'ai des tables utilisées pour la logique pure : constructions, unités. Une des difficultés est comme tu dis grouik de maintenir la bijection entre les coordonées dans le binaire et en base. Maintenir cette correspondance est indispensable, et ca fait calirement du travail en plus. Perso j'ai fait des routines de vérification à la résolution des tours pour détecter les anomalies.

@grouik :
rapport a l'ouverture de fichier : tu l'ouvres une bonne fois pour toute à la connexion et tu laisses le pointeur en session.

Qui a parlé de temps réel ?

Pour la map, dans ideo, on utilise une map statique sur png (revient au même qu'un fichier binaire sauf que les fonctions sont déjà fournies dans gd ). Mais là je suis en train de changer pour un nouveau système encore plus rapide, que je tends à généraliser pour tout le jeu en fait.

En fait c'est tout con : je met tout en cache php. Concrètement, je travaille sur base de données, et à chaque modification, j'exporte les données en générant du code php (vive var_export).
Et au final, pour récupérer les données, plus de requêtes, pas besoin de se prendre la tête avec un fichier binaire, un include suffit.
Gain de vitesse indéniable.

Evidemment cette solution n'est envisageable que pour des données relativement statiques. Mais en tout cas ça me permet de rester sous la dizaine de requête pour la page de jeu et à une requête en moyenne sur les autres pages.

C'est qu'il faut le ménager le petit mysql.

nono, faudras que tu m'expliques ton systeme ^^

Parce que la, j'ai pas tout compris...
var_export() ca affiche le contenu d'un tableau, comme un echo, mais pour les tableau... Donc la j'ai pas compris.

En plus, mettre en cache sur le serveur (en php donc), ca implique de le faire pour chaque joueur. Et la, plus t'as de joueur, plus tu ralentis le serveur. Donc soit j'ai mal compris, soit tu t'es tres mal exprimer, soit tu vas droit dans un mur avec ton systeme ^^

Bon, sinon, je pense que je vais m'approcher d'un systeme comme zumba, qui me parait plutot pas trop mal

Par contre, l'histoire de la GD, j'ai pas tout suivi.
Est ce que les intéressés peuvent me détailler un peu ca ?

OUCH !!

OUCH !!

Ouaip

D'autant plus que ça ne fonctionne pas du tout a priori (à moins que le langage ne soit pas du php, ou que la doc mente ^^). À la fin du script, PHP ferme toutes les connexions ouvertes: pointeurs sur fichier, connexions sql, sockets, etc... Le seul moyen de conserver une session c'est si le serveur en face gère des connexions persistantes (comme ça peut être le cas avec un serveur mysql par exemple), ce que ne permettent pas les fichiers simples.

Faire ça c'est simplement ne pas fermer le fichier à la fin du script, mettre une variable inutile en session, et rouvrir quand-même le fichier à chaque appel ^^
Autant ne rien mettre en session.

Et quand bien même ça fonctionnerait, ce serait d'une lourdeur extrème pour le serveur (bien plus que de rouvrir le fichier à chaque fois): au lieu d'ouvrir le fichier 1/4 secondes et de le refermer tout de suite, il le garderait ouvert durant de longues minutes. Impossible à gérer pour le système.

Ton "temps réel", c'est juste une variable "temps" que tu colles dans ta session.
Et à chaque fois que tu fais un "refresh" (ordre, clic, lien, refresh auto, etc...), tu compares la date actuelle à la date session et tu voies si quelque chose est à mettre à jour...

Rien de plus simple.

Maintenant, il faudra dire : "temps réel par à coup" ou "réel réel par saut de brèche temporel" !

Non, c'est print_r qui affiche le contenu du tableau. var_export, affiche le code php correspondant ) la déclaration du tableau. Essaye, tu verras.

Ensuite, j'ai dis que je ne mettais que les données (quasi)statiques en cache, comme la map par exemple, la liste des objets du jeu, etc. Ces données sont communes à tous les joueurs, donc indépendant des joueurs.

Question perf, ya pas photo, et on peut même pousser le vice jusqu'à mettre toutes ces données en mémoire partagée (lib sysvshm), si t'as plus d'une centaine de joueurs simultanés, ça peut faire la différence.

euh...

var_export affiche bien le contenu du tableau aussi ^^, et d'ailleur meme mieux que print_r ^^, car c'est ce que j'utilise tout le temps

par contre, je vois pas comment tu peux mettre des données en cache pour tout le monde :s

Ben typiquement, le contenu de la carte, c'est le même pour tout le monde ^^
Tout ce qui est ressource partagée est la même chose pour tout le monde (statistiques, carte, news, etc...), tout ceci peut être avantageusement mis en cache au niveau des données (si tu veux faire une mise en cache de l'affichage, là il vaut mieux générer du html en l'enregistrer, plutot que de générer du php).

Petite note à propos de var_exporte: elle gère mal les objets ( elle génère parfois du code qui provoquera des parse error ), pour mettre en cache des objets, il vaudra mieux utiliser serialize/unserialize.

puisqu'on aprle de carte, tout ca m'a bien donenr envie de faire la mienne pour mon jeux,seul problème faire de ebaux carrés j'y arrive,mais là ou je bloque c'est pour faire les transitions,par exemple un bord de emr,comment faite vous (sans flash) pour les réaliser,pour qu'il y ait une continuité dans la carte.
merci

bon, alors a mon avis, on parle pas du meme var_export, qui ne fait que de l'affichage comme le fait un echo, mais plutot pour des tableau, des objets...

ca n'a rien a voir avec de la génération de code !!!!

deuxio: Y en a qui non pas du comprendre le fonctionnement de php ^^

Parce que si je serialize un objet, je le serialise pour chaque utilisateur !!!
Donc il n'y a pas de données commune a tout les utilisateur du site, si ce n'est la base de donnée ou les fichiers a plat.

Donc ca n'apporte rien de bon, parce que ca surcharge le serveur en donnée pour pas grand chose. La meilleur soluce que j'ai vu jusqu'a present, c'est de "buffuriser" (meme si le terme convient pas trop) les données en JavaScript, et qu'elles soient traités coté client pour tout ce qui est données commune, comme la map de fond (c'est a dire pas les objets, les joueurs ou les batiment, mais uniquement le décort non modifiable).

Mais on m'as toujours pas expliquer le coup de la GD ^^

Une astuce utilisée par certains jeux consiste à ce que les tuiles de la carte représentent non pas chacune un terrain "plein" (ce qui pose alors le problème de la transition entre les tuiles) mais directement une transition... c'est pas clair ?

Tout d'abord est décidé une hiérachie dans les terrains : tous les terrains ne peuvent pas être directement accolés à tous les autres. Par exemple, mettons qu'on ait décidé de faire simple en prenant une hiérarchie à 1 seul degré, ont pourrait avoir les relations de proximité suivante : eau profonde <-> eau cotière <-> plage <-> prairie <-> forêt. Généralement il y aura plus de connexions mais l'idée est de réduire le nombre de transitions possibles. Dans le cas présent : 4 types de transitions (au lieu de beaucoup plus*).

Ensuite, chaque tuile "transition" est réalisée. Avec des tuiles carrées par exemple il faut compter 16 cas pour 1 type de transition (on peut diminuer le nombre à 6 en jouant sur les symétries). Ca nous fait 4 x 16 = 64 (ou 4 x 6 = 24) tuiles à faire pour cet exemple. Pour savoir quelle tuile afficher à un endroit (x, y), il faudra connaitre les terrains des endroits (x-1/2, y-1/2), (x-1/2, y+1/2), (x+1/2, y-1/2) et (x+1/2, y+1/2), ce qui veut dire que pour une carte de N par M, il faut avoir une grille de (N+1) par (M+1).

Bon, sans faire un dessin, c'est pas fastoche à expliquer, désolé

* pas seulement 10 car avec des tuiles carrées il peut y avoir jusqu'à 4 terrains à une même intersection... soit, sauf erreur, 25 cas possibles dans notre exemple, et c'est exponentiel avec le nombre de terrains.


Pour les autres : je ne comprend pas trop ces histoires de conservation des données communes... il n'y a pas dans PHP la notion de variable d'application, donc je ne vois pas comment conserver les données communes autrement qu'en passant par l'écriture de celles-ci sur le disque du serveur (BDD, fichier ou whatever...)

Je vais être blessant parce que tu te permets de l'être: toi, non seulement tu ne connais pas suffisamment PHP pour te permettre un tel jugement, mais en plus tu ne lis pas les docs, alors que j'ai donné le lien direct vers la bonne page.

Je suis gentil, revoici le lien: http://fr2.php.net/var_export

Et voici, non pas un détail obscur de la doc, mais la première phrase qu'on peut y lire: Retourne le code PHP utilisé pour générer une variable (et je passe les divers exemples qui suivent dans la même page, et qui devraient te faire comprendre l'étendue de la bêtise de ta remarque).

Quand on ne sait pas, en général on se tait.

C'est exactement ça, on écrit dans un fichier sur le serveur.
Tu génères un fichier "vars.php" dans lequel tu vas mettre le code permettant de déclarer ces "variables communes" (à l'aide de var_export).
Tous les scripts incluant "vars.php" connaîtront ces variables.

C'est la solution la moins gourmande pour le système, puisqu'il n'y a AUCUN calcul pour connaître ces valeurs: on les a directement.

oui, je suis vraiment désolé, j'ai pas fait gaffe au deuxieme parametre de la fonction var_export().

Enfin soit dit en passant, par defaut, elle ne fait que de l'affichage ^^
Donc je m'excuse humblement, et je voulais pas me montrer blessant, vraiment

et le deuxio ne s'adressait pas pour le var_export(), mais pour les datas partagées en memoire, du type variables d'applications. Et la encore je voulais pas me montré blessant

Le stress du boulot, lol ^^

Nan, j'avais juste pas trop le temps, et j'ai pas fait gaffe que mon langage etait un peu brute.

Donc encore désolé tout le monde, j'essaierais de faire moins brutale la prochaine fois

d'ailleur au passage, faudras qu'on m'explique l'utilité de générer du code via la fonction var_export(), puisque si l'on passe un tableau en parametre, c'est comme si au final on fesait: $array1 = $array2; ...
Ca manque de logique ^^

Si des personne ont une explication logique, je suis preneur ^^