Die ersten Prototypen von Imp89 [Assemblerphase] versuchen Spiele zu sein, die den Ideen der ‚grossen‘ Spiele/Demos folgen. Sie versuchen also diese Spielmechaniken und Stile zu simulieren.
Konkret gibt es nicht soviel Einfluss aus anderen Bereichen. Es wird wenig versucht einen eigenen Stil zu entwickeln. Eventuell gibt es eigene Entwicklung in der Grafik bei Dingen wie Büchern etc. Vorlagen sind eher Arcade/Spielhallen-Games, die verkauften Homecomputespiele (Hits) und die Demoscene.
In Sachen Spiel gibt es vermutlich falsche Vorstellungen zu den benutzten Techniken. Dabei ist der benutzte Computer Atari ST nicht gerade hilfreich, da er kein „Videogame-Computer“ ist. Er bringt fast nichts mit wie Hardwaresprites, Scrolling, Musikroutinen (YM). Die Magazinartikel oder Bücher sind dürftig – etwa 1987. Anders gesagt: Es muss eigentlich alles selbst gemacht werden. Ein Fehlen von anderen Ressourcen und Programmierinteressierten (ausser meinem Bruder) in der Peergroup half dabei auch nicht. Die nächsten an Spielprogrammierung interessierten Kollegen war in der Kantonsschule. Dieser hatte einen PC (MS-DOS) und das war dann noch jenseitiger. Er programmierte mit einem Kollegen zusammen ein Tetris in PASCAL.
Deswegen basieren einige Prototypen auf Falschannahmen (In Technik und Konzept) und sind viel zu kompliziert im Vergleich zu den Lösungen in publizierten Games nach heutigem Wissen.
Komplexität von Spielen – das OneScreenGame
Das erste Spiel (Basic Zeit) war ein Listingkampfspiel – der Smilie-über-den-Abgrund-Shooter (freie Bennungen).
Hier handelte es sich um ein OneScreenGame. Richtig gute Spiele waren natürlich keine OneScreen-Games und auch keine Screen-to-Screen-Umschaltspiele sondern eben State-Of-The-Art. Sie scrollten! oder hatten eine Kamera – aus heutiger Perspektive. Der Fokus als Entwickler* war also getrieben von den Ganz Grossen, den Spielen, die im PowerPlay „gut-sehr gut“-Wertungen hatten.
In diesem Sinn, war das einfach zu erreichende Spiel im „Genre“ OneScreen Game nicht so attraktiv. Es war aber auch klar, mit Basic kam man nicht besonders weit. Dann STOS – eine Basic-Game-Variante. Darum war der nächste Abstecher C. Aber auch dies half wenig für die Spielproduktion – zu wenig schnell und keine Einsicht halt Spiele zu machen, die „man machen konnte“.Und dann Assembler mit dem ersten Spiel: Auffüllen eines Kübels mit Joystick-Links-Rechts-Gerüttle (Decathlon). Dies war möglich, wenn man zwei Bilder von einem Gegenstand hatte – leer und voll. Dann konnte man einfach die Linien darüber kopieren. Dazu brauchte man nicht viel Ahnung.
ToDo: Abklärung TEKO – ein OneScreen-Geschicklichkeitsspiel-Prototyp.
Die „Erlösung“ kam dann, als der STE auf den Markt kam. Eine Variante, die funktionierte wie der Amiga – Scrolling, Digitaler Sound. Hier enstanden einige Spiel-Prototypen.
// ToDo: Konkretere Datierung und Timeline der Entwicklungen der Prototypen
Spritekollisionen
Hier versuchte ich Pixel-Kollisionen, wie sie die richtigen GameHardwares wie Consolen/C64 und vermeintlich auch der Amiga hatten zu emulieren. Darum gibt es viele Versuche mit einer speziellen Farbe, um die Dinge herum, das zu simulieren. Wissen heute: es reicht auch völlig mit Rechteck-Kollisionen zu arbeiten. Der Unterschied wird vom Spielenden nicht bemerkt.
ToDo: BeispielScreens und Prototypen hochladen inklusive Ressourcen
Grafik und Designvorstellungen
Siehe dazu auch Grafik- und Designentwicklung der Consolen & Homecomputerscene https://research.swissdigitization.ch/?p=3933
[…]
[In Überarbeitung]