Archiv für den Monat: Oktober 2025

Imp89 – MacOS-Development von IndieGames 1995+- Designaspekte [Erfahrungsbericht]

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

Mehr zu Vorlagen und Ideen siehe auch hier: Skizzenbücher, Grafiken – Überlegungen [Erfahrungsbericht]

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.

Dieses Bild hat ein leeres Alt-Attribut. Der Dateiname ist Bildschirmfoto-2025-10-22-um-11.41.21.png

https://www.la1n.ch/macosclassic

Alle download- und auf Emulation spielbar.

Ein Kurzreview bietet der folgende Youtube-Bericht.

Weiterlesen

Imp89 – MacOS-Development von IndieGames 1995+- Ressourcen

Hier sind einige Development-Ressourcen also die Orginalentwicklungfolders von Imp89 herunterladbar.

bonYxII – Developmentfolder

roTyx – Developmentfolder

Die Development-Ressourcen inklusive Source-Codes finden sich hier.

blownEye – Developmentfolder

breakIn (inkl. erste javaversion) – Developmentfolder

blackBox (1997?) Prototyp

(Indie-)Spielentwicklung auf dem Mac/Finder 7.1+ (1995) [Erfahrungsbericht]

Nach dem Ende der Homecomputer gab es eigentlich nur noch zwei Computer-Game-Platformen: Macintosh (ab 1985) und der Windows PC (so richtig ab 1995).

Beide Plattformen waren teuer. Wobei der PC immer schon – seit den Clones – damit arbeitete erweitert werden zu können. Das verwischte dann die tatsächlichen Kosten dieser Highend-Computer ab 1993 nicht nur mit 2D sondern oft auch einer 3D Grafikkarte. Die Homecomputer waren auch an der Entwicklung und Integration von 3D beteiligt von Wireframe (Adventure, OpenWorld, Strategiespiele) bis hin zu Polygongrafiken. Siehe dazu auch: Komplexere 3D mit Vektor- und PolygonGrafiken in Spielen ein Spezialgebiet der Homecomputer? [These] https://research.swissdigitization.ch/?p=1812 Aber gegen die neuen 3D Grafikkarten hatten die Homecomputer und auch ihre Nachfolger keinen Stich.

Der Macintosh ging (seit es ein Macintosh ist vs Apple II) den All-In-One weg, also eine Platform mit wenig Ausbau. Die Homcomputer-Gamer hatten sich also zu entscheiden: ReadOnly Console oder dann doch einen Computer Windows oder Mac. Die Wahl war selbstverständlich eher MS-DOS/Windows. Hier konnte auch gebastelt werden, ein wichtiger Ausweis in diesen Zeiten – schliesslich musste die „Nerd-Energie“ als Status oder gar symbolische Kapital erworben werden oder irgendwohin.

Grafische Betriebssysteme als neue Grundlage

Im Folgenden sollen nun die Möglichkeiten aufgezeigt werden als GameDev-Platform, dabei ist auf der Ebene eines Betriebssystem damals wie Windows 95 oder Finder ein ähnliches Setting anzutreffen. Das Betriebssystem war die neue Grundlage für Spiele – denn es bot nun Unterstützung für die Maus und auch Netzwerk.

PowerMac – die neue Platform

Auf dem Mac standen gerade im Unterbau grosse Veränderungen an. Statt auf die Motorola-Prozessoren (wie fast alle Homecomputer auch – Ausnahme Acorn Archimedes) setzte Apple neu auf den PowerPC (32/64 bit) von IBM.

Mehr dazu hier: https://en.wikipedia.org/wiki/PowerPC

Die Idee – die fertigen ja Grossrechner mit diesen PowerPCs und warum nicht auch PCs damit herstellen. Die Idee war auch eine PowerPC-Platform (an der IBM dann schnell das Interesse verlor).

Apple passte sein Betriebssystem an und brachte die PowerPC-Macs heraus.

Mehr dazu: https://en.wikipedia.org/wiki/Power_Macintosh

