Der Autor dieses Textes ist auch einer der GameEntwickler hinter Imp89. Es wird dennoch versucht hier aus der Distanz das eigene Schaffen zu reflektieren.

Mehr zu allgemeinen Überlegungen über das MacOS Development siehe hier: https://research.swissdigitization.ch/?p=6270

Imp89 entstand als mein Bruder und ich ein Listingspiel für ein Basic-Atari-ST-Game eingeschickt haben fürs HappyComputer. Siehe dazu hier: https://research.swissdigitization.ch/?p=1089. Danach entstanden in diversen Abstufungen Gameprototypen auf dem Atari ST https://research.swissdigitization.ch/?p=4131.

Zusammengefasst auf der Nachfolgewebseite von Imp89 la1n liest sich dann das so:


.coding & creating games

at the end coders are gods over the turing maschine: writing code is ‚having power‘, coding is ‚to speak the magic language‘. this magic words are than reality executed by the slave machine (or an error). 

in the 80ies on homecomputers young people could step into this world of ‚power‘ of interaction. the 16/32 bit homecomputer even brought the mouse, the gui, a lot of colors, memory, modern fast cpus and were modern as hell (and not so expensive like the mac). a whole game could be made on one computer from sound, to graphics, to code. 

your code controls a machine (with assembler) and over this all the the output and all the interactions. so computers became our funslave, they do what we ‚want‘ – a quite strange thing. so for a lot of coders: coding is absolute power (over a small maschine) and explains also why they till today want to control everything. they want to write their own engines and not use a game engine.

coding is defining rules, creating your own world defined by this rules and there is also the link to games. games at the end are also defined by rules and are creating a magic circle (huizinga). so creating videogames is at the end double coding: you create computer codes for game codes.

starting with basic, gfa-basic, c and than assembler (bbs demo) on atari st imp89 1988+
switching to mac os. coding in c++ 1995+
java-codings in applets (not documented here) 1996+
flash-codings(?)

Imp89 Games

Die Imp89 Games, die auf dem Mac entstanden finden sich hier auf der Webseite von la1n.ch.

https://www.la1n.ch/macosclassic

Alle download- und auf Emulation spielbar.

Ein Kurzreview bietet der folgende Youtube-Bericht.

Idee

Die Idee war damals sicherlich Games mit einem gewissen Qualitätsanspruch zu entwickeln, die sich auch verkaufen liessen, vornehmlich als Shareware. Siehe dazu auch: Veröffentlichungsarten von digitalen Spielen [in Arbeit] https://research.swissdigitization.ch/?p=2417

Designideen

