Du bist an Ruhr gestorben: Die Designgeschichte des Oregon Trails erforschen

Der Oregon Trail ist nach den meisten Maßstäben das erfolgreichste Bildungscomputerspiel aller Zeiten. Im Laufe der Jahre wurden viele Versionen des Spiels entwickelt, die bis ins Jahr 1971 zurückreichen. Die Version, von der viele Menschen annehmen, dass sie das "Original" ist - die Version, die ständig in Memes und Zeitschriftenartikel ist das Jahr 1985 Apple II Version. (Das Design von 1985 wurde auch auf dem IBM PC, dem Macintosh und anderen Plattformen umgesetzt, aber es erschien zuerst auf dem Apple II). Ich war der leitende Designer und Teamleiter dieser berühmtesten Version des berühmtesten Lernspiels und bin daher eine hervorragende Quelle, um genau zu erfahren, wie es zu diesem Design kam.

Da es sich hier um eine Erfolgsgeschichte handelt - und "Erfolg hat viele Väter" - werden in diesem Bericht die Namen mehrerer Personen genannt (nicht nur mein eigener Name, trotz der Prahlerei im Titel dieses Artikels). All diese Menschen haben eine wichtige Rolle für den Erfolg von Der Oregon Trail.

Es gibt mehrere Gründe für den weit verbreiteten Eindruck, die Version von 1985 sei das "Original". Ein offensichtlicher Grund ist, dass die Version von 1971 ein reines Textspiel war und nur relativ wenige Menschen die reine Textversion gesehen oder gespielt haben. Ein zweiter wichtiger Grund ist, dass die meisten Funktionen, die die Leute gerne mit dem Spiel verbinden, erst 1985 eingeführt wurden. Das Produkt von 1985 war weit mehr als nur eine neue Version - es war eine komplette Neukonzeption des Spiels über den Oregon Trail. Ich bin mir ziemlich sicher, dass der Entwurf von 1985 die originellste und kreativste Version in der gesamten Geschichte des Produkts war, abgesehen von der völlig originellen Version von 1971. Mit anderen Worten: Das Spiel, das letztendlich so erfolgreich wurde, wurde in zwei gleichwertigen Phasen erfunden - eine 1971 und die zweite 1984-85.

Willst du mehr über Spieldesign lesen?
5 Dinge, die du über Stardew Valley wissen solltest
Fotografieren mit einer Nintendo Game Boy Kamera von 1998
Die besten neuen Spiele für Designerinnen und Designer

Die wahre Originalversion

Die allererste Version von Der Oregon Trail begann als Idee im Kopf von Don Rawitsch, der 1971 ein Lehramtsstudent in Minnesota war. Er stellte sich ein Brettspiel vor, das von den Schülern in der Klasse, die er unterrichten sollte, gespielt werden konnte. Kurz nachdem Don mit der Arbeit an diesem Konzept begonnen hatte, teilte er seine Idee mit seinen Mitbewohnern - Bill Heinemann und Paul Dillenberger - die ebenfalls Lehramtsstudenten waren. Sie waren von Dons Idee begeistert, schlugen aber vor, dass es sich um ein Computerspiel und nicht um ein Brettspiel handeln sollte. Der Schulbezirk von Minneapolis, in dem alle drei unterrichteten, hatte vor kurzem einen Großrechner angeschafft, und jede Schule im Bezirk verfügte über ein Fernschreibterminal für den Fernzugriff auf den Computer. Außerdem hatten sowohl Bill als auch Paul gelernt BASICEine einfache Programmiersprache, die sich ideal für die Erstellung eines kleinen Computerprogramms wie das, das sie sich vorstellten, eignete.

Bild einer Fernschreibmaschine über Flickr.

Don stimmte der Planänderung schnell zu, und die drei begannen mit der Gestaltung und Programmierung des Konzepts. Zwei Wochen später, pünktlich zu der Klasse, die Don unterrichten sollte, war eine erste Rohfassung des Spiels fertig und konnte den Kindern gezeigt werden. Trotz der Unbeholfenheit der Fernschreibmaschine hatten die Kinder sichtlich Spaß an dem Spiel. Bill und Paul beobachteten ähnliche Ergebnisse an ihrer Schule. Das Spiel blieb für den Rest des Semesters verfügbar und konnte von den Schülern in ihrer Freizeit gespielt werden. Doch am Ende des Semesters, als seine Zeit als Lehramtsstudent zu Ende ging, löschte Don das Programm aus dem Computersystem.

Ein paar Jahre später begann Don seine Arbeit bei MECC (Minnesota Educational Computing Consortium), einer neuen staatlichen Behörde in Minnesota, deren Aufgabe es war, allen Schulen im Bundesstaat Zugang zu Computern zu verschaffen. Das Computermodell des MECC ähnelte dem des Schulbezirks von Minneapolis - ein zentraler Großrechner, auf den über ein Fernschreibterminal in jeder Schule zugegriffen werden konnte. Doch statt für einen einzelnen Schulbezirk war diese neue Organisation nun für den ganzen Staat zuständig. Don hatte einen Ausdruck des BASIC-Programms aus dem Spiel von 1971 aufbewahrt. 1974 tippte er dasselbe Programm in das Computersystem des MECC ein. Dann nahm er einige Feinabstimmungen vor, indem er die Häufigkeit der verschiedenen Zufallsereignisse im Spiel veränderte. 1975 stellte er das Spiel schließlich allen MECC-Nutzern zur Verfügung. OREGON (wie es damals hieß) wurde bald zur beliebtesten Lernaktivität auf dem System - und das blieb es auch, bis MECC 1983 seinen Großrechnerbetrieb einstellte.

Diese frühe reine Textversion von Der Oregon Trail war äußerst einfach - wie fast alle Bildungsaktivitäten auf dem MECC-Großrechner. Und doch tauchen sieben der Kernkonzepte, die im Spiel von 1971 vorkamen, in jeder Version seither wieder auf.

Diese Kernkonzepte sind:

• Der Spieler kauft Vorräte, bevor er die Reise nach Oregon antritt.
• Unterwegs gibt es Gelegenheiten, nach Nahrung zu jagen.
• Entlang der Route gibt es die Möglichkeit, in Forts einzukaufen.
• Der Spieler muss den Vorrat verwalten, damit er nicht ausgeht.
• Die Geschwindigkeit der Fahrt hängt von den aktuellen Bedingungen ab.
• Unglücksfälle kommen häufig vor.
• Das Spiel endet, wenn der Spieler/die Spielerin Oregon erreicht oder wenn er/sie unterwegs stirbt.

Das Spiel von 1971 war als ein sich wiederholender Zyklus aufgebaut. Jeder Zyklus entspricht einer zweiwöchigen Reise auf dem Wanderweg. Nachfolgend siehst du ein Beispiel für einen typischen Zyklus aus einer aktuellen Spielsitzung. Der meiste Text in diesem Beispiel wurde vom Computer getippt, aber manchmal hält der Computer an, um auf eine Antwort des Spielers zu warten. Die Antworten des Spielers sind gelb hervorgehoben:

Wie du an diesem Beispiel sehen kannst, beginnt jeder Zyklus mit einer Statusaktualisierung. Dann entscheidet der Spieler, ob er jagen will. (Manchmal gibt es auch die Option, ein Fort zu besuchen, wie hier gezeigt.) Wenn der Spieler sich für die Jagd entscheidet, schießt er das Gewehr ab, indem er "BANG" tippt, wenn er dazu aufgefordert wird. Wenn das Tippen schnell und genau war, ist die Jagd erfolgreich. Der Spieler entscheidet nun, wie viel er essen möchte. Schließlich ereignen sich ein oder mehrere "Unglücke", die die Vorräte verringern können. Dann wiederholt sich der Zyklus zwei Wochen später, wobei die in der Zwischenzeit verbrauchten Vorräte berücksichtigt werden. Der Zyklus geht weiter, bis der Spieler entweder Oregon erreicht oder bei dem Versuch stirbt. Für eine erfolgreiche Reise werden etwa 12 Zyklen benötigt - abhängig von verschiedenen Umständen, die die Reisegeschwindigkeit beeinflussen.