Auf der Windows-Compatiblen Seite passierte etwas ähnliches – statt total neuem Prozessor wurde hier auf den Kompatiblen Pentium 1993+ von Intel gesetzt (https://en.wikipedia.org/wiki/Pentium).

Neue Plattformen – neues Level: OS-Games (VGA+)

Das Resultat war bei beiden dasselbe. Ungeahnte Leistung und der Abschied von der hardwarenahen Programmierung. Fortan liefen die meisten Dinge dann als Windows Prg und nicht mehr als MS-DOS und darauf OpenGL. Dabei spielte natürlich auch eine Rolle, dass die Computer intern in vielen Dingen verschieden schnell waren – sei es auf der Prozessorebene oder im Grafischen (Grafikkarten). Dadurch musste eine Abstraktion stattfinden in übergreifende transparente Layers, die unabhängig von der tatsächlichen Hardware liefen. Und damit endete dann auch das meiste an Assembler-programmierten Games. Hier fand eine weitere Virtualiisierung der Hardware in diesen neuen Operating Systems statt.

// Vgl. dazu CHLudens-Interview mit Schüssler zu Click-O-Mania.

Weiterlesen

Von klassischer Spielprogrammierung (MacOS) zu Java Applets 1996+ (VirtualMaschines) [Erfahrungsbericht]

Erfahrungsberichte dazu:
Applets (VM) sind da – Programmierung mit Events – 1996+ [Erfahrungsbericht]
https://research.swissdigitization.ch/?p=1860
Flash & JavaApplets – die Idee von einer Zukunft jenseits von Plattformen [Erfahrungsbericht Zukunft 1996+]
https://research.swissdigitization.ch/?p=4994

Das neue Framework Java-Serverseitig und JavaApplet-Front-End

Java Applets erweiterten wie andere Plugins ab 1996 das Web. Dadurch wurde das Web um ein interaktives unpropriertäres offenes Format erweitert. Es war mit einer ’normalen‘ Programmiersprache gemacht und nicht wie FLASH oder Director mit etwas ‚abstraktem‘. Zusätzlich liessen sich mit Java auch Serverseitige Dinge realaisieren. Die Idee war damit klar: Java konnte die umfassende neue klammer werden und schloss das Webfrontend auch für ’normale‘ Programmiersprachen aus der C-Familie (extended) auf.

Konkreter

Sie waren wie ein Bild aber mit der Möglichkeit der Interaktion. Allgemein beschrieben etwa hier:

A Java applet is a Java program that is launched from HTML and run in a web browser. It takes code from server and run in a web browser. It can provide web applications with interactive features that cannot be provided by HTML. Since Java’s bytecode is platform-independent, Java applets can be executed by browsers running under many platforms, including WindowsUnixmacOS, and Linux. When a Java technology-enabled web browser processes a page that contains an applet, the applet’s code is transferred to the client’s system and executed by the browser’s Java virtual machine.[5] An HTML page references an applet either via the deprecated <applet>tag or via its replacement, the <object> tag.[6]
https://en.wikipedia.org/wiki/Java_applet

Mehr dazu auch hier: https://medium.com/@BitrockIT/java-the-world-wide-web-the-beginnings-d186cb0d381

HTML

Im HTML-Text sah dieses Objekt dann direkt so aus:

<HTML>               
<BODY>               
<APPLET CODE=SimpleApplet.class WIDTH=200 HEIGHT=100>               
</APPLET>               
</BODY>               
</HTML>
https://www.oracle.com/java/technologies/jpl1-building-applet.html

CodeStructure

Das Konzept der Applets unterscheidet sich grundsätzlich von normaler Gameprogrammierung damals.

CodeStructure MacOS (Klassische Spielprogrammierung)

Die Programmierung eines Macspiels wie etwa breakIn (Imp89) sah folgendermassen aus in C(++). Dabei kamen letztlich die genau gleichen Code-Paradigmen wie in Assembler / BASIC / Pascal zum Einsatz: Es war letztlich ein File – ein MainPrg, das den Prozessor nutzte.

Screenshot

Das heisst, der ganze Code wurde von Oben nach Unten abgearbeitet, dann wurde falls nötig auf den Vsync gewartet und es ging von vorne los. Das Resultat waren etwa die Spiele von Imp89.

Weiterlesen

banner (unix command) um grosse Beschriftungen und sogar Demonstrationsbanner herzustellen?

https://en.wikipedia.org/wiki/Banner_(Unix)

// ToDo: Suche nach Bildern aus den 70/80er/90er: Gab es Beschriftungen, die so gemacht wurden – etwa in Rechenzentren? (Daran kann ich mich noch so wage erinneren) – Wurde auch Banners ans Konferenzen benutzt oder sogar im Bereich von Demos? Denn letztlich war es die schnellste Möglichkeit mit Endlospapier Texte gross auszudrucken.