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

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.

Case PowerPC Indie-Games

Von aussen ein gewöhnlich hässliches Design der PowerMac.

Im Inneren steckte aber viel Power. Dazu besass der PowerPC eine „SoftwareEmulation“ für den Motorola 68000. Damit konnte dann auch alte Software „emuliert“ werden.

„System 7.1.2 is the first version of the Macintosh System Software to support Apple’s new PowerPC-based computers. 68k applications that had not yet been … “ 1994 https://en.wikipedia.org/wiki/System_7

Visuellen Möglichkeiten

Alles an diesen Systemen war digital. Von der Grafik bis zum Sound. Es waren geradezu digitale Ermächtigungsmaschinen.

Default (1 MB VRAM):
512×384, 640×480, or 832×624 at 16-bit;
1024×768 or 1152×870 at 8-bit.

https://everymac.com/systems/apple/powermac/specs/powermac_7100_66.html#:~:text=*By%20default%2C%20this%20model%20has%201%20MB%20of%20VRAM%20on,Details:

Damit übertrafen die Modelle viele Standardauflösungen etwa der Arcade-Hallen und der Consolen bei weitem, denn hier wurden nur allmählich grössere Formate (Monitormodelle) eingeführt. Die Consolen klebten sogar noch mehr am Videoformat als die Arcades. Gleichzeitig werteten natürlich auch diese neuen Skills die Spielautomatenklassiker ab, weil diese nun ‚alt‘ aussahen. In den Spielhallen wurde dagegen gepockert mit viel 3D-Spielen mit Atemberaubenden Effekten und 3D-Hardware, die den Kaufpreis eines PC meist weit überstiegen (siehe Racing-Games).

Coding

Entwicklung mit Codewarrior 1993+. Codewarrior war ein Tool das sowohl 68k wie auch PowerPC-binaries erstellen konnte. Diese waren dann zusammengefasst als Fat-Binary nutzbar.

he system was developed by Metrowerks on the Macintosh, and was among the first development systems on that platform to cleanly support both the existing Motorola 68k and the PowerPC (PPC) instruction set architectures. During Apple’s transition to PowerPC, CodeWarrior quickly became the de facto standard development system for the Mac, rapidly displacing Symantec’s THINK C and Apple’s own Macintosh Programmer’s Workshop. Apple’s purchase of NeXT in 1996 led to a decline in CodeWarrior’s relevance as Mac programming moved to the NeXT platform’s own developer tools: Interface Builder and Project Builder, which were built on top of the GNU Compiler Collection. […] Metrowerks also made it easy to generate fat binaries, which included both 68K and PowerPC code.

https://en.wikipedia.org/wiki/CodeWarrior

Der Titel der Software ist anscheinend eine Adaption von Apples Dev CDs.

CodeWarrior CD packaging was very much in the tradition of the Apple developer CDs, featuring slogans such as „Blood, Sweat, and Code“ and „Veni, Vidi, Codi“ in prominent lettering. Competing products such as Symantec’s THINK C were more conventionally marketed.
https://en.wikipedia.org/wiki/CodeWarrior

Auf jeden Fall brachte CodeWarrior etwas Martialisches in diese technische Welt und fokkusierte auch auf Einzelentwickler*, so liess sich das zumindest lesen. Es liest sich auch als Bruch zu Turbo XYZ.

„Boxes“

IDE

More here: https://www.macintoshrepository.org/577-codewarrior-pro-6

Dazu gab es später auch die Möglichkeit Java direkt in der IDE zu entwickeln.

Libraries – Frameworks

Speziell für Spiele entwickelte Hardware (wie Sprites oder Scrolling) für 2D gab es auf diesen Computern nicht mehr. Dies musste alles selbst entwickelt werden. Dabei waren die Computer schnell genug, so dass es nicht mehr nötig war.


Die wichtigsten Libraries für die Entwicklung von Games waren:

  • Verwaltung: Arrays mit Structs für die GameObjekte (Default C/C++)
  • Graphik-Display – Transparenz – TIFF (?)
  • Sound (direct digitaler AIFF-Sound)
  • 3D-Libraries war ein schwieriges Feld damals – wenig zugänglich (kein OpenGL etc)

Entwicklung einer eigenen kleinen Engine

Diese Generation von Hardware kam also ohne jede Hardware Abstraktion daher wie etwa die Sprites es zumindest noch waren. Das heisst hier wurden Games virtualisiert – sie waren Software mit angehängter Grafik- / Soundkarte. Als Interface kam mehrheitlich nur noch die Tastatur zum Einsatz.

In der „Grossindustrie“ entstanden dann auch die ersten klassischen Gameeninges wie DOOM, Quake und dann Unreal. Diese Engins waren aber teuer und gerade für die Indiescene/Sharewareszene nicht praktikabel. Und so entstanden je kleine GameEgines für die jeweiligen Spiele etwa in C oder C++..

Eine kleine Engine konnte etwa die Verwaltung der Objekte beinhalten mittels STRUCTs mit allem drum und dran: Position, Aussehen, Animation und Behaviour. Dabei war alles sehr auf das einzelne Spiel zugeschnitten und noch nicht abstrahiert wie bei den „grossen GameEngines“.

Ressourcen – ResEdit 1994+

// https://eclecticlight.co/2024/07/20/managing-classic-mac-os-resources-in-resedit/

Die Ressourcen im MacUniversum waren – anders als auf dem PC (alles ausgelagerte Files) – in einer Art „Datenbank“-Ressourcen-File gebündelt und gespeichert. Dadurch waren alle Ressourcen zentralisiert. Ein Tool – ResEdit – erledigte das Verwalten für Entwickler dieser Ressourcen. Dabei konnte ResEdit alle möglichen Ressourcen – heute würde man sagen Assets – verwalten von Texten, Bildern bis Tönen. Diese wurden hier angelegt und dann aus dem Programm heraus genutzt.

Ein Beispiel hier: QuarkExpress

// https://eclecticlight.co/2024/07/20/managing-classic-mac-os-resources-in-resedit/

Selbstverständlich waren auch alle Menus, Icons etc darin enthalten.
https://en.wikipedia.org/wiki/ResEdit

Visuelle Entwicklung

Wie entstanden nun diese Ressourcen? Meist nutzte man die Tools jener Zeit wie etwa Photoshop. Photoshop 3 (1994) war erstauntlich, es kam mit Layern daher. Dadurch konnte man sehr fortschrittlich Dinge kombinieren und auch nachträglich wieder verändern (Ebenen mit verschiedenen Arten von Kombinationsmöglichkeiten zu x% anpassen. Es war nun mehr ein Variationendesignen und herausfinden, was passte. Also ein langsames Herantasten als Methode.

Dabei spielte natürlich auch eine Rolle, dass es nun möglich war Games mit 256 Farben zu kreieren. Anders gesagt: der einzelne Pixel verlor sowohl in der Menge 640x480Pixeln wie auch in der Farbe an Wert. Es ging nun eher nicht mehr um Pixeln im klassischen Sinn sondern um das Nutzen von Tools grossflächig.

Plugins

Adobe Photoshop war zusätzlich wichtig, weil es auch Plugins erlaubte und damit geradezu ein Setzkasten war für Tools. Es entwickelte sich auch eine zusätzliche Ebene und Verwertungskette mit diesen Tools.

Sound

Der Sound konnte nun rein digital sein und durch die die Datenmenge waren auch einfache Soundeffekte nur digital machbar. Die Frage war jedoch: Woher bekommt man die Effekte.

Konkrete Beispiele am Indiedeveloper: Imp89 – https://research.swissdigitization.ch/?p=6320

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert