Un simulator poate explica o succesiune de stări fără să explice experiența unui om. Ca să folosim rezultatul bine, trebuie să știm ce date a primit, ce reguli a aplicat și ce a rămas în afara modelului.
Fișierul acceptat este doar începutul
Un nivel descris prin date trebuie să poată fi citit înainte să poată fi jucat. Contractul stabilește ce înseamnă câmpurile: dimensiunea tablei, tipurile de celule, obiectivele, limitele și eventual versiunea formatului. Validarea de schemă poate controla prezența și tipul valorilor. Alte verificări pot controla relații între ele, dacă au fost definite explicit.
Separarea contează fiindcă un număr întreg poate fi corect ca tip și nepotrivit ca valoare. O coordonată poate avea forma cerută și totuși să indice în afara tablei. Iar un obiectiv bine descris poate fi imposibil în combinație cu regulile nivelului. Cât poate detecta instrumentul depinde de verificările pe care le are, nu de cuvântul general «valid».
Și transferul între instrumente are nevoie de sens comun. Dacă un format numără straturile unui obstacol, iar altul numără obstacolele eliminate complet, copierea numărului nu păstrează neapărat obiectivul. Un fișier acceptat la import nu încheie această discuție.
Un nivel inventat, cu reguli declarate
Exemplul următor este integral sintetic, construit numai pentru acest articol. Nu descrie un nivel existent și nu prezintă rezultate obținute prin rulare. Imaginăm o tablă de 6 × 6 celule, patru culori de piese și patru lăzi cu un singur strat. Obiectivul este colectarea a 9 piese verzi și eliminarea tuturor lăzilor în cel mult 18 mutări.
Declarăm regulile necesare: se schimbă două piese vecine; numai un schimb care produce o potrivire consumă o mutare; o potrivire elimină cel puțin trei piese de aceeași culoare; o ladă dispare dacă o potrivire este alăturată ei pe orizontală sau verticală. După eliminare, piesele cad și celulele libere sunt completate. Presupunem că nu există piese speciale.
Pentru primul pas, presupunem o configurație care permite eliminarea a trei piese verzi lângă o singură ladă. Presupunem și o completare fără altă potrivire. După acest schimb ar rămâne 17 mutări, 6 piese verzi de colectat și 3 lăzi de eliminat. Numerele sunt consecințele regulilor declarate, nu măsurători ale unui instrument.
Această mică secvență ne permite să întrebăm precis unde apare o diferență. Dacă un consumator raportează patru lăzi rămase, verificăm regula vecinătății și momentul actualizării obiectivului. Nu tragem direct concluzia că întregul nivel este greșit.
Modelul trebuie comparat cu ceea ce pretinde că reprezintă
Datele inițiale nu stabilesc singure ce urmează. Ordinea operațiilor poate conta: când se aplică efectul asupra lăzilor, când se completează tabla și când se decide victoria? Două implementări care citesc același fișier pot ajunge la rezultate diferite dacă aceste reguli sunt diferite sau incomplete.
Un simulator util nu trebuie să reproducă orice detaliu vizual. Poate omite animații și sunete dacă scopul lui este examinarea regulilor. Dar trebuie să știm ce fidelitate cerem. Pentru verificarea obiectivelor contează tranzițiile și numărătorile; pentru ritmul perceput contează și durata, lizibilitatea sau întreruperile. Fidelitatea nu este o proprietate universală, independentă de întrebare.
O comparație propusă ar porni de la aceeași stare și aceeași acțiune în model și în joc, apoi ar urmări prima diferență relevantă. Ar include și limite precum ultima mutare sau două efecte simultane. Aceasta este o metodă posibilă de evaluare, nu afirmația că o asemenea comparație a fost efectuată aici.
Reluarea unei secvențe nu este alegerea unui jucător
Pentru a relua exact secvența inventată, nu ajunge să păstrăm nivelul. Ar trebui cunoscute versiunea regulilor, starea inițială, acțiunile și completările tablei. Dacă folosim un generator pseudoaleator, o valoare de inițializare ajută numai în condițiile aceluiași algoritm și aceleiași ordini de folosire. O înregistrare explicită a completărilor poate servi altui tip de reluare.
Reproducerea ar răspunde întrebării «putem obține din nou această secvență?». Nu ar răspunde la «ar alege un om acele mutări?». Chiar și o succesiune câștigătoare arată doar existența acelui traseu în condițiile date. Nu stabilește că soluția este vizibilă sau accesibilă unui începător.
Dacă alegerile sunt făcute automat, regula de alegere trebuie numită separat de regulile jocului. Un mecanism care urmărește mereu eliminarea imediată a celor mai multe piese nu reprezintă implicit strategia sau atenția unei persoane.
Hazardul cere condiții de comparație
În nivelul fictiv, completarea tablei poate schimba mutările disponibile. O singură secvență favorabilă nu justifică afirmația că nivelul este ușor. Nici una nefavorabilă nu dovedește că este imposibil. Pentru o concluzie mai largă ar trebui definit ce variații explorăm și cum alegem acțiunile.
Dacă am compara două configurații, am păstra explicite versiunea regulilor, modul de alegere a mutărilor, limita de oprire și modul de generare a pieselor. Am stabili dinainte ce observăm: de exemplu, obiectivele rămase la oprire. Folosirea acelorași valori de inițializare poate ajuta comparația, dar nu garantează aceleași completări când configurațiile consumă aleatorietatea în ordine diferită.
Mai multe rulări ar descrie comportamentul modelului în condițiile alese. Nu s-ar transforma automat într-o rată de reușită a oamenilor. Un eventual rezultat trebuie prezentat împreună cu condițiile și limitele lui; aici nu raportăm rulări, procente sau performanțe măsurate.
Ce rămâne de aflat de la oameni
Jucătorul trebuie să înțeleagă ce vede și ce urmărește. Observă că lada are un singur strat? Distinge piesele relevante? Înțelege de ce o mutare a fost refuzată? Poate urmări o cascadă fără să piardă legătura cu propria acțiune? Acestea sunt întrebări despre experiență, nu doar despre tranzițiile dintre stări.
O evaluare cu oameni ar putea urmări unde ezită, ce cred că s-a întâmplat și ce aleg în continuare. Ar avea nevoie de un scop și de participanți potriviți întrebării. Nu relatăm aici asemenea observații. Ideea nu este că simularea valorează puțin, ci că poate elimina neclarități tehnice înainte de a pune oamenilor întrebări pe care modelul nu le poate rezolva.
Lucrarea despre workbench-ul de niveluri descrie contribuția documentată la editare, simulare și validare. Reluarea exactă, comparațiile controlate și evaluările discutate în acest articol nu sunt prezentate drept funcții dovedite ale acelui instrument. Nu rezultă de aici echilibrare automată, predicție a dificultății sau timp economisit măsurat.
O descriere precisă poate spune «această secvență respectă modelul» și lăsa deschisă întrebarea «cum este pentru un jucător?». Este aceeași limită a concluziei discutată în «O citare nu este un verdict»: rezultatul rămâne util atunci când nu îi cerem să dovedească altceva.
