Die ersten Betriebssysteme auf Grossrechnern, die sich durchgesetzt haben, waren mehrheitlich Shell-Betriebssysteme. Das heisst auf den Terminals lief (es gibt Ausnahmen wie PlatoSystems) eine Shell. Hier konnte man Befehle eingeben mit Argumenten. Es war eine Art Valenzgrammatik.
Der Computer sucht dabei in einigen Verzeichnissen nach dem Befehl „banner“. Findet er dies führt er das Programm mit dem Argument „YES“ aus. Das sieht dann so aus.
Darauf baut letztlich die ganze erste Phase der Informatik auf. Input und Output klar getrennt. Erst danach kommen dann Abfragen für Input dazu und alsdann können Programme auch klassische Interaktiv sein – in den Programmen selbst. Noch viel später kommt dann (wieder mit Ausnahmen wie PLATO Systems) das direkte Abfragen von Tastaturevents dazu. Dies wird allerdings nie zu einem C-Standard. Und C ist bekanntlich die Grundlage für UNIX, das bis heute, das meistverwendet Betriebssystem bzw. die Grundlage für fast alle Main-Betriebssysteme ist.
(Siehe dazu auch: Von der Turnbased-Input-Informatik (Stop&Go) zur/und Optionalen-Input-Informatik (und die Auswirkungen auf Games) [Diskussion] https://research.swissdigitization.ch/?p=4161)
Genre: Shell-Argument-Only-Input-Games
Die Frage ist nun, gab es Spiele, die wie ein Befehl mit Argument funktionierte? Bis anhin konnten keine gefunden werden.
Anforderungen
- Input: Der Input muss von aussen kommen als Argument Bsp: > game input
- Dadurch gibt es nur zwei Möglichkeiten für ein Spiel: Einmal Input – Mehrmals Input
EinmalInput 1x
Diese Variante scheint nur mit sehr einfachen Spielen möglich.
Es könnte etwa ein Münzenwurf sein. Man gibt als Input an: coin 1. das Programm nimmt eine Zufallszahl und vergleicht sie mit dem coin. Dieses Spiel wäre endlos. Die Frage ist, ob es sich dabei um ein interessantes Spiel handelt.
Man kann sich auch ein komplexeres Spiel wie ein Labyrinth vorstellen, bei dem man die Züge im Voraus eingibt und schaut, wie weit man kommt etwa in einem Labyrinth. > labyrinth Uri
Möglich wäre auch eine Art Strategiespiel. Man gibt ein, was man so einsetzen will für das unbekannte Schlachtfeld. Natürlich ist das alles sehr wenig unterhaltsam (aus einer heutigen Gameperspektive), wenn man gar nicht weiss, welchem Szenario man gegenüber steht.
Das Ganze wäre damit eine Art Autobattler als Genre.
ZweimalInput 2x
Eine andere Möglichkeit wäre hier, dass man das Programm mindestens zweimal startet. Das erste Mal ohne Input man sieht den einen möglichen Level. Dann startet man dasselbe Programm nochmals mit den Parametern. Und dann ist es schon ein recht interessantes Setting.
Ein ähnliches Konzept könnte man hier schon sehen bei Oregon Trail, bei dem auch am Anfang der Möglichkeitsraum erschlossen wird: Man kauft im Laden Dinge, die man auf dem Weg nutzen konnte.
Mehr zu OregonTrail hier auf Wikipedia: https://en.wikipedia.org/wiki/The_Oregon_Trail_(series)
MultiInput 2+x
Das 2mal Inputspiel (ohne Speichern von irgendwelchen Daten als Dateien) lässt sich natürlich auch öffnen. Es ist egal wie oft man das Spiel aufruft mit Parametern. Es geht einfach darum ein bestimmtes Ziel zu lösen.
Selbstverständlich verliert hier das Spiel die Kontrolle über die Anzahl der Versuche. Man könnte auch argumentieren, dass das auch normale Spiele tun, da man ja einfach neu anfangen kann. Das Gewissen „um wie gut der Spieler*“ ist, liegt hier also beim Spielenden* und nicht beim Spiel. Und klar ist, je grösser das Spiel umso unwahrscheinlicher der Trick mit dem neu anfangen. Vielleicht sind Computerspiele auch deswegen bemüht, ein so langes Spiel wie möglich zu ermöglichen. Das Commitment steigt mit der Länge, im Spiel zu bleiben und das „Erarbeitete“ weiter zu ziehen.
Genre
Sicherlich ist diese Art des Spiels nicht besonders interessant, sobald es Stop&Go Games gibt wie mit Input/Returns wie bei MUDs (Basic) oder dann direkt „kontrolliert“ Games per Tastatur. Insofern fallen diese Computerspiele ab. Dennoch wären solche Spiele auch interessant, weil sie auf den ersten MainframeRechnern gespielt hätten werden können, selbst auf Teletypes/Druckern!
Leider gibt es keine Artefakte dazu, denn: Viele Experimente der Anfangszeit der Mainframes wurden nicht dokumentiert oder sogar extra „gelöscht“, weil man Grossrechner nicht für so etwas missbrauchen sollte. Wenn man sich allerdings all die Software anschaut auf Plato Systems (heute noch spielbar) wird schon klar: Die Leute haben viel ausprobiert. Es ist also unwahrscheinlich, dass es diese Software nicht gab. Ein weiterer Hint sind die 101 BASIC Games. Hier gibt es viele Programme, die einfach auch irgendetwas einmal machen, etwa ein zufälliges Labyrinth genieren etc. Das die Leute dann auf Papier lösen. Siehe dazu auch BASIC 101 1973 – Papier oft ausgedruckt & dann Displayspiele
Elearning-Format?
Vielleicht müsste man diese „Spiele“ auch eher im Elearning jener Zeit finden für Simulationen. Wo die Studierenden eine Fall kriegten und dann schauen konnten, was kam raus als Resultat mit ihren selbsterrechneten Parametern.
Aktuelle Ideen
Zureich Oregon Trail
Eine narrative Herangehensweise. Zuerst gibt man an, was man mitnehmen möchte. Der Rest des Spiel passiert dann automatisch.
https://www.and-or.ch/zureichoregontrail
Dieses Gamekonzept liesse sich natürlich auch einfach per Argumente realisieren.
> zureich apfel orange tasse
Und das Spiel gäbe die Antwort als Geschichte.
ShellDungeon (In Entwicklung)
Eine andere Möglichkeit ist näher an das Genre der Dungeon&Dragons heran zu gehen und ganz konkret die Eingaben als Parameter zu machen.
Hier erweitert sich einfach die Eingabe mit jedem Move. Und die Antwort kommt aus dem Programm.