Una scelta conta quando la storia la ricorda. Questo progetto per principianti segue due collaboratori adulti che decidono come aprire uno studio, usando un piccolo grafo di passaggi, una decisione memorizzata e due finali. Richiede pochissime risorse grafiche. Il tuo primo compito è fare in modo che ogni scelta porti al risultato previsto, poi assicurarti che quel risultato si mantenga dopo un salvataggio e un ricaricamento.
Il file da scaricare contiene il sorgente Twee per SugarCube. Compilalo in HTML giocabile con Tweego e un formato di storia SugarCube installato, oppure ricrea manualmente i passaggi della storia in Twine. Qui l’esempio non è stato eseguito in un ambiente di esecuzione Twine, quindi completa i test descritti sotto prima di pubblicarlo.
Scegli prima il formato
Crea una storia in Twine, seleziona SugarCube 2 come formato della storia e annota la versione che usi. Tieni a portata di mano la documentazione ufficiale su macro, variabili e salvataggi. Gli esempi per Harlowe usano una sintassi diversa; copiarli direttamente in SugarCube è un modo rapido per trasformare una scena semplice in una sessione di debug.
Nel sorgente scaricato, le righe che iniziano con :: introducono i passaggi. StoryTitle e StoryData contengono le informazioni di configurazione. Nell’editor di Twine, imposta il titolo della storia e il formato SugarCube, poi crea StoryInit e i sei passaggi della storia usando esattamente i loro nomi. Copia il contenuto di ciascuno senza l’intestazione :: e seleziona Start come passaggio iniziale. Un file .twee è un sorgente modificabile; pubblica HTML per i giocatori.
Costruisci il grafo dei passaggi
L’esempio inizializza $sharedPlan a false. Start offre due risposte: SharedPlan lo imposta a true, mentre SeparatePlan lo imposta a false. Entrambe portano a Discussion, che controlla il valore e mostra il collegamento a SharedEnding o IndependentEnding. Questo è tutto il grafo: una decisione con una conseguenza visibile.
Assegna ai passaggi nomi stabili e ben distinguibili e controlla ogni destinazione sia nel grafo visivo sia nella build pubblicata. Un’etichetta accattivante non può rimediare a un errore nel nome della destinazione. Mantieni il nome interno del passaggio separato dal testo che potresti riscrivere o tradurre, così un cambio di formulazione non interrompe il percorso.
Rendi prevedibili i cambiamenti di stato
Usa una variabile con un nome per una decisione specifica. Qui $sharedPlan registra se il giocatore ha scelto un piano condiviso; non deve rappresentare ogni sentimento tra i personaggi. Impostala nel punto in cui avviene la scelta e leggila nel punto in cui compare la conseguenza. Rendere evidente questo rapporto facilita l’espansione di una piccola storia.
Controlla cosa succede quando un giocatore torna su un passaggio. Se visualizzarlo aggiunge un punto, una nuova visita può assegnarne involontariamente un altro. Nei progetti più grandi, dai agli eventi che devono accadere una sola volta regole specifiche e decidi se tornare indietro nella cronologia della storia debba annullarne gli effetti. Testa anche i ricaricamenti, senza dare per scontato che si comportino come una prima visita.
Progetta una pagina leggibile
Parti dall’interfaccia predefinita del formato della storia. Dai al testo una larghezza comoda per la lettura, usa caratteri leggibili e rendi evidente il focus sui link durante la navigazione con la tastiera. Controlla paragrafi e scelte su uno schermo stretto. Un elemento decorativo sovrapposto serve a poco quando il giocatore non riesce a trovare la riga successiva; aggiungi sfondi elaborati solo quando la lettura è scorrevole.
Mantieni facili da trovare le impostazioni e i controlli per ricominciare e salvare. Non affidarti solo al colore per indicare i link disponibili o uno stato importante, così la pagina resta comprensibile anche se un segnale cromatico passa inosservato. Se aggiungi audio o movimento, fornisci dei controlli e parti in modo discreto. Lascia che siano i giocatori a scegliere quando la colonna sonora o l’animazione entra nella scena.
Pubblica e testa la persistenza dei dati
Pubblica tramite Twine, oppure compila il sorgente in HTML con il formato SugarCube selezionato, poi distribuisci il file tramite l’hosting che intendi usare. Testalo nel browser e all’origine del sito che i giocatori useranno. La memoria del browser è legata al suo contesto, quindi un salvataggio locale riuscito non basta a stabilire come si comporterà la versione ospitata online.
Salva prima della decisione e di nuovo dopo. Chiudi la pagina, riaprila e carica ogni salvataggio, verificando che la scelta memorizzata e il finale disponibile siano corretti. Ripeti il test in un nuovo profilo del browser, creando lì nuovi salvataggi. Controlla separatamente la navigazione privata, il comportamento dopo la cancellazione dei dati del browser e la distribuzione incorporata in un’altra pagina. Descrivi gli eventuali limiti riscontrati; le impostazioni del browser e il comportamento dell’hosting possono impedire che i salvataggi persistano.
Prepara un percorso per gli aggiornamenti
Mantieni il sorgente modificabile sotto controllo di versione e archivia ogni versione HTML pubblicata. Registra la versione di SugarCube e le modifiche ai passaggi e conserva file di salvataggio rappresentativi, così puoi confrontare un aggiornamento con la build precedente. Decidi se gli aggiornamenti supporteranno i salvataggi esistenti. Se i giocatori devono ricominciare, spiega questa necessità prima che carichino la nuova versione.
Gioca ogni finale partendo da zero e controlla ogni link con la tastiera e, dove pertinente, con i controlli touch. Usa la matrice di test dei percorsi per registrare i risultati attesi e quelli effettivi. Puoi passare oltre quando la storia si legge con chiarezza, il suo stato si comporta in modo prevedibile e riesci a ripetere il processo di pubblicazione. Consulta la guida ai percorsi e agli stati prima di costruire una grande rete di diramazioni.
Decisioni chiave
- Seleziona SugarCube 2 prima di scrivere macro SugarCube.
- Conserva il sorgente Twee; pubblica HTML giocabile.
- Testa visite ripetute, salvataggi e ricaricamenti sull’hosting previsto.
- Mantieni stabili i nomi dei passaggi e archivia le versioni pubblicate.
File della guida
Esempio Twee per SugarCube ↓Matrice di test dei percorsi ↓Le comunità esterne dedicate ai modelli e i siti di pubblicazione esterni possono contenere materiale esplicito. I link alle fonti si aprono in una nuova scheda; questa guida non carica le relative anteprime.
Fonti e approfondimenti +
Ultimo controllo 5 ottobre 2026.