Dual-Grid Tile System : la solution aux problèmes des TileMaps classiques

Vous développez un jeu 2D avec des TileMaps et, à un moment, ça coince : transitions moches, coins qui bavent, variantes à dessiner par dizaines… et l’autotiling qui est censé aider, mais qui vous donne surtout envie de tout refaire. Accrochez-vous, parce qu’on va voir ça ensemble : le Dual-Grid Tile System, c’est un principe simple (pas “simplet”, simple) qui change complètement la manière de penser vos tuiles.

L’idée, ce n’est pas d’ajouter une couche de magie noire. C’est plutôt de comprendre pourquoi les TileMaps “classiques” vous poussent dans une impasse, et comment une petite bascule de perspective peut rendre tout ça plus propre, plus stable, et franchement plus agréable à produire (artistiquement comme techniquement).

Le vrai problème des TileMaps classiques (et pourquoi ça finit souvent en galère)

Dans la plupart des moteurs, une TileMap “standard”, c’est une grille où :

• 1 case = 1 tuile
• la tuile affichée dépend des voisins autour (souvent les 8 voisins : haut, bas, gauche, droite + diagonales)

C’est le fameux modèle 3×3 : on regarde autour, et on choisit la bonne variante graphique.

Sur le papier, c’est logique. En pratique, c’est efficace… jusqu’au moment où vous voulez quelque chose d’un peu plus organique, un peu plus propre, un peu plus “naturel”.

1) L’explosion combinatoire (le piège classique)

Avec 8 voisins qui peuvent être “présent / absent”, vous obtenez 256 combinaisons théoriques. Évidemment, on regroupe, on simplifie, on utilise des patterns… mais même “optimisé”, un tileset propre demande souvent des dizaines de variantes (le chiffre de 47 revient très souvent dans les sets 3×3 minimaux corrects).

Résultat (et vous l’avez peut-être déjà vécu) :

• c’est méga long à dessiner
• c’est lourd à maintenir
• ça casse vite visuellement dès qu’un cas n’a pas été anticipé

2) Des transitions rigides (les coins “cassés”)

Le 3×3 a un côté “bloc” : les coins sont souvent anguleux, les bords font des marches d’escalier, et obtenir des formes arrondies demande soit :

• des sprites très spécifiques,
• soit des triches graphiques,
• soit d’accepter que “bon… c’est pas si grave”.

Sauf que si, parfois, c’est grave (genre quand tout votre jeu repose sur des terrains naturels).

3) Le couplage logique ↔ visuel (le point qui fait mal)

Et là, on touche le cœur du problème : dans une TileMap classique, la case logique et la case graphique sont la même chose.

C’est pratique, c’est intuitif… mais c’est aussi une contrainte énorme. Parce que vous forcez votre représentation visuelle à épouser exactement la structure logique de votre monde. Et vous vous demandez peut-être : “OK, mais on fait comment autrement ?” Justement.

Le changement de perspective clé : séparer ce qui existe de ce qui s’affiche

Le Dual-Grid part d’une idée qui paraît presque “contre-nature” au début :

Et si la grille logique et la grille visuelle n’étaient pas la même chose ?

Dit autrement (et c’est là que ça devient intéressant) :

• la grille logique, c’est ce qui existe dans le monde (sol, mur, eau, vide…)
• la grille visuelle, c’est comment on le montre à l’écran (bords, coins, transitions, arrondis…)

C’est un découplage. Et ce découplage, c’est tout le système.

Le Dual-Grid Tile System : le principe (version claire, sans jargon inutile)

Ce système a été popularisé notamment par Oskar Stålberg (Townscaper), et on le retrouve sous plusieurs noms : dual grid, corner-based tiling, ou encore bitmask 2×2.

Le concept central, c’est celui-ci :

• au lieu de décider l’apparence d’une tuile à partir des 8 voisins (3×3),
• on observe des blocs de 2×2 cellules logiques,
• et on dessine une tuile au centre de ce bloc (sur une grille visuelle décalée).

