[Carte] 2D isométriques & innovation

[Holy]

Bonjour,

Je suis actuellement en train de faire quelques recherches pour un moteur graphique pour un petit projet et à force de bosser sur les cartes isométriques et d'en mater, je suis arrivé à quelques conclusions que j'aimerais partager avec vous :
1. La représentation traditionnelle des cartes isométriques à tuile carré donne une forme générale en losange. C'est pas top comme représentation du monde, mais ça fonctionne plutôt bien au niveau de la lecture.
2. Cette représentation, bien que respectant parfaitement les règles isométriques, laisse une partie de l'espace de la page vide (dans les coins, à fortiori) lorsqu'on ne "zoom" pas dans la carte : exemple sur le plugin de Prelude. On voit bien qu'il y a une parie de l'espace au-dehors des limites de la représentation qui n'est pas présentée, ça donne la sensation d'un monde fini.
3. Les coordonnées traditionnellement renseignées sur les cartes (non-isométriques comprises) rompent avec une lecture "naturelle" de la carte pour s'attacher à une lecture plus pragmatique et technique de celle-ci.

A partir de ces différents constats, j'ai tiré quelques conclusions.
1. En lieu et place des coordonnées (que je trouve trop peu immersifs), dans mon prochain jeu de stratégie en temps réel, j'aimerais utiliser un principe de lieu dit et de province. Ca permettrait de lier le background du jeu avec une pièce maîtresse du gameplay (le positionnement).
Exemple : la case [14;48] deviendrait "le nord d'Abyssie" (comme plusieurs des cases autour de celle-ci).
2. Idéalement, je trouve que le zoom sur la carte doit être suffisant pour qu'on ne perçoive pas les "limites" de la représentation de la carte. Voici le type de traitement que je trouve vraiment bien : Civ3
C'est sur que dans un navigateur ce type de représentations ne doit pas être simple à gérer mais je pense que ça serait vraiment intéressant.

Avez-vous d'autres réflexions à faire sur la 2D isométriques et plus largement sur les cartes de jeu en général ? Avez-vous des exemples de jeu web qui fonctionnent avec une carte isométrique ?

[Ter Rowan]

Ce n est pas parce que tu fais de la 2D iso que tu aboutis a un losange

C est parce que tu fais le choix d afficher une carte plus petite que l écran.

Il te suffit de créer un "losange" plus grand que la carte affichée, quitte a avoir certaines cases (celles des coins) affichées qu en partie

Pour la province, pourquoi pas, mais soit une province est juste un agrégat de cases et dans ce cas je pense qu il est préférable de laisser en plus les coordonnées pour le gp, soit les provinces remplacent complètement les cases et dans ce cas le concept de carte 2D iso n a plus sa place, on sera alors uniquement dans une représentation 2D iso, mais sans stockage de coordonnées, plus stockage de frontière

[Holy]

Pour la province, pourquoi pas, mais soit une province est juste un agrégat de cases et dans ce cas je pense qu il est préférable de laisser en plus les coordonnées pour le gp, soit les provinces remplacent complètement les cases et dans ce cas le concept de carte 2D iso n a plus sa place, on sera alors uniquement dans une représentation 2D iso, mais sans stockage de coordonnées, plus stockage de frontière

De toute façon je stocke forcément les coordonnées dans ma base de données, mais je ne les affiche pas à l'utilisateur. L'idée étant de se dire que, par exemple, dans un univers d'héroic fantasy médiéval, y a pas vraiment de raison que les joueurs s'expriment sur la carte comme si il parlait de leur GPS ^^

[Xenos]

