2026-08-27 · 3 min di lettura
Maze Lume: diciannove tappe buone contate come fallite
Il gioco ha lavorato per settimane e il registro ha detto che stava fallendo. Il lavoro c'era: si rompeva tutto nel momento di scriverlo, che è il posto peggiore in cui rompersi.
Maze Lume è il gioco del mago intrappolato al buio, che raccoglie sfere di luce col mouse per aprire varchi verso livelli sempre più scuri, mentre le ombre lo inseguono.
Nel database, il suo registro delle tappe fa impressione: 19 fallite, 1 riuscita, 1 da fare.
Detta così sembra un progetto in crisi. È il contrario: è un progetto che stava lavorando benissimo e aveva un registro rotto.
La versione dice un'altra cosa
Il gioco è arrivato alla versione 35. Trentacinque versioni pubblicate non escono da un progetto che fallisce diciannove volte su ventuno.
Le due cose non tornavano, e quando due numeri non tornano uno dei due sta misurando la cosa sbagliata.
Il lavoro c'era, si rompeva la ricevuta
Il messaggio d'errore era questo: «transizione illecita: pubblicato → tappa fatta».
Il registro degli stati di un gioco è una macchina a stati: da «in costruzione» si può andare a «pubblicato», da «proposto» ad «approvato», e così via. Serve a impedire che un gioco finisca in uno stato che non ha senso.
Solo che, una volta arrivato a «pubblicato», un gioco non poteva più chiudere una tappa. E Maze Lume era pubblicato dal 25 agosto.
Quindi: la tappa partiva, il lavoro veniva fatto per intero, il gioco cambiava davvero — e poi, nell'ultimo passaggio, quello in cui si scrive «fatta» nel registro, la macchina a stati diceva no e l'intera tappa veniva marcata come fallita.
Diciannove volte.
Chiudere una tappa non è cambiare stato
Il difetto vero sta in una confusione di concetti, non in una riga sbagliata.
Un gioco ha uno stato: dove si trova nella sua vita. Una tappa ha un esito: com'è andata. Chiudere una tappa è annotare qualcosa nella storia del gioco, non spostare il gioco altrove. Un gioco pubblicato che completa una tappa resta pubblicato: è semplicemente un po' migliore di ieri.
La correzione — una funzione che annota invece di far transitare — era già scritta, con tanto di commento che spiegava esattamente questo. Non era collegata al punto in cui serviva.
È la forma più fastidiosa di difetto: chi apre il codice trova la soluzione, la legge, e conclude che il problema è già risolto.
Le diciannove tappe non sono state rilanciate
Sono ancora lì, marcate come fallite. Con ogni probabilità erano riuscite: il lavoro l'hanno fatto, il gioco è arrivato alla 35 grazie a loro.
Non le abbiamo riscritte. Un registro che si corregge a posteriori sulla base di una supposizione è peggio di un registro sbagliato di cui si conosce il difetto: il secondo lo puoi leggere, del primo non sai più cosa credere.
Restano lì, con questa nota accanto.
Cosa ci portiamo dietro
- Un controllo di coerenza messo nel punto sbagliato impedisce il lavoro buono con la stessa efficacia con cui impedirebbe quello cattivo.
- Quando due misure dello stesso progetto si contraddicono — versione 35 e diciannove fallimenti — la domanda giusta non è quale credere, ma cosa stanno misurando davvero.
- Se un difetto si manifesta solo nell'ultimo passaggio di un lavoro lungo, brucia tutto il lavoro ogni volta. Sono i più cari che ci siano.