Für viele Spielerinnen und Spieler bestand der Reiz dieses Spiels vor allem in der Herausforderung, das Wort "BANG" schnell genug zu tippen, um erfolgreich zu sein, ohne einen Tippfehler zu machen. Daher bestand die typische Spielweise darin, in jedem Zyklus eine identische Antwort zu geben - zuerst tippst du "2″, um zu jagen, dann tippst du "BANG", dann tippst du "2″, um mäßig zu essen. Die einzige notwendige Abweichung ist, wenn einer der Vorräte gefährlich niedrig wird und der Spieler gezwungen ist, in einem Fort einzukaufen, anstatt zu jagen. Der zweite reizvolle Aspekt dieses Spiels war die Herausforderung, die Ressourcen zu verwalten - die Vorräte im Auge zu behalten, um sicherzustellen, dass keiner davon ausgeht, was ein fataler Fehler wäre. Der dritte reizvolle Aspekt ist, dass es so viele verschiedene Unglücke gibt, die passieren können. Du weißt also nie, was als Nächstes passiert - es sei denn, dir gehen die Vorräte aus, dann stirbst du wahrscheinlich ziemlich schnell.

Das ursprüngliche Design beinhaltete auch zufällige Angriffe von wilden Tieren, Banditen und "feindlichen Reitern", die jeweils zusätzliche Gelegenheiten boten, "BANG" zu tippen - und schlimme Konsequenzen, wenn man nicht schnell und genau tippte. Ende der 1970er Jahre wurde eine kleine Änderung am Spiel vorgenommen, so dass der Spieler nicht mehr im Voraus wusste, welches Wort er tippen musste, wenn es Zeit zum Schießen war. Manchmal war es "BANG", aber es konnte genauso gut "POW", "BLAM" oder "WHAM" sein.

Die Welt verändert sich

Im Jahr 1978 veröffentlichte Don Rawitsch den BASIC-Code für OREGON in Kreatives Rechnen Zeitschrift. Danach haben viele Leute den Code so verändert, dass er auf verschiedenen Marken von Mikrocomputern lief. Jemand - ich weiß nicht, wer - hat eine Version dieses Programmcodes auf einem Apple II installiert. Diese Version des Spiels war nicht neu, sondern verwendete größtenteils denselben BASIC-Code, der in der Zeitschrift erschienen war. Allerdings nahm der Autor drei wichtige Änderungen am Spiel vor, von denen eine eine Neukonzeption der Jagd war. Anstatt textbasiert zu sein - wie alle anderen Teile des Spiels - zeigte diese neue Aktivität eine Skizze eines Rehs, auf das der Spieler durch Drücken einer beliebigen Taste auf der Tastatur schießen konnte.

1979 kaufte MECC Apple II Computer in großen Mengen (zu einem vergünstigten Preis) und verkaufte sie zum Selbstkostenpreis an Schulen in ganz Minnesota weiter. 1980 begann das MECC auch, Disketten mit Apple II Software an diese Schulen zu verteilen. (Diese Disketten wurden den Schulen in Minnesota kostenlos zur Verfügung gestellt, aber mit erheblichem Gewinn an Schulen außerhalb von Minnesota verkauft.) Jede Diskette enthielt eine Sammlung von Programmen, die vom Großrechner des MECC portiert worden waren. Das Spiel OREGON erschien in zwei dieser Sammlungen, von denen eine den Namen "Elementary Volume 6" trug:"

MECC vertrieb "Elementary Volume 6″ noch viele Jahre lang, und das Spiel OREGON blieb das bekannteste Produkt von MECC, auch nachdem MECC seine Mainframe-Aktivitäten eingestellt hatte, um sich ganz auf Mikrocomputer (Apple II, Atari, IBM usw.) zu konzentrieren. Doch zwischen 1980 und 1984 änderte sich die Wettbewerbslandschaft komplett. 1980 wurde die gesamte Computersoftware für den Unterricht noch von Amateuren entwickelt und programmiert - von Hobbyisten und Lehrern, die diese kleinen, einfachen Programme in ihrer Freizeit erstellten. Außerdem waren noch keine großen privaten Unternehmen in den Markt für Lernsoftware eingestiegen - weder in den Schulmarkt noch in den Markt für Privatpersonen.

Im Jahr 1984 sah die Welt der Lernsoftware ganz anders aus. Zahlreiche große und kleine Unternehmen hatten begonnen, Computersoftware für den Unterricht zu verkaufen. Einige dieser Unternehmen spezialisierten sich auf den Schulmarkt, andere auf den Privatkundenmarkt. 1984 wurde die beste Lernsoftware von Fachleuten entwickelt und programmiert - von Menschen, die hauptberuflich solche Software entwickeln oder programmieren. Um wettbewerbsfähig zu bleiben, vollzog sich derselbe Wandel auch bei MECC. Bis 1983 hatte MECC einen Stab von professionellen Designern und Programmierern eingestellt, die die Aufgabe hatten, hochwertige Originalsoftware für den Apple II zu entwickeln. 1984 war die Verbesserung der Produkte von MECC für jeden offensichtlich. Dies war der Beginn von MECCs "goldenem Zeitalter" - eine zehnjährige Periode, in der MECC Jahr für Jahr außergewöhnliche neue Software herausbrachte, die vor allem für den Schulmarkt bestimmt war, aber auch einige Titel für den Privatkundenmarkt enthielt.

Obwohl sich MECC nun fast ausschließlich auf die Entwicklung neuer, origineller Titel konzentrierte, gab es auch drei berühmte Simulationen aus den 1970er Jahren.Oregon Trail, Limonadenstand, und Odellsee-, die sie nicht aufgeben wollte. Alle drei Aktivitäten waren bereits 1980 auf den Apple II portiert worden, aber 1984 waren sie peinlich veraltet - vor allem, was ihr Aussehen betraf. MECC beschloss, neue Versionen aller drei Aktivitäten zu erstellen.

Die Entscheidung, mit der Vergangenheit zu brechen

In diesem Zusammenhang wurde ich im Oktober 1984 vom MECC ausgewählt, um die Erstellung einer neuen Version der Der Oregon Trail. Als ich 1981 zum MECC kam, verfügte ich über umfangreiche Erfahrungen in der Gestaltung und Programmierung computergestützter Simulationen (obwohl alle meine Simulationen vor 1981 für Studenten gedacht waren). Ich war die einzige Person im Team, die über diese Art von Erfahrung verfügte, und deshalb war ich die logische Wahl für die Rolle des Chefdesigners und Teamleiters. Dennoch war ich von den Details des Auftrags, den ich erhielt, überrascht.

Zunächst einmal wurde mir gesagt, ich solle ein Produkt für den privaten Markt entwerfen, nicht für den Schulmarkt. Bislang hatte sich MECC immer auf den Schulmarkt spezialisiert. Dies wäre der allererste Versuch von MECC, ein Produkt speziell für den privaten Markt zu entwickeln.

Zweitens sollten meine Anweisungen weit mehr als nur eine besser aussehende Version des Originalspiels sein. Mir wurde gesagt, ich solle das ursprüngliche Konzept übernehmen und damit arbeiten. Ich sollte das ursprüngliche Konzept erweitern und ein viel ausgefeilteres und robusteres Spiel entwickeln. Das konnte ich auf jede Art und Weise tun, die ich für richtig hielt, vorausgesetzt, ich behielt die Magie bei, die das Original so beliebt gemacht hatte. Allerdings musste ich das Produkt speziell für den Apple II entwerfen, was zu einigen ernsthaften Einschränkungen führte, z. B. musste ich mit einer Palette von nur sechs Farben arbeiten. (Ich hätte es vorgezogen, einen neueren Rechner zu verwenden, wie zum Beispiel den Commodore 64.)

Mein Auftrag zur Überarbeitung und Neugestaltung Der Oregon Trail war anfangs fast überwältigend - die Möglichkeiten waren endlos, aber ich musste es bei der ersten Veröffentlichung absolut richtig machen. 13 Jahre lang, von 1971 bis 1984, war das OREGON-Spiel im Wesentlichen unverändert geblieben. Ein paar kleine Details waren im Laufe der Zeit verändert worden, aber nie war das Produkt komplett neu konzipiert und gestaltet worden. Auch die zugrunde liegenden Modelle - die Strukturen, Algorithmen und Annahmen, auf denen das Spiel basiert - wurden nie verändert. Zum ersten Mal wollten wir alles über den Haufen werfen - einschließlich der gesamten Softwareprogrammierung, die noch aus dem Jahr 1971 stammte - und ganz von vorne anfangen. Jedes Detail musste neu überdacht werden. Außerdem musste ich ein viel reichhaltigeres und aufwändigeres Erlebnis schaffen als das ursprüngliche OREGON - und das würde eine Menge neues, originelles Denken erfordern.

Zum Start des Projekts habe ich eine wichtige Kennzahl definiert, die als Eckpfeiler unseres Ansatzes dienen sollte: "Mögen die Kinder, die die alte Version lieben, die neue Version noch mehr?" Die Idee war, diesen Test während des Projekts regelmäßig durchzuführen, um zu überprüfen, ob wir noch auf dem richtigen Weg sind. Wann immer wir uns in die Nesseln setzten, holte uns dieser Maßstab in die Realität zurück und ermöglichte es uns, das große Ganze wieder zu sehen.