Parler GPS peut parfois s'avérer utile. Dans ton contexte, peut-être pas, mais dans des contextes type simulation routière... ou militaire.... ou maritime (y'a pas de province nommée dans les eau internationales), c'est autre chose.
Pour l'histoire de la carte finie, tu peux utiliser un bouclage sphérique: lorsque t'arrive au bord droit, tu repars à gauche (donc, si t'as une unité à droite, elle sera dupliquée à gauche). En haut, quand tu sors, tu boucle sois en bas (bouclage planaire) soit 50% plus à gauche (ou à droite) tout en restant en haut (bouclage sphérique).
La carte est alors infinie sans avoir un nombre de cases infinies (cf la Terre: on peut marcher infiniement dans une direction donnée, mais sa surface est finie).
Les tuiles peuvent également être hexagonale (pavage régulier) ou simplement polygonales régulières (pavages semi réguliers), https://www.google.fr/search?hl=fr&q=pav...3%A9gulier

[Holy]

L'idée d'une terre sphérique et infinie est attirante mais elle implique une difficulté conceptuelle selon moi (qui peut être relevée sans trop de soucis) : une fois qu'on a créé son monde sphérique, il est définitivement fini. C'est une difficulté qui n'est pas insurmontable mais qui, quelque part, est une gageure au moment de lancer son jeu, elle "coince" quelque part le développement futur du jeu, même si c'est une super idée. Il faut d'ailleurs noter que pour certains types de jeu, le fait que la carte soit "finie" dés le départ du jeu est une condition sine qua non à l'existence du jeu (Risk par exemple).

Sinon, j'ai commencé un peu à bosser sur un prototype (n°1) : voici mes premiers travaux. J'ai fait pas mal de recherche sur le pavage et c'est assez difficile d'avoir des résultats intéressants et exploitables sans trop se casser la tête. J'ai choisi une solution simple au final : j'utilise une base hexagonale. Je vais commencer à développer une deuxième version du prototype qui comprend notamment les éléments area afin d'avoir une "grille" d'interaction avec les "cases".

[Holy]

Voilà j'ai continué à bosser sur mon prototype et je suis parvenu à établir une première couche basique d'interaction avec les cases de ma carte : http://terresdecy.herokuapp.com/ontheroad

Je me permets de soulever une nouvelle problématique : la navigation au sein d'une carte de jeu.

Actuellement, je n'ai encore trouvé aucune réelle bonne solution concernant la navigation sur les cartes. Evidemment, il y a pas mal de cartes différentes, donc les besoins de navigation sont différents. Par exemple, un jeu de rôle pourra se permettre de rester focaliser sur le héros là où un jeu de stratégie demandera une plus grande mobilité.

J'aimerais avoir votre avis sur la problématique suivante :
- Votre plateau de jeu est une carte de 120 sur 120.
- A l'écran, vous ne pouvez représenter que maximum une carte de 20 sur 20.

Dés lors comment gérer vous les transitions et la navigation ?
- Vous permettez au moteur de se déplacer d'une ligne à la fois ? (En gros je clique sur une flèche pour accéder à une nouvelle ligne : de 0 - 20 je passe à 1 - 21).
- Vous permettez au moteur de se déplacer de cinq lignes en cinq lignes ? (de 0 - 20 à 5 - 25 puis à 10 - 30, ...).
- Vous créez des zones de jeu qui constituent la base de la navigation : soit 36 zones de 20 cases sur 20 cases auxquelles on accède par une mini-carte. Le défaut de ce type de navigation est les lignes de frontières entre les zones où on a pas accès à l'information de la ligne suivante qui se trouve dans une autre zone. Le gros avantage est la navigabilité à grande échelle.
- Autre solution ?

[Xenos]

Les flèches, c'est lourd et peu pratique. A ne conserver que si l'utilisateur n'a pas de javascript.
Par paquets de lignes, c'est peu précis, et ca ne résoud pas le problème précédent si la distance à parcourir est grande
La 3e solution n'est pas top conviviale.

Je préfèrerai:
- Pour les mobiles & tactiles: clic & drag pour déplacer la carte, style googlemap. Intuitif, simple, répandu et efficace. Pas de rechargement complet de la page: un ajax sera plus aisé pour l'utilisateur et allègera le serveur (le serveur n'envoie que les données de la carte et des cases, c'est le client qui compile tout ca peut l'affichage)
- Pour les pc fixes: si la souris va en bord d'écran, on déplace la carte, de plus en plus vite (comme sur des jeux de stratégie/tactique classique tel supreme commadner ou AOE2)

