Un tablero es algo simple: 256 piezas, cada una con cuatro aristas coloreadas,
cada una colocada en una celda con una rotación. Pero la comunidad lo ha puesto
por escrito de una docena de maneras a lo largo de diecinueve años, y esas
maneras nunca coinciden del todo. Una cadena de letras, una cadena de dígitos,
una URL, un CSV, un JSON. Dicen lo mismo en alfabetos distintos, y en el momento
en que mueves un tablero de una herramienta a otra tropiezas con la costura.
Esta página es la costura, puesta por escrito: todos los formatos en los que un
tablero o un puzzle circula aquí, con las reglas a nivel de byte, incluido el
único detalle que muerde a todo el mundo, cómo codifica cada formato el borde
gris, y, para cada uno, una nota clara sobre qué puede y qué no puede
recuperar. Si solo te llevas una cosa: pega cualquier tablero en el
conversor de formatos y lee los demás directamente.
Una entrada, una salida
El contrato IO es simétrico y reducido. Entrada: una instancia de puzzle en
JSON (el esquema Puzzle del sitio, abajo); cada algoritmo se invoca con
--puzzle <file>.json. Salida: un documento de tablero en JSON (el
BoardDoc, abajo), que lleva como campo una URL eternity2.dev lista
para abrir. Eso es todo: puzzle-JSON de entrada, tablero-JSON de salida, ambos
archivos únicos y autodescriptivos. Todo lo demás en esta página es o bien una
entrada heredada que las herramientas siguen aceptando (CSV, board_edges
pelado), o bien un formato derivado que el conversor sabe darte.
Ya no hay una separación .url-aquí, .json-allá, dos-archivos-a-veces.
Un color es un entero pequeño. 0 es el borde gris exterior; los colores
interiores van de 1..=22 para el puzzle oficial (22 es exactamente cuántos
motivos existen). Un cuádruple de aristas es el conjunto de los cuatro
colores de una celda en orden URDL (arriba, derecha, abajo, izquierda),
leyendo la pieza tal como está colocada y rotada, no como una pieza de
catálogo. Una celda está o bien llena (un cuádruple real) o bien vacía; una
celda vacía se escribe como si fuera toda borde, [0, 0, 0, 0].
Un hecho se deriva de «tal como está colocada», y es la fuente de la mayor parte
de la confusión entre formatos: un tablero lleva aristas rotadas, no un
número de rotación. Pero no es una pérdida. Las piezas de Eternity II son
todas distintas salvo rotación (el conjunto oficial lo es, y cualquier
generador fiel lo mantiene), así que el cuádruple de aristas de una celda
identifica exactamente una pieza, y la rotación es el giro que lleva el cuádruple
de catálogo de esa pieza sobre el colocado. Aparear el cuádruple contra el
conjunto recupera ambos: la identidad y la rotación.
Así que las aristas son el tablero entero: lo renderizan, lo puntúan y nombran
cada pieza y su orientación. El único caso en que se quedan cortas es un conjunto
artificial con dos piezas que comparten un patrón de aristas salvo rotación, algo
que el Eternity II real nunca tiene, y ahí un canal de número de pieza
desambigua. Esa es la única razón de ser de board_pieces.
La lingua franca. Cuatro letras minúsculas por celda, fila por fila, URDL, con
letter = 'a' + colour. Así el borde es a, el color interior 1 es b,
hasta el color 22 = w. Una celda vacía es aaaa, indistinguible de una
pieza real toda borde, lo cual nunca ocurre en un tablero legal, de modo que la
ambigüedad es inofensiva. El tablero oficial 16×16 tiene 256 × 4 = 1024
letras.
adca beaa … cell 0 = [0,3,2,0], cell 1 = [1,4,0,0], …
- Borde: la letra
a (color 0).
- Recupera: todo del tablero, el renderizado completo, la puntuación exacta
y, como las piezas son distintas salvo rotación, la identidad de cada pieza y
su rotación por apareo contra el conjunto.
- No puede recuperar: qué celdas se dieron como pistas en vez de resolverse;
eso es una propiedad del puzzle, no del tablero, y viaja en
hints.
Un matiz poco frecuente: algunas herramientas permutan qué glifo dibuja cada
letra (motifs_order). Los órdenes marie y jblackwood son idénticos entre
sí; jef es una permutación distinta. El conversor y el visor los retraducen al
alfabeto por defecto a la entrada, así que nunca tienes que pensar en ello; pero
si ves un tablero cuyos colores parecen revueltos, un motifs_order sin traducir
es la causa.
Un tablero y las pistas de las que surge tienen su lugar en el mismo sitio,
direccionadas de la misma forma. hints lista las celdas-pista fijadas, cada una
como pos.rot, el índice de celda en orden fila por fila y el cuarto de vuelta
horario, unidas por -. Cinco pistas oficiales ocupan unos treinta caracteres.
hints=34.1-45.2-135.0-210.3-221.0
La pieza de cada celda-pista ya se conoce por board_edges, así que una pista
solo necesita su posición y su orientación, nunca un identificador de pieza. Es
la misma forma (celda, rotación) que emplea todo formato duradero para una
pieza fijada: el x,y,rotación del CSV, el {pos, rot} del JSON del sitio.
- Recupera: qué celdas son pistas, para que el visor las marque y un
solucionador parta de ellas. Ausente significa «sin pistas», un tablero
resuelto o parcial normal.
- Se combina con:
board_edges. Juntos llevan un puzzle-con-pistas entero
en un solo enlace, algo que un tablero desnudo nunca podría.
Algunas herramientas de la comunidad, en particular los enlaces e2.bucas.name,
llevan un canal de piezas explícito: tres dígitos decimales por celda, el número
de pieza en base 1, 000 para una celda vacía (el tablero oficial tiene
256 × 3 = 768 dígitos). Lo leemos cuando está presente, pero nunca
necesitamos emitirlo, porque board_edges ya nombra cada pieza en un conjunto de
piezas distintas.
001 005 007 … piece 1 at cell 0, piece 5 at cell 1, …
- Borde / vacío:
000.
- Recupera: la identidad de pieza directamente (y la rotación, apareada
contra el conjunto), lo mismo que las aristas recuperan por sí solas en un
tablero real.
- Por sí solo: inútil sin las aristas; es una capa superpuesta, no un tablero.
Su único uso irremplazable es un conjunto artificial con piezas que se repiten
salvo rotación, donde las aristas solas son ambiguas.
El formato de intercambio más antiguo, puesto por escrito por la comunidad en
2007 (ver el censo de la caja de herramientas). Una
línea por celda llena, en orden de lectura, cuatro enteros de arista
separados por espacios en orden URDL.
0 3 2 0
1 4 0 0
…
- Borde: el entero
0.
- Recupera: renderizado y puntuación, igual que
board_edges; son los mismos
datos en decimal. Lista las piezas tal como están colocadas y rotadas, así
que no es un catálogo canónico a rotación 0, y un tablero solo no puede
devolverlo a ese estado.
El formato que consumen el C de McGavin y el C# de Blackwood, y la forma en que
se escriben los archivos variant_NN.csv del banco de pruebas. Una cabecera de
tamaño, luego una fila por pieza: top,right,bottom,left seguido opcionalmente
de x,y,rotation para una pista fijada.
16
1111111111111111,0000000000000001,0000000000000010,1111111111111111,0,0,0
…
Cada color es una palabra binaria de 16 bits rellenada con ceros. Y aquí
está el detalle que hace tropezar a todo el mundo, y la razón de ser de esta
página:
En el CSV, el borde es todo unos
En el CSV de puzzle, el borde gris es 1111111111111111, todo unos, la
palabra de 16 bits 65535, y no todo ceros. Los colores interiores son su
entero pequeño en binario, así que el color 1 es 0000000000000001. Un lector
remapea la palabra 65535 de vuelta al id interior 0. Esto es lo contrario de
todos los demás formatos de esta página, donde el borde es el valor bajo (a,
0, 000). Es una elección de centinela heredada, conservada por compatibilidad
a nivel de byte con los motores que lo leen.
- Borde: la palabra todo unos
1111111111111111 (65535).
- Recupera: el puzzle completo, piezas y pistas. Es un formato de puzzle
(el conjunto de piezas), no solo un tablero colocado.
El único formato con el que se alimenta cada algoritmo: --puzzle variant_NN.json. El motor del sitio, los estudios DFS/repair y el banco de
pruebas monocore leen todos el mismo esquema (compatible a nivel de byte con el
tipo Puzzle del web), de modo que cada experimento corre sobre las mismas
instancias. Lleva el conjunto de piezas a rotación 0 y las pistas fijadas de
forma explícita, que es lo que lo convierte en una entrada desde la que un
solucionador puede arrancar, en lugar de un tablero que ya ha rellenado.
{
"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 }, …]
}
- Borde: el color
0, como entero en los cuádruples de pieces.
- Recupera: todo lo que concierne a la instancia: las piezas canónicas a
rotación 0, el número de colores, y cada pista fijada con su rotación exacta.
Es el único formato que lleva la rotación y el orden de catálogo por
construcción, porque describe el puzzle, no una colocación sobre él.
Lo que cada solucionador de este sitio escribe ahora: un .json autodescriptivo
por tablero. Pliega el tablero, su puntuación, su hash de contenido, ambas
cadenas de letras y la URL del visor en un único documento, de modo que una
herramienta aguas abajo no necesita nada más.
{
"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 es el vector de colocación piece*4 + rot en orden fila por fila
(-1 para una celda vacía), la misma codificación por la que el Puzzle del
sitio hace su ida y vuelta. breaks vale max_score − score (las aristas
interiores no apareadas; en un tablero lleno, el número de roturas). board_hash
es un hash FNV-1a de la rejilla de colocación, el cerrojo bit a bit que responde
a «¿produjeron estas dos ejecuciones el mismo tablero?».
- Borde: como en
board_edges (a) y board_pieces (000); el vector
board usa -1 para el vacío.
- Recupera: todo lo que un tablero puede llevar: renderizado, puntuación,
identidad y rotación (vía
board_pieces y board), además de la procedencia
(name, board_hash) y una vista en un clic (url).
Dos URL, mismo tablero, dos anfitriones.
eternity2.dev, el enlace canónico. El formato que emite cada algoritmo aquí.
El tablero viaja entero en board_edges; cualquier pista fijada viaja en
hints. Tableros cuadrados, así que un único puzzle_size (el visor también lee
los board_w/board_h de bucas), y cada valor permanece en el rango URL-seguro,
de modo que el enlace no necesita ningún encodeo por porcentaje:
https://eternity2.dev/viewer?puzzle=NAME&puzzle_size=16&board_edges=…&hints=135.0-210.1
hints se omite en un tablero sin pistas. Como las aristas llevan la identidad
de las piezas, aquí no hay canal de piezas: el tablero y sus pistas caben en
estos dos campos.
e2.bucas.name, el visor comunitario. El original de Jef Bucas, el visor cuyo
formato de URL se convirtió en todo este vocabulario (la
caja de herramientas cuenta esa historia). Plenamente
soportado como entrada, y disponible como salida derivada usando su par
board_w/board_h y un fragmento #. Lo emitimos solo con aristas (bucas
recupera las piezas a partir de las aristas para un conjunto distinto); los
enlaces bucas de otras herramientas suelen llevar además un canal board_pieces,
que leemos en la entrada:
https://e2.bucas.name/#puzzle=NAME&board_w=16&board_h=16&board_edges=…
El visor lee cualquiera de los dos de forma transparente; el
conversor te da ambos. La forma eternity2.dev es canónica aquí solo
porque abre el visor de este sitio, con su puntuación, su capa de pistas y su
verificación del conjunto de piezas; la forma bucas sigue siendo el original
compartido de la comunidad, acreditado en consecuencia.
| Formato | Borde | ¿Lleva rotación? | ¿Lleva identidad? | Es un… |
|---|
board_edges | a | sí (por apareo) | sí (por apareo) | tablero colocado |
hints | n/a | sí (pos.rot) | vía aristas | juego de pistas |
board_pieces | 000 | con las aristas | sí | capa superpuesta |
e2pieces.txt | 0 | sí (por apareo) | sí (por apareo) | tablero colocado |
| Puzzle CSV | 1111…1 (todo unos) | solo pistas | sí (piezas) | puzzle |
| JSON del sitio | 0 | sí | sí | puzzle |
JSON BoardDoc | a / 000 / -1 | sí | sí | tablero colocado |
| URL eternity2.dev | a | sí (por apareo) | sí (por apareo) | enlace a un tablero |
| URL bucas | a | con las piezas | con las piezas | enlace a un tablero |
Cada conversión de esa tabla está a un pegado de distancia en el
conversor de formatos: suelta una URL, una cadena board_edges
pelada o un bloque de parámetros, y lee de vuelta la URL eternity2.dev, el JSON
canónico, el CSV, board_pieces, e2pieces.txt y la URL bucas, con una vista
previa en vivo y la puntuación, para que veas que el archivo es correcto antes de
fiarte de él.