Un plateau est chose simple : 256 tuiles, chacune munie de quatre arêtes
colorées, chacune posée à une case avec une rotation. Mais la communauté l'a
couché sur le papier d'une douzaine de manières en dix-neuf ans, et ces manières
ne coïncident jamais tout à fait. Une chaîne de lettres, une chaîne de chiffres,
une URL, un CSV, un JSON. Ils disent la même chose dans des alphabets
différents, et à l'instant où l'on déplace un plateau d'un outil à l'autre, on
bute sur la couture.
Cette page, c'est la couture, couchée sur le papier : tous les formats sous
lesquels un plateau ou un puzzle circule ici, avec les règles au niveau de
l'octet, y compris le seul détail qui mord tout le monde, la façon dont chaque
format encode la bordure grise, et, pour chacun, une note claire sur ce qu'il
sait et ne sait pas restituer. Si vous ne retenez qu'une chose : collez
n'importe quel plateau dans le convertisseur de formats et relisez
directement les autres.
Une entrée, une sortie
Le contrat IO est symétrique et réduit. Entrée : une instance de puzzle en
JSON (le schéma Puzzle du site, ci-dessous) ; chaque algorithme est invoqué
avec --puzzle <file>.json. Sortie : un document de plateau en JSON (le
BoardDoc, ci-dessous), portant en champ une URL eternity2.dev
prête à ouvrir. C'est tout : puzzle-JSON en entrée, plateau-JSON en sortie, deux
fichiers uniques et autodescriptifs. Tout le reste de cette page est soit une
entrée historique que les outils acceptent encore (CSV, board_edges nu),
soit un format dérivé que le convertisseur sait vous fournir. Il
n'y a plus de séparation .url-ici, .json-là, deux-fichiers-parfois.
Une couleur est un petit entier. 0 est la bordure grise extérieure ; les
couleurs intérieures vont de 1..=22 pour le puzzle officiel (22 est exactement
le nombre de motifs existants). Un quadruplet d'arêtes est l'ensemble des
quatre couleurs d'une case dans l'ordre URDL (haut, droite, bas, gauche), en
lisant la tuile telle que posée et tournée, et non comme une tuile de
catalogue. Une case est soit remplie (un quadruplet réel), soit vide ; une case
vide s'écrit comme si elle était toute en bordure, [0, 0, 0, 0].
Un fait découle de « telle que posée », et il est la source de la plupart des
confusions entre formats : un plateau porte des arêtes tournées, pas un
numéro de rotation. Mais ce n'est pas une perte. Les pièces d'Eternity II sont
toutes distinctes à rotation près (le jeu officiel l'est, et tout générateur
fidèle le maintient), donc le quadruplet d'arêtes d'une case identifie une seule
pièce, et la rotation est le tour qui amène le quadruplet de catalogue de cette
pièce sur celui qui est posé. Apparier le quadruplet au jeu restitue les
deux : l'identité et la rotation.
Ainsi les arêtes sont le plateau tout entier : elles le rendent, le scorent, et
nomment chaque pièce et son orientation. Le seul cas où elles échouent est un jeu
artificiel où deux pièces partagent un motif d'arêtes à rotation près, ce que le
vrai Eternity II n'a jamais, et là un canal numéro-de-pièce désambiguïse. C'est
l'unique raison d'être de board_pieces.
La lingua franca. Quatre lettres minuscules par case, ligne par ligne, en URDL,
avec letter = 'a' + colour. La bordure est donc a, la couleur
intérieure 1 est b, jusqu'à la couleur 22 = w. Une case vide est aaaa,
indistinguable d'une vraie tuile toute en bordure, ce qui n'arrive jamais sur un
plateau légal ; l'ambiguïté est donc sans danger. Le plateau officiel 16×16 fait
256 × 4 = 1024 lettres.
adca beaa … cell 0 = [0,3,2,0], cell 1 = [1,4,0,0], …
- Bordure : la lettre
a (couleur 0).
- Restitue : tout du plateau, le rendu complet, le score exact, et, parce que
les pièces sont distinctes à rotation près, l'identité de chaque pièce et sa
rotation par appariement au jeu.
- Ne restitue pas : quelles cases étaient données comme indices plutôt que
résolues ; c'est une propriété du puzzle, pas du plateau, et cela voyage dans
hints.
Une subtilité rare : certains outils permutent le glyphe que chaque lettre
dessine (motifs_order). Les ordres marie et jblackwood sont identiques
entre eux ; jef est une permutation différente. Le convertisseur et le
visualiseur les retraduisent vers l'alphabet par défaut à l'entrée, si bien que
vous n'avez jamais à y penser ; mais si vous voyez un plateau dont les couleurs
semblent brouillées, c'est un motifs_order non traduit qui en est la cause.
Un plateau et les indices dont il est issu ont leur place au même endroit,
adressés de la même façon. hints liste les cases-indices épinglées, chacune
sous la forme pos.rot, l'indice de case en ordre ligne par ligne et le
quart de tour horaire, joints par -. Cinq indices officiels font environ
trente caractères.
hints=34.1-45.2-135.0-210.3-221.0
La pièce de chaque case-indice est déjà connue par board_edges, donc un indice
n'a besoin que de sa position et de son orientation, jamais d'un identifiant de
pièce. C'est la même forme (case, rotation) que tout format durable emploie
pour une pièce épinglée : le x,y,rotation du CSV, le {pos, rot} du JSON du
site.
- Restitue : quelles cases sont des indices, pour que le visualiseur les
marque et qu'un solveur en parte. Absent signifie « aucun indice », un simple
plateau résolu ou partiel.
- Se marie avec :
board_edges. Ensemble ils portent un
puzzle-avec-indices entier dans un seul lien, ce qu'un plateau nu ne
pourrait jamais.
Certains outils de la communauté, notamment les liens e2.bucas.name, portent un
canal de pièces explicite : trois chiffres décimaux par case, le numéro de pièce
en base 1, 000 pour une case vide (le plateau officiel fait
256 × 3 = 768 chiffres). Nous le lisons quand il est présent, mais n'avons
jamais besoin de l'émettre, car board_edges nomme déjà chaque pièce sur un jeu
aux pièces distinctes.
001 005 007 … piece 1 at cell 0, piece 5 at cell 1, …
- Bordure / vide :
000.
- Restitue : l'identité de pièce directement (et la rotation, par appariement
au jeu), la même chose que les arêtes restituent seules pour un vrai plateau.
- À lui seul : inutile sans les arêtes ; c'est une surcouche, pas un plateau.
Son seul usage irremplaçable est un jeu artificiel dont des pièces se répètent
à rotation près, où les arêtes seules sont ambiguës.
Le plus ancien format d'échange, couché sur le papier par la communauté en 2007
(voir le recensement de la boîte à outils). Une ligne
par case remplie, dans l'ordre de lecture, quatre entiers d'arête séparés par
des blancs dans l'ordre URDL.
0 3 2 0
1 4 0 0
…
- Bordure : l'entier
0.
- Restitue : rendu et score, comme
board_edges ; ce sont les mêmes données
en décimal. Il liste les pièces telles que posées et tournées, ce n'est
donc pas un catalogue canonique à rotation 0, et un plateau seul ne peut pas
l'y ramener.
Le format que consomment le C de McGavin et le C# de Blackwood, et la forme sous
laquelle sont écrits les fichiers variant_NN.csv du banc d'essai. Un en-tête de
taille, puis une ligne par pièce : top,right,bottom,left, suivi
optionnellement de x,y,rotation pour un indice épinglé.
16
1111111111111111,0000000000000001,0000000000000010,1111111111111111,0,0,0
…
Chaque couleur est un mot binaire 16 bits complété par des zéros. Et voici le
détail qui fait trébucher tout le monde, et la raison d'être de cette page :
Dans le CSV, la bordure est tout en un
Dans le CSV de puzzle, la bordure grise est 1111111111111111, tout en un,
le mot 16 bits 65535, et non tout en zéros. Les couleurs intérieures sont
leur petit entier en binaire, donc la couleur 1 est 0000000000000001. Un
lecteur remappe le mot 65535 vers l'identifiant intérieur 0. C'est
l'inverse de tous les autres formats de cette page, où la bordure est la valeur
basse (a, 0, 000). C'est un choix de sentinelle historique, conservé
pour la compatibilité au niveau de l'octet avec les moteurs qui le lisent.
- Bordure : le mot tout-en-un
1111111111111111 (65535).
- Restitue : le puzzle complet, pièces et indices. C'est un format de
puzzle (le jeu de tuiles), non un simple plateau posé.
L'unique format dont chaque algorithme est nourri : --puzzle variant_NN.json.
Le moteur du site, les études DFS/repair et le banc d'essai monocœur lisent tous
le même schéma (compatible au niveau de l'octet avec le type Puzzle du web),
de sorte que toutes les expériences tournent sur les mêmes instances. Il porte
explicitement le jeu de pièces à rotation 0 et les indices épinglés, ce qui en
fait une entrée depuis laquelle un solveur peut démarrer, plutôt qu'un plateau
qu'il aurait déjà rempli.
{
"name": "e2_official_variant00_pin3corners",
"width": 16, "height": 16, "numColors": 22,
"pieces": [[0,1,2,0], [0,0,3,1], …],
"hints": [{ "pos": 34, "piece": 118, "rot": 2 }, …]
}
- Bordure : la couleur
0, comme entier dans les quadruplets pieces.
- Restitue : tout ce qui concerne l'instance : les tuiles canoniques à
rotation 0, le nombre de couleurs, et chaque indice épinglé avec sa rotation
exacte. C'est le seul format qui porte la rotation et l'ordre de catalogue par
construction, parce qu'il décrit le puzzle, et non un placement sur celui-ci.
Ce que chaque solveur du site écrit désormais : un .json autodescriptif par
plateau. Il replie le plateau, son score, son empreinte de contenu, les deux
chaînes de lettres et l'URL du visualiseur en un seul document, si bien qu'un
outil en aval n'a besoin de rien d'autre.
{
"name": "…",
"size": 16,
"score": 466,
"breaks": 14,
"board": [3, 16, 24, …],
"board_hash": 2059303548241384230,
"board_edges": "abda…",
"board_pieces": "001005…",
"url": "https://eternity2.dev/viewer?puzzle=…&puzzle_size=16&board_edges=…"
}
board est le vecteur de placement piece*4 + rot en ordre ligne par ligne
(-1 pour une case vide), le même encodage par lequel le Puzzle du site fait
son aller-retour. breaks vaut max_score − score (les arêtes intérieures non
appariées ; sur un plateau plein, le nombre de cassures). board_hash est une
empreinte FNV-1a de la grille de placement, le verrou bit-à-bit qui répond à
« ces deux exécutions ont-elles produit le même plateau ».
- Bordure : comme dans
board_edges (a) et board_pieces (000) ; le
vecteur board utilise -1 pour le vide.
- Restitue : tout ce qu'un plateau peut porter : rendu, score, identité et
rotation (via
board_pieces et board), plus la provenance (name,
board_hash) et une vue en un clic (url).
Deux URL, même plateau, deux hôtes.
eternity2.dev, le lien canonique. Le format qu'émet chaque algorithme ici.
Le plateau voyage entièrement dans board_edges ; les indices épinglés voyagent
dans hints. Plateaux carrés, donc un unique puzzle_size (le visualiseur lit
aussi les board_w/board_h de bucas), et chaque valeur reste dans la plage
URL-compatible, de sorte que le lien n'a besoin d'aucun encodage-pourcent :
https://eternity2.dev/viewer?puzzle=NAME&puzzle_size=16&board_edges=…&hints=135.0-210.1
hints est omis pour un plateau sans indices. Comme les arêtes portent
l'identité des pièces, il n'y a pas de canal de pièces ici : le plateau et ses
indices tiennent dans ces deux champs.
e2.bucas.name, le visualiseur communautaire. L'original de Jef Bucas, le
visualiseur dont le format d'URL est devenu tout ce vocabulaire (la
boîte à outils raconte cette histoire). Pleinement
pris en charge en entrée, et disponible en sortie dérivée avec sa paire
board_w/board_h et un fragment #. Nous l'émettons en arêtes seules (bucas
retrouve les pièces à partir des arêtes pour un jeu distinct) ; les liens bucas
d'autres outils portent souvent aussi un canal board_pieces, que nous lisons en
entrée :
https://e2.bucas.name/#puzzle=NAME&board_w=16&board_h=16&board_edges=…
Le visualiseur lit l'un comme l'autre de façon transparente ; le
convertisseur vous fournit les deux. La forme eternity2.dev est
canonique ici uniquement parce qu'elle ouvre le visualiseur de ce site, avec
son scoring, sa surcouche d'indices et sa vérification du jeu de pièces ; la
forme bucas reste l'original partagé de la communauté, crédité en conséquence.
| Format | Bordure | Porte la rotation ? | Porte l'identité ? | C'est un… |
|---|
board_edges | a | oui (par appariement) | oui (par appariement) | plateau posé |
hints | n/a | oui (pos.rot) | via les arêtes | jeu d'indices |
board_pieces | 000 | avec les arêtes | oui | surcouche |
e2pieces.txt | 0 | oui (par appariement) | oui (par appariement) | plateau posé |
| Puzzle CSV | 1111…1 (tout en un) | indices seulement | oui (tuiles) | puzzle |
| JSON du site | 0 | oui | oui | puzzle |
JSON BoardDoc | a / 000 / -1 | oui | oui | plateau posé |
| URL eternity2.dev | a | oui (par appariement) | oui (par appariement) | lien vers un plateau |
| URL bucas | a | avec les pièces | avec les pièces | lien vers un plateau |
Chaque conversion de ce tableau est à un collage de distance dans le
convertisseur de formats : déposez-y une URL, une chaîne
board_edges nue ou un bloc de paramètres, et relisez l'URL eternity2.dev, le
JSON canonique, le CSV, board_pieces, e2pieces.txt et l'URL bucas, avec un
aperçu en direct et le score, pour voir que le fichier est correct avant de vous
y fier.