Buchempfehlung zur Videospielgeschichte

Hallo zusammen,

ich bin auf der Suche nach einem Buch zu einem Thema, bei dem ich bisher erstaunlich wenig gefunden habe.

Videospiele begleiten mich eigentlich mein ganzes Leben – angefangen mit Schneider CPC und NES. Früher habe ich einfach gespielt. Heute interessiert mich immer mehr das Wie dahinter.

Also nicht unbedingt die klassische Videospielgeschichte nach dem Motto „Konsole X erschien 1985, danach kam Spiel Y“, sondern:

Wie wurde aus Technik, Programmcode und einer Idee überhaupt ein Videospiel?

Wie bringt man etwas auf dem Bildschirm in Bewegung? Wie entstehen Grafik, Sound, Kollisionen und Spielregeln? Und wie haben die Entwickler das gerade in den Anfangsjahren überhaupt umgesetzt?

Ich suche ein Buch, das so etwas verständlich erklärt, ohne gleich ein Informatikstudium vorauszusetzen. Am liebsten auf Deutsch, gerne auch etwas Älteres oder nur noch gebraucht erhältlich.

Vielleicht hat hier jemand einen Tipp oder kennt einen guten Einstieg in genau dieses Thema?

Viele Grüße

Christian

Da passen vielleicht die Game Engine Black Books von Fabien Sanglard.

„Wolfenstein 3d“ ist noch verständlich mit mehr Fokus auf den Algorithmen, für die Grafik „Doom“ geht etwas mehr auf damalige PC Technik ein.

Und danach noch Doom Guy von Romero selbst.

2 „Gefällt mir“

Vielen Dank für den Tipp, zumal der Autor Fabien Sanglard beide Bücher als PDFs kostenlos auf seiner Homepage zur Verfügung stellt.

Sehr gut. Ich hatte die noch von Annas Keller

Schönes Thema generell.

Als Programmierersicht würd ich sagen, eine gute Methode ist, man lernt von anderen Programmen. Damals wie heute. Auch damals gab’s ja schon Listings. Sachen abändern bis was eigenes draus wird. Bücher studieren vielleicht erst wenn man sich schon mal die Finger in der Praxis schmutzig gemacht hat, weil sonst geht nur „viel rein und wieder raus“.

Bei Konsolen damals ist es so, dass man zwar in Assembler programmieren können muss, aber sie die Dinge fast wie Schema-F vorgeben. Die Sprites müssen als Bitmap-artige Grafiken vorliegen an bestimmten Orten im Videospeicher, dann bewegt man sie einfach indem man die Koordinaten ändert. Hintergrundgrafiken ähnlich, die müssen als Kacheln (Characters oder Tiles) vorliegen.

Das ist sehr effizient, so dass es auch „in Software“ auf Heimcomputern (bei den typischen 2D-Arcade-Games) meist so gemacht wird, nur muss man da noch mehr das entsprechende Grundgerüst selber programmieren, wenn es die Hardware nicht von sich aus macht (was natürlich oft langsamer ist). Also da wird in der Regel nicht „frei gezeichnet“. Aber generell hat man auf vielen Heimcomputern mehr Freiheitsgrade (i.d.R. weniger Hardware-Grafikchip Features aber mehr RAM), sodass mehr experimentiert wurde mit ganz anderen Dingen („isometrisch“ oder 3D), wo man dann mit neuartigen Grafikroutinen aufwarten kann.

Ich weiß, das ist jetzt kein Buch, aber ich hoffe es beantwortet doch ein wenig. :wink:

1 „Gefällt mir“

Vielleicht ist die Platform Studies-Serie von MIT Press was für dich?

https://mitpress.mit.edu/series/platform-studies/

Da geht’s mehrheitlich um die Plattformen/Konsolen, nur zweitrangig um die Spiele selbst. Aber die Plattformen definieren ja zu einem gewissen Grad, wie Bilder und Ton erzeugt werden, und wie die historisch einzuordnen sind, und wieso die Plattformen so entstanden sind, wie sie entstanden sind.

1 „Gefällt mir“

Danke dir!

