Das Phänomen PLATO (oder PLATO Systems wie es korrekterweise heisst) ist eigentlich eine Unglaublichkeit. Es sollte in einer Reihe stehen mit Xerox-Parc, UNIX, LOTUS NOTES, Email, BBS, ATARI, Space War, DOOM, UNREAL und natürlich mit Themen wie ELearning, MultiuserSystems, MUDs, FirstPersonShooter, Multiusergames, Autorensysteme, Vekorgrafiken, Mikfofilm & Demokratisierung von CODE aber nein: Es ist bis heute in der Aufmerksamkeitsökonomie in der grosstmöglichen Nische.
Der Grund dafür ist sicherlich seine frühe Entstehung (Das ganze System wurde Anfang der 60er Jahr entwickelt), die Technologiefeindlichkeit und ihre Nichtöffentlichkeit bis um die 2000er Jahre, sein doppelt geschlossenes System: Server-Client-Architektur, seine im System integrierten umfassenden Kommunikationsmöglichkeiten und sein Einsatzzweck Automated Learning in der universitären Lehre und die einsetzende Privatisierung als Personal Computer (inklusive Homecomputer) Anfang der 80er Jahre.
Selbstverständlich gibt und gab es innerhalb des Systems ‚Bekannte‘, ‚Heroes‘ oder ‚VIPs‘ aber gegen aussen ist erstaunlich wenig öffentlich geworden. Und das obwohl es Tausende von Lektionen gibt/gab, Tausende von Studenten ausgebildet wurden, Bücher darüber geschrieben wurden. Selbst die Konferenz zum 50 jährigen Bestehen von PLATO war eher ein Systemtreffen als ein „WOW“ über die Systemgrenzen hinweg. Einige weitere möglichen Gründe finden sich am Ende des Artikels.
PLATO SYSTEMs – Cyber1.org
Selbst heute nach mehr als 50 Jahren PLATO SYSTEMS gibt es immer noch eine aktive Community (es sind immer mehr als 20 Leute online Tag und Nacht!) auf einer neuen Installation auf Cyber1.org (seit 2004). Über die Webseite Cyber1.org kann man sich einen User anlegen. Nach 2 oder 3 Tagen kriegt man dann einen Zugang für die Terminalsoftware PTerm (PlatoTerm). Über die Lektion „>big jump“ bekommt man eine Auflistung aller Lektionen bzw. Games. Wer möchte kann sich das System auch auf seinem Computer installieren (mehr dazu hier) und eine Menge vorinstallierter Software ausprobieren oder selbst ausprobieren wie man kleine Lektionen erstellt. Die weitaus einfachere Art ist jedoch mit Cyber1.org zu beginnen, denn hier kann eine aktive Community helfen (‚> notes‘) und zeigt, wo das Potential von PLATO lag und liegt – auch in der Community. Eine ausführlichere Beschreibung findet man hier >
Das System
PLATO mit vollem Namen Programmed Logic for Automatic Teaching Operations wurde als Projekt ab 1960 entwickelt an der Universität von Illinois (auch mit militärischer Finanzierung). Philosophisch steht das Projekt in der um sich greifenden Kybernetik und der Idee Systeme über alles hinweg zu erkennen, modellieren und als Anwendung zu entwickeln (Automatic Teaching). Ein und dieselbe Idee in verschiedenen Formen: Der analoge Prometanboy
Systeme wie PLATO waren die ersten grossen Spielwiesen der Digitalisierung (der Kybernetik).
platohistory.org
www.friendlyorangeglow.com
Es wurde von Anfang an auf einen Server mit Clients gesetzt. Der Ausbau ging rasant von statten in Sachen Terminals/Clients: 1961 2x (Army navy air force), 1967 PlatoIII 20x , 1972 Plato IV Xx über Modems (1260 Bauds – 150 Bytes pro Sekunde), wobei die Clients sehr teuer waren dank ihrer modernen Ausstattung (Vector Screens, 512×512 Pixel, Microfilmüberblendung, TouchScreen, Instrumenteninterface, Modem). In späteren Jahren kamen auch noch Clients für Computer und Consolen heraus.
Dabei zeigt die Infrastruktur die Möglichkeiten von Multiusersystemen. Einen Einblick in die Entwicklung von Multiusersystemen findet sich hier: Wie die Welt in den Computer kam (Guggerli). Wie komplex das System ist und war, zeigt sich noch heute, wenn man die Software auf dem eigenen Laptop installiert. Das ganze System mit einem Haufen Lektionen hat über 8 Gigabytes und emuliert diverse Speicherungssysteme wie Tapes und Co und zeigt auf, wie teuer das System damals im Einsatz vermutlich war.
Als Client kommt ein Display zum Einsatz mit sagenhaften 512×512 Pixel und der Möglichkeit Grafiken darzustellen – zuerst nur Monochrom danach auch mit Farben. Auch hier wird wiederum klar, wie weit unten die Personalcomputers und Consolen gestartet sind bei der Demokratisierung der Computertechnologie. Oder kommerzieller gesprochen: Wieviel Abstriche gemacht werden mussten, damit Computertechnologie bei den Endusern ankommen konnte.
Users & systeminterne Kommunikation & Communities
Das Platosystem bildet eine Universität bzw. eine Grossorganisation auch organisatorisch ab. So gibt es Abteilungen und die User sind diesen zugeordnet. User wiederum haben Rechte, Dinge zu lesen, Lektionen auszuführen bzw. Speicher zu verwalten. Im Laufe der Jahre entstand rund um die User eine ganze Menge von Services. So gibt es PublicNotes, es kann 1:1 gechattet werden oder es können persönliche Nachrichten verschickt werden. Das System verfügt über praktisch alle modernen Kommunikationsmöglichkeiten oder anders gesagt: Es ist – mit Ausnahme von Filesharing (aber gab es damals schon den Need für Files?) – in sich geschlossen. Dies wirkt sich bis heute aus – die meisten Informationen dazu gibt es in PLATO. Auf die Frage: „Soll es nicht eine Dokumentation ausserhalb Platos geben?“, antworten die User noch heute mit „Warum? Erweitere die Dokumention, schreib es in PublicNotes“. Grössere Softwaren haben sogar ihre eigenen Notes, wo man nachfragen kann, die FAQs durchlesen kann . Hier war PLATO eindeutig zu ‚erfolgreich‘ und verhinderte ein Bekannterwerden.
Nicht zufällig entsteht Lotus Notes als geistiges „Spin-Off“ der Applikation Notes auf PLATO. Und nicht zufällig wird diskutiert, ob die persönlichen Notes das Template waren für die Entwicklung des Emails (Emails verwenden ein dezentrales System). Nicht zu leugnen ist auf jeden Fall die Nähe der BulletBoardSystems (BBS) zu Platos PNotes, die in den 80er Jahren aufkommen und als lokale Alternative für informmelle Informationen werden.
Lektionen
Die kleinste Einheit, auf der alles aufbaut, ist die Lektion. Jede „Software/Inhalt“ (mehrheitlich) auf Plato ist grossmehrheitlich eine Lektion. Der Aufbau der Lektion ist eng abgestimmt mit den Möglichkeiten des Hauptinterfaces: der Tastatur. Es gibt einen HELP, LAB, NEXT und einen BACK-Button. Der HELP Button gibt in fast jeder Situation Auskunft und weiterführende Informationen. Dadurch ist alles im System abgebildet und es finden sich konsequenterweise dann auch fast keine Informationen ausserhalb des Systems. Aufgeteilt ist eine Lektion in Blöcke. Blöcke können von einem User mit Blöcken zugeteilt werden. Hier entsteht dadurch schnell eine Hierarchie für Entwickler, die etwas Unabhängiges etwa Games entwickeln wollen.
Der erste Block ist jeweils zuständig für die Rechte etc. Die nachfolgenden Blöcke enthalten den Code. Dabei ist die Programmierung eher ein Mix von Programmiersprache und Expertensystem. Die ‚Programmiersprache‘ ist dabei TUTOR.
Programmieren in TUTOR (1969+)
Mehr dazu findet sich hier. https://en.wikipedia.org/wiki/TUTOR. Die Blöcke einer Lektion können mit dem integrierten TextEditor editiert werden. Der Editor ist Zeilenbasiert und Keybasiert. Man gibt zuerst das Kommando als Buchstaben ein: <i> für Insert oder <d> für Delete und anschliessend schreibt man in die Zeile oder löscht Zeilen.
Die Programmiersprache Tutor ist eine Art Hochsprache und elaboriert. Zwar müssen nach wie vor, die 100 Variablen pro Programm und User zugewiesen werden (define). Aber danach funktioniert alles in gewohnter bis heute benutzter Weise. Anstelle von = kommen Commandos wie calc zum Einsatz, es gibt für fast alle mathematischen Funktionen Befehle von Sin bis Tan (Also viele Dinge man später auf Homecomputer wieder lange suchen wird) – verwundert allerdings auch wieder nicht, wenn man daran denkt, das dies auf einem Highend-Mainframe läuft. Die Programmiersprache basiert dabei auf Labeln und Sprungmarken. Komplexe If-Abfragen oder Repeats werden dabei mit Tab-Intendierung gelöst (Die Phyton-Fraktion triumphiert hier gerade freudig).
Der Code ist Teil des Projektes TuringsAssemblyLine, das man auf cyber1.org unter der Lektion „> turingsal“ spielen kann.
Mehr dazu findet man unter: turingsal.and-or.ch
Neben den klassischen Funktionen wie WRITE, INPUT (Keys, strings) verfügt TUTOR und auch die Terminals per default über die Möglichkeit Vectorgrafiken zu zeichnen. Das System verfügt über einfache komplexe Flusstrukturen mit Sprungmarken. Es können etwa Keys für Units programmiert werden aber auch Keys direkt abgefragt werden und Timeouts gesetzt werden. Mit all diesen Sonderfunktionen wird ein schnelles Erstellen von Lektionen möglich, seien sie Information svermittelnd aber auch Informations abfragend. Die Einstiegshürde. Das System kommt damit beim Inhalt wie beim Erstellen als Expertensystem daher und demokratisiert damit im universitären Rahmen (später konnten auch Grundschüler das System nutzen) den Bereich Learning bzw. ELearning (Der Begriff Automated Learning hat sich als Unterkategorie im Elearning bekanntlich nicht durchgesetzt).
Ein System, das Elearning demokratisierte.
Tutor: Grafische Fähigkeiten
Nicht zu unterschätzen sind im ELearning-Bereich die grafischen Darstellungsformen, dies zeigt PLATO sehr gut. Viele der Einheiten gewinnen durch Vektorgrafiken an Plastizität. Aber nicht nur das: Vieles ist auch nur möglich mit Vektorgrafiken etwa wissenschaftliche Rechner, komplexere Experimente. Richtig interessant sind dabei auch die interaktiven Lektionen, wo der Vorteil von digitalisiertem Learning zur interaktiven Erfahrung wird, wo Dinge erlebbar werden und sich die Möglichkeiten des automated Teaching einlösen.
Die Programmiersprache deckt die grafischen Fähigkeiten auch komfortabel ab. Linien, Kreise, Boxen gezeichnet, Text kann in verschiedenen Grössen ausgegeben und Drehungen (!) ausgegeben werden. Dadurch sind recht komplexe Anwendungen möglich. Dies ist vorallem in den vielen ELearning-Einheiten sichtbar, die alle mehr nach Ende 80er Jahre aussehen als nach 1972+!
Tutor: Natürliche Sprache als Inputmöglichkeit
Daneben verfügt TUTOR über erweiterte Funktionen, die an (damals zukünftige) Expertensysteme erinnern. So kann etwa bei String-Inputs mehrere Möglichkeiten angeben werden, welche Wörter positiv gewertet werden (> Rechteck, Quadrat) oder welche einfach falsch sind. Interessant ist auch, dass nicht zu beachtende Füllwörter eingegeben werden können. Aus heutiger Perspektive ist interessant, wie sehr gerade diese Funktionen noch in den damaligen Paradigmen verankert waren – natürliche Sprache für die Eingabe zu benutzen. Ein Aspekt, der danach eher dem Paradigma der Anpassung an die Maschine und GUIs geopfert wurde, einem technisch offensichtlich viel einfacher zu lösenden Problem.
Das System PLATO war so konsequent ausgelegt, dass bis heute alle Informationen über TUTOR innerhalb von Tutor abgelegt ist. Alle Änderungen, Hinweise wurden hier eingepflegt über all die Jahre. Man findet die meisten Informationen dazu in der Lektion ‚> AIDS‘.
Automated Learning
Die Entwickler von PLATO sahen die Zukunft des Lernens schon ab den 60er Jahren im Bereich automatisiertes Lernen. Die Anzahl- und Komplexität der Lektionen sind atemberaubend. Von einfachen Anwendungen über den ‚wissenschaftlichen Taschenrechner‘ mit Plotfunktion bis hin zu Schwangerschafts- oder Dithering-Lektionen. Dabei wird oft Inhalt und Abfrage/Test gekonnt gemischt. Es handelt sich dabei – soweit erkennbar – um eine didaktische unausgesprochenen Strategie.
Mehr zum Konzept von PLATO als Software:
Anbei eine Auswahl der installierten Lektionen auf Cyber1.org:
Das System wurde aktiv benutzt bis Anfang der 90er Jahre. Hier wartet noch einiges an Arbeit auf die Geschichte des ELearnings , denn sicherlich muss die Geschichte des ELearnings mit dem Inhalt von PLATO umgeschrieben werden.
Mehr dazu findet man hier:
PLATO – Biotop des GameDesigns avant la lettre
Was PLATO SYSTEMS noch erstaunlicher macht, ist die Fülle der auf diesem System entwickelten Spiele, die Gamemechaniken und die Komplexität der Spiele. Das System bot – als Mainframe – alles, was erst Jahrzehnte später möglich wurde und dort nur falls es direkt in Assembler programmiert wurde.
Die Gamehardware PLATO Systems verfügt über einige Dinge, die Jahrzehnte in der Zukunft des Gamedesigns liegen: ein Vektordisplay, eine einfache Hochsprache, Floating-Points, alle mathematischen Funktionen etwa um 3D zu berechnen, einiges an Speicher, persistenter Speicher (etwa für Highscores), gemeinsame von mehreren Usern nutzbare und speicherbare Variablen, interaktive Möglichkeiten, standardisierte Cursor und Möglichkeiten wie Touchscreen.
Standardisierte Cursortasten: WAS(X|D)
All dies ermöglichte für die 70er Jahre unglaubliche Spiele in grosser Komplexität. Einzig der Speed der Terminals über Modems sowie die Komplexität und Unberechenbarkeit von Multiusersystemen (Performance) bringt selbstverständlich Abstriche mit sich und dies sieht man auch an den Spielen.
Selected Games
Im Folgenden sollen einige der bekanntesten Spiele – die für eine ganze Reihe von Spielen im PLATO Universum stehen – unter die Lupe genommen werden.
Die Spiele, so scheint es, sind am Anfang als Erweiterung des ELearnings entstanden und waren im heutigen Jargon „Serious oder Applied Games“.
Serious Games – die Krönung des ELearnings
Ein Beispiel hierfür wäre etwa das Spiel „AdvertisingGame (> adgame)“. Hier geht es – wie man das klassisch kennt aus Wirtschaftssimulationen – um die Frage, welche Werbung wie und wann man einsetzt, um seine Projekt zu promoten.
Fun-Games oder der Missbrauch des Systems
Nach und nach sind aber – geduldet – immer mehr Fun-Games entstanden. Prinzipiell musste man dazu jemanden finden, der einem eine Lektion überlässt und entsprechende Blöcke freischaltet. Dann konnte es losgehen. Die Dynamik scheint beachtlich gewesen zu sein und die Ergebnisse aus heutiger Sicht atemberaubend.
BugsNDrugs – zwischen Serious und Fun – 1977(?)+ M. Gorback, D. Tanaka, P. Alfille
Ein Mittelding ist dabei das Spiel BugsNDrugs. Es ist ein echtes Spiel mit einer Gamemechanik, einem Motivationsdesign, viel schrägem Humor und dennoch kann dabei viel gelernt werden – sogar sehr spezifisches Wissen, ohne das ist das Spiel nicht gewinnbar. Die Aufgabe: Ein ‚verseuchtes‘ Krankenhaus wartet. Das Framework sind die Adventure-Games (Avatar im Labrinth) bei denen man als Rollenspielfigur unterwegs ist, Objekte einsammelt (Vaccine, Krankheiten,, Erfahrung sammelt (Wissen, wie man gewisse Bugs bekämpft), sich entwickelt (Ressitenzen) und Monster (Krankheiten) bekämpft. Die Komplexität des Spiels zeigt sich neben den sehr spezifischen Fragen etwa zu Staphylokokken, dass man in der Hierarchie des Krankenhaus aufsteigen kann und dass das Spiel (dem Multiusersystem sei Dank) über eine ewige Highscore/Rangordnung verfügt. Alles Dinge, die Jahrzehnte später in käuflichen Games Einzug halten. BugsNDrugs ist schwer zu finden (gehört nicht zur Standardinstallation) und zeigt auch, das viel der Software vermutlich schwer noch auffindbar bzw. spielbar ist. Ein Nachfragen in der cyber1.org-Community kann da helfen.
RPG & MORPG
BugsNDrugs verwendete dabei ein ebenfalls auf PLATO entwickeltes System, die 2D-Dungeon-RulePlays wie Dungeon (pedit5), Swords and Sorcery (sorcery) oder dnd.
RPG: Dungeon (pedit5) – 1975+ Rusty Rutherford
Dungeon steht für eine Menge von Dungeon-Rollenspielen. Sie sind 2D und von unglaublicher Grafik (vergleicht man es mit den Nachfolgern auf PC oder auf Consolen). Die Spiele nutzen oft auch komplexere Ressourcenmodelle und Simulationen, die Avatare und Gegner haben oft verschiedenste Ressourcen von Widerstandskraft, IQ bis zum Klassiker Health. All das kann im ‚Rollenspiel‘ entwickelt werden. Die Spieler* können aufsteigen – all das was man auch heute wieder kennt – einfach 1975. Oder anders gesagt: Heute steckt in jedem Computer simuliert ein Grossrechner von damals.
In wieweit hier auch die Rogue-Likes schon begründet wurden, muss noch genauer abgeklärt werden.
dnd – 1975 + D. Pellet diverse Authoren*
Wie sehr die Szene inspiriert war vom 1974 veröffentlichten Dungeon & Dragons zeigt auch ein anderes Spiel, das gleichzeitig enstand mit dem Namen dnd. Aus den Infos zum Spiel.
RPG: Swords and Sorcery (sorcery) – 1980+(?) Don Gillies / Jim Mayeda (?)
Viele Erfindungen oder Experimente sieht man auf dem PLATO SYSTEMS erst beim näheren Hinsehen. Ein Beispiel dafür wäre etwa Sorcery. Es implementiert im Universum der RPGs ein Quest-System.
Die 3. Dimension
Wer jemals auf den späteren Consolen oder Heimcomputern versucht hat ein 3D Spiel zu implementieren, weiss wie komplex das ist. Die meisten Spielsysteme verfügen auf Prozessorebene (und nur das war schnell genug) über keine Floating-Point-Strukturen und schon gar nicht über graphische Möglichkeiten wie Sin oder Tan. Hier muss alles über Lookup-Tables organisiert werden. Nicht so PLATO auf seinem Top-Level. Hier gibt es dies alles wie später in Hochsprachen. Und die Auswirkungen dieser technischen Möglichkeiten der Produktionsbedingungen sind wiederum erstaunlich.
Es entstehen Spiele mit und in 3D. Angefangen von Spielen, die Konzepte wie die RPGs erweitern bis zu neueren Konzepten. Dabei werden die 2D Konzepte ins 3D gehievt (Spiele wie OUBLIETTE, MORIA (1978) oder danach Avatar, Camelot). Aus diesem ursprünglichen Konzept entstehen dann eigene neue Genres wie die FPS oder auch rasterlose 3D-Konzepte wie SPASIM.
Moria – ein 3D RPG – 1975 2D /1978 3D + MORPG
Moria erweitert ebenfalls wie viele andere Games die 2D Spielmechanik um die dritte Dimension ab 1978. Man ist nun in 3D unterwegs (nicht unbedingt in den Bewegungsmöglichkeiten).
Interessant auch hier – durch die Vektorgrafiken erscheinen die Grafiken sehr graphisch und detailiert, vergleicht man es mit den Pixelkulturen der späteren Jahre
Der Turn vom Alles-Überblickenden (2D) wird nun zum Suchen im Raum, zum Hingehen. Die Komplexität bleibt aber weiterhin erhalten: Objekte im Raum, Inventare, Ressourcen und wiederum RPG-Elemente. Damit werden hier die ganzen Klassiker der kommenden Zukunft vorweggenommen wie etwa Dungeon Master (Atari ST/Amiga).
OUBLIETTE – 1978+ – Jim Schwaiger – MORPG
Oubliette ist ebenfalls eines der ersten RPGs in 3D. Scheint aber ohne Vorgänger in 2D daherzukommen. Interessant auch wiederum hier: Es scheint Multiuserfunktionen zu geben. Siehe Multiusergames.
Camelot – 1979+ J. Tabin (MORPG)
Einen guten Einblick in die Komplexität der RPG-Spiele auf PLATO und ihrer Spielmechanik bietet das Guidebook zu Camelot. Das PDF bietet auch eine Geschichte der RPGs, MMOS:
https://www.cyber1.org/Camelot_Guidebook.pdf
Futurewar – First Egoshooter – 1977+ E. Witz & N. Boland (MOFPS)
Mit der Erweiterung ist es aber noch nicht getan. Die Entwickler auf PLATO gehen weiter. führen den Egoshooter ein. Es ist auch hier wiederum herauszustreichen, dass auch hier die Komplexität überrascht. Es gibt verschiedene Stockwerke, Türen, verschiedene Monster und wiederum verschiedene Ressourcen. Visuell geht das Spiel auch einen Schritt in die Zukunft: Es verfügt über schon animierte Avatare und NPCs. Ebenso verfügt es über die Möglichkeit gegeinander anzutreten als Multiplayerspiel. Siehe Multiusergames.
Visueller Stil wie oft zu sehen 10 Jahre später
Irgendwo zwischen RPG und einem modernen Egoshooter
Erstaunlich komplexes Modell für einen Shooter im Vergleich zu heute.
Der Egoshooter scheint hier als eine Art Erweiterung des RPGs daherzukommen und wird sich erst zukünftig ausdifferenzieren und weiter vereinfachen in ein eigenes Genre.
Freies 3D Movement
Einige Entwickler gingen dabei noch weiter und orientierten sich nicht mehr an einem Raster sowohl in der Darstellung wie auch in der Bewegung.
SPASIM – 1976+ J. Bowery
Sobald die Bewegungsmechanik vom klassischen Regelwerk der menschlichen Bewegung befreit ist (es gibt kein oben mehr), wird es bekanntlich wirklich schwierig. Es gibt eine Unmenge gescheiterter Projekt in diesem Bereich und das trifft auch auf das erste dieser Spiel zu SPASIM. SPASIM ist schwierig zu steuern und dennoch auch wiederum ein Spiel wert, gerade auch um zusehen, wie sich dies alles verändert hat durch die Jahrzehnte.
Seit 50 Jahren ein Problem, die freie Bewegung im 3D Raum
Multiplayer
Wenn man sich länger auf PLATO bewegt, ist man sehr oft irritiert. Die Irration kommt von Kommentaren des Spiels wie:
Urplötzlich wird wieder klar: Wir sind auf einem Multiusersystem in Multiusergames und es gibt viele davon und viele Games sind nebenbei Multiuser fähig. Listet man die Games auf, so findet man viele Multiuser fähige Games. Man erkennt sie mit einer Zahl am Anfang. Diese repräsentiert die gerade aktiven Spieler* in dem Spiel. Die Anzahl der Multiplayerspiele ist erschlagend.
Multiplayer – Technologie
PLATO verfügt über Variabeln, die man über die einzelnen Entitäten eines Spiels hinweg nutzen kann – eine Art Spielvariabeln. Dies ermöglicht es, relativ ‚einfach‘ Multiplayerspiele zu entwickeln. Diese Technik wird verschieden eingesetzt (soweit man das eruieren kann) vom klassischen Multiplayer bis hin zum nur Dabeisein im selben Level (etwa Futurewar). Die meisten Spiele integrieren schon ab Mitte der 70er Jahre Dinge wie Begegnungs- bzw. (Team-)Matching-Räume und handeln danach die Spiele als einzelne abgeschlossene Spiele ab oder setzen alle Spieler in ein Spiel. Viele Spiele (und nicht nur Multiplayerspiele aber hier zwingender) ermöglichen es einen Avatar zu erschaffen, angefangen von einem gewählten Nickname über gewählte Eigenschaften (vgl. DND), einem Team bis hin zu einem Aussehen.
DogFight – 2D Multiplayer Plane Fightgame – 1976 + D. Green, L. White
DogFight ist eine klassisches Multiplayerspiel, das seine Spieler verteilt auf verschiedene Kämpfe und im Warteraum den Highscores bereit. Im Spiel selbst ist man unterwegs als Flugzeug mit begrenzter Anzahl Kugeln. Obwohl das Spiel eher ein Reflexspiel ist, macht das ganze extrem viel Spass. Es läuft recht zügig und beide haben dieselben Probleme, was Delays angeht. Gespielt kann nur zu zweit werden.
Viele Spiele ermöglichen – anders als die Konsolen später – die Möglichkeit einen Avatar (Name, Bild, Eigenschaften) zu erschaffen.
Der Warte- und Matching-Raum – leider gerade alleine. Die View wird automatisch aktualisiert!
Das Spiel erinnert stark an das viel später erscheinende TrippleAction/Flugzeugspiel auf Intellivision.
Anders die nun folgenden zwei Spiele: Futurewar und EMPIRE. Hier steigt man in eine Welt ein und spielt dort. Es gibt quasi nur diese eine Welt wie in heutigen grossen MMOs. Man wird Teil dieser Welt irgendwo im Virtuellen.
Futurewar – 1977+ E. Witz & N. Boland
Futurewar ist dabei eine Art Mischung aus Einzel- und Multiplayerspiel. Der Spieler loggt sich als Einzelspieler in das Spiel ein und kann ganz normal spielen. Loggt sich ein zweiter Spieler ein, so ist er im selben Universum und kann auch auf andere Spieler treffen. Es scheint zudem auch so eine Art Teamplay zu geben.
EMPIRE – 1977+ C Miller & G. Fritz
Ähnlich wie auch Futurewar funktioniert auch EMPIRE. Das hier stellvertretend vorgestellt werden soll für all die anderen Multiuserpiele. Dabei sei hier auch einmal auf die vielen gespielten Spiele hingewiesen, die die meisten Spiele statistisch zählen – seit 2013 149’555 Spiele. Hier können bis zu 32 (!) Spieler in 4 verschiedenen Teams gleichzeitig spielen. Ausgangspunkt ist dabei das StarTrek-Universum.
Beeindruckende Statistiken bei den meisten Spielen
Sei Teil des StarTrekUniversums – Wähle die Seite (Romulaner sei aussichtlos)
In EMPIRE ist man als ein Vertreter eines Empires der 4 Empires unterwegs und muss gemeinsam die Herrschaft übernehmen. Es ist wiederum ein komplexes Spiel, das hier gespielt werden kann. Man ist mit einem oder mehreren Raumschiffen in Echtzeit unterwegs zwischen verschiedenen Planeten. Die Steuerung ist dabei nicht besonders intuitiv, man gibt die Richtung in Grad an. Zudem kann man in 9 verschiedenen Speeds fliegen. Findet man einen Planeten kann man sich in dessen Umlaufbahn zirkeln, um mit dem Planeten zu kämpfen, zu handeln, Truppen aufzunehmen. Dabei können verschiedene Bündnisse eingegangen werden.
Das Spiel wird auch heute noch fleissig gespielt, erfordert aber einiges an Knowhow um aktiv mitspielen zu können, denn auch hier ist wiederum zu sagen: Die Komplexität hat es in sich für ein Spiel von 1977.
Mehr zu dem Spiel findet man hier >
Kontrolle & Actiongames
Radikale nur auf Action ausgerichtete Spiele, wie sie die Arcades kennzeichnen, sind auf einem Server-Client System (mit 1260 Bauds (Bits/Sekunde)) viel schwieriger umzusetzen. Das ist ja bis heute so geblieben. Hier sieht man worauf grosse Teile der 70/80er Jahre Einzelspieler-Games getrimmt waren: möglichst viel Speed, schnelle Reaktion und wenig Delay. Was nichts anderes bedeutete als die Maschine zu 100% zu kontrollieren und dies möglichst in Maschinensprache. Ein Paradigma, das die 70er und die 80er Jahre beherrschte und bis heute weiterlebt im Kontrollwahn vieler GameDevs* und GameDesigner*: Die Angst vor dem Glitch, dem Ruckeln. Selbstverständlich gibt es auch diese Spiele für PLATO wie etwa Asteroids – ein Arcade-Clone. Man muss als Spieler* einfach hoffen, dass nicht gerade viele Spieler online sind.
PLATO als GameEntwicklungsplatform
Die Bandbreite von entwickelten Fun-Games auf PLATO ist erstaunlich. Hier nochmals eine Liste der wichtigsten Spiele, die bis 1975 entwickelt wurden. Gleicht man sie ab mit den Spielen, die über die nächsten Jahrzehnte wichtig werden sollten im kommerziellen Gamebereich ist sehr viel dabei und die Komplexität der Spiele wird erst Jahrzehnte (so zumindest meine Einsicht) erreicht werden, werden die Spiele grafischer und schneller werden.
Im Rahmen von 50 Jahre PLATO gab es ein Panel der damaligen GameDevs. Ein auch historisch interessantes Panel – die Namen der meisten Entwickler der ersten Stunde unbekannt. Anders als Atari und die japanischen Gamehersteller der 80er und 90er Jahre, die absichtlich die GameDevs* und GameDesigner* verbargen, sind diese Personen nicht besonders bekannt geworden.
Es scheint als hätten sie nur auf PLATO Games entwickelt als Nebenbeschäftigung zum Studium, als Assistenten und seien anschliessend weitergezogen nach ihren Abschlüssen. Es scheint als hätte das System sie zwar im Innern bekannt gemacht und als seien einige Spieler* inspiriert weitergezogen. Anders gesagt: Die Spiele haben sich nicht für die eigentlichen Entwickler ‚gelohnt‘. Es lässt sich auch vermuten, dass die Kommerzialisierung ein zu grosser Gap gewesen war in diesen Jahren (Vom Grossrechner zur Arcade, Konsole oder Homecomputer). Ein weiterer Punkt ist sicherlich, dass die Spiele auf PLATO zwar extrem populär waren, aber sich nicht (in dieser Komplexität) kommerzialisieren liessen.
Trotz all dem bleibt es rätselhaft, warum nicht wenigstens historisch die Bedeutung ihrer Arbeit tradiert wurde. Es scheint als gäbe es eine Art zweite kommerzielle Geschichtsschreibung der Computerspielgeschichte, die erst mit den kommerzialisierten Games beginnt als Arcades, Consolen und Homecomputern. Dabei beginnt diese Entwicklung auf einem viel ‚tieferen‘ Komplexitätsniveau, dies sowohl technisch, mechanisch wie auch visuell. Ein Teil der Erfindungen wie die Multiplayergames waren zudem in diesem Moment viel zu teuer und wurden erst Ende der 80er Jahre (Telefon BBS) und im Laufe der 90er Mainstream fähig (Internet).
Abschliessende Frage
Stellt sich am Ende die Frage, ob wir Gamedesigner(Innen)? auch heute an Mainframes oder an teure Quantencomputer lassen sollten. Schaut man PLATO an, so muss man sagen: JA, wenn man in die Zukunft schauen möchte!
Abschlussbemerkung
Selbstverständlich ist dies nur ein erster Eindruck von PLATO (nach Stunden Elearnings, Spiel und Entwicklung). Aber gerade aus der GameDesign/Gamestudies-Perspektive kann und muss das erst ein Anfang sein. PLATO ist eine der wichtigsten frühen Gameplattformen, ein Framework mit Potential. Dies wird auch heute noch klar, wenn man damit und dafür entwickelt.
Dieser Artikel steht auch im Zusammenhang mit einem Projekt des Gamelabs der ZHDK ( gamelab.zhdk.ch ). Dabei wird versucht die Produktionsbedingungen von Spielen und ihren Platformen erfahrbar zu machen und herauszuarbeiten wie das Verhältnis von Spiel, Platform und Möglichkeiten der Platformen waren.