Sei morto di dissenteria: Esplorare la storia del design dell'Oregon Trail

Il sentiero dell'Oregon è, a detta di molti, il gioco educativo per computer di maggior successo di tutti i tempi. Nel corso degli anni sono state create molte versioni del gioco, che risalgono al 1971. Tuttavia, la versione che molti considerano l“”originale", quella che appare costantemente nei meme e nelle articoli di riviste è il 1985 Apple II (Il progetto del 1985 è stato implementato anche su PC IBM e Macintosh e altre piattaforme. (Il progetto del 1985 è stato implementato anche su PC IBM, Macintosh e altre piattaforme, ma è apparso per la prima volta sull'Apple II). Sono stato il progettista principale e il responsabile del team di questa versione più famosa del più famoso gioco educativo, e quindi sono una fonte eccellente per rivelare esattamente come è nato questo progetto.

Poiché questa è una storia di successo - e “il successo ha molti padri” - in questo resoconto compariranno i nomi di molte altre persone (non solo il mio nome, nonostante la vanagloria del titolo di questo pezzo). Tutte queste persone hanno avuto un ruolo chiave nel successo di Il sentiero dell'Oregon.

Ci sono diverse ragioni alla base dell'impressione popolare che la versione del 1985 sia l“”originale". Una ragione ovvia è che la versione del 1971 era di solo testo e relativamente poche persone hanno visto o giocato alla versione di solo testo. Un secondo motivo importante è che la maggior parte delle caratteristiche che la gente associa con affetto al gioco sono state introdotte per la prima volta nel 1985. Il prodotto del 1985 era molto più di una nuova versione: era una rivisitazione completa di come creare un gioco sull'Oregon Trail. Sono certo che quella del 1985 sia stata la versione più originale e creativa dell'intera storia del prodotto, escludendo (ovviamente) la versione completamente originale del 1971. In altre parole, il gioco che alla fine ha avuto così tanto successo è stato inventato in due fasi ugualmente importanti: la prima nel 1971 e la seconda nel 1984-85.

Volete saperne di più sul game design?
5 cose da sapere su Stardew Valley
Fotografia con la fotocamera del Nintendo Game Boy del 1998
I migliori nuovi giochi progettati per i designer

La vera versione originale

La prima versione di Il sentiero dell'Oregon è nato come un'idea nella testa di Don Rawitsch, che nel 1971 era uno studente insegnante in Minnesota. Immaginò un gioco da tavolo che potesse essere giocato dagli studenti della classe in cui doveva insegnare. Subito dopo aver iniziato a lavorare su questo concetto, Don condivise la sua idea con i suoi compagni di stanza, Bill Heinemann e Paul Dillenberger, anch'essi studenti insegnanti. Erano entusiasti dell'idea di Don, ma suggerirono che avrebbe dovuto essere un gioco per computer invece che un gioco da tavolo. Il distretto scolastico di Minneapolis, dove tutti e tre insegnavano, aveva da poco acquistato un computer mainframe e ogni scuola del distretto aveva un terminale di telescrivente per l'accesso remoto al computer. Inoltre, sia Bill che Paul avevano imparato BASE, Un linguaggio di programmazione semplice, ideale per creare un piccolo programma per computer come quello che avevano immaginato.

Immagine di una macchina telescrivente via Flickr.

Don accettò subito il cambiamento di programma e i tre iniziarono a progettare e programmare il gioco. Due settimane dopo, giusto in tempo per la lezione che Don doveva tenere, una prima versione grezza del gioco era pronta per essere mostrata ai bambini. Nonostante la goffaggine della telescrivente, i bambini si divertirono chiaramente a giocare. Bill e Paul osservarono risultati simili nella loro scuola. Il gioco rimase disponibile, accessibile agli studenti nel loro tempo libero, per il resto del semestre. Ma alla fine del semestre, quando il suo periodo come studente insegnante si concluse, Don cancellò il programma dal sistema informatico.

Qualche anno dopo Don ha iniziato a lavorare presso MECC (Minnesota Educational Computing Consortium), una nuova agenzia statale del Minnesota incaricata di fornire accesso informatico a tutte le scuole dello Stato. Il modello informatico del MECC era simile a quello del distretto scolastico di Minneapolis: un computer mainframe situato a livello centrale a cui si poteva accedere tramite un terminale di telescrivente in ogni scuola. Ma ora, invece di servire un singolo distretto scolastico, questa nuova organizzazione serviva l'intero Stato. Don aveva conservato una stampa del programma BASIC della partita del 1971, così nel 1974 digitò lo stesso programma nel sistema informatico del MECC. Poi fece alcune messe a punto, modificando la frequenza dei vari eventi casuali del gioco. Infine, nel 1975, rese il gioco disponibile a tutti gli utenti del MECC. OREGON (così si chiamava) divenne presto l'attività educativa più popolare del sistema, e lo rimase fino a quando il MECC chiuse le sue operazioni su mainframe nel 1983.

Questa prima versione di solo testo di Il sentiero dell'Oregon era estremamente semplice, come lo erano quasi tutte le attività didattiche sul mainframe del MECC. Eppure, sette dei concetti fondamentali che comparivano nel gioco del 1971 sono ricomparsi in ogni versione da allora.

Questi concetti fondamentali sono:

Il giocatore acquista le provviste prima di iniziare il viaggio verso l'Oregon.
Lungo il percorso ci sono occasioni di caccia per procurarsi il cibo.
Ci sono possibilità di fare acquisti presso i forti lungo il percorso.
Il giocatore deve gestire il livello delle scorte per evitare di rimanere senza.
La velocità di spostamento dipende dalle condizioni attuali.
Le disgrazie si verificano spesso.
Il gioco termina quando il giocatore raggiunge l'Oregon o muore durante il percorso.

Il gioco del 1971 era strutturato come un ciclo ripetuto. Ogni ciclo rappresenta due settimane di viaggio sul sentiero. Di seguito è riportato un esempio di un ciclo tipico, tratto da una sessione di gioco reale. La maggior parte del testo in questo esempio è stato digitato dal computer, ma a volte il computer si ferma per attendere una risposta dal giocatore. Le risposte del giocatore sono evidenziate in giallo:

Come si può vedere da questo esempio, ogni ciclo inizia con un aggiornamento di stato. Poi il giocatore decide se cacciare o meno. (Se il giocatore sceglie di cacciare, spara con il fucile digitando “BANG” quando gli viene detto di farlo. Se la digitazione è stata veloce e precisa, la caccia è riuscita. A questo punto il giocatore decide quanto mangiare. Infine, si verificano una o più “disgrazie” che possono ridurre le scorte. Il ciclo si ripete due settimane dopo, tenendo conto delle scorte utilizzate nel frattempo. Il ciclo continua finché il giocatore non raggiunge l'Oregon o muore nel tentativo. Un viaggio di successo richiede circa 12 cicli, a seconda di varie circostanze che influenzano la velocità del viaggio.

Per molti giocatori, l'attrattiva principale di questo gioco era la sfida della caccia: digitare la parola “BANG” abbastanza velocemente da avere successo, senza commettere errori di battitura. Pertanto, il modo tipico di giocare consisteva nel dare una risposta identica in ogni ciclo: prima digitare “2″ per cacciare, poi digitare “BANG”, quindi digitare “2″ per mangiare moderatamente. L'unica deviazione necessaria è quando uno dei rifornimenti diventa pericolosamente basso, costringendo il giocatore a fare acquisti in un forte invece di cacciare. Il secondo aspetto interessante di questo gioco è stata la sfida di gestire le risorse: tenere d'occhio le scorte per assicurarsi che non si esauriscano, il che sarebbe un errore fatale. Il terzo aspetto interessante è che ci sono così tante disgrazie diverse che possono verificarsi. Non si sa mai cosa succederà, a meno che non si finiscano le scorte, nel qual caso probabilmente si morirà molto presto.

Il progetto originale prevedeva anche attacchi casuali da parte di animali selvatici, banditi e “cavalieri ostili”, ognuno dei quali forniva ulteriori opportunità di digitare “BANG” - e conseguenze terribili per chi non riusciva a digitare rapidamente e con precisione. Alla fine degli anni Settanta fu apportata una piccola modifica al gioco, in modo che il giocatore non sapesse in anticipo quale parola avrebbe dovuto digitare quando sarebbe arrivato il momento di sparare. A volte era “BANG”, ma poteva anche essere “POW”, “BLAM” o “WHAM”.”

Il mondo cambia

Nel 1978 Don Rawitsch pubblicò il codice BASIC per OREGON in Informatica creativa rivista. In seguito molte persone modificarono il codice per farlo funzionare su varie marche di microcomputer. Qualcuno, non so chi, inserì una versione di questo codice su un Apple II. Questa versione del gioco non era un progetto nuovo, infatti utilizzava per lo più lo stesso codice BASIC apparso sulla rivista. Tuttavia, l'autore apportò tre importanti modifiche al gioco, una delle quali fu una rivisitazione dell'attività di caccia. Invece di essere basata sul testo, come tutte le altre parti del gioco, questa nuova attività presentava lo schizzo di un cervo, al quale il giocatore poteva sparare premendo qualsiasi tasto della tastiera.

Nel 1979 il MECC acquistava computer Apple II in grandi quantità (a prezzo scontato) e li rivendeva a prezzo di costo alle scuole di tutto il Minnesota. Nel 1980 il MECC iniziò anche a distribuire dischi contenenti software Apple II a queste stesse scuole. (Questi dischi venivano forniti gratuitamente alle scuole del Minnesota, ma venduti con un notevole profitto alle scuole al di fuori del Minnesota). Ogni disco conteneva una raccolta di programmi trasferiti dal computer mainframe del MECC. Il gioco OREGON apparve in due di queste raccolte, una delle quali si chiamava “Elementary Volume 6”.”

MECC continuò a distribuire “Elementary Volume 6″ per molti anni, e il gioco OREGON rimase il prodotto più famoso di MECC, anche dopo che MECC chiuse le sue operazioni sui mainframe per concentrarsi interamente sui microcomputer (Apple II, Atari, IBM, ecc.). Tuttavia, il panorama competitivo cambiò completamente tra il 1980 e il 1984. Nel 1980, tutto il software didattico per computer era ancora progettato e programmato da dilettanti, hobbisti e insegnanti che creavano questi piccoli e semplici programmi nel tempo libero. Inoltre, nessuna grande azienda privata era ancora entrata nel mercato del software didattico, né in quello scolastico né in quello domestico.

Nel 1984 il mondo del software didattico era completamente diverso. Un gran numero di aziende, grandi e piccole, aveva iniziato a vendere software didattico. Alcune di queste aziende erano specializzate nel mercato scolastico, altre in quello domestico. Nel 1984, tutti i migliori software didattici erano progettati e programmati da professionisti, il cui lavoro a tempo pieno consisteva nel progettare o programmare tali software. Per rimanere competitivi, la stessa transizione avvenne all'interno di MECC. Nel 1983 MECC aveva acquisito uno staff di progettisti e programmatori professionisti incaricati di creare software originale di alta qualità per l'Apple II. Nel 1984 il miglioramento dei prodotti MECC era evidente a tutti. Questo fu l'inizio dell“”età dell'oro" di MECC, un periodo di dieci anni in cui MECC sfornò di anno in anno nuovo software eccezionale, destinato soprattutto al mercato scolastico, ma che comprendeva anche alcuni titoli per il mercato domestico.

Sebbene MECC si concentrasse ormai quasi esclusivamente sulla creazione di titoli nuovi e originali, aveva anche tre famose simulazioni degli anni Settanta.Oregon Trail, Bancarella della limonata, e Lago Odell-che non voleva abbandonare. Tutte e tre le attività erano state portate sull'Apple II nel 1980, ma nel 1984 risultavano imbarazzantemente obsolete, soprattutto per quanto riguarda l'aspetto. Il MECC decise di creare nuove versioni di tutte e tre le attività.

La decisione di rompere con il passato

È in questo contesto che, nell'ottobre 1984, sono stato scelto dal MECC per guidare la creazione di una nuova versione di Il sentiero dell'Oregon. Ero entrato a far parte dello staff del MECC nel 1981 con una notevole esperienza nella progettazione e nella programmazione di simulazioni al computer (anche se prima del 1981 tutte le mie simulazioni erano state rivolte a studenti universitari). Ero l'unica persona dello staff con questo tipo di esperienza e quindi ero la scelta più logica per il ruolo di progettista principale e leader del team. Tuttavia, sono rimasto sorpreso dai dettagli del mandato che mi è stato affidato.

Innanzitutto, mi è stato detto di progettare un prodotto per il mercato domestico, non per quello scolastico. In precedenza, MECC si era sempre specializzata nel mercato scolastico. Questo sarebbe stato il primo tentativo di MECC di creare un prodotto specifico per il mercato domestico.

In secondo luogo, le mie istruzioni erano di fare molto di più che creare una versione più bella del gioco originale. Mi è stato detto di prendere l'idea originale e di utilizzarla. Dovevo espandere il concetto originale, costruendo un gioco molto più elaborato e robusto. Potevo farlo nel modo che ritenevo più opportuno, a patto di preservare la magia che aveva reso l'originale così popolare. Tuttavia, ho dovuto progettare il prodotto specificamente per l'Apple II, il che ha comportato alcune gravi restrizioni, come quella di dover lavorare con una tavolozza di soli sei colori. (Avrei preferito utilizzare una macchina più recente, come l'Apple II). Commodore 64.)

Il mio mandato di rivedere e riprogettare Il sentiero dell'Oregon all'inizio era quasi opprimente: le possibilità erano infinite, eppure dovevo riuscire ad azzeccare tutto alla prima uscita. Per 13 anni, dal 1971 al 1984, il gioco OREGON era rimasto sostanzialmente invariato. Alcuni piccoli dettagli erano stati modificati nel corso del tempo, ma mai il prodotto era stato completamente ripensato e ridisegnato. Non erano mai stati modificati i modelli sottostanti, le strutture, gli algoritmi e i presupposti su cui si basa il gioco. Per la prima volta, avremmo buttato via tutto, compresa tutta la programmazione software esistente, che risaliva al 1971, e saremmo ripartiti completamente da zero. Ogni dettaglio doveva essere riconsiderato. Inoltre, dovevo creare un'esperienza molto più ricca ed elaborata rispetto all'originale OREGON, e questo avrebbe richiesto una grande quantità di idee nuove e originali.

