Die einfachste Art für eine Ausstellung das Color-Sudoku (8*16 Boxen mit je 3 neuen Farben) erfahrbar zu machen, ist direkt an einem Monitor ein Geflecht darüber zu legen. So dass man sieht wie das ganze ‚funktioniert‘. Eine andere Möglichkeit wäre natürlich eine App für ein Mobile Phone, wo man die Welt durch C64 (oder Apple)-Augen sehen könnte.
OneScreen-Games
Die ersten Spiele waren grossmehrheitlich One-Screen-Games. Das bedeutet aus Sicht des Gamedesigns und auch in der Spielmechanik, alle Dinge sind sichtbar auf einen Blick. Selbstverständlich gibt es Möglichkeiten auch hier die Sicht einzugrenzen, Techniken wären etwa Fog of War oder noch nicht geöffnete Zimmer (die erst beim Eintreten gezeigt werden).
Es bedeutet aber auch, das die Spiele oft die TopDown-Perspektive oder die Seitenperspektive verwenden. Die Objekte sind dabei relativ klein bzw. müssen klein sein, damit wenigstens etwas auf dem Screen passieren kann – auch wenn das Spiel auf verschiedene Screens verteilt ist. Die Spielmechanik des Suchens kommt in diesem Fall auch anders zum Einsatz, die Objekte müssen eher in Dingen versteckt sein wie Kisten als dann später in 3D Welten.
Scrolling-Games
Mit der Einführung des Scrolling ändert sich das. Der Spieler muss bei den einen Spielen im Bild der Kamera bleiben (etwa beim ersten Scrollenden Spiel) oder später in vielen ShootEmUps oder er steuert aktiv den Bildausschnitt oder moderner gesagt: Die Kamera ist über dem Spieler. Da erstaunt es dann auch nicht, dass Parallax-Scrolling genutzt wird, um die Welt auch ins 3D zu erweitern. Die Komplexität der Spielsituation rund um den Avatar bleibt meist die gleiche. Aber der Avatar rückt mehr ins Zentrum und wird nun oft grösser. Und das Suchen durch Scrolling von Gegenständen wird zu einer beliebten Spielmechanik.
// Einsatz von Flöte und Harfe und Funktion einmal untersuchen (vgl. 8Bit-Sound)
Es ist ein Moment, der eingepasst ist in den Iterationsprozess im Coding oder auch Gamedesign. Aus der These wie der Code funktionieren sollte wird ein Warten.
Beim Compillieren testet der Computer, ob alles zumindestesn formal korrekt ist. Der Entwickler* ist gespannt.
Einfach nicht das beim Compillieren:
Was ist falsch daran? Ein Hinweis vom Compiler. Aber gerade ist das nur die Idee, was sein könnte. Es geht weiter:
Ein erstes Entspannen folgt: „Ok es läuft“. Dann die zweite Anspannung: „Ok was läuft“. „Läuft das, was geplant war.“ Also die These von der Architektur, das was die Veränderung im Source-code nun im Resultat dem laufenden Programm, ist es das.
Dann das Warten beim Aufstarten und dann die Kontrolle, ist die These vom Konstrukt der Software korrekt, stimmt es mit dem laufenden Programm übereinander oder nicht?
Das ist ein Upchecken und ein oft sehr schnelles: „Ok, es läuft“ oder „Nein shit, es geht nicht. Warum nicht? Ist mein Gesamtkonzept falsch?“
Nächste Runde. Nächste Challenge. Nächstes Iteration: IDE. Changes > Kompillierung > Game.
Nachdem nur 6 Sprites kontrolliert werden konnten auf dem Amiga, konnte nun ein ‚weiteres‘ gerettet (kontrolliert) werden. Das eine aber hängt nach ausser ‚Order‘ oben am Rand. Keine Ahnung warum.
Oder anders gefragt: Wie sah die Crack- und Demoscene das Gamedev und ihre Komplexität. Und wie sahen/sehen die Gamedev-Scene die Crack und Demoscene. Dies ist gerade im Schweizerumfeld eine interessante Frage, da diese Scenen sich überschnitten haben.
Die Maus eingeführt in den Massenmarkt mit dem Macintosh kam bei der Masse dann an mit den 16/32Bit Homecomputern Atari ST und kurz danach Amiga. Die Mäuse machten GUI bedienbar und einige Game Genres wirklich attraktiv von Arkanoid-Games über Point-And-Click Adventures bis zu Strategiespielen.
Mäuse waren analog (im Gegensatz zu den optischen heute) und damit Maschinen, die Dreck ansammelten bei den Rollen, über die die Kugel „rollte“. Und wenn der Nutzer* sie nicht öfters reinigte, dann sprang der Zeiger oder bewegte sich ruckartig.
Hier ein Beispiel, wie man eine solche (kein Orginal) Maus reinigen musst. Es war eine recht grausige Sache, da der Nutzer* ja wusste, dass das alles Dreck von der – im besten Fall – Mausmatte war.
// Smaky fehlt hier: er taucht auf bei 8Bit und 16Bit home bzw. EducationComputer.
// Todo: Differenzierung zwischen Homecomputeren und EducationComputer einführen bzw. als Pole darstellen oder Option.
Warum ging letztlich die Homecomputerszene so sang- und klanglos unter?
Aspekt: Bürosoftware
Da gibt es zuerst natürlich die einfachsten Erklärungen. Die ersten (nach den Selbstbaucomputern) PCs waren teuer und eigentlich Businessmodelle – APPLE II 1977 und viel später der PC 81. Vorallem der zweitere war überhaupt keine Multimediamaschine eher veraltete Technik auf Text(mode) ausgerichtet. Und einem grauenhaften Beepser (7). Mehr brauchte es für die Vorgänger von Excel und Word nicht. Und schliesslich kam der PC als Gegensatz zu den verkauften Mainframe-Computern von IBM auf den Markt. Die Radiation begann mit den Kompatiblen und Microsoft, dass allen MS-DOS verkaufte.
Aspekt: Multimedia und darin eingeschlossen Games (inkl. Piraterie)
Die Homecomputer hingegen mussten sich sehr früh schon zu Hause auch als Konkurrenz auch zum Fernseher etablieren und eben andere Funktionen finden, als nur Business-Software. Da die Zielgruppe Interessiert und auch Jugendliche dabei waren (neben den Elektronikinteressierten). Und da spielten dann Grafik und Sound eine grössere Rolle. Und diese boten fast alle 8Bit-Homecomputer und die 16/32Bitter sowieso. Dieser Umstand wurde erst eingebnet Mitte der 90er Jahre, wo vorallem 3D-Karten und Soundkarten aufkamen für den PC, der PC billiger wurde (Hohe Gesamtkosten) und die Spielindustrie darauf neu ‚erfunden‘ wurde auf aufrüstbaren Computern vs Consolen und Homecomputer.
Aspekt: Programmierung
Fast jeder Homecomputer der 8Bit Generation kam mit einer Programmier-Entwicklungsumgebung meistens Basic daher, das auch meistens gerade das Interface für die Nutzer* war! Soviel Angebot an Softwareentwicklung war nie. Dies wird schon zurückgedrängt in der 2ten Homecomputer Generation mit den 68000ern, Maus und GUI.
Aspekt: Anforderungen über Anforderungen (ab Mitte der 90er Jahre)
Die Anforderungen an Computer steigen ab Anfang der 90er Jahre massiv. So müssen die Systeme ein GUI haben, in der Lage sein Netzwerk, einzubeziehen (LAN und Internet) und vorallem müssen immer mehr Prozesse mehrfach auf den Systemen laufen können. Damit haben alle System, die von „unten“ kommen, also letztlich vom „Rechner“ abstammen (Commodore), immer weniger liefern können. Siehe Macos 6-9 oder Windows 3.11, Windows 95.
Diese Funktionalität kommt vorallem mitgeliedert in den Workstation, die eigentlich Vereinfachungen sind von Mainframes bzw. Mainframe Technologie ist mit Multitasking (Ja der Amiga hatte auch Multitasking), Mehrusersystemen, Netzwerklayer. Und so wundert es denn kaum, dass alle danach überlebenden Systeme von Grossrechnern abstammen – mehrheitlich von UNIX (das nur frei entstand, weil AT wegen Monopolverletzung verurteilt wurde dazu)wie NExTSTep>MacOSX, Windows NT und zuletzt Linux. Es gab natürlich auch andere Versuche ganz neue Betriebssysteme zu entwickelten, aber auch die schauten sich vorallem bei UNIX um.
Fazit
Im Grossen und Ganzen betrachtet, ‚verliert‘ letztlich die Homecomputerszene als Empörkömmling gegen die Grossrechnertechnologie mit ihren Workstationsablegern. Die Homecomputeranbieter hatten einfach zu wenig finanziellen Power (trotz dem Workstation-68000.Prozessor) all dies (trotz Vorlage) nochmals neu zu erfinden und entwickeln.
Gestern wieder einmal versucht, ob mir ChatGPT helfen könnte bei Assembler Problemen: Erstelle den Assembler-Code für das Laden eines 16Color Bildes in den Amiga.
Das Resultat, ausser über dass allgemeine Formulieren der Schritte und eines Codes, der nicht funktionierte, ist ChatGPT 4.x nicht hinausgekommen.
Scheint doch noch zu wenig standartisiertes Wissen und deren Repräsentation im Netz und auf Github und Co zu geben, als dass man das trainieren könnte. Dies verwundert auch nicht, weil die meisten Einführungen auch nicht Standard-Anforderungen thematisieren. Insofern …
Mein erster Approach wäre Snake. Aber selbst Snake ist nicht so einfach, es braucht zumindest einen Array, den man darstellt und eine Keypressed-Routine. Alles Dinge, die es gerade in Basic lange nicht gab und damit wurde ja zuerst vornehmlich ‚gelern’t.
Schaut man sich etwa 101 Basic Games an, findet man Snake selbstverständlich nicht, dafür viele „CLI“-Games und natürlich auch neben Quizes – der Star – mein aktueller Favorit: HangMan. Und HangMan ist relativ einfach zu programmieren, hat aber schon einige Features, die interessant sind, nutzt programmiertechnisch schon den einen oder anderen kniff oder anders gesagt: Ist eine Herausforderung und damit ist die Programmierung schon eine Challenge, ein Spiel. Dazu kommt, dass es auch leicht anrüchig ist. Also vielleicht sogar erst in den ‚Ueberstunden‘ oder danach entwickelt und gezockt wurde.
Oder dann doch TicTacToe, das ein Einspieler wie auch Mehrspieler sein kann? Oder Life (auch daran lässt sich vorzüglich der Vorteil von Arrays demonstrieren .-)
Die Antwort in 101 Basic Games ist „eindeutig“ (auch wenn hier natürlich jedes Spiel nur einmal vorkommt) nach Titeln nicht nach Spielmechanik – 2 mal TicTacToe in 2D und 3D und 2x Life.
Die Suche geht weiter.
Die Frage ist nun, wie sieht es in den Übungsbüchern oder Lernbüchern von damals aus. Eine interessante Frage.
// ToDo: Auszählen auf Plato Systems – welche Spiele waren da beliebt?
// ToDo: Nachschauen/Auszählen in Basic/Pascal Einführungen, Basic-Programmen …
// ToDo: Nachfragen bei Entwicklern*, was ihr erstes Spiel war (Erstes einfaches, erstes komplexes Spiel)
etc.
Wer nach dem C64 erwartete, es wird nun alles einfacher mit den Homecomputer 16/32-Bittern ab 1985, der wurde eher beim Atari ST glücklich oder vom Sinclair QL. Das waren Computer mit viel RAM und einem fantastischen Prozessor (Motorola 68000), der endlich auch auf Entwickler zugeschnitten war und nicht tot gespart war wie der 6502. Der Atari ST war billig, den Jack Tramiel trieb auch hier sein Spiel für billig und für die Massen, darum wurde an Grafik aber vorallem an Audio gespart (Der Amiga war ja auch mal als Atari Produkt im Gespräch, endete aber bei Commodore).
Der Amiga eingeführt kurz nach dem Atari ST 1985+ war das Homecomputer-Highend-Produkt (neben dem Macintosh und anderen 68000er based Workstations) und am Anfang auch eher teuer (mit wenig RAM 256k), erst der Amiga 500 (1987+) änderte dies grundlegend.
Als Entwickler* sieht die Sache dabei im ersten Moment super aus: Wow, der Amiga, der kann soviel, soviel mehr als der C64 und auch als der Atari ST. Die Facts sind überragend, verschiedenste Bildschirmmodis, die Möglichkeit den Bildschirm mit verschiedenen Screens zu füllen, Hardwarescrolling, Sprites, digitalisierter Sound und sogar Aufgaben können an den Co-Prozessor abgegeben werden. Zudem ist die Grafik skalierbar über Bitplanes. Pro Bitplane kann man die dargestellten Farben vergrösseren. 1 Bitplane 2 Farben, 2 Bitplanes 4 Farben bis zu 5 Bitplanes mit 32 Farben und mit Spezialmodis noch mehr. Was allerdings auch sehr viel mehr Rechnzeit braucht. Aber was will Entwickler* mehr?
Hier muss vermutlich ein Unterschied eingeführt werden zwischen: Entwickler* für die Demoscene und Entwickler* für die Gamedesignscene. Für Erstere* ist der Amiga bis heute eine technische Herausforderung – ein Instrument aus dem bestehenden noch mehr herauszuholen. Die grosse Challenge oder ein Spiel. Für Zweitere* ist der Amiga nur Mittel zum Zweck. Natürlich gab und gibt es auch Mischformen, wie man an vielen Games als technischen Meisterleistungen schnell erkennt. Aber eben nicht unbedingt.
Weiterlesen