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\u00fcchern 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\u00fccher sind d\u00fcrftig – 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\u00e4chsten 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. <\/p>\n\n\n\n
Deswegen basieren einige Prototypen auf Falschannahmen (In Technik und Konzept) und sind viel zu kompliziert im Vergleich zu den L\u00f6sungen in publizierten Games nach heutigem Wissen.
<\/p>\n\n\n\n\n\n\n\n
Das erste Spiel (Basic Zeit) war ein Listingkampfspiel – der Smilie-\u00fcber-den-Abgrund-Shooter<\/a> (freie Bennungen). 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<\/a> – eine Basic-Game-Variante. Darum war der n\u00e4chste Abstecher C. Aber auch dies half wenig f\u00fcr die Spielproduktion – zu wenig schnell und keine Einsicht halt Spiele zu machen, die „man machen konnte“.Und dann Assembler mit dem ersten Spiel: Auff\u00fcllen eines K\u00fcbels mit Joystick-Links-Rechts-Ger\u00fcttle (Decathlon). Dies war m\u00f6glich, wenn man zwei Bilder von einem Gegenstand hatte – leer und voll. Dann konnte man einfach die Linien dar\u00fcber kopieren. Dazu brauchte man nicht viel Ahnung.<\/p>\n\n\n\n ToDo: Abkl\u00e4rung TEKO – ein OneScreen-Geschicklichkeitsspiel-Prototyp. <\/p>\n\n\n\n Die „Erl\u00f6sung“ kam dann, als der STE auf den Markt kam. Eine Variante, die funktionierte wie der Amiga – Scrolling, Digitaler Sound. Hier enstanden einige Spiel-Prototypen.<\/p>\n\n\n\n \/\/ ToDo: Konkretere Datierung und Timeline der Entwicklungen der Prototypen<\/p>\n\n\n\n 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\u00f6llig mit Rechteck-Kollisionen zu arbeiten. Der Unterschied wird vom Spielenden nicht bemerkt.<\/p>\n\n\n\n ToDo: BeispielScreens und Prototypen hochladen inklusive Ressourcen<\/p>\n\n\n\n
Hier handelte es sich um ein OneScreenGame. Richtig gute Spiele waren nat\u00fcrlich 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. <\/p>\n\n\n\nSpritekollisionen<\/h2>\n\n\n\n
Grafik und Designvorstellungen<\/h2>\n\n\n\n