Da ich ein Produkt für den heimischen Markt entwickelte, wusste ich, dass ich ein Spiel entwickeln musste, das sowohl unterhaltsam als auch lehrreich ist. Ich war der Meinung, dass es möglich war, beides zu erreichen, ohne dabei ernsthafte Kompromisse einzugehen - aber ich musste bei den Details eine sorgfältige Balance finden. Ich war der Meinung, dass sowohl der Bildungswert als auch der Unterhaltungswert daraus resultieren sollten, dass der Spieler in eine historisch korrekte Erfahrung eintaucht.

Von Anfang an war mir klar, dass dieses Projekt viele Herausforderungen mit sich bringen würde, aber das Problem des Platzmangels schien eine besondere Herausforderung zu sein. Das neue Spiel sollte reichhaltige Farbgrafiken enthalten, aber die Grafiken würden viel Platz benötigen - sowohl auf der Diskette als auch im RAM (Speicher) des Apple II. Außerdem hoffte ich, viele neue Details und Spielaspekte hinzufügen zu können, die alle Platz benötigen würden. Leider habe ich das Spiel für einen Computer entwickelt, der nur 64K RAM hatte. Außerdem sollte das Produkt auf einer doppelseitigen 5,25″-Diskette vertrieben und gespielt werden, was insgesamt nur 280 K Speicherplatz bedeutete. (Der Apple II hatte übrigens keine Festplatte, sondern nur ein Diskettenlaufwerk).

Als das Projekt begann, bestand unser Kernteam aus fünf Personen. Neben mir (Philip Bouchard) gehörten John Krenz (leitender Programmierer), Charolyn Kapplinger (leitende Künstlerin), Shirley Keran (Forschung) und Bob Granvin (zusätzliche Programmierung) dazu. Wir alle fünf spielten eine aktive Rolle beim Brainstorming und bei der Planung des Produkts, obwohl MECC Bob schließlich zu einem anderen Projekt abkommandierte, das seine Aufmerksamkeit benötigte. Und so begannen wir fünf ein Projekt, das zu MECCs bisher größter Anstrengung wurde und insgesamt 10 Monate dauerte, von Oktober 1984 bis Ende Juli 1985.

Entwicklung von Schlüsselkonzepten

Beim traditionellen Design-Ansatz von MECC (seit 1984) stellt sich der/die Lerndesigner/in zunächst eine computergestützte Schüleraktivität vor und erstellt dann eine Reihe von Skizzen, die veranschaulichen, was bei jedem der wichtigsten Schritte der Aktivität auf dem Bildschirm erscheinen soll. Diese Sammlung von Skizzen wird dann mit schriftlichen Notizen ergänzt, die zusätzliche Details enthalten. Die Skizzen und Notizen bilden zusammen ein "Designdokument". Der Designer prüft das Dokument dann mit einem kleinen Team von bis zu drei anderen Personen - dem leitenden Programmierer, dem leitenden Grafikdesigner und einem erfahrenen Programmierer/Analysten. Gemeinsam stellen sie fest, welche Details im Entwurf fehlen und helfen dabei, alle anderen Probleme zu lösen. Der Designer nimmt dann alle Ergänzungen oder Änderungen vor, die zur Vervollständigung des Entwurfs notwendig sind, und das Team macht sich an die Arbeit, um die Grafiken zu erstellen und den Programmcode zu generieren.

Dieses Modell funktionierte gut genug für die relativ einfachen Produkte, die MECC bis dahin entwickelt hatte, aber ich konnte mir vorstellen, dass es für das Produkt, das ich entwerfen wollte, nicht funktionieren würde. Zunächst einmal stellte ich mir vor, dass das Spiel auf einer komplexen, ineinandergreifenden Reihe von mathematischen Simulationsmodellen basieren würde - einem Wettermodell, einem Gesundheitsmodell, einem Reisemodell und so weiter. Außerdem würde jedes dieser Modelle auf einer komplexen, ineinander greifenden Reihe von mathematischen Formeln beruhen. Das bedeutete nicht nur, dass ich eine große Anzahl von Formeln ausarbeiten musste, sondern auch, dass das Design in mehreren Schritten spezifiziert und implementiert werden musste, anstatt alles auf einmal.

Zweitens war ich der Meinung, dass der beste Weg, ein innovatives und erfolgreiches Design zu entwickeln, darin besteht, mit einer Reihe von ehrgeizigen neuen Ideen zu beginnen und diese Ideen dann schrittweise zu verfeinern und zu testen - zuerst durch die Erstellung eines einfachen Prototyps und dann durch den Aufbau des echten Produkts, einen Aspekt nach dem anderen. Bei jedem Schritt des Prozesses sollten wir bewerten, wo wir stehen, verglichen mit dem, wo wir hinwollen, und dann Prioritäten setzen, was als Nächstes zu tun ist. Einige unserer liebgewonnenen Ideen müssen wir auf dem Weg dorthin aufgeben, aber wenn wir ständig Prioritäten setzen und uns verbessern, werden wir am Ende ein erfolgreiches Ergebnis erzielen. (Ich habe das Konzept der sukzessiven Verfeinerung zum ersten Mal gelernt und angewendet, als ich in den 1970er Jahren Informatik studiert habe. Jahrzehnte später sah ich viele Überschneidungen zwischen diesen Ideen und dem Konzept der "agilen Programmierung").

Aber zuerst muss ich das Grundgerüst für das Spiel entwerfen, und das hat mich ein paar Wochen lang in Atem gehalten. Das ursprüngliche OREGON basierte auf dem Konzept der "Runden", die jeweils genau zwei Wochen Echtzeit repräsentieren. Dieser einfache Rahmen war gut für den ursprünglichen Zweck geeignet - ein textbasiertes Spiel, das mit einem Fernschreiber gespielt wurde - aber er war schlecht an die Bedürfnisse des neuen Spiels angepasst. Ich wollte einen Rahmen schaffen, der eng mit der tatsächlichen Geografie des Oregon Trails verbunden war, und ich wollte dem Spieler viel mehr Möglichkeiten geben, Entscheidungen zu treffen - nicht nur, was er kaufen und wie viel er essen sollte. Es wurde schnell klar, dass ich für das neue Spiel einen völlig anderen Rahmen erfinden musste. Aber als ich eine Idee nach der anderen in Betracht zog, schien keine dieser neuen Ideen zu funktionieren.

Also zerlegte ich das Problem in seine Einzelteile und begann, jedes Stück einzeln anzugehen. Über einen Zeitraum von mehreren Wochen gelang es mir schließlich, für jedes Problem eine Lösung zu finden. Der daraus resultierende neue Rahmen für Der Oregon Trail basierte auf sieben Schlüsselkonzepten, von denen keines im Entwurf von 1971 enthalten war:

1. Um das neue Design mit dem Die tatsächliche Geografie des Oregon TrailsDie Reise besteht aus verschiedenen Abschnitten unterschiedlicher Länge, die jeweils an einer wichtigen Sehenswürdigkeit entlang des Weges enden. (Von all den vielen Unterschieden zwischen dem Produkt von 1971 und dem Entwurf von 1985 ist dies vielleicht der wichtigste - auch weil er so viele andere entscheidende Änderungen ermöglichte).

2. An jeder Landmarke gibt es eine Reihe von Aktivitätsmodulen. In vielen Fällen gibt es eine Schlüsselaktivität, die mit der Landmarke verbunden ist, z. B. die Überquerung eines Flusses oder der Kauf von Waren in einem Fort.

3. Die Sehenswürdigkeiten sind in verschiedene geografische Zonen eingeteilt, jede mit ihren eigenen Daten über Klima, Gelände und wilde Tiere.

4. Die meisten Aktivitätsmodule sind datengesteuert und enthalten eine Zufallsgenerierung, die jedes Mal, wenn das Modul verwendet wird, ein anderes Erlebnis bietet. Wenn zum Beispiel die Jagdaktivität gestartet wird, nutzt sie die Zonendaten, um Tiere und Gelände zu präsentieren, die zur aktuellen Position auf dem Pfad passen. Aber selbst wenn der Spieler/die Spielerin immer wieder in derselben Zone jagt, wird die Anordnung des Geländes immer einzigartig sein und die Tiere werden zu unvorhersehbaren Zeiten und an unvorhersehbaren Orten erscheinen.