Auf dem Mac 1995 fehlten mehr oder weniger fast alle Arten von Spielen mit Ausnahme vielleicht der grossen 3D Spiele, hier gab es einige neue Spiele und Umsetzungen (Myst https://en.wikipedia.org/wiki/Myst (Qucktime3D) oder Marathon – Developer Pippin! https://en.wikipedia.org/wiki/Marathon_(video_game) 1994 oder diverse Echtfilm-Games).

Im Bereich der Arcade Games aus den Spielhallen war jedoch Fehlanzeige. Diesen Bereich gab es nach den Heimcomputern einfach gar nicht mehr. Sie wurde vornehmlich von Sharewaregames gefüllt. Diese waren in ihren Qualitätsansprüchen meist nicht besonders anspruchsvoll und diesen Bereich gab es zu füllen – weil man wollte ja visuelle interessante Spiele spielen.

Design

Das Design konnte nun anders als bei den Homecomputern auch ohne Tilebasierung realisiert werden. Eine Diskette hatte nun immerhin 1.44 MB zur Verfügung. Dadurch waren nun ganzseitige Bilder oder Levelhintergründe möglich.

SettingRules vs VisualOnlyRules

Eine der wichtigsten Entscheidungen im Design ist: Gibt es ein konkretes VisuellesTopic oder ist es ein abstraktes VisuellesTopic. Anders gesagt: Muss es etwas Gegenständliches sein aus einem Setting oder ist es ein abstraktes . Das erste verlangt dann eine mehr oder weniger inhaltliche Bezugnahme – eine Konkretisierung in einem Setting, die Gestaltung eines Systems in dem Formen, Farben und eben Inhalt zusammenläuft. Beim Zweiten braucht es ledgilich ein visuelle Konzept. Die Dinge müssen zusammenpassen – müssen eine visuelle Story erzählen – ein visuelles Feld füllen. Beim ersten sind visuelle und inhaltliche Regeln beim zweiten allein visuelle Regeln.

Im Folgenden Spiel BONYX (dem ersten Imp89-Spiel auf dem Mac) sieht man zweiteres in Aktion bei den Steinen. Die Steine sind mehrheitlich „abstrakt“, indem sie keinem Setting folgen. Sie müssen einfach nur unterschiedlich sein, damit man sie erkennt beim Spielen. Dabei geht es hier um die Grundfarbe und den konkreten Stein. .

Die Steine wurden dabei in ihrer Grundform mit KaiPowerTools generiert. Und also eher ausgelesen als von Anfang an designed. Dabei arbeitete KaisPowerTool-Plugin natürlich mit Zufalls generierten Patterns.

Design ist mit KaiPowerTools auch mehr ein Evolutionsspiel: Variation auslesen, schauen, was klappt, weitermachen, weitervarieren. Dabei geht es mehr um surfend designen als um eine Idee zu haben und diese umzusetzen. Es ist ein Designen mit dem unbekannten anderen, den Möglichkeiten von procedural generiertem Inhalt.

https://en.wikipedia.org/wiki/Kai%27s_Power_Tools

Links kann die Mutationrate (Baum) eingestellt werden und rechts kann rund um das Hauptelement gewählt werden in welche Richtung sich die Texture entwickeln soll.

Dabei ist fast alles ausgewählte Zufallsgrafik. Hier sieht man zwei Sorten von manueller „3Difizierung“. Die einen scheinen ebenfalls aus KaisPowerTools zu kommen, etwa den roten Stein. Andere wie der blaue oder der graue Stein scheinen manuell gemalt zu sein mit Schatten und Licht.

Allein die Hand und der Zeiger oben ist klassisch designed. Der Rest scheint generiert und nachträglich bearbeitet zu sein.

Anderes Beispiel aus Imp89-Games – BreakIn

Wobei hier unterschieden werden muss – die Animationen scheinen von Hand gezeichnet (Explosion) oder dann mittels Distortion von Photoshop gemacht.

Bei GROTIC sieht es ähnlich aus. Hier sind die Bälle auch KTP-Geniert und dann nachträglich mit Licht und Schatten versehen worden per Photoshop.

Der Hintergrund ist eine extrudierte Texture und sollte – soweit ich mich erinnere plastik-metallig sein.

Mehr zur Idee dieser Arcade Umsetzung hier: https://research.swissdigitization.ch/?p=5173

Photoshop: Layers, Auswahl und Painting

Ebenfalls KPT-generiert scheinen die Hintergründe aus roTYX zu sein. Dann scheint es in der Mitte einen gemalten flächigen Bereich zu geben, der gelb eingefärbt ist und als Ebene darüber gelegt ist mit Saturierung.

Auch der Rest scheint nur per zusätzlichen darübergelegten Ebenen gezeichnet worden zu sein. Es handelt sich soweit sichbar um eine einzige Texture.

„Einfurchung“

Dies sind nur darüber gelegte schwarze Ebenen.

Erstellt wurden sie:
1. Ebene erstellen
2. Ovale Selektion
3. Malen in die ovale Sektion mit einem Brush mit Schwarz
4. Löschen mit einer weitern ovalen Selektion nach links.

„Höhle“

Die Höhle ist „nur“ eine schwarze Ebene. Diese wurde damals wie folgt erstellt:
1. Generierung eines Selektion mittels Ovalen und +
2. Malen mit einem Brush mit Schwarz
3. Suche nach einer geeigneten Kombinierungsart

„See“

Auch der See-Effekt ist gleich gemacht. Beim genauen Hinsehen fällt dann auf, dass die Texture im See einfach weitergeht und gar nicht gespiegelt ist. Das ist natürlich nur möglich, weil die Texture recht „eintönig“ farblich wie auch strukturell ist.

„Gegenständlicher“ – SettingRules

Sehr viel Gegenständlicher ist das Spiel BlownEye. Das beginnt schon mit dem Titelscreen. Ein übermaltes Analogbild.

Und setzt sich im Spiel fort. Hier werden ganz bewusst Dinge aus dem Genre der Sidescrolling ShootEmUps zitiert und die wenigsten ShootEmUps sind abstract oder folgen nur visuellen Regeln.

Mehr zu konkreten Daten aus der Entwicklung finden sich hier:
https://research.swissdigitization.ch/?p=6357