La possibilité de zoomer/dézoomer avec la molette est également une bonne solution (le zoom se fait sur la position du curseur, le dézoom se fait sur le centre de l'écran ce qui permet, au final, de se "déplacer" facilement sur la carte en prenant un fort recul puis en zoomant sur la zone à voir).

Le système de mini-carte peut également être intéressant par-dessus: un clic sur la mini carte correspond à une position x;y sur cette mini-carte, il suffit de faire une proportionnalité pour trouver la case de la vraie carte qui correspond, et on fait sauter la vue sur cette case.

AJAX et de maniète plus générale, javascript+XML te permettront de faire transiter d'un coté, le XML (ou JSON) des données de la carte, et de l'autre, la page web, ce qui découplera les deux et facilitera le codage.

[Holy]

Concernant la mini-carte, je pense que c'est un outil indispensable et la solution du clic correspondant à une donnée de navigation est très simple à implémenter (j'avais déjà prévu un système de ce type).

Je préfèrerai:
- Pour les mobiles & tactiles: clic & drag pour déplacer la carte, style googlemap. Intuitif, simple, répandu et efficace. Pas de rechargement complet de la page: un ajax sera plus aisé pour l'utilisateur et allègera le serveur (le serveur n'envoie que les données de la carte et des cases, c'est le client qui compile tout ca peut l'affichage)
- Pour les pc fixes: si la souris va en bord d'écran, on déplace la carte, de plus en plus vite (comme sur des jeux de stratégie/tactique classique tel supreme commadner ou AOE2)

Ce sont deux solutions que j'aimerais expérimenter sur mon prototype mais qui rencontrent plusieurs difficultés selon moi :
- Pour le drag& drop, comment savoir quelle partie de la carte doit être chargée ?

- Pour le scroll progressif en fonction de la position du curseur (solution privilégiée jusqu'à présent), y a un soucis assez évident lié au temps de réponse des requêtes ajax, surtout si il y a accélération au plus on laisse sa souris au bord de l'écran. Tu récupères combien de lignes en plus par seconde par exemple ? Et si la requête met du temps à répondre ?

- Et pour les deux : Que fait-on des anciennes cases affichées (on les laisse dans notre dom ou on les sucre ?) ?

Les questions de performances du client sont très importantes, dit autrement 120 cases sur 120 cases ça représente 14400 cases, soit une charge totalement ingérable pour les navigateurs (déjà 20 cases sur 20 c'est parfois limite si y a encore d'autres éléments imbriqués).

Actuellement la solution qui me semble la plus intéressante en termes de performance et de navigabilité :
- Une mini-carte avec une aimantation de cinq en cinq (par exemple).
- Une carte qui permette de se décaler à chaque fois de cinq lignes (que ça soit via le drag&drop, via les flèches ou un scroll).

[Xenos]

Pour la D&D, on connait le point de départ et la position du curseur à la date T. On connait la taille de la carte en pixels et en case, on peut donc faire le ratio: la souris se déplace de x pixels, avec P pixels par case, donc on se déplace de x/P cases. On sait quelle est la case centrale de la carte au départ, on sait donc quelle sera la case centrale après déplacement.

Pour le déplacement par bord d'écran (ou par les flèches), il suffit de calculer la durée de la requète précédente, admettons, S secondes. On connait la vitesse maximale V de déplacement. ON sait donc qu'au plus, en moyenne, on se déplacera de V*S cases. On charge donc une carte qui contient S*V cases de plus à droite, gauche, haut et bas.
Si tu as bien conçu ta carte, tu peux faire un document xml léger avec de très nombreuses cases, récupéré par le javascript.

Les anciennes cases hors écran sont virées du DOM, mais pas du contenu des variables javascript On peut donc ainsi avoir une page web légère, mais si on revient sur les cases déjà vues, le javascript a conservé les données en cache.

120*120=14.400 oui, mais si c'est un simple tableau javascript, cela peut passer. De plus, qui te dit que sur ce carré de 120x120, toutes les cases ont été vues?
Enfin, si tu as peu de types de case, intéresse-toi aux octrees (dans la 2D, on appellera ca des quad-tree). L'idée est très simple:
On considère que la carte est un carré de 2^n par 2^n éléments. Par exemple, 128x128. Si, parmis tous ces éléments, 2 ne sont pas identiques du point de vue d'une donnée (par exemple, pas le même joueur qui possèdfe la case, ou pas le même type de sol, etc), alors on découpe ce carré (qu'on appellera le carré de niveau 0) en 4 sous-carrés (carrés de niveau 1) de 64x64 cases chacun. Et on recommence.