5. Zusätzlich zum Zyklus von Landmarke zu Landmarke gibt es einen unabhängigen täglichen Zyklus, der neben den Zufallsereignissen auch alle Berechnungen zur Ressourcenverwaltung (Vorräte, Gesundheit usw.) enthält. Daher beträgt der Hauptrechenzyklus im Entwurf von 1985 nur einen Tag statt des zweiwöchigen Zyklus im ursprünglichen Entwurf. Das hat enorme Auswirkungen auf alle Berechnungen und alle Interaktionen.

6. Zwischen den Orientierungspunkten wird die Reise automatisch fortgesetzt, aber der Nutzer kann jederzeit eine Pause einlegen. (Das war ein besonders wichtiges Konzept, weil es dem Nutzer Zugang zu vielen Aktivitäten und Ereignissen verschafft, ohne das Spiel ständig zu unterbrechen.) Die Reise wird jedoch automatisch unterbrochen, wenn ein wichtiges Ereignis eintritt.

7. Wenn du zwischen den Landmarken pausierst, hast du Zugang zu einer ganzen Reihe von Aktivitätsmodulen, von denen sich einige von den an den Landmarken verfügbaren Aktivitäten unterscheiden. (Zum Beispiel kannst du an Landmarken mit Leuten reden und zwischen den Landmarken auf die Jagd gehen).

Dieser neue Rahmen unterschied sich grundlegend von dem Entwurf aus dem Jahr 1971 und ermöglichte es mir, ein viel reichhaltigeres Erlebnis für die Spieler/innen zu schaffen. In dem neuen Entwurf sah die Beziehung zwischen den Aktivitätsmodulen folgendermaßen aus:

Mit dieser hochflexiblen Struktur als Rückgrat des neuen Produkts konnten wir nun planen, welche Aktivitäten auf der Reise zwischen den Sehenswürdigkeiten (A-F im Diagramm) und welche Aktivitäten an den einzelnen Sehenswürdigkeiten (G-L im Diagramm) zugänglich sein würden. Jedes dieser verschiedenen Module (dargestellt durch die vier Rechtecke und die 12 Kreise) kann separat entworfen und programmiert werden. Darüber hinaus könnte jedes des halben Dutzend mathematischer Simulationsmodelle (die in diesem Diagramm nicht dargestellt sind, aber unter dem Ganzen arbeiten) ebenfalls separat entworfen und programmiert werden.

Meine Kolleginnen und Kollegen waren von diesem neuen Rahmen begeistert, also begann ich mit der Ausarbeitung der Details. Zunächst erstellte ich auf der Grundlage meiner Recherchen und der meiner Kollegin Shirley eine Liste mit in Frage kommenden Orientierungspunkten. Dann habe ich die Liste anhand verschiedener Auswahlkriterien so reduziert, dass die Reise aus etwa 16 Etappen bestehen würde. Außerdem führte ich das Konzept der "Abzweigungen" ein, d. h., dass der Spieler neben der Hauptroute manchmal auch die Möglichkeit hat, eine alternative Route zu nehmen. Dann begann ich mit der Erstellung einer Liste von möglichen Aktivitätsmodulen und erstellte systematisch "Konzeptdokumente" für die vielversprechendsten Ideen.

In dieser Phase der Konzeptentwicklung habe ich mich intensiv mit meinen Teamkollegen beraten. Vor dem Verfassen eines jeden Konzepts besprach ich die Ideen, die ich hatte, in der Regel mit meinen Teamkollegen. Und nachdem ich jedes Konzeptdokument geschrieben hatte, besprach ich es mit meinen Teamkollegen, um ihr zusätzliches Feedback einzuholen. Obwohl ich bis auf eine Ausnahme alle Konzeptdokumente verfasst habe, flossen die Ideen meiner Teamkollegen (Cheryl, John, Shirley und Bob) oft in meine Dokumente ein. Das gilt vor allem für die ersten Konzepte für die Jagd, die Bob, John und ich gemeinsam ausgearbeitet haben.

Den Menschen in die Gestaltung einbeziehen

Zu Beginn des Projekts war es meine zweithöchste Priorität - gleich nach der Einbeziehung realer geografischer Gegebenheiten -, menschliche Charaktere in das Design einzubinden. Im Entwurf von 1971 gab es keine Menschen, und deshalb reist man die gesamte 2000-Meilen-Route, ohne jemals einen anderen Menschen zu treffen oder mit ihm zu interagieren. Das wollte ich ändern. Mir fielen viele verschiedene Konzepte ein, wie der Spieler mit menschlichen Charakteren entlang der Strecke interagieren könnte - oder zumindest andere Menschen wahrnehmen könnte - und ich hoffte aufrichtig, fast alle dieser Ideen in das fertige Produkt einfließen zu lassen. Doch als das Projekt voranschritt, musste ich einige meiner liebgewonnenen Konzepte streichen, weil der Platz auf der Diskette und das Budget für die Entwicklung und den Bau des Produkts begrenzt waren. Dennoch konnte ich vier der Konzepte in das Design einfließen lassen, von denen jedes einen großen Einfluss auf das "menschliche Gefühl" des Produkts von 1985 hatte:

• Bevor du die Reise antrittst, nennst du vier weitere Personen, die mit dir reisen werden - in der Regel Familienmitglieder oder Freunde. Jedes Mitglied deiner 5-köpfigen Gruppe kann krank werden oder verunglücken. Während du unterwegs bist, ist es dein wichtigstes Ziel, dass alle diese Personen am Leben und gesund bleiben. Wenn einer von ihnen krank wird oder stirbt, wird er namentlich erwähnt. Diese Sammlung von Konzepten war eine wichtige Ergänzung für das neue Design.

• Wenn du deine Waren einkaufst, bevor du die Reise antrittst, betrittst du einen Laden ("Matt's General Store") und interagierst mit dem Besitzer des Ladens. Matt gibt dir hilfreiche Tipps, während du deine Einkäufe erledigst.

• Auf dem echten Oregon Trail versammelten sich die Menschen an den einzelnen Grenzsteinen. Zu diesen Menschen gehörten nicht nur andere Reisende, sondern auch amerikanische Ureinwohner, lokale Händler und Soldaten. Deshalb kann der Spieler an jeder Landmarke im Spiel drei verschiedene Personen treffen und mit ihnen sprechen - jede von ihnen bietet eine interessante Perspektive auf ihre Erfahrungen. Außerdem enthalten viele dieser Gespräche hilfreiche Tipps, wie man die Reise überleben kann. (Leider konnten wir aufgrund des begrenzten Speicherplatzes keine Bilder dieser Personen einfügen).

• Wenn du es bis nach Oregon schaffst, wird die Highscore-Liste mit den Namen von Menschen gefüllt, die tatsächlich nach Oregon gereist sind oder die als frühe Entdecker in der Region tätig waren.

Dank der federführenden Grafikdesignerin Charolyn Kapplinger sind auf vielen der großen Landmark-Grafiken auch Menschen zu sehen. Auch das trägt wesentlich zur menschlichen Seite des Designs bei.

Mein größtes Bedauern bezüglich Der Oregon Trail ist, dass ich die meisten meiner Ideen für komplexe, nuancierte Interaktionen mit den amerikanischen Ureinwohnern aufgeben musste. Mehrere solcher Module waren in den Konzepten enthalten, die ich aufgeschrieben hatte. Ein paar der einfacheren Ideen haben es jedoch in das fertige Produkt geschafft. So ist es zum Beispiel viel wahrscheinlicher, dass du den Snake River erfolgreich überquerst, wenn du einen einheimischen Indianer als Führer anheuerst - so wie es auch auf dem echten Oregon Trail der Fall war.

Andere Top-Prioritäten

Eine weitere Priorität war es für mich, Flussüberquerungen einzubeziehen - ein wichtiger Aspekt des Oregon Trails, der in der ursprünglichen Planung fehlte. Ich wählte eine Reihe repräsentativer Flussüberquerungen aus - eine kleine Teilmenge der tatsächlichen Anzahl von Flussüberquerungen, die die Reisenden auf dem Trail gemacht haben. An jedem Fluss muss der Spieler zwischen mehreren Überquerungsmethoden wählen und dabei die aktuellen Bedingungen an der Kreuzung berücksichtigen. Diesem Modul liegt ein sehr detailliertes Simulationsmodell zugrunde, das die aktuellen Bedingungen des Flusses (u.a. basierend auf dem aktuellen Wetter) und die Wahrscheinlichkeiten der verschiedenen Ergebnisse steuert, die von den Bedingungen und der Wahl des Spielers abhängen. Die Ergebnisse werden in einer spannenden Animation dargestellt, die viele Spieler/innen in helle Aufregung versetzt.