Pourquoi 2×2, c’est un gros deal ?

Parce qu’un bloc 2×2, c’est 4 coins. Chaque coin est soit rempli, soit vide. Donc :

• 4 bits (0/1)
• 2⁴ = 16 configurations possibles

Et 16, c’est… raisonnable. C’est même “top”, parce que ça veut dire que votre tileset de transitions peut tenir en 15 ou 16 tuiles (selon si vous gardez ou non le cas “tout vide”).

Deux grilles, deux rôles (et ça devient tout de suite plus net)

On va poser les choses simplement.

La grille logique (celle qui “compte”)

C’est votre monde, votre gameplay :

• sol / vide
• mur / pas mur
• eau / pas eau
  Bref : du binaire (ou du catégoriel si vous avez plusieurs types).

Elle peut être invisible à l’écran (et souvent, c’est mieux). Elle est là pour être stable, simple, facile à modifier.

La grille visuelle (celle qui “dessine”)

Elle est décalée d’une demi-tuile. Et chaque tuile visuelle correspond à un carré formé par 4 cellules logiques.

C’est un truc important à visualiser : la tuile affichée n’est plus “dans” la cellule logique, elle est entre les cellules logiques (au centre du bloc 2×2).

Et là, tout s’aligne :

• les coins et bords deviennent naturels,
• les transitions sont cohérentes,
• et surtout : vous n’avez plus besoin de regarder à 3 cases de distance pour savoir quoi afficher.

Pourquoi ça réduit drastiquement le nombre de tuiles (et pourquoi c’est plus stable)

Comparons, vite et bien.

En 3×3 (autotiling classique)

• dépendance à 8 voisins
• beaucoup de cas “presque identiques” mais pas tout à fait
• diagonales qui créent des ambiguïtés
• besoin de variantes nombreuses pour éviter les artefacts

En 2×2 (Dual-Grid)

• seulement 4 entrées (les 4 coins)
• 16 cas, point
• chaque cas correspond à une forme claire (un coin, un bord, un plein, une diagonale, etc.)
• moins d’ambiguïtés, donc moins de bugs visuels

C’est mathématiquement plus “propre”. Et artistiquement, c’est un bonheur : vous dessinez un set compact, mais qui couvre vraiment les transitions.

Un exemple mental simple (pour que ça clique)

Imaginez un terrain “herbe” sur fond “vide”.

Chaque cellule logique est :

• herbe (1)
• vide (0)

Maintenant, vous prenez un bloc 2×2 de cellules logiques. Vous regardez les 4 coins. Vous obtenez une combinaison :

• 0000 : rien (souvent vous n’affichez rien)
• 1000 : un coin
• 1100 : un bord
• 1010 : une diagonale (cas particulier, mais gérable)
• 1110 : trois coins
• 1111 : plein

Chaque combinaison renvoie vers une tuile graphique unique. Et vous n’avez pas besoin de “scanner” tout le voisinage : ce carré 2×2 suffit.

C’est ça, le côté “pas de magie, juste de la géométrie”.

Comment l’implémenter conceptuellement (ex : dans Godot)

Vous vous demandez peut-être : “OK, mais Godot ne le propose pas nativement, donc je fais comment ?” Bonne nouvelle : ce n’est pas natif, mais c’est très implémentable.

L’organisation typique, c’est :

• TileMap logique : contient les cellules gameplay (sol/vide, etc.)
• TileMap visuelle : contient les tuiles de rendu (bords, coins, transitions)
• un script qui réagit aux changements de la grille logique et met à jour la grille visuelle localement (pas besoin de recalculer toute la map à chaque fois, heureusement)

La boucle algorithmique (simple et efficace)

1. Le joueur place/enlève une cellule logique (ex : herbe)
2. Vous identifiez les blocs 2×2 impactés autour de cette cellule
   (en pratique, une modification affecte quelques blocs voisins, pas toute la carte)
3. Pour chaque bloc 2×2, vous calculez un index binaire sur 4 bits
4. Vous placez la tuile visuelle correspondant à cet index dans la TileMap visuelle