Per dare il via al progetto, ho definito una metrica chiave che fungesse da pietra angolare del nostro approccio: “Ai bambini che amano la vecchia versione piace ancora di più la nuova?”. L'idea era di eseguire questo test periodicamente nel corso del progetto, per verificare che fossimo ancora sulla buona strada. Ogni volta che ci trovavamo in difficoltà, questo metro di giudizio ci riportava alla realtà, permettendoci di vedere di nuovo il quadro generale.

Poiché stavo progettando un prodotto per il mercato domestico, sapevo di dover creare un gioco molto divertente, oltre che chiaramente educativo. Ho pensato che fosse possibile fare entrambe le cose senza compromettere seriamente nessuna delle due, ma ho dovuto trovare un attento equilibrio nei dettagli. In particolare, ritenevo che sia il valore educativo che quello ludico dovessero derivare dall'immersione del giocatore in un'esperienza storicamente accurata.

Fin dall'inizio ho capito che questo progetto presentava molte sfide, ma la questione dei vincoli di spazio sembrava particolarmente impegnativa. Il nuovo gioco doveva avere una ricca grafica a colori, ma la grafica avrebbe richiesto molto spazio, sia sul floppy disk che nella RAM (memoria) dell'Apple II. Speravo anche di aggiungere molti nuovi dettagli e aspetti del gioco, che avrebbero richiesto spazio. Purtroppo, stavo progettando per un computer che aveva solo 64K di RAM. Inoltre, il prodotto sarebbe stato distribuito e giocato su un floppy disk da 5,25″ a doppia faccia, per un totale di soli 280K di spazio di archiviazione. (Si noti che l'Apple II non aveva un disco rigido, ma solo un lettore di dischetti).

All'inizio del progetto, il nostro team principale era composto da cinque persone. Oltre a me (Philip Bouchard), c'erano John Krenz (programmatore principale), Charolyn Kapplinger (artista principale), Shirley Keran (ricerca) e Bob Granvin (programmazione aggiuntiva). Tutti e cinque abbiamo svolto un ruolo attivo nelle prime fasi di brainstorming e pianificazione del prodotto, anche se alla fine il MECC ha trasferito Bob a un altro progetto che richiedeva la sua attenzione. Così noi cinque iniziammo un progetto che divenne il più grande sforzo del MECC fino a quel momento e che durò in totale 10 mesi, dall'ottobre 1984 alla fine di luglio 1985.

Sviluppare i concetti chiave

Nell'approccio di progettazione tradizionale del MECC (a partire dal 1984), il progettista didattico immagina prima un'attività per studenti basata sul computer e poi crea una serie di schizzi che illustrano ciò che dovrebbe apparire sullo schermo in ciascuna delle fasi chiave dell'attività. Questa raccolta di schizzi viene poi integrata da note scritte che forniscono ulteriori dettagli. Gli schizzi e le note costituiscono un “documento di progettazione”. Il progettista esamina quindi il documento con un piccolo team composto da un massimo di altre tre persone: il programmatore principale, il grafico principale e un programmatore/analista esperto. Insieme identificano i dettagli mancanti nel progetto e aiutano a risolvere qualsiasi altro problema che il progetto presenta. Il progettista apporta quindi le aggiunte o le modifiche necessarie per completare il progetto e il team si mette al lavoro per creare la grafica e generare il codice del programma.

Questo modello funzionava abbastanza bene per i prodotti relativamente semplici che MECC aveva creato fino a quel momento, ma vedevo che non avrebbe funzionato per il prodotto che intendevo progettare. Innanzitutto, immaginavo che il gioco fosse basato su un complesso insieme di modelli matematici di simulazione: un modello meteorologico, un modello sanitario, un modello di viaggio e così via. Inoltre, ognuno di questi modelli si baserebbe su un complesso insieme di formule matematiche interconnesse. Questi modelli avrebbero richiesto una progettazione e una messa a punto incrementale, il che significava non solo che dovevo sfornare un gran numero di formule, ma anche che il progetto doveva essere specificato e implementato in fasi iterative, anziché tutto in una volta.

In secondo luogo, ritenevo che il modo migliore per costruire un progetto innovativo ma di successo fosse quello di iniziare con un insieme ambizioso di nuove idee, per poi costruirle e testarle gradualmente attraverso un affinamento successivo: prima creando un semplice prototipo e poi costruendo il prodotto reale un aspetto alla volta. In ogni fase del processo dovremmo valutare dove siamo, rispetto a dove vorremmo essere, e quindi stabilire le priorità da seguire. Alcune delle nostre idee più care dovranno essere abbandonate lungo il percorso, ma dando costantemente priorità e migliorando, alla fine otterremo un risultato di successo. (Ho imparato e applicato per la prima volta i concetti di affinamento successivo quando studiavo informatica alla scuola di specializzazione negli anni Settanta. Tuttavia, decenni dopo, ho visto molte sovrapposizioni tra queste idee e il concetto di “programmazione agile”).

Prima, però, devo progettare la struttura di base del gioco, e per un paio di settimane mi sono trovato in difficoltà. L'OREGON originale si basava sul concetto di “turni”, ognuno dei quali rappresentava esattamente due settimane di tempo reale. Questa struttura semplice si adattava bene al suo scopo originario - un gioco basato sul testo e giocato su una telescrivente - ma era poco adatta alle esigenze del nuovo gioco. Volevo creare una struttura che fosse intimamente legata alla geografia reale dell'Oregon Trail e volevo dare al giocatore una serie molto più ampia di opportunità per prendere decisioni, non solo su cosa comprare e quanto mangiare. Ben presto fu chiaro che avrei dovuto inventare una struttura completamente diversa per il nuovo gioco. Ma mentre prendevo in considerazione un'idea dopo l'altra, nessuna di queste nuove idee sembrava funzionare.

Così ho suddiviso il problema in pezzi e ho iniziato ad affrontare ogni pezzo singolarmente. Alla fine, nell'arco di diverse settimane, sono riuscito a trovare una soluzione a tutti i problemi. La nuova struttura che ne è risultata per Il sentiero dell'Oregon si basava su sette concetti chiave, nessuno dei quali era presente nel progetto del 1971:

Per legare il nuovo design al la geografia reale dell'Oregon Trail, Il viaggio consisterà in segmenti distinti di lunghezza variabile, ciascuno dei quali terminerà in un unico punto di riferimento importante lungo il percorso. (Tra le molte differenze tra il prodotto del 1971 e il progetto del 1985, questa potrebbe essere la più importante, in parte perché ha permesso di apportare molte altre modifiche cruciali).
Per ogni punto di riferimento è disponibile una serie di moduli di attività. In molti casi c'è un'attività chiave legata al punto di riferimento, come l'attraversamento di un fiume o l'acquisto di merci in un forte.
I punti di riferimento sono raggruppati in zone geografiche distinte, ciascuna con i propri dati su clima, terreno e animali selvatici.
La maggior parte dei moduli di attività sono basati sui dati e contengono una randomizzazione, in modo da fornire un'esperienza diversa ogni volta che il modulo viene utilizzato. Ad esempio, ogni volta che viene avviata l'attività di caccia, questa utilizza i dati della zona per presentare gli animali e il terreno adatti alla posizione corrente sul sentiero. Ma anche se il giocatore caccia sempre nella stessa zona, la disposizione del terreno sarà sempre unica e gli animali appariranno in momenti e posizioni imprevedibili.
Oltre al ciclo da punto di riferimento a punto di riferimento, esiste un ciclo giornaliero indipendente, che include tutti i calcoli di gestione delle risorse (rifornimenti, salute, ecc.) insieme agli eventi casuali. Pertanto, il ciclo di calcolo principale nel progetto del 1985 è di un giorno, invece del ciclo di due settimane utilizzato nel progetto originale. Questo ha enormi ripercussioni su tutti i calcoli e su tutte le interazioni.
Tra un punto di riferimento e l'altro, il viaggio procede automaticamente, ma l'utente può fare una pausa in qualsiasi momento. (Questo è un concetto particolarmente importante, perché consente all'utente di accedere a molte attività ed eventi, senza interrompere continuamente il gioco). Tuttavia, il viaggio si interrompe automaticamente se si verifica un evento importante.
La pausa tra i punti di riferimento consente di accedere a un'altra serie completa di moduli di attività, alcuni dei quali sono diversi da quelli disponibili nei punti di riferimento. (Ad esempio, si può parlare con le persone nei punti di riferimento e si può andare a caccia tra i punti di riferimento).

Questa nuova struttura era molto diversa da quella del 1971 e mi ha permesso di creare un'esperienza molto più ricca per il giocatore. Nel nuovo progetto, la relazione tra i moduli di attività era la seguente:

Con questa struttura altamente flessibile che funge da spina dorsale del nuovo prodotto, possiamo ora pianificare quali attività saranno accessibili durante il viaggio tra i punti di riferimento (A-F nel diagramma) e quali attività saranno accessibili in ciascuno dei punti di riferimento (G-L nel diagramma). Ciascuno di questi moduli distinti (rappresentati dai quattro rettangoli e dai 12 cerchi) può essere progettato e programmato separatamente. Inoltre, anche ciascuna mezza dozzina di modelli di simulazione matematica (non mostrati in questo diagramma, ma che operano sotto di esso) potrebbe essere progettata e programmata separatamente.

I miei compagni di squadra erano entusiasti di questa nuova struttura, così ho iniziato il lungo processo di definizione dei dettagli. Innanzitutto, sulla base delle mie ricerche e di quelle della mia collega Shirley, ho preparato un elenco di punti di riferimento candidati. Poi, applicando diversi criteri di selezione, ho ridotto l'elenco in modo che il viaggio fosse composto da circa 16 tappe. Ho anche introdotto il concetto di “cutoff”, vale a dire che, oltre al percorso principale, il giocatore avrebbe talvolta avuto la possibilità di prendere un percorso alternativo. Poi ho iniziato a lavorare alla creazione di un elenco di possibili moduli di attività, realizzando sistematicamente dei “documenti concettuali” per tutte le idee più promettenti.

Durante questa fase di sviluppo del concetto, mi sono confrontato molto con i miei compagni di squadra. Prima di scrivere ogni documento concettuale, di solito discutevo le idee che avevo con i miei compagni di squadra. E poi, dopo aver scritto ogni documento concettuale, lo rivedevo con i miei compagni di squadra per avere il loro ulteriore feedback. Il risultato è che, anche se sono stata l'autrice di tutti i documenti concettuali tranne uno, le idee dei miei compagni di squadra (Cheryl, John, Shirley e Bob) si sono spesso riflesse nei miei documenti. Questo è stato particolarmente vero per i concetti iniziali dell'attività di caccia, che Bob, John e io abbiamo elaborato insieme.

Incorporare l'uomo nella progettazione

All'inizio del progetto, la mia seconda priorità - seconda solo all'incorporazione della geografia reale nel prodotto - è stata quella di includere personaggi umani nel design. Il progetto del 1971 ometteva il concetto di persone e quindi si percorreva l'intero percorso di 2000 miglia senza mai incontrare o interagire con un'altra persona. Volevo cambiare questa situazione. Ho elaborato molti concetti diversi su come il giocatore potesse interagire con i personaggi umani lungo il percorso, o almeno essere a conoscenza di altri esseri umani, e speravo sinceramente di includere quasi tutte queste idee nel prodotto finito. Tuttavia, man mano che il progetto procedeva, ho dovuto tagliare alcuni dei miei cari concetti, a causa dello spazio limitato sul dischetto e del budget limitato per progettare e costruire il prodotto. Tuttavia, sono riuscito a incorporare nel progetto quattro concetti, ognuno dei quali ha avuto un grande impatto sulla “sensazione umana” del prodotto del 1985:

Prima di iniziare il viaggio, nominate altre quattro persone che viaggeranno con voi, in genere membri della famiglia o amici. Ogni membro del vostro gruppo di 5 persone è soggetto a malattie e incidenti. Durante il viaggio, l'obiettivo principale è quello di mantenere in vita e in salute tutte queste persone. Se qualcuno di loro si ammala o muore, viene menzionato per nome. Questa raccolta di concetti è stata un'aggiunta fondamentale al nuovo design.

Oregon-Trail-08-altri membri del partito

Quando si acquista la merce prima di iniziare il viaggio, si entra in un negozio (“Matt's General Store”) e si interagisce con il proprietario del negozio. Matt fornisce consigli utili durante gli acquisti.

Sul vero Oregon Trail, le persone tendevano a riunirsi in ogni punto di riferimento. Tra queste persone non c'erano solo altri viaggiatori, ma anche nativi americani, commercianti locali e soldati. Pertanto, in ogni punto di riferimento del gioco, il giocatore può incontrare e parlare con tre persone diverse, ognuna delle quali offre una prospettiva interessante sulle proprie esperienze. Inoltre, molte di queste conversazioni forniscono suggerimenti utili su come sopravvivere al viaggio. (Purtroppo, a causa dello spazio limitato su disco, non abbiamo potuto includere le immagini di questi personaggi).

Se si arriva fino all'Oregon, l'elenco dei punteggi più alti è precompilato con i nomi di persone reali che hanno intrapreso il viaggio verso l'Oregon o che sono state i primi esploratori della regione.

Grazie alla responsabile della grafica, Charolyn Kapplinger, le persone appaiono anche in molte delle grandi immagini di riferimento. Anche questo contribuisce in modo significativo al lato umano del progetto.

Il mio più grande rimpianto per quanto riguarda Il sentiero dell'Oregon è che ho dovuto abbandonare la maggior parte delle mie idee di interazioni complesse e ricche di sfumature con i nativi americani. Diversi moduli di questo tipo erano inclusi nei concetti di design che ho scritto. Tuttavia, alcune delle idee più semplici sono state inserite nel prodotto finito. Ad esempio, è molto più probabile che l'attraversamento del fiume Snake avvenga con successo se si assume un indiano locale come guida, come avvenne anche sul vero Oregon Trail.

Altre priorità principali

Un'altra priorità assoluta per me è stata quella di includere gli attraversamenti dei fiumi, un aspetto fondamentale dell'esperienza dell'Oregon Trail che mancava nel progetto originale. Ho scelto una serie di attraversamenti rappresentativi, un piccolo sottoinsieme del numero effettivo di attraversamenti effettuati dai viaggiatori sul sentiero. A ogni fiume il giocatore deve scegliere tra diversi metodi di attraversamento, tenendo conto delle condizioni attuali dell'incrocio. Alla base di questo modulo c'è un modello di simulazione molto dettagliato, che controlla le condizioni attuali del fiume (in base alle condizioni meteorologiche recenti, tra gli altri fattori) e controlla anche le probabilità di vari risultati, in base alle condizioni e alla scelta del giocatore su come attraversare. I risultati sono comunicati in un'animazione che mette in tensione molti giocatori.

Un'altra delle mie priorità era quella di includere altre due attività “d'azione”, oltre alla caccia. Presto modificai questo piano in modo che una di queste attività funzionasse come un puzzle logico esteso, piuttosto che come un gioco d'azione. Queste due attività sarebbero state associate all'ultima tappa del viaggio verso l'Oregon, le ultime 100 miglia. Il giocatore può scegliere di fare rafting lungo il fiume Columbia (l'attività d'azione), oppure di percorrere la Barlow Toll Road, nel qual caso l'attività consiste nel far salire e scendere il carro attraverso il difficile terreno montuoso lungo il percorso. Anche in questo caso, lo spazio su disco e il budget ci hanno costretto a fare dei tagli, ma alla fine una versione ridotta del gioco del rafting è stata inserita nel prodotto.

Oregon-Trail-15-Sito di atterraggio di alberi

Infine, un'altra priorità è stata quella di trovare il maggior numero possibile di modi per costruire la “rigiocabilità” del prodotto. Questo aspetto è stato raramente oggetto di preoccupazione per MECC in tutti i prodotti precedenti, perché tutti questi prodotti erano destinati al mercato scolastico. Per le scuole, dove i bambini superano di gran lunga i computer e il tempo di accesso è molto limitato, la maggior parte dei prodotti MECC è stata progettata in modo che il valore del prodotto potesse essere sperimentato in breve tempo. Per il mercato domestico, invece, dovevo progettare un prodotto che un bambino potesse visitare più volte e che fosse ancora interessante dopo 20, 30 o 40 ore di gioco. Per incoraggiare la rigiocabilità, ho inserito nel nuovo progetto un lungo elenco di caratteristiche e dettagli:

Il fattore motivante iniziale, identico a quello del prodotto originale, è sopravvivere all'intero viaggio verso l'Oregon. Come nell'originale, la maggior parte dei giocatori fallisce al primo tentativo, ma percepisce che è possibile fare meglio. Così continuano a provare, facendo sempre meglio nella maggior parte dei tentativi, finché non riescono finalmente a raggiungere l'Oregon.
Appena il giocatore raggiunge l'Oregon per la prima volta, viene svelata una sorpresa: sopravvivendo fino all'Oregon, gli viene assegnato un punteggio. Questo punteggio si basa su diversi fattori distinti, che sono chiaramente elencati. Quindi, proprio nel momento in cui il giocatore raggiunge l'obiettivo iniziale - raggiungere l'Oregon - viene svelato un nuovo obiettivo altamente motivante: ottenere un punteggio molto migliore.
Il giocatore vede anche che l'elenco dei punteggi più alti è pre-popolato di nomi e la maggior parte di questi hanno punteggi più alti di quelli raggiunti dal giocatore. Questo elenco iniziale crea un chiaro punto di riferimento a cui aspirare per salire sempre più in alto fino a superare il punteggio più alto dell'elenco (quello dell'esploratore Stephen Meek).
Man mano che il giocatore cerca di ottenere punteggi più alti, diventa evidente che è necessario tentare le condizioni di partenza più difficili: viaggiare come falegname (con meno soldi) o come contadino (con ancora meno soldi), piuttosto che viaggiare come banchiere. Sebbene sia più difficile raggiungere l'Oregon quando si hanno meno soldi, si ottengono più punti per i propri sforzi.
Il nuovo gioco ha molte più opzioni e approcci alternativi da esplorare rispetto al gioco originale. Con il tempo, molti giocatori sono interessati a esplorare queste alternative. Cosa succede se inizio in un mese diverso? E se cambiassi il ritmo o le razioni? E se mi fermassi di tanto in tanto per riposare? E se parlassi con molte più persone per ricevere consigli? E se attraversassi ogni fiume a galla invece di provare a guadarlo? E se cacciassi di meno (cosa che nel nuovo progetto consuma un giorno di tempo) e facessi più acquisti o viceversa? E se portassi con me un maggior numero di pezzi di ricambio per i carri? E se prendessi la Barlow Toll Road invece di fare rafting sul Columbia River o viceversa?
Come nel gioco originale, alcuni giocatori vorranno giocare più volte solo per andare a caccia. A tal fine, volevo che il nuovo gioco di caccia fosse stimolante e avvincente. Tutti questi fattori, e molti altri che ho incluso nella progettazione, hanno portato a un gioco con un alto grado di rigiocabilità. Senza questa caratteristica, il gioco non avrebbe avuto molto successo nel mercato domestico.

I modelli matematici

Sia nel gioco originale del 1971 che nel nuovo progetto del 1985, la simulazione è guidata da un insieme di formule matematiche legate a variabili di stato. Ogni variabile di stato tiene conto del valore corrente di una quantità importante. Nel progetto del 1971 c'erano esattamente otto variabili di stato:

Contanti (in dollari)
Cibo (valore in dollari)
Munizioni (il numero di proiettili)
Abbigliamento (valore in dollari)
Forniture varie (valore in dollari)
Buoi (valore in dollari)
Distanza percorsa finora (in miglia)
Data attuale (incrementata con salti di due settimane)

Si noti che nel prodotto 1971 non esiste una variabile di stato per la salute. Pertanto la salute nel turno corrente non dipende in alcun modo dalla salute del turno precedente. Il gioco termina se si muore, e si può morire in uno dei seguenti stati:

Si finisce il cibo e si muore di fame.
Si finiscono le “scorte varie” e ci si ammala (il freddo e l'abbigliamento insufficiente aumentano la probabilità di ammalarsi). La logica era che ogni volta che ci si ammala gravemente, bisogna avere le medicine, altrimenti si muore.
Si finisce il denaro e ci si ammala. La logica era che ogni volta che ci si ammala gravemente si deve pagare un medico, altrimenti si muore.
Finite le pallottole, venite attaccati da “cavalieri ostili” che vi massacrano.

Non ero affatto d'accordo con l'idea alla base di tre di queste quattro condizioni finali: solo morire di fame aveva senso per me. L'anno in cui ho ambientato il gioco (1848) era molto prima dell'invenzione dei moderni antibiotici. Le medicine disponibili all'epoca avevano poco effetto sulle malattie comunemente contratte lungo l'Oregon Trail. Non aveva quindi senso che tutte le malattie fossero 100% curabili con le medicine e 100% mortali senza medicine.

Allo stesso modo, non aveva senso che si potesse sempre trovare un medico disponibile in qualsiasi punto del percorso, e che si morisse sempre senza un medico, ma che si vivesse sempre se un medico era presente, e che un medico non ci avrebbe mai e poi mai curato gratuitamente. Alla fine ho eliminato completamente la medicina e i medici dal progetto.

Inoltre, non ero d'accordo con i frequenti attacchi di banditi, animali selvatici e “cavalieri ostili” nel gioco originale, e con la necessità di scacciarli tutti sparando. Nulla di tutto ciò era coerente con le mie ricerche storiche sull'Oregon Trail. Così ho eliminato tutte queste interazioni dal progetto.

Per il nuovo progetto, ho ripensato completamente il funzionamento del modello di simulazione sottostante. Parte di questo cambiamento è stato necessario a causa del passaggio da incrementi temporali di due settimane a incrementi temporali di un giorno. Ma la maggior parte del cambiamento è stata dettata dal desiderio di fornire un modello molto più ricco e anche da una visione completamente nuova di ciò che dovrebbe innescare la morte dei cinque membri del party. Il nuovo gioco avrebbe incluso un complesso modello di salute che utilizzava diverse variabili di stato, consentendo al gioco di tenere traccia della salute generale del gruppo su base giornaliera, nonché dello stato di recupero di ciascun membro del gruppo da eventuali incidenti o malattie.

Un'altra modifica importante è stata l'inclusione di un complesso modello climatico e meteorologico, basato sui valori effettivi mese per mese delle temperature medie e delle precipitazioni in vari punti del percorso. (Mentre il giocatore viaggia lungo il sentiero, il clima di ogni giorno si basa sul mese corrente e sulla posizione attuale del giocatore lungo il sentiero. La simulazione recupera la temperatura media corrispondente e aggiunge o sottrae una deviazione casuale. La simulazione recupera anche le probabilità di precipitazioni e genera condizioni che possono essere asciutte, piovose o molto piovose (se il tempo è molto freddo, la neve sostituisce la pioggia).

Invece di un singolo modello di simulazione, ho progettato i seguenti modelli interconnessi, ciascuno dei quali è composto da diverse formule matematiche interconnesse:

Clima e meteo
Salute
Progressi sul sentiero
Rifornimenti (denaro, cibo, buoi, proiettili, vestiti e pezzi di ricambio)
Attraversamento del fiume
Sistema di punteggio

Mi sono ritrovato con un'enorme serie di variabili di stato e un'enorme serie di formule matematiche. Con così tanti dettagli che si influenzano l'un l'altro, sapevo che avrei dovuto fare molte regolazioni fini del gameplay durante i test del gioco. Soprattutto negli ultimi tre mesi di sviluppo del prodotto, ho modificato tutte le formule e i valori iniziali per ottenere un equilibrio sempre migliore nel gameplay.

Il nuovo insieme di concetti fondamentali

Entro la fine di luglio 1985, Il sentiero dell'Oregon era completo e pronto per essere rilasciato. Con nostra grande gioia, il prodotto fu un successo immediato. Oltre a diventare molto popolare nel mercato domestico, divenne presto il prodotto software educativo più diffuso nelle scuole del Nord America. Il nostro nuovo gioco, insieme alle versioni successive, fece guadagnare milioni di dollari ai proprietari di MECC negli anni successivi. (Il MECC era nato come agenzia statale, ma in seguito fu venduto a investitori privati). Anche se queste ricchezze non arrivarono alle persone che avevano progettato e costruito il gioco, eravamo molto soddisfatti di vedere ciò che avevamo realizzato: la creazione di un prodotto di grande successo che alla fine divenne un gioco classico e un'icona culturale.

Progettare e costruire questa versione completamente nuova di Il sentiero dell'Oregon non è stato un processo lineare e lineare. Nei primi documenti di progettazione, avevo proposto e preso in considerazione ogni sorta di idea, di cui solo alcune sono entrate a far parte del prodotto finito. Al momento della pubblicazione del gioco, erano state incorporate le seguenti caratteristiche innovative:

Dettagli geografici reali. Il gioco OREGON originale non includeva quasi nessun dettaglio geografico. Non venivano mai citati fiumi, montagne, fortezze o altri punti di riferimento. Uno degli obiettivi principali del mio nuovo progetto è stato quello di incorporare un sacco di geografia reale, che si intrecciasse con il gioco e fosse illustrata con una grafica a colori accattivante.
Ciclo di viaggio basato su punti di riferimento. L'OREGON originale utilizzava un ciclo di gioco molto semplice di due settimane, senza punti di riferimento. Ho diviso il percorso principale in 16 segmenti, ognuno dei quali inizia e termina con un famoso punto di riferimento. Ad ogni punto di riferimento, e anche tra un punto di riferimento e l'altro, il giocatore prende molte decisioni che non erano disponibili nel gioco originale.
Cicli giornalieri continui. Il viaggio verso l'Oregon dura in genere circa 150 giorni. Dovevo incorporare un ciclo giornaliero nel progetto, in modo che gli eventi cruciali potessero verificarsi in qualsiasi giorno del viaggio e per consentire al giocatore di seguire i rifornimenti su base giornaliera. Per evitare di interrompere il gioco in continuazione, il gioco continua con il “pilota automatico” tra i punti di riferimento, finché il giocatore non lo interrompe o non si verifica un evento importante.
Scelta del percorso. L'OREGON originale presentava l'Oregon Trail come un unico percorso continuo, senza diramazioni o scelte di percorso. Ho introdotto una situazione più realistica in cui il giocatore deve occasionalmente prendere una decisione su quale strada seguire, e questa decisione può avere conseguenze molto importanti per il giocatore.
Attraversamento del fiume. Nell'OREGON originale non c'erano fiumi né attraversamenti. Ho reso gli attraversamenti dei fiumi una caratteristica importante del nuovo gioco. A ogni attraversamento, il giocatore deve prendere decisioni cruciali, basate sulle condizioni attuali, che sono fortemente influenzate dal clima recente, che varia a ogni partita.
Un'attività di caccia ripensata. Nell'originale OREGON, si caccia digitando la parola “BANG”. Il nostro obiettivo era quello di trasformare l'attività di caccia in un vero e proprio gioco di abilità in stile arcade, incorporando il terreno in cui si caccia, come la prateria, le montagne o il deserto. Allo stesso modo, le specie di animali che si trovano si basano sulla posizione del percorso in cui ci si trova.
Un sistema a punti. Nell'OREGON originale non esiste un sistema di punti. Per creare un alto livello di rigiocabilità del prodotto, ho progettato un sistema di punti strettamente legato al livello di difficoltà scelto. Inoltre, come ulteriore motivazione, l'elenco dei punteggi più alti è pre-popolato con una serie di nomi storici che coprono un'ampia gamma di punteggi.
Membri della famiglia. Nell'OREGON originale, il fatto che altre persone viaggino con voi è poco menzionato. Per rendere l'esperienza più personale, il mio progetto prevede che ogni giocatore fornisca quattro nomi aggiuntivi come compagni di viaggio. Se si prendono decisioni sbagliate o si incontra una serie di sfortune, i membri della propria famiglia o del proprio gruppo moriranno.
Parlare con le persone. Nell'OREGON originale non esiste un sistema di conversazione. Nel mio nuovo progetto ho permesso al giocatore di parlare con le persone lungo il percorso. Questo è un metodo importante per ottenere suggerimenti utili e scoprire dettagli storici e geografici di interesse. Inoltre, fa sembrare il gioco molto più umano.
Gioco del rafting sul fiume. L'originale OREGON non menziona il rafting lungo il fiume Columbia, che mi sembrava un pezzo di storia affascinante, oltre che una grande opportunità per includere un altro gioco arcade nel prodotto. Abbiamo quindi realizzato il gioco del rafting sul fiume, anche se in una versione più semplice rispetto a quella che avevamo previsto in origine.
Lapidi. Un'altra famosa caratteristica che abbiamo aggiunto è la possibilità di creare una lapide per se stessi dopo la morte. Questo intermezzo umoristico compensa il mancato completamento del viaggio da parte del giocatore. Ma il vero punto di forza è la memorizzazione dei dati della lapide sul disco di gioco, in modo che il giocatore successivo che utilizza lo stesso disco possa vedere la lapide.
Un modello sanitario dettagliato. L'OREGON originale non tiene traccia della salute del giocatore di turno in turno. Il mio nuovo progetto prevedeva un modello di salute continuo per l'intero gruppo, oltre al monitoraggio delle malattie e delle ferite individuali. Le condizioni atmosferiche, le razioni di cibo e il ritmo hanno effetti cumulativi sulla salute del gruppo, che può migliorare o diminuire nel tempo.
Un modello meteorologico dettagliato. L'OREGON originale non includeva un vero e proprio modello meteorologico, con stagioni e dati legati a diverse zone climatiche. (Nel nuovo gioco, il programma calcola il tempo ogni giorno, in base al mese e alla posizione corrente. Questo influisce a sua volta su molti altri fattori, come la salute, l'attraversamento dei fiumi, la disponibilità di acqua e così via.
Gestione robusta delle risorse. Il mio nuovo progetto prevedeva molti nuovi modi per il giocatore di gestire le proprie risorse, tra cui: 1) regolare il ritmo del viaggio, 2) acquistare tipi specifici di pezzi di ricambio, 3) riposare in qualsiasi momento per migliorare la salute del gruppo, 4) barattare con altri viaggiatori per acquisire risorse essenziali e 5) acquistare altri buoi ai forti.
Uno schermo da viaggio accattivante. Lo schermo da viaggio del prodotto del 1985, caratterizzato da un piccolo bue animato e da un carro, è diventato la rappresentazione iconica di tutta la storia di Il sentiero dell'Oregon gioco. La combinazione di elementi su questa schermata è molto memorabile ed efficace.
Il negozio generale di Matt. Nel gioco originale non si interagiva mai con le persone. Nel progetto del 1985, abbiamo introdotto il Matt's General Store. Matt è il simpatico proprietario del negozio che vi assiste negli acquisti, fornendovi consigli utili su cosa e quanto comprare.
Malattie specifiche. Nel gioco originale, se ci si ammala, la malattia non viene mai nominata. (Per il nuovo design, ho incorporato cinque malattie o sintomi spesso nominati dai viaggiatori dell'Oregon Trail: tifo, colera, morbillo, dissenteria, esaurimento e febbre. Stranamente, una di queste cinque ha catturato l'immaginazione popolare ed è diventata un grande meme. (“Sei morto di dissenteria”.”)
Livelli di difficoltà. Per incoraggiare la rigiocabilità, ho inserito nel gioco tre livelli di difficoltà. Ho scelto tre professioni distinte per rappresentare i tre livelli di difficoltà: banchiere, falegname e contadino. Queste scelte sono diventate anche un meme.
Commercio con le persone. In qualsiasi momento, tra un punto di riferimento e l'altro, il giocatore può tentare di scambiare oggetti con i passanti. Questo può essere molto utile in certe circostanze, soprattutto se un pezzo cruciale del carro si è rotto. Tuttavia, questo modulo è una pallida ombra del sistema di commercio che avevo intenzione di includere. In seguito ho inserito nel gioco un sistema di commercio completo e robusto. Lewis e Clark rimasero a casa.
Possibilità di riposare o cambiare ritmo. Il giocatore può scegliere di accelerare o rallentare il passo, o di fermarsi del tutto per qualche giorno di riposo. Queste decisioni rappresentano un importante compromesso tra la salute del gruppo e il progresso sul sentiero.
Musica d'epoca. A ogni punto di riferimento lungo il percorso, si può ascoltare una melodia diversa. Inoltre, ogni melodia è un vero motivo popolare all'epoca dell'Oregon Trail. Purtroppo, questa innovazione può essere più fastidiosa che utile, soprattutto sull'Apple II, che non ha un controllo del volume.

L'insieme di queste 21 innovazioni ha dato vita a un'esperienza molto diversa rispetto alle versioni precedenti del gioco. Il nuovo gioco era più lungo, con una serie molto più ricca di opportunità per prendere decisioni. Inoltre, permetteva ai giocatori di avere successo in più di un modo, utilizzando diverse strategie e tecniche di gioco possibili. Questo era essenziale per il mio obiettivo di rendere il gioco attraente per le ragazze come per i ragazzi, oltre che per una gamma più ampia di gusti. Alla fine, il nuovo gioco si è rivelato immensamente popolare presso un pubblico estremamente ampio.

Naturalmente, un'altra grande differenza è che l'OREGON originale era un gioco basato sul testo, mentre il progetto del 1985 era ricco di grafica a colori. La decisione di includere la grafica era una necessità ovvia, non un'innovazione. D'altra parte, alcune delle nostre decisioni su come includere la grafica erano effettivamente innovative. Per il gioco del 1985, abbiamo incorporato il maggior numero di dettagli grafici possibile sul disco dell'Apple II, tra cui la schermata di viaggio animata, gli attraversamenti animati del fiume, il gioco della caccia, il gioco del rafting e una grafica a schermo intero per ogni punto di riferimento.

Ogni tanto mi imbatto in un articolo online che suggerisce che la versione per Apple II del 1985 di Il sentiero dell'Oregon era essenzialmente identico al gioco originale del 1971, tranne che per l'aggiunta della grafica a colori. Questa affermazione è così ridicolmente inesatta che mi lascia completamente perplesso. In effetti, la maggior parte delle caratteristiche e dei dettagli che la gente associa al gioco sono stati inventati per la prima volta per il prodotto del 1985. D'altra parte, il mio nuovo progetto non sarebbe mai stato creato se non fosse stato per il grande successo dell'originale. Inoltre, la versione originale ha introdotto sette concetti chiave su cui si sono basate tutte le versioni successive del prodotto. Ma dopo l'uscita del mio progetto del 1985, ogni versione successiva ha trattato i 21 nuovi concetti principali di quel progetto come parte del nucleo essenziale del progetto originale. Allo stesso modo, anche molti dettagli minori del progetto del 1985 sono stati incorporati nelle versioni successive.

Perché il processo ha avuto successo

Alla fine abbiamo raggiunto e superato tutti gli obiettivi di questo progetto, tranne che per i tempi e il budget un po' più lunghi del previsto. Tuttavia, il prodotto è stato completato in tempo per il lancio sul mercato domestico nell'autunno 1985, come previsto. Fedele agli obiettivi, il prodotto ha avuto un enorme successo, non solo nel mercato domestico, ma anche in quello scolastico.

Abbiamo incontrato alcuni ostacoli e deviazioni durante la progettazione, la costruzione e il collaudo. Il sentiero dell'Oregon. Eppure, nel complesso, il processo è stato un successo. Ripensando ai dettagli del progetto, vedo diverse lezioni su come pianificare e avviare un nuovo progetto:

1. Cercate di ottenere molti input, ma non cedete alla progettazione da parte di un comitato.

Volevo che tutti i membri del team di prodotto esprimessero i loro pensieri e contribuissero con le loro idee. Tuttavia, raramente un comitato produrrà un buon progetto, né potrà prendere decisioni in tempi brevi. Pertanto, per le fasi iniziali della progettazione, ho iniziato con una fase divergente, in cui si generano idee, seguita da una fase convergente, in cui le idee vengono ristrette. Molte persone possono e devono partecipare alla fase divergente, ma non più di tre persone dovrebbero partecipare alla fase convergente per un particolare modulo. Dopo la selezione dei concetti vincenti, la maggior parte del lavoro di progettazione è ancora da fare, e la maggior parte di questo lavoro sarà svolto da singoli individui. Tuttavia, nel corso del progetto, i membri del team si forniscono regolarmente un feedback reciproco. Inoltre, nei momenti chiave del progetto, si sollecita il feedback di persone esterne al team e si conducono test sugli utenti. In questo modo continuiamo a mantenere l'equilibrio tra il ricevere idee da molte persone e il prendere decisioni con pochissime persone.

2. Creare il progetto in fasi successive di perfezionamento.

Prima di tentare di progettare Il sentiero dell'Oregon, Ho ritenuto importante definire le idee di alto livello, a partire dagli obiettivi: Perché stiamo creando questo prodotto? Chi è il pubblico di riferimento? Quali saranno i nostri criteri di successo? Poi ho proposto una struttura generale per il prodotto, con i moduli e le caratteristiche principali. In seguito, abbiamo definito ciascuno dei moduli e delle funzionalità a un livello medio di dettaglio, sufficiente a comunicare il funzionamento di ciascuno di essi. Infine, ho definito tutti i dettagli di ogni modulo e funzionalità. Nel frattempo, mentre il prodotto prendeva forma - prima come prototipo e poi come moduli di codice effettivi - ho continuato ad apportare miglioramenti al design. Ogni schermata è stata sottoposta a successive ondate di controlli per migliorare il layout, il testo e l'usabilità, e le equazioni matematiche sottostanti sono state messe a punto per migliorare il gameplay. Dubito che sarebbe stato possibile progettare tutto prima, in un unico enorme documento, prima di iniziare a lavorare alla realizzazione del prodotto. Tentare di creare un unico enorme documento all'inizio sarebbe stato uno spreco, nel migliore dei casi, e una catastrofe, nel peggiore.

3. Creare prototipi.

Sebbene sia utile disegnare schizzi delle schermate proposte, un prototipo fornisce ulteriori informazioni. Il primo obiettivo della prototipazione è la “visualizzazione”: permettere alle persone di vedere una visione del prodotto finito, anche se solo in forma grezza. In una seconda fase, il prototipo può essere reso parzialmente interattivo, consentendo alle persone di avere un assaggio del gioco finito. Entrambe queste fasi forniscono informazioni utili per modificare il design relativamente presto nel progetto, sicuramente molto prima di quanto avremmo fatto se avessimo aspettato una versione beta prima di mostrarla a tutti.

4. Testare i prototipi e le prime bozze di software con gli utenti.

È certamente utile che i compagni di squadra e gli altri colleghi valutino i prototipi, ma questo da solo non è sufficiente. È anche fondamentale indagare su come gli utenti reali reagiscono al prodotto, il prima possibile nel ciclo di sviluppo. Per quanto i progettisti siano esperti e perspicaci, ci saranno sempre delle sorprese quando gli utenti reali proveranno il prodotto. Queste sorprese vanno da piccoli dettagli a problemi più grandi. Per Il sentiero dell'Oregon, Una delle piccole sorprese è stata che i bambini non capivano la parola “outfit”, che ho cambiato in “set di vestiti”. Una sorpresa di medio livello è stata che molti giocatori erano confusi dalle schermate in cui si nominano i membri del party, quindi le ho riviste. Il problema più significativo che abbiamo riscontrato è che la schermata del viaggio, durante l'alpha testing, non suscitava l'interesse dei giocatori. Abbiamo quindi ridisegnato questa schermata, che è poi diventata la più famosa del prodotto.

5. Dare costantemente la priorità a ciò che deve essere fatto dopo.

In quasi tutti i progetti a cui ho lavorato, a un certo punto abbiamo dovuto ridimensionare i piani, in modo sottile o drastico. Questo è un motivo fondamentale per dare priorità ai vari componenti. Ponete sempre l'accento sui moduli e sulle funzionalità che hanno maggiori probabilità di essere presenti nel prodotto finito.

I rischi sono un altro fattore da considerare. Qualsiasi progetto presenta dei rischi, che sono legati alle incognite. Per ridurre i rischi, è fondamentale esplorare le incognite fin dalle prime fasi del progetto. Alcuni rischi si basano sulla tecnologia: questo modulo sarà abbastanza veloce? Riusciremo a far stare tutto sul disco? Alcuni rischi sono legati all'utente: gli utenti saranno in grado di completare con successo questo compito complicato? Gli utenti capiranno il significato e i dettagli di questa schermata cruciale? Le priorità nelle prime fasi del progetto sono la progettazione e la realizzazione di prototipi o moduli di prova che affrontino le principali incognite, aumentando così le probabilità di successo.

Questo è esattamente ciò che abbiamo fatto con Il sentiero dell'Oregon. Nelle prime fasi abbiamo deciso cosa fosse più importante illustrare con il prototipo interno. Poi abbiamo deciso quali fossero le funzioni più importanti da testare con i bambini e le abbiamo incluse nella versione Alpha. Subito dopo abbiamo stabilito le priorità di tutti i moduli e le funzionalità previste per il prodotto, partendo dal presupposto che non tutto sarebbe stato inserito nel prodotto finito. Fin dalle prime fasi, abbiamo anche elaborato piani tecnologici e condotto test tecnologici per affrontare i rischi tecnici.

Sintesi e ringraziamenti

Nel corso della mia carriera, ho lavorato a innumerevoli progetti software. Per la maggior parte di questi progetti, ho tutte le ragioni per essere orgoglioso dei risultati ottenuti, pur essendo consapevole di alcuni dettagli che avrebbero potuto essere ulteriormente migliorati. Tuttavia, ad eccezione di Il sentiero dell'Oregon-e in misura minore Mangiatori di numeri-Nessuno di questi progetti è sfociato in un prodotto che è diventato veramente famoso, anche se alcuni di essi (soprattutto le applicazioni basate sul Web che ho progettato per le aziende) sono stati molto utilizzati.

Il risultato è che mi sento grato per la fama che i miei prodotti sono riusciti a raggiungere. Sono particolarmente grato per aver avuto l'opportunità di lavorare a *The Oregon Trail *e per la combinazione di circostanze che hanno permesso al prodotto di diventare un successo così straordinario. Sono grato di aver potuto lavorare con colleghi di grande talento e dedizione, la cui collaborazione ha giocato un ruolo fondamentale nel successo del progetto. (I miei principali collaboratori sono stati Charolyn Kapplinger, John Krenz, Shirley Keran, Bob Granvin e Roger Shimada). Sono grato al MECC per avermi assegnato a questo progetto come progettista principale e capo progetto, e per avermi dato la possibilità di dirigere il progetto come meglio credevo (per la maggior parte del tempo). Sono grato a Don Rawitsch, Bill Heinemann e Paul Dillenberger per aver inventato la prima brillante versione del gioco, che ha generato tutte le versioni successive. E sono grato che milioni di persone abbiano potuto giocare e divertirsi con questo gioco, e che molti di loro lo ricordino con affetto dopo tutti questi anni.

R. Philip Bouchard ha trascorso 32 anni a progettare software per computer, 18 dei quali incentrati sul software didattico. È stato il principale progettista dei giochi per Apple II. Il sentiero dell'Oregon e I numeri da sgranocchiare. Per saperne di più sulle sue esperienze di design, si può consultare il suo sito web blog, dove questo articolo è stato originariamente pubblicato.