Eine weitere meiner Prioritäten war es, neben der Jagd zwei weitere "Action"-Aktivitäten einzubauen. Ich änderte diesen Plan bald so ab, dass eine dieser Aktivitäten eher ein erweitertes Logikrätsel als ein Actionspiel sein sollte. Diese beiden Aktivitäten sollten mit der letzten Etappe der Reise nach Oregon, den letzten 100 Meilen, verbunden sein. Der Spieler kann wählen, ob er mit dem Floß den Columbia River hinunterfährt (die Action-Aktivität) oder die Barlow Toll Road nimmt. In diesem Fall besteht die Aktivität darin, den Wagen durch das schwierige bergige Gelände entlang der Strecke zu bringen. Auch hier mussten wir aus Platz- und Kostengründen Abstriche machen, aber eine abgespeckte Version des Rafting-Spiels hat es schließlich in das Produkt geschafft.

Eine weitere Priorität war es, so viele Möglichkeiten wie möglich zu finden, um den Wiederspielwert des Produkts zu erhöhen. Das war für MECC bei früheren Produkten nur selten ein Thema, weil alle diese Produkte auf den Schulmarkt ausgerichtet waren. Für Schulen, in denen es viel mehr Kinder als Computer gibt und die Zugriffszeit sehr begrenzt ist, wurden die meisten Produkte von MECC so entwickelt, dass man den vollen Wert des Produkts in kurzer Zeit erleben kann. Aber für den privaten Markt musste ich ein Produkt entwerfen, das ein Kind immer wieder besuchen kann - und das auch nach 20, 30 oder 40 Stunden Spielzeit noch interessant ist. Um die Wiederholung des Spiels zu fördern, habe ich eine lange Liste von Funktionen und Details in das neue Design eingebaut:

• Der anfängliche Motivationsfaktor - identisch mit dem Motivator im Originalprodukt - besteht darin, die gesamte Reise nach Oregon zu überleben. Wie im Original scheitern die meisten Spieler/innen beim ersten Versuch, aber sie merken, dass sie es besser machen können. Und so versuchen sie es immer wieder und werden dabei immer besser, bis sie es schließlich schaffen, Oregon zu erreichen.

• Sobald der Spieler zum ersten Mal Oregon erreicht, gibt es eine Überraschung: Wenn der Spieler bis nach Oregon überlebt, erhält er eine Punktzahl. Dieser Punktestand basiert auf verschiedenen Faktoren, die klar aufgeschlüsselt sind. Genau in dem Moment, in dem der Spieler das ursprüngliche Ziel - Oregon zu erreichen - erreicht hat, wird ein neues, sehr motivierendes Ziel enthüllt: eine viel bessere Punktzahl zu erreichen.

• Der Spieler sieht auch, dass die Highscore-Liste bereits mit Namen gefüllt ist - und die meisten dieser Personen haben eine höhere Punktzahl als der Spieler erreicht hat. Diese anfängliche Liste ist ein klarer Maßstab, nach dem der Spieler streben muss - er muss die Liste immer weiter nach oben klettern, bis er schließlich die höchste Punktzahl auf der Liste (die des Entdeckers Stephen Meek) übertrifft.

• Während der Spieler versucht, eine höhere Punktzahl zu erreichen, wird deutlich, dass es notwendig ist, die schwierigeren Startbedingungen zu wählen - als Zimmermann (mit weniger Geld) oder als Bauer (mit noch weniger Geld) zu reisen, anstatt als Bankier zu reisen. Obwohl es schwieriger ist, Oregon zu erreichen, wenn du weniger Geld hast, bekommst du mehr Punkte für deine Bemühungen.

• Das neue Spiel bietet viel mehr Optionen und alternative Ansätze als das ursprüngliche Spiel, die es zu erkunden gilt. Mit der Zeit interessieren sich viele Spieler/innen dafür, diese Alternativen zu erkunden. Was wäre, wenn ich in einem anderen Monat beginne? Was ist, wenn ich das Tempo oder die Rationen ändere? Was, wenn ich ab und zu Pausen einlege? Was, wenn ich mit viel mehr Leuten rede, um Ratschläge zu bekommen? Was wäre, wenn ich jeden Fluss schwimmend überquere, anstatt zu versuchen, einen von ihnen zu durchqueren? Was wäre, wenn ich weniger jagen würde (was im neuen Design einen Tag Zeit in Anspruch nimmt) und mehr einkaufen würde - oder umgekehrt? Was wäre, wenn ich mehr Ersatzteile für meine Wagen mitnehme? Was ist, wenn ich die Barlow Toll Road nehme, anstatt den Columbia River zu befahren - oder umgekehrt?

• Wie im Originalspiel werden einige Spieler immer wieder spielen wollen, nur um auf die Jagd zu gehen. Deshalb wollte ich, dass das neue Jagdspiel sowohl herausfordernd als auch fesselnd ist. All diese Faktoren - und einige andere, die ich bei der Entwicklung berücksichtigt habe - führten zu einem Spiel mit einem sehr hohen Wiederspielwert. Ohne diese Eigenschaft wäre das Spiel auf dem heimischen Markt nicht sehr erfolgreich gewesen.

Die mathematischen Modelle

Sowohl im Originalspiel von 1971 als auch in der neuen Version von 1985 wird die Simulation durch eine Reihe von mathematischen Formeln gesteuert, die an Zustandsvariablen gebunden sind. Jede Zustandsvariable zeigt den aktuellen Wert einer wichtigen Größe an. Im Entwurf von 1971 gab es genau acht Zustandsvariablen:

• Bargeld (in Dollar)
• Lebensmittel (als Dollarwert)
• Munition (die Anzahl der Kugeln)
• Kleidung (als Dollarwert)
• Verschiedene Lieferungen (als Dollarwert)
• Ochsen (als Dollarwert)
• Bislang zurückgelegte Strecke (in Meilen)
• Aktuelles Datum (erhöht um Zwei-Wochen-Sprünge)

Beachte, dass es im Produkt von 1971 keine Zustandsvariable für die Gesundheit gibt. Daher hängt deine Gesundheit in der aktuellen Runde in keiner Weise von deiner Gesundheit in der vorherigen Runde ab. Das Spiel endet, wenn du stirbst, und du kannst an einem der folgenden Zustände sterben:

• Dir geht das Essen aus und du verhungerst.
• Dir gehen die "sonstigen Vorräte" aus und du wirst krank. (Kaltes Wetter und unzureichende Kleidung erhöhen die Wahrscheinlichkeit, krank zu werden.) Der Grundgedanke war, dass du jedes Mal, wenn du ernsthaft krank wirst, Medizin haben musst, sonst wirst du sterben.
• Wenn du kein Geld mehr hast, wirst du krank. Der Grundgedanke war, dass du jedes Mal, wenn du ernsthaft krank wirst, einen Arzt bezahlen musst, sonst wirst du sterben.
• Dir gehen die Kugeln aus und du wirst von "feindlichen Reitern" angegriffen, die dich niedermetzeln.

Ich war mit der Idee hinter drei dieser vier Endspielbedingungen nicht einverstanden - nur das Verhungern machte für mich Sinn. Das Jahr, in dem ich das Spiel ansetze (1848), war lange vor der Erfindung moderner Antibiotika. Die damals verfügbaren Medikamente hatten kaum eine Wirkung auf die Krankheiten, die man sich entlang des Oregon Trails zuzog. Daher machte es keinen Sinn, dass alle Krankheiten 100% mit Medizin heilbar und 100% ohne Medizin tödlich sein sollten.

Es machte auch keinen Sinn, dass du immer einen verfügbaren Arzt irgendwo auf dem Weg finden konntest und dass du ohne Arzt immer sterben würdest, aber immer leben würdest, wenn ein Arzt anwesend wäre - und dass ein Arzt dich niemals kostenlos behandeln würde. Schließlich habe ich Medizin und Ärzte ganz aus dem Entwurf gestrichen.

Ich war auch mit den häufigen Angriffen von Banditen, wilden Tieren und "feindlichen Reitern" im Originalspiel nicht einverstanden - und mit der Notwendigkeit, sie alle zu vertreiben, indem man auf sie schießt. All das entsprach nicht meinen historischen Recherchen über den Oregon Trail. Also habe ich all diese Interaktionen aus dem Entwurf entfernt.

