Map, PhP ou Flash?

Je tiens d'abord à préciser un point très important: Je suis complètement nul en codage.
Je suis chef de projet, et donc chargé des relations avec les autochtones
Tout ça pour dire qu'il n'est pas vraiment nécessaire de me poser des questions techniques, car je serais bien en peine de fournir une réponse (au pire je demanderais à un de mees codeurs mais bon).

Je voudrais faire une map pour mon jpc. Voici l'inclinaison:


(oui elle est moche mais c'est pas l'essentiel )

Donc les graphismes seraient en 2D, le problème c'est qu'on m'a dit que créer une telle map (570*400 cases) en PhP/MySQL c'était la grosse galère question serveur. On m'a donc conseillé de la faire en flash, et je viens donc vous demander conseil à mon tour, pour avoir vos avis sur la question (à savoir: quel genre de map choisir) d'une part, et puis pour que vous me donniez vos conseils sur comment crée rune map en flash.

Merci

holé.
tu peux décharger grandement le serveur en déportant le moteur côté client, en lui passant un buffer contenant une bonne portion de ta carte. les images de la carte ne sont plus générés par le serveur mais par une logique locale en javascript(js) ou en flash qui promene la vue dans le buffer. Si tu sors de la zone, il va chercher la suivante et la met en buffer.

Personellement c'est ce que j'ai fait dans continent (lien en dessous, démo du moteur en page d'accueil, attention premier chargement très long). et bonne surprise sur un hébergement mutualisé bas de gamme le serveur tient très bien la pleine charge (350 joueurs). Je bufferize côté client des zones de 200*200 tirées d'une carte côté serveur en 1500*1500, la carte étant sur 2 couches (sols et objets)
ex :



MAIS : ca demande une synchro permanente client/serveur -> du boulot en plus :une mise a jour de la carte doit être faite dans la vue client ET dans la map en base de donnée (a ce propos stocker la map dans un fichier binaire est bien plus optimisé que la stocker en bdd, et permet de faire des cartes de taille immense sans impacter la performance). Et c'est donc inadapté a du temps réel, donc si ton jeu est un jdr oublie c que j'ai dit. Pour faire du temps réel le plus simple est de faire générer a chaque déplacement la vue locale.

ensuite, si tu as lu jusqu'ici, JS ou flash ? Bon le JS est clairement pas coucu pour faire du multimédia, mais offre d'intéressantes facilités de programation (mise à jour du spriteset, sprites animés...). On serait tenté de croire que flash est bcp plus adapté mais pour avoir bien creusé la question et fait moulte tests c'est décevant pour faire un rendu de type matriciel à base comme ta carte et la mienne, flash étant basé sur une philosophie d'affichages vectoriesl. bref les perfs ne sont pas meilleures qu'en JS (dans l'état actuel des choses).

voilà pour finir il y a de nombreux topics dans ce forum abordant la problématique de la carte.

Tiens zumba, niveau bande passante ca se passe comment?

Sinon j'ai remarquer qu'il y avais des problème d'affichage de map (la map qui se déforme au déplacement). Je le signalerais quand le rush des signalement des bugs seront passé

Pour revenir au sujet, personnellement, je préfère le GD. Pour la vitesse et la bande passante. Mais la question que doit se poser notre invité, est combien de couche il va mettre sur sa map, et combien de joueur tu compte avoir sur ton jeu (beaucoup (A&F) ou peu (stratégie))?
Il est clair qu'avec le mutualisé, moi avec 400 joueurs journalier, le serveur rame un peu. (mais SD est très lourd niveau traitement)
@+

bon ben je vais défendre flash



disons que flash permets le meilleur comme le pire

j'ai mis enormement de temps à trouver une formule qui fasse survivre serveur et client.

une fois que l'on a compris que les objets ont leurs limites et que l'on a bien optimisé son joujou, il est d'une rapidité indéniable vu le peu de données à transferer entre le client flash et le fichier xml ou le socket.

je suis parti dans l'option d'un tout petit client flash qui telecharge en cache les petits morceaux. cette solution n'etait pas viable il ya peu mais les derniéres versions des navigateurs gerant beaucoup mieux leur cache permets une utilisation raisonnable de bande passante.

flash permets aussi l'utilisation du dessin vectorisé, je n'utilises pas cela mais des possibilités de zoom sont alors envisageable.

je n'ai malheureusement pas trouvé de partie serveur gratuite permettant la mise en place de le temps réel sous flash par l'intermediaire de socket. les version d'essais sont bleufantes.

pour la taille de ta carte en 500 par 600 a vrai dire... pas vraiment là le soucis.

depends de combien de cases tu affiche a la fois et combien de cases remplies il y a sur ta carte.

disons que pour commencer un carte à la smiles pourrait te permettre de voire comment utiliser tes ressources.

sur le nombre de couches... pas eu de soucis sur ce point ... il faut limiter dans les requetes sql afin de ne pas afficher trop de personnages...(1 + un petit numéro).

j'avais une version php qui mettais les objets portés mais ma requetes etaient vraiment mal foutue en y repensant

Tiens sur un serveur dédier (c'est ca que tu a?) tu peut acceuillir combien de joueur avec un map en flash? Car avec SD je peut en recevoir 300 à 400 par jour en mutualisé.
Parce que je suis pas convaincu des performance du flash.

(même si en voyance certain résultat, il faudrais que je m'y mettent un jour )
@+

Le Flash, c'est 100% le client qui travaille; donc, tu ne trouveras pas plus léger qu'un client flash auquel on transmet les data sous forme txt plat. (sauf si tu utilises la connexion socket, moi je ne parle que de http).

là on tourne à 3/400 joueurs actifs par jour sans coup dur pour le serveur

la carte flash se résume pour le serveur à la création d'un fichier xml.

si un client JS . enfin pas mieux mais pareil (et je fonctionne exactement comme tu dis, avec des dats transmisent à plat en binaire)

en tout cas impressionnant gorgu ton moteur.il gere l'altitude si je comprends bien ?? je ne défoncais pas spécialement flash, pour ma part, je disais juste que je m'attendais a un truc 100 fois plus fluide

en fait je paralis de la vitessse d'affichage/déplacement
en fait nous on avait fait des essais avec le scrolllpan.idéal d'un point de vue ergo mais pas tellement tellement rapide.
y aurait t'il des objets plus optimisés avec la meme ergo ?
sinon comment geres tu les ressources graphiques : elles sont emabraquées dans le flash ? (c'est notre autre gros pbm)
sinon dans les pus du flahs il y a la gestion codeless du zoom, du bluring.
pour le js on a la gestion codeless des anims, des ressources graphiques...

sinon pour moi la BP ca va.
avec 300 joueurs on a pas dépassé 28% d'utilisation. un php génère le ficjhier html/js, avec une zone de 150*90 en mémoire, de 60ko (hors images et libs js en cache)

PS: oh les jolis palmiers... il me semble les avoir déjà vus qq part... non ?

les images etaient embarquée... un peu lourd du coup et pas trés pratique en maintenant du coup j'utilises de petits fichiers chargés à la volée. pas trés optimisé mais au bou de 3/4 cases identiques le cache de flash se mets en route et tout cela devient bien plus simple.

pour le scrolling...j'ai pas cherché en fait car je part du principe qu'un joueur n'aperçois que se que son personnage pourrais voir.
les animations sous flash sont une calamité à vrai dire lol... alors que c'est son boulot à la base...

les animations dans le corps du fichier passent trés bien.

mais celles dans les cases sont assez peu fluides. l'astuce consiste alors à découper les mouvement en image par image et supprimer tout se qui a permis la création. ainsi lors de l'affichage il n'y a plus rien à calculer.

le gros soucis de flash est son language vraiment... vraiment... mal foutu
J'ai tenté de faire un fichier dans les regles de l'art d'aprés la doc, total un véritable carnage... les joueurs n'osaient plus bouger

il faut garder l'intégralité de ses scripts dans le la scéne (pas dans les objets)

la gestion de la hauteur de terrain. pas une réelle difficultée en soit. la mise en place de "skin" sur le terrain créé est une réelle galére. Flash ne prévoyant pas cela d'origine.

les cocotiers.. aucune idée, c'est l'image envoyée par un joueur... si y a un soucis dis le moi que je ressorte mes crayons me doutant que cela dois venir d'un jeu du commerce (voir le tien) et hop de nouveaux cocotiers pour les petits monstres

khiguard > tu es hebergé où ?

le principal inconvenient du flash c'est que je trouve , il n'est pas adapté aux petites connections , en plus certains joueurs jouent depuis des postes publique et ne peuvent pas installer le plugin flash.

mais sinon il est clair que le rendu est tres joli.

mon fichier flash fait 32Ko. chaque skin de case environ 3Ko. les cases vides etant comprises dans el fichier d'origine .

les modems ne se plaignent pas. (plus.. mon client faisait 350Ko et à du passer les 500 avant son régime )

les ordinateurs d'entreprises ont flash maintenant.

ok , effectivement si il y a eu un allegement du script ,ca doit aller bcp mieux , à l'epoque , j'avais du tester l'ancienne version et avec ma petite connection , c'etait assez lent

enfin je parlais pas forcement des entreprises mais aussi des universités/ecole etc ... qui fonctionnent souvent avec des administrateurs un peu feneant qui ne mettent pas à jour le navigateur et qui n'installent pas flash , enfin c'est sur que ca ne doit pas representer une grande part des joueurs mais je trouve que c'est quand meme un point à prendre en compte.

OVH.
pourquoi, trop lent?

Sinon, c'est vrai que 35ko le client, ca fait rien. Mais dés lors que tu va chercher des images, ce n'est pas la bande passante qui prend un coup? Moi au final, j'aurais entre 400 et 500 images, si je les fait passer par la bande passante tu imagine la cata. Alors qu'avec le GD il n'y a que 20ko qui passent a chaque fois (l'inconvéniant c'est le CPU qui prend un coup, mais sur un dédier, un millier de joueur journalier est possible, mais il faut optimiser sont moteur a fond)
@+

@khiguard :
si les images sont en cache, ca ira. sinon, bah tu auras un chargement équivalent a celui de continent quand tu viens de vider le cache (363 sprites entre 70*50 et 170*250).

@gorgu : oui c'est bien un sprite issu de continent. Dans la mesure ou c'est le seul et ou on te l'a envoyé, ca ne nous dérange pas. Mais c'est clair que notre graphiste n'aimerait pas voir tout une partie de sont travail récuperé sans sa permission. D'une part car il les a déposé, et les a par ailleurs mis en vente sous forme d'un pack sur un site d'infographie. Nous publierons notre moteur et ses ressopurces graphiques sous license gnu quand la phase beta du jeu sera terminée mais en attendant, pas sans notre accord.

Hello tout le monde.

Dites j'ai une question:

Qu'est ce que vous entendez par fichier binaire... Parce que c'est pas trop clair votre histoire. De meme, comment vous buffuriser coté client ? Parce que d'une facon comme d'une autre, meme en buffurisant coté client, ca bouffe la meme mémoire coté serveur, puisque les données viennent de la. Sauf qu'a la limite, elle y reste moins longtemps.
Mais je vois pas quand meme comment vous envoyez les données de la map dans coté client, sans rester coté serveur.

De plus, un selon l'idée de mon petit camarade qui a creer le post, ils veut faire une bonne map dynamique, et donc logiquement avoir une syncro la plus "parfaite" possible, sinon le jeu perdant sont interet.

Donc en gros, j'aimerais savoir comment dans un fichier binaire, et si j'ai bien compris vos message, avec un 0 ou 1 par case, vous arrivez a faire une map avec plus de 2 sprite, lol ^^

Ou alors, c'est juste le format de stockage en binaire, mais dont chaque case tient sur un ou plusieur octet (quoi que 1 octet laisse quand meme la possibilité de 255 sprite :-D différent).

Ou alors j'ai louper quelques episodes

Merci par avance d'eclaircir ma lanterne ^^

Je vais juste répondre simplement, un byte = 8 bit (un 1 ou un 0). Donc comme tu l'a dis on peut alors avec 1 byte on peut avoir 256 possibilité, si on prend 5 couche (batiment, terrain, ect...) ca fait 5 octet la case. Donc ton fichier binaire fera : (nombre de case X * nombre de case Y) * 5 octets. Ce qui est peut.
Ce n'est pas parce que c'est binaire qu'on ne peut pas assembler pour donner des valeurs...

Pour se balader dedans on fait un simple seek.

Tu comprend comme ca?
@+

Euh... Bien.

Par contre j'aimerais savoir comment vous traiter ca, parce que j'ai pas trouver de fonction en php qui traite réellement du binaire ^^
donc bon, je sais pas trop comment vous vous y prenez ne serait ce que pour ecrire un fichier en binaire sur 8bit.
Car un entier, c'est 4 octet (32Bits). Et en caractere string, c'est 1 octet par caractere. Donc si je prends 10 en integer, ca prendras quand meme 4 octets, et si je prends 10 en string, ca me prends 2 octects. Donc dans les deux cas, il est impossible d'arriver a traiter du binaire pur.

A moins que j'ai oublier quelque chose dans les profondeur de nexen ^^

Vala, si vous arrivez a me dire comment vous avez géré ca "réellement" en bits, je suis preneur ^^

Regarde du côté de pack() et unpack() surtout

Ben c'est simple, tu récupère octet par octer (ou des paquet plus gros), et avec des masques binaire, tu récupères les infos voulues.

Si par exemple, ma case est codée sur un octet. Les 4 premiers bits correspondent au terrain, les 2 suivant au niveau d'élevation, et les 2 derniers au royaume associé.

Tu récupère ton octet avec un fseek($f, $position), $data = fread($f, 1).
Puis tu crées tes masques :
$masque_terrain = 0xF0; (1111 0000)
$masque_niveau = 0x0C; (0000 1100)
$masque_royaume = 0x03; (0000 0011)

Ensuite, pour récupérer les infos, tu combine les masques avec le terrain (en décalant pour avoir le nombre correct) :
$terrain = ($data & $maque_terrain) >> 4;
$niveau= ($data & $maque_niveau) >> 2;
$royaume = ($data & $maque_royaume);

Ca répond à la question ou je suis hors sujet ?

zumba... arf desolé, c'etait vraiment pas l'objectif.

hop avec les nouveaux cocotiers

pour les images chargées et la bande passant, oui c'est plus lourd. je suis en train de fouiller du coté des fichiers locaux comme pour va version de test en fait .

par binaire j'endais pas que je le lis bit à bit, mais dans le sens que ce n'est pas un fichier de donnée structurée. Juste une suite d'octets. Je code chaque case sur 1 ocytet par couche ce qui donne donc 256 variantes de terrain / d'objets.
pour la technique c'est à peu près comme nono le dit.
en gros mon putmap sera

a la fin ton fichier de map ressemblera a un truc du style

[shdjkgq456sdgdsfg-yèn"zé"gé"g54gé"gyfgyufyufyufvids-è_"g_ç_çr4653M%.M?K]

mais de toute facon ca n'a pas de sens de le lire au sens caractères, ce qui nousintéresse ce sont le svaleurs hexa.

ensuite niveau buffer client / serveur : comment ca un buffer serveur ? il n'y a pas de buffer serveur, tu n'as que ton fichier carte.bin partagé entre tous les utilisateurs comme le serait une base de donnée.
côté client tu auras un html/js géneré par le php avec un un buffer sou sla forme d'une variable js du genre

attention certains carractères sont illégaux en js, il faut normaliser la carte pour qu'elle ne contienne pas ces valeurs interdites (en pratique, cette limite intrinsèque à l'utilisation de JS côté client limite le nombre de codes cases différents à 245 ou lien de 256)

et concernant la synchro parfaite : ca dépend du type du jeu. déjà de quelle synchro on parle ?
1) la synchro client-seveur : il faut qu'a tout moment ce que voit un joueur sur sa carte corresponde à ce qu'il y a. c'est ca la grosse complication puisque tous tes putmap/getmap doivent avoir une version client ET serveur, avec controles de non désynchro. Donc quasiment doublage du code.

2)la synchro client-client : ca ca veut dire que tous les joueurs voient la meme chose au même moment. Si machin bouge son gus, truc doit le voir aussitot. Un jeu de startégie asynchrone en tour par tour n'a pas forcément besoin d'une comme ca synchro parfaite, ou du moins peut se contenter de la faire à la demande. Un jeu de rôle par contre il la faut. On peut s'en approcher facilement en faisant une regénération de la vue a chaque déplacement serversiode, typiquement basée sur GDlib. Mais c'est pas encore parfait car la mise a jour est en réaction. En gros je bouge pas, le temps n'avance plus. OU alors tu forces des refreshs côté clients tous les quarts de secondes mais la bonjour la BP et le CPU serveur ! D'ailleurs a ce propos non si tu pouvais m'expliquer comment ca se passe dans ideo : je suis a l'arret, je fais rien. un vilain gob arrive par derriere et me bute. Quand je fais mon déplacement suivant il me dit "trop tard tu es mort!". En fait je n'ai aucune idée de comment on peut faire un jdr synchrone sans avoir la possiilité que le serveur déclenche un evt sur le client (ce qui est le sens contraire du principe de base des technos web scriptées !)

apres la solution ultime, qui semble être celle dont parle gorgu, et qui est utilisée dans tous les jeux mmp non web, c'est un socket ouvert à l'écoute en permanence et qui recoit a tout moment en evt du serveur. C'est aussi le plus compliqué a coder. Flash visiblement implémente les sockets, mais c'est galere niveau hébergeur qui doit heberger un exe ou flash/serveur (va trouver ca pas cher, je peux te dire que si tu en trouves un je suis preneur !). En js je ne pense pas qu'on puisse implémenter des sockets, si ?

ouep, ca reponds assez bien.

donc je vais voir ca, si je peux arriver a quelque chose de propre et rapide.

Par contre, je sais toujours pas comment vous réussissez a buffuriser les données coté client...

Ca c'est deja moins compréhensible, et j'aimerais bien savoir comment vous vous y prenez. Parce que ca me parait louche

(je veux pas le code, hein, je suis assez grand pour en sortir un, mais ca m'intrigue vraiment votre histoire )

ok bon, tu vas apeller un script php pour generer ta map

ce script va faire des getmap dans le fichier binaire de la carte qui peut être vu come ca

mapw=16 colonnes , maph=6 lignes, les codes cases sont les codes des caractères.

ton carte.bin ressemble à ca :

ahguidaguiguigda
aghuiguiguiguigd
adhiahdiohioadhi
dhkqdhklqhdsklhq
hdqsjhjkhqsdjkqs
hqdshlhdqsklaqhds
(je reviens a laligne maisc'est purement conceptuel)

tu veux bufferiser une zone de zw= 4 sur zh=4, origine ox=2,oy=2 soit obtenir dans le fichier html/js que le client aura dans son navigateur

tu vas avoir un map.php :


map.php

tu auras bien a l'arrivée dans la source coté client
var carte_locale=''ghuidhiahkqddqsj";
qui est ton buffer en javsacript
a partir de la tu n'as plus qu' a dessiner une zone de 2*2 se balladant dans ton buffer 4*4. en déplacant ta vue a l'intérieur du buffer, il n'y aura pas besoin d'aller charger des données sur le serveur.
il faut que tu détectes quand ta vue sort du buffer et aller chercher une zone ox/oy centrée sur les nouvelles coords.

A c'est ce que vous appellez buffuriser ^^

Fallais comprendre.
Donc c'est pas non plus une solution miracle, lol.

Ouep, bon bah c'est pas trop compliqué en soit ^^

Merci pour les petites infos, je vais voir a faire quelque test de rapidité, et de montée en charge.

Bah oui, être synchrone en HTTP (request / response) est par définition un non sens. Après si tu es courageux et que tu as les doigts musclés, d'autres protocoles t'ouvrent les bras

Sinon, tu n'as pas de problème d'accès concurrents ou de file d'attente trop longue sur ton fichier "binaire" lors des pics de charge ?