On obtient ainsi une structure arborescente qui regroupe les cases identiques (ce principe est utilisé aussi en compression d'image).
En 3D, ca donne ca



(je cite plutôt la 3D car c'est ce à quoi j'ai eu recours durant mon stage ingénieur de cet été).
Si la carte présente une forte répétition d'éléments, cela peut réduire la taille des données à transférer.
Enfin, je rappelle que ces données sont assez légères point de vue javascript, et donc, cela ne rame QUE parceque tu essaie d'AFFICHER 120x120 cases, pas parce que tu essaie de gérer 120x120 cases.

Rien ne t'empêche, sinon, de faire un fichier xml ou json coté serveur avec les données statiques ou quasi-statiques de toutes les cases de la carte, et de laisser le navigateur aller récupérer ce xml. Le navigateur devrait, normalement, mettre le document en cache assez rapidement, et donc, tu n'auras plus de gros transfert.

[Holy]

Rien ne t'empêche, sinon, de faire un fichier xml ou json coté serveur avec les données statiques ou quasi-statiques de toutes les cases de la carte, et de laisser le navigateur aller récupérer ce xml. Le navigateur devrait, normalement, mettre le document en cache assez rapidement, et donc, tu n'auras plus de gros transfert.

C'est une solution qui peut être très intéressante par rapport aux données statiques (typiquement : le décor de la carte). On pourrait avoir une évolution en temps réels reposant sur un Json en cache avec uniquement une actualisation des données dynamiques.
Mais... c'est une solution incompatible avec un brouillard de guerre totale où même le décor est caché (révélé qu'une fois que le joueur a découvert). A voir si le brouillard de guerre total vaut le fait de se priver d'un tel système.

Enfin, je rappelle que ces données sont assez légères point de vue javascript, et donc, cela ne rame QUE parceque tu essaie d'AFFICHER 120x120 cases, pas parce que tu essaie de gérer 120x120 cases.

A mais là-dessus je suis entièrement d'accord. Ce que je voulais dire c'est que pouvoir afficher de façon fluide 400 cases (20 x 20) nécessite de pouvoir gérer 14400 cases efficacement, donc à fortiori de pouvoir compter sur la solidité des requêtes ajax & de la gestion des events qui les lancent.

L'octree est super intéressant. Personnellement, sur un autre moteur purement 2D (non isométrique), j'ai utilisé un système de compression basé sur la redondance des infos sur les cases affichées. Couplé à un système très efficace de classes CSS et de sprites, ça me permettait de réduire de 90% les informations transférées lorsque celles-ci étaient explicites et dépliées : autrement dit, pas besoin de transférer "/images/herbe.png", mais uniquement "herbe". Mieux, si une seconde instance du mot "herbe" était transférée, je la convertissais en "a" par exemple. Pareil, si une ligne était vide, je renseignais simplement un tableau vide. Tout le "dépliage" était géré par le client. Ca fonctionnait du feu de dieu (je crois que c'est un des meilleurs taffs de programmation que j'ai fait jusqu'à présent).
Si j'ai l'occasion de le sortir de façon documentée, ça serait top ^^

Merci pour tes explications sur les events de navigation, ça m'éclaire assez bien. Je vais essayer de taffer ça dans les prochains jours pour voir ce que ça pourrait donner