Für das neue Design habe ich das zugrunde liegende Simulationsmodell komplett neu konzipiert. Ein Teil dieser Änderung war notwendig, weil ich von zweiwöchigen Zeitschritten auf eintägige Zeitschritte umgestiegen bin. Aber der größte Teil der Änderung wurde von dem Wunsch angetrieben, ein viel reichhaltigeres Modell bereitzustellen, und auch von einer völlig neuen Vision, was den Tod der fünf Gruppenmitglieder auslösen sollte. Das neue Spiel enthielt ein komplexes Gesundheitsmodell mit verschiedenen Zustandsvariablen, die es dem Spiel ermöglichten, den allgemeinen Gesundheitszustand der Gruppe täglich zu verfolgen und den Genesungszustand der einzelnen Gruppenmitglieder nach Unfällen oder Krankheiten zu ermitteln.

Eine weitere wichtige Änderung war die Einführung eines komplexen Klima- und Wettermodells, das auf den tatsächlichen monatlichen Durchschnittswerten für Temperatur und Niederschlag an verschiedenen Punkten entlang des Weges basiert. (Im Originalspiel hat der Monat des Jahres keine Auswirkung auf das Wetter.) Während der Spieler den Pfad entlang reist, wird das Wetter für jeden Tag auf der Grundlage des aktuellen Monats und der aktuellen Position des Spielers auf dem Pfad berechnet. Die Simulation ermittelt die entsprechende Durchschnittstemperatur und addiert oder subtrahiert eine zufällige Abweichung. Die Simulation ermittelt auch die Regenwahrscheinlichkeit und erzeugt dann Bedingungen, die trocken, regnerisch oder sehr regnerisch sein können (wenn das Wetter sehr kalt ist, ersetzt Schnee den Regen).

Anstelle eines einzigen Simulationsmodells habe ich die folgenden ineinandergreifenden Modelle entworfen, die jeweils aus mehreren bis vielen ineinandergreifenden mathematischen Formeln bestehen:

• Klima und Wetter
• Gesundheit
• Fortschritte auf dem Weg
• Vorräte (Bargeld, Lebensmittel, Ochsen, Munition, Kleidung und Ersatzteile)
• Flussüberquerungen
• Punktesystem

Am Ende hatte ich eine riesige Anzahl von Zustandsvariablen und eine riesige Anzahl von mathematischen Formeln. Bei so vielen Details, die sich gegenseitig beeinflussen, wusste ich, dass ich eine Menge Feinabstimmungen am Spiel vornehmen musste, während wir das Spiel testeten. Vor allem in den letzten drei Monaten der Produktentwicklung habe ich alle Formeln und Startwerte optimiert, um eine immer bessere Balance im Spiel zu erreichen.

Der neue Satz von Kernkonzepten

Bis Ende Juli 1985, Der Oregon Trail war fertig und bereit zur Veröffentlichung. Zu unserer Freude war das Produkt ein sofortiger Erfolg. Es wurde nicht nur auf dem heimischen Markt sehr beliebt, sondern entwickelte sich auch bald zum meist verbreiteten Lernsoftwareprodukt in nordamerikanischen Schulen. Unser neues Spiel und seine Nachfolgeversionen brachten den Eigentümern von MECC in den folgenden Jahren Millionen von Dollar ein. (MECC war als staatliche Behörde gegründet worden, wurde aber später an private Investoren verkauft.) Obwohl dieser Reichtum nicht bis zu den Leuten durchgesickert ist, die das Spiel entwickelt und gebaut haben, waren wir sehr zufrieden mit dem, was wir erreicht hatten - ein äußerst erfolgreiches Produkt zu schaffen, das schließlich zu einem Spieleklassiker und einer kulturellen Ikone wurde.

Die Entwicklung und der Bau dieser völlig neuen Version von Der Oregon Trail war kein geradliniger, linearer Prozess gewesen. In meinen frühen Entwurfsunterlagen hatte ich alle möglichen Ideen vorgeschlagen und in Betracht gezogen, von denen es nur einige in das fertige Produkt geschafft haben. Als wir das Spiel herausbrachten, waren die folgenden innovativen Neuerungen bereits integriert:

1. Echte geografische Details. Das ursprüngliche OREGON-Spiel enthielt fast überhaupt keine geografischen Details. Keine Flüsse, Berge, Festungen oder andere Landmarken wurden jemals namentlich erwähnt. Ein Hauptziel meines neuen Designs war es, viele echte geografische Informationen in das Spiel einzubauen, die mit attraktiven Farbgrafiken illustriert wurden.

2. Landmarkenbasierter Reisezyklus. Das ursprüngliche OREGON hatte einen sehr einfachen, zweiwöchigen Spielzyklus ohne Wahrzeichen. Ich habe die Hauptroute in 16 Abschnitte unterteilt, die jeweils mit einer berühmten Landmarke beginnen und enden. An jeder Landmarke und auch zwischen den Landmarken muss der Spieler viele Entscheidungen treffen, die im Originalspiel nicht möglich waren.

3. Kontinuierliche tägliche Zyklen. Die Reise nach Oregon dauert normalerweise etwa 150 Tage. Ich musste einen Tageszyklus in das Design einbauen, damit an jedem Tag der Reise wichtige Ereignisse eintreten können und der Spieler die Vorräte täglich verfolgen kann. Um zu vermeiden, dass das Spiel immer wieder unterbrochen wird, läuft das Spiel zwischen den Landmarken auf Autopilot, bis der Spieler es unterbricht oder ein wichtiges Ereignis eintritt.

4. Die Wahl der Route. Das ursprüngliche OREGON stellte den Oregon Trail als einen einzigen durchgehenden Weg dar, ohne Abzweigungen oder Routenwahlen. Ich habe eine realistischere Situation eingeführt, in der der Spieler gelegentlich eine Entscheidung treffen muss, welchen Weg er gehen soll - und diese Entscheidung kann sehr wichtige Konsequenzen für den Spieler haben.

5. Flussüberquerungen. Im ursprünglichen OREGON gab es keine Flüsse und keine Überquerungen. Ich habe Flussüberquerungen zu einem wichtigen Bestandteil des neuen Spiels gemacht. Bei jeder Überquerung muss der Spieler wichtige Entscheidungen treffen, die von den aktuellen Bedingungen abhängen, die stark vom aktuellen Wetter beeinflusst werden, das sich bei jedem Durchgang des Spiels ändert.

6. Eine neu konzipierte Jagdaktivität. Im ursprünglichen OREGON jagst du, indem du das Wort "BANG" eingibst. Unser Ziel war es, die Jagd in ein echtes Geschicklichkeitsspiel im Arcade-Stil zu verwandeln, das das tatsächliche Gelände, in dem du jagst, mit einbezieht, z. B. die Prärie, die Berge oder die Wüste. Auch die Tierarten, die du findest, hängen davon ab, wo du dich gerade auf dem Weg befindest.

7. Ein Punktesystem. Im ursprünglichen OREGON gibt es kein Punktesystem. Um einen hohen Wiederspielwert in das Produkt einzubauen, habe ich ein Punktesystem entwickelt, das eng an den von dir gewählten Schwierigkeitsgrad gebunden ist. Als weiterer Motivationsfaktor ist die Bestenliste mit einer Reihe historischer Namen gefüllt, die eine große Bandbreite an Punkten abdecken.

8. Familienmitglieder. In der Originalversion von OREGON wird kaum erwähnt, dass andere Personen mit dir unterwegs sind. Um das Erlebnis persönlicher zu gestalten, verlangt mein Entwurf von jedem Spieler, dass er vier zusätzliche Namen als Reisebegleiter angibt. Wenn du schlechte Entscheidungen triffst oder eine Pechsträhne hast, werden Mitglieder deiner Familie oder Gruppe sterben.

9. Mit Menschen reden. In der ursprünglichen OREGON gibt es kein Konversationssystem. In meinem neuen Entwurf erlaube ich dem Spieler, mit Leuten entlang des Weges zu sprechen. Dies ist eine wichtige Methode, um hilfreiche Hinweise zu erhalten und interessante historische und geografische Details zu erfahren. Außerdem wirkt das Spiel dadurch viel menschlicher.

10. River Rafting Spiel. In der Originalversion von OREGON wird das Rafting auf dem Columbia River nicht erwähnt, was ich für ein faszinierendes Stück Geschichte und eine großartige Gelegenheit hielt, ein weiteres Arcade-Spiel in das Produkt zu integrieren. Deshalb haben wir das Fluss-Rafting-Spiel entwickelt, wenn auch in einer einfacheren Version als ursprünglich geplant.

11. Grabsteine. Ein weiteres berühmtes Feature, das wir hinzugefügt haben, ist die Möglichkeit, einen Grabstein für sich selbst zu erstellen, nachdem man gestorben ist. Dieses humorvolle Zwischenspiel entschädigt den Spieler dafür, dass er die Reise nicht beendet hat. Aber der eigentliche Haken ist, dass wir die Daten des Grabsteins auf der Spieldiskette speichern, so dass der nächste Spieler, der dieselbe Diskette benutzt, den Grabstein sehen kann.

