Schöne Folge. Den ewigen Wettstreit zwischen den ehemaligen Lucasfilm Games und Sierra Schöpfern haben die Herren um Ron Gilbert aktuell entschieden. Return to Monkey Island (Metacritic 87) ist ein super Spiel, das Colossal Cave Remake (Metacritic 53) von den Williams ist ein schauderhafter Abklatsch seiner selbst.
Wieder mal eine super Folge! Kings Quest ist eine meiner allerersten Erinnerungen, die ich im Bezug auf Computerspiele habe. Bei meinem Vater im Regal standen damals Ende der 80er / Anfang der 90er die Boxen von Kings Quest im Regal und mich haben die Artworks als Kind damals schon fasziniert 
Ich hatte schon immer die Theorie, dass die Sierra Spiele in Deutschland nie so gut angekommen sind, weil der typische Jugendliche/das typische Kind genau wie bei den Infocom Adventures einfach nicht in der Lage war, anspruchsvolles Englisch mit Parser zu verstehen. Der Unterschied zu den Lucasfilm Spielen lag klar darin, dass man diese auch mit seinem grünen Pons Buch verstehen konnte, selbst wenn das Englisch sonst auf fünfte Klasse Niveau war.
Infocom hat doch in Deutschland auch niemand gespielt. außer den Happy Computer Redakteuren, oder? 
Ich habe damals zu meiner Englischlehrerin einen kleinen Zettel mit dringend zu übersetzen Wörtern mitgenommen (ich erinnere mich noch an „Swörd“ und „Isle“), aber bei den Sierra Spielen war das halt nicht möglich.
13 „Gefällt mir“
King’s Quest 1 
Natürlich musste man mich nicht davon überzeugen, dass KQ der Meilenstein war, der er war, aber danke, dass ihr das trotzdem tut. Super schöne Folge zu einem tollen, wenn auch quälenden Spiel. Das ich erst in der EGA Fassung gespielt hab.
Und ich bin bei Chris: Eine Folge zu To Heir is Human muss Irgendwann sein.
1 „Gefällt mir“
Ich war lange Zeit irritiert über viele Spieler, vor allem von der Commodore Base (no hate ), dass die Englisch so oft als Argument angeführt haben, etwas nicht zu spielen.
Ich hab wegen solchen Games überhaupt angefangen Englisch zu lernen, noch vor der fünften. Seltsames Englisch…Open door.
Mir kam viel später der Gedanke, dass es halt auch an den Spielen lag. Auf nem XT war halt nicht viel Action und Parser-Adventures waren das geilste, was ich für so eine Kiste haben konnte.
1 „Gefällt mir“
Dann braucht man aber auch jemanden, der einem mal kurz erklärt, wie das grundsätzlich funktioniert.
Beim C64 lief das so: Diskette rein, am Joystick wackeln, nichts tut sich => Schrott.
Beim IBM-PC waren vielleicht mehr Erwachsene im Umfeld, die sich auskannten.
3 „Gefällt mir“
Das lang aber dann vor allem an dem Besitzer. Ich hab aus meiner Zeit mit dem XT (zuerst noch mit Hercules, später dann CGA) noch folgende Spiele hier, die meisten auf 5 1/4 rumliegen:The Blues Brothers, Budokan: The Martial Spirit, California Games, Defender of the Crown, D/Generation, The Duel: Test Drive II, Golden Axe, Grand Monster Slam , It Came from the Desert, Prince of Persia, Rock 'n Roll, Xenon 2: Megablast, North&South.
1 „Gefällt mir“
Klar, gegeben hat’s die und gespielt hat man die auch. Aber war halt geiler, solche Spiele beim Lars auf dem C64 oder bei Andrea auf dem Amiga zu spielen.
Hier hat sich LGR passenderweise auch noch die PCjr-Version von King’s Quest angeschaut.
4 „Gefällt mir“
Durch mein zartes Alter ist das die einzige KQ-Version, die ich gespielt habe. Ich fand es damals unheimlich gruselig, sterben zu können – gerade der erste Abschnitt ja auch unheimlich trostlos mit der Wüste und dem zum Wandern verdammten Geist.
Leider ist das Spiel nicht besonders toll gealtert. Die Hintergründe gehen schon noch klar, aber die Animationen sind echt nicht mehr der Burner…
Wirklich eine außergewöhnlich gelungene Folge, ich bin begeisert! Herzlichen Dank dafür.
In meiner Spieler-Biographie hat Kings Quest V eine herausgehobene Stellung. Für mich war es Anfang der 1990er so, dass ich (im Grundschulalter) das Spiel wie einen „Zeichentrickfilm zum spielen“ wahrgenommen habe - genau wie die Podcaster zeitgenössische Spieler des ersten Teils in den 80er Jahren zitieren.
Einerseits freue ich mich, dass Christian noch eigene Folgen zu Teil 3 und Teil 5 angekündigt hat. Wenn ich jetzt allerdings sehe, dass zwischen den Folgen von Baldurs Gate I und II rund 8 Jahre gelegen haben, werde ich mich bis zur Folge zu Teil 5 wohl noch bis ins Jahr 2041 gedulden müssen 
In Anlehnung an Marcus Porcius Cato (oder dem Känguru) sollte jeder Post mit folgendem Satz enden: Man sollte jedes Episodenbild kaufen können, weil ich die alle haben will.
Nun.
1 „Gefällt mir“
Einen herzlichen Dank für eine (weitere) wunderbare Folge!
Die Beinahepleite von Sierra schon Anfang der 80er war für mich völlig neu. Die starke Expansion auch durch Zukäufe hatte ich in den späteren Jahren immer mit Erstauen wahrgenommen. Wenn man auch da Sierra und Lucasfilm Games vergleicht: der Gesamtkatalog war ja mehr als eine Größenordnung umfangreicher - und enstand unter ganz anderen wirtschaftlichen Randbedingungen, die beim „Ende“ von Sierra dann ganz gut sichtbar werden. Wobei man sich natürlich schon fragen kann, ob vom „echten“ Lucasfilm Games heute mehr übrig ist als von Sierra … ich bin schon unheimlich gespannt, wenn ihr die Sierra Geschichte mal ausführlich im Detail beleuchtet!
Zum Podcast: An dem Punkt, an dem es um den IBM-Auftrag geht, eine Vorzeigespiel zu machen, dachte ich schon: jetzt erklärt ihr sicher gleich, warum KQ trotz der möglichen 320x200 trotzdem nur eine Auflösung von 160x200 nutzt. Zumal die Grafiken bei AGI ja nicht mehr Speicher auf der Diskette belegt hätten. Woher kommt das?
Der C64 kann auch keine höhere Auflösung bei 16 Farben, aber dorthin wurde das Spiel mangels Hauptspeicher ja nie portiert (der Speicher des C128 hätte aber wohl genügen müssen? Und die Engine an sich wurde ja portiert, wie man an den Disney-Spielen sieht).
Das eröffnet gleich den nächsten Gedankengang: an sich hängt die Auflösung und Farbtiefe ja sowieso nur am Grafiktreiber. Der könnte die theoretisch zumindest ja in jeder Auflösung „rendern“ (um das mal so zu nennen). Ja, bei der Begrezung von Fülloperationen kommt es schon auf die extakte Pixelposition an, aber grundsätzlich ist 160x200 oder 320x200 4 Farben, 16 Farben, Composite oder EGA doch „nur“ eine Treiberfrage - hätte ich zumindest angenommen. Was meint ihr?
(Warum KQ3 trotz gleicher Engine trotzdem noch schöner aussieht als die ersten beiden Teile, werdet ihr dann sicher in der angekündigten KQ3-Folge eklären )
Ach ja, ganz vergessen hatte ich noch, was ihr zur IBM Erstausgabe mit (c) 1983 auf der Packung rausgefunden habt. Wurde die einfach nur zu früh hergestellt? Die hat ja auch ein anderes Keyboard-Overlay als die 1984er IBM Ausgabe.
Übrigens auch ein interessanter Punkt, dem Spieler nochmal so eine Hilfestellung an die Hand zu geben.
Ich habe die Folge noch nicht zu Ende gehört, aber eine kurze Anmerkung zur big f***ing company BFC:
Das Kinderbuch „Sophiechen und der Riese“ von Roald Dahl heißt im Original „The BFG“, was die Abkürzung für „Big friendly giant“ ist. Das kam 1982 raus und der erste Sohn des Ehepaars Williams kam 1973 zur Welt, hatte also genau das richtige Alter für das Buch.
Roald Dahl typisch ist der Humor in diesem Buch so, dass damit auch Erwachsene ihren Spaß haben können und ich lehne mich mal weit aus dem Fenster und sage: Ken Williams kannte das Buch. Und ich nehme an, die BFG aus Doom lehnt sich auch an diesen Buchtitel an.
3 „Gefällt mir“
Zu der 1983er-Frage und zum Keyboard-Overlay sagen wir in der kommenden „Wusstet ihr eigentlich …?“ Folge noch was.
Zur 160er-Auflösung kann ich auch nur spekulieren. Wenn ich das richtig sehe, ist 160x200 einer der nativen Grafikmodi des PCjr. Er könnte auch 320x200. Du hast recht, dass das für den Speicherplatz auf der Diskette keinen Unterschied machen dürfte, aber für den Bildaufbau schon; eine der Operationen ist ein Flood Fill der Flächen, das dauert bei höherer Auflösung länger. Ich kann mir vorstellen, dass die zumutbare Wartezeit fürs Zeichnen der Grafik hier der limitierende Faktor war. Sicher bin ich mir aber nicht.
2 „Gefällt mir“
Deine Gedanken sind schon nachvollziehbar, aber da gibt es auch Abers.
Speicher und Rechenleistung kann man oft ineinander tauschen. Merke ich mir den Wert von 4+5 in der Variablen x oder spare ich Speicher und berechne neu. Für eine höhere Auflösung muss ich also beim Füllen mehr speichern (etwa Positionen) oder mehr rechnen (etwa die Abfrage, ob ein x-Wert (es gibt doppelt so viele) zwischen den Füllgrenzen ist.
Dazu kommen Zugriffe auf den Videospeicher. Christian hat schon Recht: Das Zeichnen wäre deutlich langsamer.
Es gibt aber womöglich (ich kenne mich weder sonderlich gut mit dem Eigenarten des PC jr noch dem Quellcode von King‘s Quest aus) noch ein ganz anderes Problem abseits der Grafikschnittstelle, das heute kein Problem ist, aber selbst in den 90ern noch Beachtung fand und bei einem PC jr.-Vorzeigetitel mit Sicherheit auch relevant war: Das Byte vs Integer Problem. Ein Byte (= 8 Bit) kann Zahlen zwischen 0 und 255 Speichern. Damit kann bei der 160x200-Auflösung mit zwei Byte-Variablen sehr schnell umgegangen werden. Will man den Wert 256, 257 oder 319 für die x-Position verwalten, braucht man plötzlich zwei Bytes. Das ist wenig zusätzlicher Speicher, aber je nach Architektur des Systems verlangsamen sich Rechenoperationen. Ein Beispiel:
Dezimalzahl / Bitcodierung
0 / 0000 0000
1 / 0000 0001
2 / 0000 0010
3 / 0000 0011
4 / 0000 0100
5 / 0000 0101
6 / 0000 0110
7 / 0000 0111
8 / 0000 1000
14 / 0000 1110
16 / 0001 0000
20 / 0001 0100
40 / 0010 1000
Wozu das Ganze? Statt komplex mal 2 zu rechnen, kann man auch einfach alle Bits um eins nach links verschieben und hinten ein 0 ranschreiben. So etwas ist schneller und geht innerhalb eines Bytes sehr einfach. Der Aufwand für zwei Bytes ist jetzt aber nicht doppelt so hoch, sondern höher, weil die führende Ziffer (das vorderste Bit) auch verschoben werden muss. Der Aufwand steigt also mehr als doppelt so stark, der Rechner wird grob geschätzt um den Faktor 3 langsamer. Eine höhere Auflösung betrifft also auch den internen Code.
Nächstes Aber: Um die Koordinaten 159/199 (0/0 ist ja auch ein Punkt) bei einem Grafikbefehl im Bitcode zu speichern, brauche ich zweimal 8 Bit oder 2 Byte. Für 319/199 brauche ich einmal 9 Bit und einmal 8 Bit. Wenn ich so maximal komprimiert speichere, brauche ich bei den gespeicherten Grafikkoordinaten schon 6,25 % mehr Speicher. Speichere ich die X-Koordinaten mit zwei Bytes, brauche ich am Ende für jeden Start- und Endpunkt einer Linie sogar 3 statt 2 Bytes, also 50 % mehr Speicherplatz für diesen Teil des Codes.
Christian und Gunnar sagen im Podcast, dass damals viele Spiele das eigentlich Sichtfenster auf die Welt kleiner halten wollten (z.B. Ultima Underworld), indem sie nur einen Teil des Bildschirms für zu berechnende Grafik nutzten und den Rest mit statischer Grafik bedeckt haben. Eine schlechtere Auflösung zu nehmen ist derselbe Trick, aber es sieht halt Fullscreen aus und beeindruckt mehr.
11 „Gefällt mir“
Die Frage beantwortet doch das aktuelle Indy Spiel. 2021 hat Disney die alten Marken von Lucas wiederbelebt und vergibt die Rechte jetzt an Drittfirmen. Und 2024 landet Microsoft (Bethesda) damit einen AAA Titel und Millionenverkäufe. Wann war der letzte Sierra Titel im AAA Bereich? Das man aktuell kein Indyspiel mehr als AAA Titel als Adventure mehr machen kann und deswegen auf ein Actionspiel setzt, liegt natürlich in der Natur der Sache. Aber Indy lebt wieder, die ganzen Quest Dinger sind tot, auch aus einen Roger Wilco könnte man einen Actionhelden in Space machen. So ein Typ wie Star Lord, aber da die Rechteinhaber keinerlei Interesse an den Marken haben, bleibt halt nur der „Ruhm“ des Alten. Ich freue mich schon auf den Indy Nachfolger. Fazit Lucas lebt, Sierra ist tot. Klar die Zeiten der Adventures kommen nicht wieder, aber das gibt der Markt auch nicht her. Der Gesamtkatalog mag von Sierra größer gewesen sein, aber alleine mit Star Wars hatte Lucas immer die Killer IP im Portfolio. Alleine diese IP ist wertvoller als alles was Sierra jemals zustande gebracht hat. Klar da kommt es vom Film, aber woher die IP kommt ist ja erstmal wurscht.
Im Spielebereich ist Star Wars keine Killer-IP. Es kamen gute Spiele unter der Lizenz heraus, keine Frage. Aber abseits von Rebel Assault imho keines, das den Markt in irgendeiner Weise beeinflusst hätte oder einen sicheren Umsatz garantieren würde wie bspw. ein Madden NFL, FIFA, GTA oder Call of Duty. Diese Strahlkraft besitzen beide IPs nicht im Ansatz, und jedem erfolgreichen Titel in deren Lizenzgeschichte stehen drei bis fünf mittelprächtige und gefloppte Titel gegenüber. Man denke allein an das Hin und Her um das unglückliche Star Wars 1313. Oder man schaue sich mal den Misserfolg von Ubsiofts Outlaws an, den man nicht allein auf die Produktionsqualität schieben kann. Es hat einfach kaum jemanden interessiert.
LucasArts/Lucasfilm hat natürlich grundsätzlich den Vorteil, dass ihre beiden Haupt-IPs in sich bereits actionorientiert sind. Mit entsprechender Hardwareleistung konnten die Spiele daher zur Vorlage aufschließen. Sierra hatte da schon größere Herausforderungen, war aber eben auch die ältere Firma, die sich im verändernden Marktumfeld immer wieder neu erfinden musste. King’s Quest 8 ist daran ja bekanntlich gescheitert, Police Quest hat mit dem SWAT-Ableger einen immerhin respektablen Turn hinbekommen, auch wenn der Taktikshooter schnell eine Sackgasse war. Dass sie sowohl den RTS- als auch den FPS-Boom verpasst hatten, am Ende sogar noch das mit der Half-Life-Lizenz vollkommen versemmelt haben, war dann ja auch einer der Sargnägel (der andere war der dubiose Mutterkonzern und die Personalentscheidungen darin). Wobei man sagen muss, dass sich Lucas in derselben Zeit auch eher durchschnittlich durch den Markt geschleppt hat. Es gab gute Gründe, warum Disney nach der Übernahme aus LucasArts eine reine Lizenzierungsbutze gemachte hat. Was heute als Lucasfilm Games firmiert, hat in meinen Augen nichts mehr mit dem ursprünglichen Studio von der Skywalker Ranch zu tun.
Da der 8088 ein 16bit Prozessor ist, wollte ich das nachprüfen. Meine Intuition sagt mir dass Left shift (SHL) auf z.B. AX vs AL/AH vermutlich genau die gleiche Anzahl Cycles brauchen sollte. Ich habe diese etwas verwirrende Referenz gefunden, welche das bestätigt: Alle SHL r, * (für 8bit) und SHL rr, * für 16bit Operationen verweisen auf den gleichen Cyclecode (P1/S3) und damit die gleiche Cycleanzahl und es macht somit keinen Unterschied ob die ein 8 oder 16 Bit Register shiftest. Anders sieht es nur aus, wenn direkt Werte im RAM shiftet und damit extra Read+Write Cycles dazukommen. Da scheint es dann 20+4N Cycles für 8bit vs 20+4N+28+4N zu sein und damit in der Tat fast 3x so lange: Bei Shift um 2 nach links also, wenn ich das richtig verstehe, 20+4*2 = 28 Cycles vs 20+4*2+28+4*2 = 64 Cycles. Danke für den Nerdsnipe 
Nachtrag: Habe noch diese auto-generierte Testsuite gefunden, welche, wenn ich das richtig verstehe, mittels Instrumentalisierung einer echten 8088 CPU generiert wurde in dem diese extern per Arduino durchgesteppt wird und dabei mitgeloggt wurde, was an allen Leitungen anliegt. Die Traces in v2/D0.4.json.gz testen unter anderem SHL AL/AH und v2/D1.4.json.gz testen u.a. SHL AX. Beides passend zu obigem PDF mit jeweils 2 Cycles (sofern die Instructions schon geprefetched wurde?). Faszinierend.
9 „Gefällt mir“