Et voilà. C’est “juste” un mapping : (4 bits) -> (tile id).

Petit aparté utile : selon votre convention, vous choisirez l’ordre des bits (haut-gauche, haut-droite, bas-gauche, bas-droite, etc.). L’important, ce n’est pas l’ordre, c’est d’être cohérent partout.

Ressources et outils (sans vous noyer)

Si vous voulez aller plus loin sans réinventer la roue :

• Il existe des discussions côté Godot (issues, propositions, exemples) qui montrent que le besoin est réel.
• Vous trouverez aussi des dépôts qui implémentent un Dual-Grid en Godot (souvent sous des noms du style dual-grid-tilemap-system), pratiques à disséquer pour voir comment les blocs 2×2 sont recalculés localement.
• Pour générer des tilesets, certains outils permettent de produire des variantes adaptées au 2×2 (utile pour prototyper vite, avant de dessiner votre set final).

L’idée, ce n’est pas de dépendre d’un outil. C’est de gagner du temps pendant l’exploration (parce que dessiner 40 sprites “juste pour tester”, c’est non).

Quand le Dual-Grid est un excellent choix (et quand il l’est moins)

On ne va pas se mentir : ce n’est pas une solution universelle. C’est un outil précis.

Très adapté si vous faites…

• des terrains organiques (nature, biomes, sols, boue, neige…)
• du top-down (RPG, roguelite, aventure)
• des city builders / jeux de construction (où les transitions propres font toute la différence)
• des jeux stylisés/narratifs où l’esthétique des bords et coins compte beaucoup

Moins adapté si vous faites…

• de la plateforme ultra stricte “pixel perfect” où la logique de collision colle exactement au visuel (ça peut se faire, mais c’est souvent moins naturel)
• des puzzles à géométrie rigide où chaque cellule doit être exactement une tuile affichée
• des environnements volontairement orthogonaux sans transitions (dans ce cas, l’intérêt est plus limité)

En gros : si votre jeu a besoin de transitions fluides et propres, le Dual-Grid est souvent un très gros gain. Si votre jeu est un damier strict, c’est peut-être overkill.

Pourquoi ce n’est pas intégré par défaut dans Godot (et pourquoi c’est logique)

Trois raisons reviennent souvent :

• c’est conceptuellement moins évident pour les débutants (“deux grilles ? pourquoi ?”)
• ça casse le modèle historique “1 cellule = 1 tuile”
• il existe plusieurs variantes (selon la gestion des diagonales, des matériaux multiples, des priorités, etc.)

Godot préfère fournir des bases flexibles plutôt qu’un seul modèle “officiel”. Donc le Dual-Grid, c’est laissé aux développeurs… ce qui est frustrant au début, mais plutôt cohérent quand on y pense.

Ce qu’il faut retenir (et votre prochaine étape)

Le Dual-Grid Tile System, ce n’est pas une astuce. C’est un changement de modèle mental : séparer la logique du monde de sa représentation.

En échange, vous gagnez :

• beaucoup moins de tuiles à produire (souvent ~16 pour un set de transitions)
• des coins et bords plus propres
• une logique plus stable (moins d’ambiguïtés)
• un contrôle artistique supérieur (vous dessinez des formes claires, pas des cas “bizarres”)

Et une fois que ça clique, oui : revenir au 3×3 “pur” peut sembler… pas si agréable.

Si vous voulez continuer l’aventure, les prochaines étapes naturelles, c’est :

• décortiquer une implémentation concrète (ligne par ligne, tranquillement)
• concevoir un tileset minimal Dual-Grid (propre et réutilisable)
• comparer Dual-Grid vs 3×3 vs Wang Tiles sur un même terrain
• étendre le système à plusieurs biomes (avec règles de priorité et mélanges)

Voilà : le terrain est posé. À vous de voir si vous avez envie de marcher sur ce chemin (spoiler : il est souvent plus simple qu’il n’en a l’air).