12. Ein detailliertes Gesundheitsmodell. Das Original von OREGON verfolgt die Gesundheit des Spielers nicht von Runde zu Runde. In meinem neuen Entwurf habe ich ein fortlaufendes Gesundheitsmodell für die gesamte Gruppe sowie die Verfolgung einzelner Krankheiten und Verletzungen vorgesehen. Das Wetter, die Essensrationen und das Tempo haben kumulative Auswirkungen auf die Gesundheit der Gruppe, die sich mit der Zeit verbessern oder verschlechtern kann.

13. Ein detailliertes Wettermodell. Das ursprüngliche OREGON enthielt kein echtes Wettermodell mit Jahreszeiten und Daten, die an verschiedene Klimazonen gebunden waren. (Das Original hatte nur zwei Klimazonen und keine Jahreszeiten.) Im neuen Spiel berechnet das Programm jeden Tag das Wetter, basierend auf dem aktuellen Monat und dem Ort. Das wiederum wirkt sich auf viele andere Faktoren aus - wie Gesundheit, Flussüberquerungen, Verfügbarkeit von Wasser und so weiter.

14. Robustes Ressourcenmanagement. Mein neues Design bot dem Spieler viele neue Möglichkeiten, seine Ressourcen zu verwalten, darunter: 1) das Reisetempo anpassen, 2) bestimmte Ersatzteile kaufen, 3) jederzeit rasten, um die Gesundheit der Gruppe zu verbessern, 4) mit anderen Reisenden handeln, um wichtige Ressourcen zu erwerben, und 5) zusätzliche Ochsen in Festungen kaufen.

15. Ein fesselnder Reisebildschirm. Der Reisebildschirm des Produkts von 1985 - mit einem kleinen animierten Ochsen und einem Wagen - ist zur ikonischen Darstellung der gesamten Geschichte von Der Oregon Trail Spiel. Die Kombination der Elemente auf diesem Bildschirm ist sowohl sehr einprägsam als auch sehr effektiv.

16. Matt's General Store. Im Originalspiel hast du nie mit Menschen interagiert. Mit dem Entwurf von 1985 haben wir Matts Gemischtwarenladen eingeführt. Matt ist der freundliche Ladenbesitzer, der dir bei deinen Einkäufen hilft und dich berät, was und wie viel du kaufen solltest.

17. Spezifische Krankheiten. Wenn du im Originalspiel krank wirst, wird die Krankheit nie genannt. (Wenn du stirbst, wird vielleicht eine Lungenentzündung erwähnt.) Für das neue Design habe ich fünf Krankheiten oder Symptome eingebaut, die von Reisenden auf dem Oregon Trail oft genannt wurden: Typhus, Cholera, Masern, Ruhr, Erschöpfung und Fieber. Seltsamerweise hat eine dieser fünf Krankheiten die Fantasie der Menschen beflügelt und ist zu einem großen Mem geworden. ("Du bist an Ruhr gestorben.")

18. Schwierigkeitsgrade. Um die Wiederholung des Spiels zu fördern, habe ich drei Schwierigkeitsstufen in das Spiel eingebaut. Ich habe drei verschiedene Berufe gewählt, um die drei Schwierigkeitsstufen zu repräsentieren: Banker, Schreiner und Bauer. Diese Auswahl ist auch zu einem Meme geworden.

19. Handel mit Menschen. Zwischen den einzelnen Stationen kann der Spieler jederzeit versuchen, Gegenstände mit Passanten zu tauschen. Das kann unter bestimmten Umständen sehr hilfreich sein, besonders wenn ein wichtiges Wagenteil kaputt gegangen ist. Dieses Modul ist jedoch nur ein blasser Schatten des Handelssystems, das ich eigentlich einbauen wollte. Später habe ich das vollständige, robuste Handelssystem in das Spiel eingebaut Lewis & Clark blieben zu Hause.

20. Optionen zum Ausruhen oder Ändern des Tempos. Der Spieler kann sich entscheiden, das Tempo zu beschleunigen oder zu verlangsamen oder ganz aufzuhören, um sich ein paar Tage zu erholen. Diese Entscheidungen sind ein wichtiger Kompromiss zwischen der Gesundheit der Gruppe und dem Fortschritt auf dem Weg.

21. Zeitgenössische Musik. An jeder Landmarke entlang des Weges kannst du eine andere Melodie hören. Außerdem ist jede Melodie eine echte Melodie, die zur Zeit des Oregon Trails beliebt war. Leider kann diese Neuerung eher lästig als hilfreich sein, besonders auf dem Apple II, der keinen Lautstärkeregler hat.

Zusammengenommen führten diese 21 Neuerungen zu einem ganz anderen Spielerlebnis als in den früheren Versionen des Spiels. Das neue Spiel war länger und bot mehr Möglichkeiten, Entscheidungen zu treffen. Außerdem konnten die Spielerinnen und Spieler auf mehr als eine Art und Weise erfolgreich sein - indem sie verschiedene Strategien und Spieltechniken einsetzten. Das war wichtig für mein Ziel, das Spiel für Mädchen genauso attraktiv zu machen wie für Jungen und ein breiteres Spektrum an Geschmäckern anzusprechen. Am Ende erwies sich das neue Spiel als äußerst beliebt bei einem sehr breiten Publikum.

Ein weiterer großer Unterschied ist natürlich, dass das ursprüngliche OREGON ein textbasiertes Spiel war, während das Design von 1985 voller Farbgrafiken war. Die Entscheidung, Grafiken einzubauen, war eine offensichtliche Notwendigkeit und keine Innovation. Andererseits waren einige unserer Entscheidungen, wie wir die Grafiken einbinden, tatsächlich innovativ. Beim Spiel von 1985 haben wir so viele grafische Details eingebaut, wie wir auf die Apple II-Diskette packen konnten, z. B. den animierten Reisebildschirm, animierte Flussüberquerungen, das Jagdspiel, das Raftingspiel und eine Vollbildgrafik für jede Sehenswürdigkeit.

Hin und wieder stoße ich auf einen Online-Artikel, der nahelegt, dass die Apple II-Version von 1985 Der Oregon Trail war im Wesentlichen identisch mit dem Originalspiel von 1971, abgesehen von den zusätzlichen Farbgrafiken. Diese Behauptung ist so lächerlich unzutreffend, dass sie mich völlig verwirrt. Tatsächlich wurden die meisten Funktionen und Details, die man mit dem Spiel verbindet, erst für das Produkt von 1985 erfunden. Andererseits wäre mein neues Design ohne den großen Erfolg des Originals nie entstanden. Außerdem wurden in der Originalversion sieben Schlüsselkonzepte eingeführt, auf denen alle späteren Versionen des Produkts basierten. Aber nachdem mein Entwurf von 1985 herauskam, wurden die 21 wichtigsten neuen Konzepte aus diesem Entwurf in jeder nachfolgenden Version als Teil des ursprünglichen Kerndesigns behandelt. Ebenso wurden viele der weniger wichtigen Details aus dem Entwurf von 1985 in die späteren Versionen übernommen.

Warum der Prozess erfolgreich war

Am Ende haben wir alle Ziele für dieses Projekt erreicht und sogar übertroffen - mit der Ausnahme, dass der Zeitplan und das Budget etwas länger waren, als wir erwartet hatten. Dennoch wurde das Produkt wie geplant im Herbst 1985 rechtzeitig für den heimischen Markt fertiggestellt. Wie geplant wurde das Produkt ein Riesenerfolg - nicht nur auf dem heimischen Markt, sondern auch auf dem Schulmarkt.

Bei der Entwicklung, dem Bau und den Tests sind wir auf einige Hindernisse und Umwege gestoßen. Der Oregon Trail. Und doch war der Prozess insgesamt recht erfolgreich. Wenn ich auf die Details des Projekts zurückblicke, sehe ich mehrere Lektionen, wie man ein neues Projekt plant und startet:

1. Holt euch viele Anregungen, aber lasst euch nicht von einem Komitee entwerfen.