Ich glaube, genau das könnte tatsächlich mein Einstiegspunkt werden. Nicht nur darüber lesen, sondern einfach mal selbst anfangen und schauen, wie aus ein paar Zeilen Code irgendwann ein Spiel wird.

Wenn ich ganz simpel anfange und das Ganze dann Stück für Stück erweitere, verstehe ich die Theorie hinterher auch viel besser.

Die Bücher laufen dann einfach nebenher. :slightly_smiling_face:

„Racing the Beam“ welches hier angeboten wird, war mir schon ein Begriff. Das hol ich mir auf jeden fall auch. Das Buch blickt, glaub ich, ganz gut unter die Haube des VCS.

Danke für den Tipp

Das klingt doch gut. Aber Vorsicht: die Bücher, die ich jetzt aus der Serie gelesen habe, gingen nicht alle auf Codelevel runter, haben aber die Hardwarearchitektur beschrieben und historisch in Kontext gesetzt.

Je nach dem, was du da für eine Plattform als Fokus raussuchst, gibt’s sicher etwas fokussiertere Bücher. In meiner Amigawelt fand ich die ganz gut und zugänglich (wohl aber mit Programmiervorkenntnissen):

Amiga Programming (3 book series) Kindle Edition

Racing The Beam, stimmt, auf jeden Fall quasi ein moderner Klassiker.

Es ist sicher eine Herangehensweise, von primitiver Hardware auszugehen (hat kaum RAM das Ding) und dann zu versuchen, das meiste herauszuholen. Dieser Weg ist besonders geeignet für Leute mit Elektronik-Hintergrund.

Nur wichtig zu wissen, dass man so heute nicht mehr programmiert, weil viel zu aufwändig, das ist nur praktikabel für relativ primitive Spiele. Bestimmte Aspekte „überlebten“, typischerweise für Sprite-Multiplexing (mehr Hardware-Sprites verwenden als die Hardware eigentlich bietet, indem man die Sprite-Slots weiter unten am Bildschirm nochmal verwendet).

Aber oft geht ja die Aussage um „mit Demo-Effekten kann man keine Spiele machen“. Auf dem Atari VCS war quasi alles, was über Pong und Tank hinausging, Demo-Effekte als Spiel. „Grand Prix“ ist quasi spielbare Copper-Bars und Split-Rasters.

Aus dem OP ging nicht ganz klar hervor, was dein Ziel ist: programmieren generell lernen anhand von Spielen (bevorzugt damals, als alles noch einfacher war), oder einfach nur Retro-Geschichte, die technisch ein bisschen tiefer geht als das sonst übliche.

Wie gesagt, was früher Listings abändern war, ist heute vielleicht das Modding, viele kommen darüber in die Spieleentwicklung. Wenn man an den Quellcode direkt will, wohl relevant: Liste quelloffener Computerspiele – Wikipedia - da gibt’s sowohl einfache 2D-Sachen wie auch moderneres, komplexeres 3D-Zeugs. „Informatiker“-Niveau ist meist erst dann erforderlich, wenn man die Engines selbst verstehen und ändern will.

1 „Gefällt mir“

Ich glaube, mein eigentliches Ziel ist tatsächlich eher: Ich möchte verstehen, was unter der Haube passiert.

Mir geht es nicht darum, möglichst schnell Spieleentwickler zu werden oder irgendwann ein großes eigenes Spiel zu veröffentlichen.

Ich möchte einfach verstehen, wie die Spiele meiner Kindheit funktionierten.

Das Ganze selbst einmal ganz simpel zu programmieren, erscheint mir inzwischen als der beste Weg, genau das zu verstehen.

Und die alte Hardware finde ich dabei besonders spannend, weil man dort vermutlich noch viel eher nachvollziehen kann, was tatsächlich passiert. Dass man heute nicht mehr so programmiert wie auf einem VCS, ist mir dabei eigentlich gar nicht so wichtig.

Ich möchte weniger lernen, wie man heute möglichst effizient ein Spiel entwickelt, sondern verstehen, warum das alles überhaupt funktioniert.

Jo Atari 2600 ist halt interessant für den Aspekt, wie wurde überhaupt Grafik ausgegeben, oder noch früher die Pong-Konsole, die hatte noch gar keine CPU im heute verstandenen Sinne.

