Superpositions D'images...

Pour l'instant, c'est un test... Je ne sais pas trop comment je vais gerer tous mes problemes d'echelle, etc...

@corentin : ca serait beaucoup trop genant pour le graphiste(moi en l'occurence) de devoir faire des arbres pour chaque texture de fond... donc, c'est une image par dessus le tile... Je veux ensuite jouer par la suite sur les z-index pour avoir des superpositions...

Mais bon, pour l'instant, il faut deja que je finisse toutes les series de calculs (parce que la c'est pas encore au point) et que je fasse l'autogeneration de la route...

je me permet de poser une petite questions au passage, les maps iso (type smile war ,adept), ne sont-elles pas plus gourmandes en bande passante ou/et en requètes que les maps version Démange (tableau / div) ?

J'aimerai bien y arriver, enfin sans non plus être perfectionniste, mais au moins que mon personnage soit pas plus grand ou aussi grand qu'un arbre.

Si elles sont plus gourmandes c'est surtout en temps de programmation. Au final les images sont les mêmes (en tous cas sensiblement du même poids), et le poids final dépend surtout du nombre de cases affichées, qui est le même dans les deux cas

C'est surtout qu'une map en 2D est beaucoup plus facile à développer/maintenir/optimiser parce qu'on se la représente plus facilement. Mais dans les deux cas une map non optimisée arrive très vite aux 30Ko-50Ko de code (sans compte le poids des images donc). Après optimisation (l'idéal c'est de générer en PHP un tableau Javascript et de faire la procédure d'affichage en Javascript) on réduit facilement de 95% suivant les méthodes.

Je te remercie de l'info . Je suis bon programmeur PHP, mais j'ai peu d'expérience en JS, je verrais donc plus tard quand j'aurais le temps, si je peux faire ça...

héhé c'est exactement ce que j'ai fait. Il est vrai que c'est une sacrée optimisation de la bp vu qu'on a pas à appeller une page du serveur qui va generer une image a chaque déplacement. Le revers de la médaille c'est que le développement est BEAUCOUP plus compliqué. Nottament les notions de synchro entre la carte client en JS et les données de la carte générale stockée sur le serveur. Mais c'est faisable ! j'avais écris un long post sur cette méthode avec le pour et le contre, l'année dernière mais je le retrouve plus.

A la limite si tu ne connais rien au JS/css, pars directement sur du flash pour ton moteur de carte côté client, c'est encore plus compliqué pour certains aspects mais bien plus rapide que du js (on bosse là dessus actuellement et c'est prometteur).

Actuellement, ma carte, fait 6ko si je n'affiche qu'une zone de 10*10 (ce qui sera fait au final...).

De plus, si on n'utilise pas de base de donnée pour stocker les infos de la map, on gagne enormement de temps...

Si c'est le probleme de la taille qui te gène, tu peux changer la taille de tes tiles (voir ici pour un affichage plus grand)

Quand au fat que c'est plus dure de se representer une carte en iso qu'en 2D, il faut simplement prendre son temps, tester correctement ses formules... et ca passe tout seul... j'ai obtenu l'apparence generale de ma carte en moins d'une heure... Pour placer les decors, c'est une autre affaire, mais ce n'est pas la mort.

Bon,maintenant, les routes marchent aussi... il faut que j'ajoute des elements de decors... et que je gere les superpositions...

Là encore je ne dirai pas le contraire !! d'ailleurs une bdd n'est fondamentalement pas faite pour stocker une info de structure matricielle !

bon alors ca ca me <pas de pub, hein ?>démange</pas de pub, hein ?> un peu au niveau du vocable. Pour l'instant, telle que je la vois, ta carte c'est de la 2D toute bête, tout comme la mienne d'ailleurs ou celle de sombre destin qui sont concues comme toi sur une matrice losange. Ce n'est pas parce que tu pars d'un losange sur lequel tu plantes un arbre droit, et pas d'une matrice "carrée" comme par exemple dans ideo pour ne citer que lui, que tu peux dire que ta carte est en 3D iso. Elle sera 3d iso a partir du moment ou tu arriveras à tirer des arretes orthogonales au plan de ton sol, et ainsi generer un véritable relief. Déjà ca implique une 3 eme coordonnée "Altitude" au niveau de chaque point de jonction entre 2 losanges. Une vraie carte 3d iso, pour citer la référence de cette technique, c'est celle de populous (les jeunes n'ont pas connu !) et crois moi c'est déjà une autre algorithmique à développer (calculer les plans d'incidence selon les deltas d'altitude, la nature du sol avec différentes expositions à la lumière, etc etc...BONNE CHANCE !! au début je voulais faire ma carte comme ca mais j'ai dû abandonner tant c'est compliqué a adapter surtout en web. Bon en bidouillant bien je suis parvenu a simuler des falaises droites mais c'est pas parfait niveau perspective.
Je crois que, à ce jour, la seule carte en vraie 3d iso que j'ai vu tourner c'est celle de gorgu, il nous confirmera !

je n'ai jamais pretendu faire de la 3d, iso, je veux juste essayer de faire une petite carte en iso...

Je n'arriverait pas à gerer le relief, j'en suis parfaitement conscient... Je vais essayer, mais je suis quasi certain de n'arriver à rien...( ou alors si, mais trop lourd...)

Le problème du relief dans les cartes statiques comme ça c'est que la hauteur masque des cases. Le seul moyen pour palier à ça serait de pouvoir tourner la carte, avoir plusieurs angles. Pas très adapté au format web (flash à la limite)...

Tu a faux zumba :

Oui la 3D isométrique est bien de la 2D mais ce n'est pas parce que tu utilise des coordonée de hauteur. A la rigueur, ton exemple serais plus porter vers le moteur 3D: tirer des polygones.
Maintenant, je reconnais que le moteur de SD n'est pas satisfaisant, mais c'est bien de la 3D iso.

Tu est sure que populous utilisait un moteur de calcul? Car de ce que je me souvient pour l'époque, c'était une bêtes projection de tiles avec des script qui calculais la hauteur.

Sinon pour le sujet (que je viens juste de voir ) je prefere le GD a l'utilisation de DIV, pour cause, la bande passante, la lourdeur des pages (essayer de lire une page avec des DIV sur un p2)

@+

Les DIV permettent l'utilisation de kits d'images téléchargeables pour réduire le besoin de BP. Si vraiment c'est critique l'installation de ce kit peut devenir obligatoire ou fortement souhaitable pour l'utilisateur (on laisse des images très basse résolution sur le site, et on met les belles images dans le kit).
Avec ce système, et le cache du navigateur s'il est bien géré, on arrive à des taux absolument ridicules, ce qui n'est pas du tout possible avec la solution GD.

Je prendrais l'exemple de SD, avec une image qui génére plus de 50 images différente par affichage et 5 couche sussessive, j'en ai maximum pour 20KO l'images générer, et ca va aussi vite sur un p2 que sur des pc 56K. Les DIV sont lourd a l'affichage, je ne parle pas seulement des images, mais également des traitements des DIV par le navigateur. Pour un jeux comme SD, il faudrais 5 couche de DIV pour arriver a afficher certaine carte. J'ai déjà fait le test avec des DIV, la performance est lamentable.

Oui, avec un kit graphique ca économise la BP, mais combien de % de joueur l'utilisent?

J'ai un moteur, qui genere pres de 200 case par couche, et bien en GD il va aussi vite que la carte de SD (9*9 case) et sans prendre plus de mémoire. L'image fait 448*336 et est remplie. Elle fait a peine 20Ko.
@+

Ouais mais les process trinquent et faut une machine pour assurer derrière. ^^

Si la map d'ideo était en GD, le serveur serait mort.

idem.

tiens je pensais qu'ideo faisait sa carte en gd moi. c'était pas le cas au début ? elle est faite en js / css/ div alors ?

sinon pour en revenir a la définition de l'isométrie khiguard tu m'as mal compris : bien sur que c'est de la fausse 3D à base de 2D, avec des sprites à plat qui simulent une élévation / dénivélation/stagnation générant l'effet de hauteur, néenmoins le choix du sprite est conditioné par le dirac, ou plutot le +/0/- des 4 cases autour. On a donc en x,y la valeur de la case (herbe, terre, bonbons haribo) + la notion de "ca monte ca stagne ca descend" qui détermine si on va afficher un pan plat, montant ou descendant d'herbe de terre ou de fraises tagada.

Nan, c'est bien du html/css/js. Faut dire que sur la map on a beaucoup plus d'élément interactif que celle de sd par exemple où on ne peut cliquer que sur une case.

Avec une map gd il faudrait définir tout un tas de zone invisible calées sur l'image, pas pratique. Alors qu'avec html/css/js, il suffit de lier l'événement à l'élément html. ^^

Bref, à chaque carte son implémentation, tout dépend de l'utilisation qu'on souhaite en faire.

Tu n'a pas vu les derniere mise a jour alors
Ce n'est plus le cas j'utilise pas mal de DIV pour décrire les cases lorsque la souris passe sur la case.
Maintenant, il est clair que si le traitement de la carte prend déjà pas mal de temps, je ne vais pas non plus en rajouter des tonnes.

Sinon, il faut pas croire qu'utiliser le GD est une erreur, il faut simplement savoir programmer comme il faut. Maintenant non, comme je l'ai dis sur un autre post, on programme les outils en fonction des besoins, pour 1000 joueurs par jour, le GD n'est pas du tout l'outils idéal. Par contre pour continent, ca le serais (mais il faudrais remanier quelques trucs.) Si j'arrive a gerer une carte sur un mutualisé avec autant de traitement que maintenant pour 200 à 300 joueur / jour, continent devrait s'en sortir sans problème.

LE GD est l'idéal pour un jeu qui demande beaucoup de traitement mais n'aura pas beaucoup de joueur (je pense que 500 par jour est un maximum). Et la programmation est facile.
Il y a des astuce pour ne pas mettre le serveur a genou: ne pas déclarer plusieurs fois la meme images, ect...

Mais tant que je te tiens Zumba, je suis impatient de voir le traitement par flash de continent, car le moteur actuel est super lent (sur toute mes machines, et je n'ai pas que des p2 ). J'ai même fait des tests de moteur semblable en GD, même si ca aurais été plus lourd niveau proc et mémoire, niveau client ca aurais été 10 fois plus vite.

Et tant que je vous tiens tout les deux: 20 jour d'abscence pour éffacement de compte c'est trop cours. je suis rester 21 jours sans me connecter, vous avez du entendre mon cris de désespoire quand j'ai ouvert ma boite lors de mon retour et que j'ai vu : compte idéo et continent éffacer la veuille!! haaarg!
@+

Tiens du coup je me pose une question : comment vous faîtes dans une carte isométrique pour qu'une case soit réactive étant donné qu'elles sont en losange et que les blocs html sont forcément rectangulaires.

A part les <map> ou l'utilisation de filtre IE, je voie pas...

PS : pour ideo, on a un mail au bout d'une semaine sans jouer et 2 semaines à partir du mail pour se reconnecter. Ce qui fait donc un minimum de 3 semaines. Seuls les niveaux < 5 sont supprimés (ça évite les pertes malheureuses). Et étant donné que le script de nettoyage est activé manuellement quand j'y pense, on a en général plus de temps que ça.

J'était niv 9. Tant pis, quand j'aurais le temps je me réinscrirais, mais j'ai plus trop envie de remonter un perso mais je voulais surtout prendre mon perso pour faire un test pour gameplay en fait. Même chose pour continent.

Ben oui, avec le GD tu cree une image, donc tu cree une map pour cette image (en polygone). LE reste on joue avec le JS.
@+

C'est ce que je suis en trainde faire en ce moment, on créé une image vide (aie...) et on fait une <map> dessus... Pas le choix autrement...

@khiguard : ma carte s'affiche sans problemes sur un P2... ( c'est la machine sur laquelle je developpe...)

j'ai pas compris. ou alors tu parles en GD ?

merci pour tes conseils mais je crois que tu n'as pas le recul suffisant pour de telles affirmations.
Pour continent il faut une machine de 2 ans max. Perso j'y joue sur un athlon xp 1200+, ca rame, c'est le minimum mais c'est jouable, ou sur un centrino 1.3 et la c'est hyper rapide. En carte standard, 1/4 de secondes pour bouger. Maintenant sur une machine plus faible, tu peux baisser la qualité et surtout retirer les effets météo. Enfin, ca va peut être te faire mal mais chez moi entre firefox et IE ca va du simple au double en vitesse. D'autres personnes m'ont dit que c'était plus rapide sous ff ou netscape 7, nottament sur les machines plus faibles (mais dans tous les cas IE l'emporte haut la main sur le glisser/déplacer des fenetres DIV, il doit y avoir une optimisation hard sur le layering dans IE, car meme avec la transparence, c'est instantané).

Donc continent est gourmand, c'est un fait, je ne l'ai jamais nié, mais en revanche en GD c'est tout simplement impossible. Mon premier moteur était en GD. En carte standard, on utilisera entre 4 et 600 images : GD ne suivait pas, je dois avoir encore les scripts de ces essais. Qui plus est, et c'est le plus important et vous omettez bien de le dire, en GD, il n'y a pas de buffering de la carte côté client de possible. Donc dialogue client serveur A CHAQUE DEPLACEMENT, ce qui dans mon cas exploserait la BP, qui est déjà limite (réservée donc pour le forum et le reste de l'interface !). Imagine que pour faire la meme chose dans un cas tu envoies un tableau de donnée destiné a fabriquer une image, et dans l'autre tu envoies carrément l'image. Pour un jeu de stratégie ou le refresh serveur n'est pas une nécéssité, le buffering est une réelle optimisation. En GD qq soit la rapidité de la génération de la carte coté serveur, il y aura tjr un temps incompressible pour le dialogue http qui peut etre d'une demi seconde au mieux du mieux à plusieurs secondes en cas de charge. incompressible QQ SOIT la config du client. Dommage de priver les possesseurs de p4 d'une vitesse supérieure je trouve.
En GD tu n'as pas non plus d'animation possible des éléments de la carte, le pointage des éléments est bcp plus complexe (moi je fais comme nono, du onXXX sur les img)... Et il y a plein de cas ou il est inutile de refaire toute l'image pour n'en changer qu'un morceau (gd t'obblige à tout repeindre : ex : quand on on déplace une troupe, quand on pose un bâtiment... bref la liste est longue en défaveur du GD mais crois moi sur le critère de la vitesse d'affichage, je ne pense pas que gd l'emporte sur une machine récente. C'est un choix que j'ai fait de privilegier ces configs pour tirer le maximum visuel de ma carte, après libre à toi de le critiquer !

GD est a limiter a des cas d'affichage simples et demandant un .raffraichissement serveur permanent (et encore je ne crois pas que ce soit une bonne soluce).
De toute facon, la GD tout comme JS/css n'a pas été concu pour faire des cartes non plus j'en conviens. le web n'est pas concu pour faire un jeu. la soluce parfaite n'existe pas. Aussi je ne jouerai pas à la plus longue d'autant que je me base pour comparer a ce que j'avai svu de sd il y a bien un an. Je veux bien aller voir la nouvelle version de la carte si elle est accessible hors jeu (d'ailleurs c'est une remarque que je fais à tous les faiseurs de jeu : une démo technique hors jeu est un réel plus pour moi, je regrette que bien peu le fassent )

Sinon la version flash avance, mais il ya des trucs vraiment compliqués à gerer en flash : le dialogue bidirectionnel avec les éléments JS de la page, la mise à jour des ressources graphiques du flash... C'est légèrement mieux mais pas non plus la panacée par rapport au JS. Rapellons que flash est optimisé pour faire du vectoriel et se contente d'assurer le minimum syndical pour ce qui est du bitmap matriciel. C'est pourquoi même quand on aura la version flash, je laisserai à dispo le moteur JS. En revanche, énorme plus dans flash : la carte se charge duynamiquement au fil des mouvements : plus de chargements intermédiaires au changement de zone.

Et pour finir, l'inactivité : bon c'est l'équipe mj qui gère ca, mais en effet je crois que c'est 20 tours dans cnt, au dela de cette période, on considère que de toute facon le fief n'est plus viable et aura trop dépérit. Il vaut mieux recommencer. Le mieux -et c'est ce que font tous les joueurs maintenant- est de se trouver un binôme pour jouer ne serait ce qu'un tour par semaine.

j'ai pas compris. ou alors tu parles en GD ?

Non rien, j'avais oublié qu'avec un mappage on pouvait utiliser n'importe quel polygone.

Quel recul il faut avoir?
C'est justement après plusieurs expériences que je peut me permettre de dire ca.
J'ai tester les DIV et javascript et le GD.

J'ai un p4 2.4go avec carte graphique de 128mo. Heu il faut un biprocesseur pour que ca rame pas maintenant c'est vrai, IE est optimiser avec Direct X pour ce genre de chose, mais bon. Moi je prend le suport internet pour que les joueurs de tout les OS et tout browser puissent jouer, sinon je programme en c++ et direct x si c'est pour limiter les utilisateurs a un OS et un browser (pas de direct X sur Mac )

non, un image GD est de 20ko, si tu prend le code html envoyer au client, je pense que tu doit etre dans les 5 a 10ko (pour les divs ect...) donc ca ne change pas tant que ca.

il faut faire des choix, j'en ai fait aussi, et je pense avoir fait le meilleur pour SD, je ne critique pas ton choix, je donne juste mon avis.

Simple? Hum, tu doit pas avoir pousser tes expérience bien loin, si tu savais ce qu'on est capable d'en faire. Maintenant tu a raison sur beaucoup de point: pas fait pour ca (pas plus que les browser ), raffraississement fréquant (mais bon 20ko ca va quoi), pas d'animation (mais bon, on est sur le net aussi, il faut choisir. Pour moi l'animation est très secondaire dans un pbem). Aucune méthode n'est parfaite, il faut juste choisir le bon outils pour son application. ET optimiser son moteur le mieux possible.

qui te demande de faire la gamin? Je ne suis pas comme ca non plus, je me fou que mon moteur soit meileur que le tiens ou inversément. J'espère pour toi, que le moteur graphique de continent n'est pas ton seul atout pour faire un bon jeu, ca serais regretable se baser sur le jeu uniquement pour ses graphismes, non?
D'autant plus que tu te base sur SD, mais la carte de SD (et je le reconnais) et un très vieux script. La carte de SD est la version 1, j'en suis a la version 3 et je peut te dire qu'on peut en faire beaucoup plus que ce que tu a vu. Mais pour SD je n'ai pas besoin de plus, alors je la laisse comme ca (version 1).

Sinon pour le flash, tu sais qu'il existe des client flash, ca pourrais vous aider pour faire un moteur plus rapide (puisque l'ordinateur se connecte au serveur et le pc fait le reste).

Sinon ne te choque pas, j'aime bien le moteur de continent, je le trouve très bien, ma seul critique était sur la lourdeur de cette application ce qui au final, est normal car le web n'est pas fait pour ca.

Ce n'est souvent pas possible non plus. pour moi balader un goblin sur une carte ne represente pas le jeu. il aurais falus plus de chose a faire.
@+

ahh ok ! je pige mieux. Non moi je n'utilise pas de mappage pour détecter sur quel losange je suis, un petite formule mathématique par rapport aux coordonnées permet de le faire.

@khiguard : ok laisse tomber.