Ich wollte, dass alle Mitglieder des Produktteams ihre Gedanken äußern und Ideen einbringen können. Ein Ausschuss wird jedoch selten ein gutes Design hervorbringen und kann auch keine schnellen Entscheidungen treffen. Deshalb habe ich in der Anfangsphase des Entwurfs mit einer divergenten Phase begonnen, in der Ideen entwickelt werden, gefolgt von einer konvergenten Phase, in der die Ideen eingegrenzt werden. An der divergenten Phase können und sollten viele Leute teilnehmen, aber an der konvergenten Phase sollten nicht mehr als drei Leute für ein bestimmtes Modul teilnehmen. Nachdem die besten Konzepte ausgewählt wurden, liegt der größte Teil der Entwurfsarbeit noch vor uns, und der größte Teil dieser Arbeit wird von Einzelpersonen erledigt. Aber während des gesamten Projekts geben sich die Teammitglieder regelmäßig gegenseitig Feedback. An wichtigen Punkten des Projekts wird auch Feedback von Personen außerhalb des Teams eingeholt und es werden Benutzertests durchgeführt. Auf diese Weise halten wir das Gleichgewicht zwischen den Ideen vieler Menschen und der Entscheidungsfindung mit wenigen Personen.

2. Erstelle den Entwurf in mehreren aufeinander aufbauenden Phasen.

Bevor du versuchst, einen Entwurf Der Oregon TrailIch hielt es für wichtig, die wichtigsten Ideen zu definieren, angefangen bei den Zielen: Warum schaffen wir dieses Produkt? Wer ist das Zielpublikum? Was werden unsere Erfolgskriterien sein? Dann schlug ich einen allgemeinen Rahmen für das Produkt vor, zusammen mit den wichtigsten Modulen und Funktionen. Danach haben wir die einzelnen Module und Funktionen bis zu einem mittleren Detaillierungsgrad definiert - genug, um zu erklären, wie sie funktionieren werden. Schließlich habe ich jedes Modul und jede Funktion bis ins Detail ausgearbeitet. Während das Produkt Form annahm - zuerst als Prototypen und dann als tatsächliche Codemodule - verbesserte ich das Design weiter. Jeder Bildschirm wurde mehrmals überprüft, um das Layout, den Text und die Benutzerfreundlichkeit zu verbessern, und die zugrundeliegenden mathematischen Gleichungen wurden überarbeitet, um das Gameplay zu verbessern. Ich bezweifle, dass es möglich gewesen wäre, alles zuerst in einem einzigen großen Dokument zu entwerfen, bevor man mit dem Bau des Produkts begann. Der Versuch, von Anfang an ein einziges großes Dokument zu erstellen, wäre bestenfalls Verschwendung und schlimmstenfalls eine Katastrophe gewesen.

3. Erstelle Prototypen.

Es ist zwar hilfreich, Skizzen der vorgeschlagenen Bildschirme zu zeichnen, aber ein Prototyp liefert zusätzliche Informationen. Das erste Ziel des Prototypings ist die "Visualisierung" - den Leuten eine Vision des fertigen Produkts zu zeigen, wenn auch nur in grober Form. In einem zweiten Schritt kann der Prototyp teilweise interaktiv gestaltet werden, damit die Menschen einen Vorgeschmack auf das fertige Spiel bekommen. Beide Phasen liefern nützliche Informationen, um das Design relativ früh im Projekt anzupassen - auf jeden Fall viel früher, als wenn wir auf eine Beta-Version gewartet hätten, bevor wir sie jemandem gezeigt hätten.

4. Teste die Prototypen und den ersten Entwurf der Software mit den Nutzern.

Es ist sicher hilfreich, wenn Teamkollegen und andere Kollegen die Prototypen bewerten, aber das allein reicht nicht aus. Es ist auch wichtig zu untersuchen, wie echte Nutzer/innen auf das Produkt reagieren - und zwar so früh im Entwicklungszyklus wie möglich. Egal, wie erfahren und einfühlsam die Designer/innen sind, es wird immer Überraschungen geben, wenn echte Nutzer/innen das Produkt ausprobieren. Diese Überraschungen reichen von kleinen Details bis hin zu viel größeren Problemen. Für Der Oregon TrailEine der kleinen Überraschungen war, dass die Kinder das Wort "Outfits" nicht verstanden - das habe ich dann in "Kleidungssets" geändert. Eine mittlere Überraschung war, dass viele Spieler/innen von den Bildschirmen verwirrt waren, auf denen man die Mitglieder der Gruppe benennt. Und das wichtigste Problem war, dass der Reisebildschirm im Alphatest nicht das Interesse der Spieler/innen weckte. Also haben wir diesen Bildschirm überarbeitet, der dann zum berühmtesten Bildschirm des Produkts wurde.

5. Setze immer wieder Prioritäten, was als Nächstes getan werden muss.

Bei fast jedem Projekt, an dem ich gearbeitet habe, mussten wir die Pläne irgendwann zurückschrauben, entweder subtil oder drastisch. Das ist ein wichtiger Grund, um die verschiedenen Komponenten zu priorisieren. Lege immer einen frühen Schwerpunkt auf die Module und Funktionen, die am wahrscheinlichsten im fertigen Produkt enthalten sein werden.

Risiken sind ein weiterer zu berücksichtigender Faktor. Jedes Projekt birgt Risiken, die mit Unbekannten verbunden sind. Um die Risiken zu verringern, ist es wichtig, die Unbekannten früh im Projekt zu erkunden. Einige Risiken sind technologiebedingt - wird das Modul schnell genug sein? Können wir alles auf die Festplatte packen? Einige Risiken sind benutzerbezogen - Werden die Benutzer in der Lage sein, diese komplizierte Aufgabe erfolgreich zu bewältigen? Werden die Benutzer die Bedeutung und die Details dieses wichtigen Bildschirms verstehen? Zu Beginn des Projekts geht es darum, Prototypen oder Proof-of-Concept-Module zu entwerfen und zu bauen, die die wichtigsten Unbekannten beseitigen und so die Erfolgsaussichten erhöhen.

Das ist genau das, was wir mit Der Oregon Trail. In der Anfangsphase haben wir entschieden, was am wichtigsten war, um es mit dem internen Prototyp zu illustrieren. Dann entschieden wir, welche Funktionen am wichtigsten waren, um sie mit Kindern zu testen, und nahmen diese in die Alpha-Version auf. Unmittelbar danach setzten wir Prioritäten für alle Module und Funktionen, die für das Produkt geplant waren, wobei wir davon ausgingen, dass es nicht alles in das fertige Produkt schaffen würde. Schon in einem frühen Stadium erstellten wir auch Technologiepläne und führten Technologietests durch, um die technischen Risiken anzugehen.

Zusammenfassung und Dank

Im Laufe meiner Karriere habe ich an unzähligen Softwareprojekten gearbeitet. Bei der überwiegenden Mehrheit dieser Projekte habe ich allen Grund, stolz auf die Ergebnisse zu sein - auch wenn ich mir bestimmter Details bewusst bin, die noch hätten verbessert werden können. Doch außer bei Der Oregon Trail-und in geringerem Maße Zahlenfresser-keines dieser Projekte führte zu einem Produkt, das wirklich berühmt wurde - auch wenn einige von ihnen (vor allem die webbasierten Anwendungen, die ich für Unternehmen entwickelt habe) tatsächlich sehr häufig genutzt wurden.

Das Ergebnis ist, dass ich dankbar bin für den Ruhm, den meine Produkte erlangt haben. Besonders dankbar bin ich dafür, dass ich die Gelegenheit hatte, an *The Oregon Trail * zu arbeiten - und für die Kombination von Umständen, die es dem Produkt ermöglichten, ein so großer Erfolg zu werden. Ich bin dankbar dafür, dass ich mit hochtalentierten und engagierten Kolleginnen und Kollegen zusammenarbeiten konnte, deren Zusammenarbeit eine große Rolle für den Erfolg gespielt hat. (Meine Hauptmitarbeiter waren Charolyn Kapplinger, John Krenz, Shirley Keran, Bob Granvin und Roger Shimada). Ich bin dem MECC dankbar, dass es mich mit diesem Projekt als leitende Designerin und Projektleiterin betraut hat und mir den Spielraum gab, das Projekt so zu steuern, wie ich es für richtig hielt (die meiste Zeit über). Ich bin dankbar dafür, dass Don Rawitsch, Bill Heinemann und Paul Dillenberger die erste brillante Version des Spiels erfunden haben, aus der alle nachfolgenden Versionen hervorgegangen sind. Und ich bin dankbar dafür, dass Millionen von Menschen dieses Spiel spielen und genießen konnten - und dass sich so viele von ihnen nach all den Jahren gerne an das Spiel erinnern.

R. Philip Bouchard hat 32 Jahre lang Computersoftware entwickelt, davon 18 Jahre lang Bildungssoftware. Er war der Hauptdesigner für die Apple II Spiele Der Oregon Trail und Number Munchers. Mehr über seine Design-Erfahrungen kannst du auf seiner Blog, wo dieser Artikel ursprünglich veröffentlicht wurde.