Da du CPC und NES erwähntest, die sind auch interessant quasi für die zwei praktisch gegensätzlichen Paradigmen damals.

Der einfachste Grafikchip gibt einfach nur linear als Pixel aus, was als Bytes im Speicher ist. CPC oder IBM-CGA funktionierten größtenteils so, beide nutzten den gleichen Grafikcontroller von der Stange, mit ein bisschen custom Schaltungen drum herum.

Nur ist dieser Ansatz für damals immens speicherintensiv. Auch CPU-intensiv wenn man denn das Bild 50 oder 60 Mal pro Sekunde updaten möchte (Arcade-/Spielkonsolenqualität), das ist unmöglich oder geht nur für Teile des Bildes. Darum waren die Spiele auf diesen Systemen oft so ruckelig. Wenn man Dinge über einen Hintergrund bewegt muss man das alles „per Hand“ und in „Software“ machen. Außerdem, 256 Werte für ein Byte, nur 4 oder vielleicht 16 Farben - also sind in ein Byte 2 oder 4 Pixel codiert - was nun wenn man per Software eine Grafik um nur 1 Pixel verschieben möchte? Viel Spaß!

Wegen des Speicherbedarfs gab’s noch früher Systeme und „Grafik“-Karten, die nur Text ausgeben konnten. Das benötigte sogar etwas komplexere, spezifische Grafikhardware für die Character-Logik, dafür ist der RAM-Bedarf viel geringer. Der Zeichensatz oft in einem ROM mitgeliefert und konnte nicht geändert werden.

Spielkonsolen bauen, vielleicht entgegen der Intuition, auf einem weiterentwickelten Ansatz dieser Richtung auf. Die hatten ja auch kaum RAM. Der Zeichensatz hat nun geringere Auflösung als bei Büro-Text-PC-Systemen, ist nun aber bunt, die Zeichen können als Grafikelemente beliebig aussehen, werden aber quasi immer noch per ROM (nur nun im Cartridge pro Spiel) geliefert. Das NES konnte ohne Spezialchips im Cartridge die Characters-/Tiles-basierte Hintergrundgrafik nicht ändern. (Die NES-Version von Elite hatte so einen Chip im Cartridge, um die benötigten Characters für die Darstellung von 3D-Linien on-the-Fly zu erstellen.)

Oben drauf hatten die Konsolen ja die Sprites in Hardware, damit ist die Arcade-Spiel-Formel quasi komplett. Jeder Sprite ist ein unabhängiges Grafikobjekt, das über den Hintergrund gelegt und unabgängig davon Pixel-genau bewegt werden kann. Die Sprites sind das, was die Grafikhardware damals relativ aufwändig machte, sodass eigene Chips produziert werden mussten, Chips von der Stange, die Sprites konnten, gab’s fast nicht. Das Ding im MSX und in der Colecovision war das einzige, glaub ich. Entwicklung solcher Custom Chips rentierte sich nur, wenn man wusste, dass die Konsole Hunterttausende absetzen wird. Kamen in Heimcomputern wenig zum Einsatz (bis natürlich berühmterweise auf den C64 und später Amiga), weil mit Sprite-Hardware kommunizierst du ja ganz klar: Dies ist eine Spielemaschine! Für „produktive“ Anwendungen konnten Sprites kaum verwendet werden.

Hier noch genauere Ausführungen zu Konsolen-Hardware:

Es gibt von dem Autor anscheinend auch ein Buch, vielleicht genau das, was du suchst.

1 „Gefällt mir“

die Sanglardbücher (und seine Website) sowie ein paar andere wurden ja schon genannt, ansonsten würde ich der Idee ebenfalls beipflichten, sich selbst ein wenig in die Programmiermaterie einzuarbeiten.

Und auch wenn es wieder kein Buch ist: einschlägige (Branchen)Podcasts oder YT-Kanäle - gerade längere Entwicklerinterviews, bei denen es mehr in die Tiefe geht, Dev Blogs, oder etwa Vorträge aus der GDC Vault - sind vielleicht keine schlechte Alternative, bzw. Ergänzung zu reiner Literatur.

Hie mal eine kleine Liste, thematisch querbeet - hoffe, Englisch ist kein Problem. :slight_smile:

Die Liste:

https://youtube.com/@gdcfestivalofgaming

https://youtube.com/@danielalbu

https://youtube.com/@videogameanimationstudy

https://youtube.com/@whitepointergaming

https://youtube.com/@mattbarton

https://youtube.com/@modernvintagegamer

https://youtube.com/@newframeplus

https://youtube.com/@onaretrotip

https://youtube.com/@acerola_t

Podcast | DESIGNER NOTES

https://www.devgameclub.com/

1 „Gefällt mir“

Danke dir, genau solche Erklärungen habe ich gesucht!

Gerade der Vergleich zwischen CPC und NES ist für mich spannend, weil ich mit beiden Systemen aufgewachsen bin, mir aber nie Gedanken darüber gemacht habe, wie unterschiedlich die beiden überhaupt ein Bild auf den Bildschirm bekommen.

Und genau da merke ich gerade, dass „unter der Haube“ für mich tatsächlich der interessante Teil ist. :grinning_face_with_smiling_eyes:

Ich muss deinen Beitrag wahrscheinlich noch zwei-, dreimal lesen, bis ich alles verstanden habe – aber genau so etwas bringt mich weiter. Danke für die ausführliche Erklärung!

Hatte auch einen CPC und Nostalgie-Feels dafür, und mit heutigem Wissen, ich finde es schade, es hätte die Top-Referenz-Beste 8-Bit-Spiele-Maschine werden können. Die CPC-Reihe wurde millionenfach verkauft, da wären Custom Chips sogar wirtschaftlicher als Stangenware gewesen. Amstrad hatte die Connections nach Taiwan damals schon (ein Alleinstellungsmerkmal damals und großer Grund des Erfolges, die Leistung für den Preis anbieten zu können).

Gibt seit ein paar Jahren Interviews mit dem damaligen Chefingenieur Roland Perry (ja, der Roland ;)), man war leider recht konservativ in der Herangehensweise, v.a. weil ein früherer Entwurf basiert auf dem 6502 bereits gescheitert war.

Der CPC Plus hatte dann ja 'nen ASIC und Hardware-Sprites, kam aber viel zu spät (1990).

1 „Gefällt mir“

Es scheint, als weißt Du bereits alles, was ich noch lernen muss.

Ich hab vor, mir mit Python die Grundlagen anzueignen, um die Praxis wenigstens ein bisschen zu verstehen. Danach versuche ich, tiefer in die Grundlagen der Computergrafik einzutauchen.

Python ist eine gute Idee, arbeite da auch beruflich viel mit. Ist natürlich im Vergleich zu oldschooligem game code a la Assembler sehr high level und komfortabel, aber letzten Endes kommt es nicht auf die genaue Sprache an, sondern das grundlegende Verständnis und ‚Blickwinkel‘ (also etwa systemisch gameplay-Ideen in funktionale Loops herunterbrechen) :+1:

1 „Gefällt mir“

ja, Python ist eine der Universal-Standardsprachen heutzutage (neben Javascript vielleicht) und gut um Programmieren zu lernen.

Man muss nur wissen, dass es dann doch in mehreren Aspekten sehr weit weg ist von der Ausgangsfrage, wie Spiele damals gemacht wurden.

Auch wie man seit über 40 Jahren programmieren lernt (FOR-Schleifen, IF-Bedingungen, und GOTO ist böse, etc), Assembler/Maschinensprache ist dann doch noch was anderes (da geht’s meist nicht anders als „GOTO“ bzw. JMP auf Adressen) und die Programmierer der frühern Arcade- und Videospiele kamen wie quasi erwähnt eher aus der Elektronik.

1 „Gefällt mir“

Das ist mir durchaus bewusst. Ich möchte mit Python erstmal die Grundlagen verstehen und überhaupt einen Einstieg in die Programmierung finden.

Mir geht es ja nicht darum, Spieleentwickler zu werden, sondern irgendwann nachvollziehen zu können, wie die Spiele damals funktioniert haben.

Vielleicht ist Python dafür nicht der direkteste Weg, aber irgendwo muss ich ja anfangen. :grinning_face_with_smiling_eyes: