| ★ GAMES ★ EDITEURS ★ REALTIME GAMES SOFTWARE: RASANTE REALITAT ★ |
| Realtime Games Software: Rasante Realitat | Games - Company | Realtime Games Software |
Wo die Programmierer von »Realtime Games« am Werk sind, da rauchen die Prozessoren. Schnelle 3D-Grafik und packende Spiele halten Heimcomputer auf Trab und Spieler in Atem. Panzer-Spiel, das in Deutschland indiziert wurde. Das Spiel bot als erster Spielhallen-Auto-mat flüssige 3D-Vektor-Grafik. Andy, lan und Graeme wollten unbedingt eine Umsetzung dieses Spiels für den Spectrum schreiben. Sie starteten Weihnachten 1983 und wurden Ostern 1984 fertig. Als die drei das Spiel das erste Mal auf einer Messe vorstellen wollten, mußten sie sich innerhalb von wenigen Stunden Namen für das Spiel und für die Firma ausdenken. Das Spiel nannten sie »Tank Duel«. die Firma in bezug auf das schnelle 3D-Spiel »Realtime Games-, übersetzt »Echtzeit-Spiele«. Angefangen hatten die drei mit nur einem einzigen Spectrum und einem einfachen Kas-setten-Recorder. Kurz vor Schluß der Entwicklung von Tank Duel, als das Assemblie-ren auf Kassette bis zu einer Viertelstunde dauerte und man so leicht die Geduld verlor, liehen sie sich hundert Pfund und kauften sich einen Sinclair Mi-crodrive. ein schnelles Endlos-Kassettenlaufwerk. Die drei brachten gemeinsam genug Geld auf. um 1000 Spielkassetten zu produzieren. Durch den Verkauf der Kassetten kam genug Geld herein, um weitere 1000. und wieder 1000 und noch mehr zu produzieren. Insgesamt konnten sie 7000 Kassetten verkaufen und hatten sich damit ein schönes Taschengeld verdient. Sie waren auf den Geschmack des professionellen Programmierens gekommen: »Wir haben dann ganz schnell angefangen. 'Star-strike' zu entwickeln.« Starstrike orientierte sich wieder an einem 3D-Spielhal-len-Automaten. diesmal dem prominenten »Star Wars«. Um das Programm zügig schreiben zu können, nahm sich Graeme ein Jahr von der Uni »frei«. Er besuchte die Vorlesungen nicht und wollte den versäumten Stoff dafür später nachholen. Richtig abgeschlossen hat er sein Studium allerdings nie. Um Starstrike zu vollenden, brauchten die drei ganze sechs Monate, oder, wie die Realtime-Programmierer betonen, »nur« sechs Monate. Um so schnell fertig zu werden, erlaubten sie sich den Luxus eines zweiten Spectrums mit Microdrive. Am 23. November 1984 kam Starstrike für den Spectrum auf den Markt. Starstrike wurde ein durchschlagender Erfolg. Es gab nur positive Testberichte, das Programm verkaufte sich wie warme Semmeln, und Realtime war als technisch hervorragendes Software-Haus etabliert. »Bis dahin arbeiteten wir in einer besonders schlimmen Gegend, wo es Dutzende von streunenden Hunden gab. Müll auf den Straßen und sonstige Unannehmlichkeiten. Mit dem Geld, das wir durch Starstrike verdienten, besorgten wir uns erstmal bessere Büros.« In den im Januar 1985 bezogenen Büros sitzt Realtime übrigens heute noch. Als nächstes setzten sich die drei an eine CPC-Version von Starstrike. Doch durch den Erfolg der ersten beiden Programme etwas faul geworden, dauerte es wieder sechs Monate. bis die CPC-Version im Juni 1985 über die Ladentische gehen konnte.
Dann war ein Jahr lang Stille um Realtime. Erst im April 1986 hörte man wieder was von den Programmierern in Form von »Starstrike II«. dem ersten Spiel auf dem Spectrum, das 3D-Grafik mit ausgefüllten Flächen verwendete. Warum das so lange gedauert hat? »Wir haben mit Starstrike so viel Geld verdient, daß wir einige Monate davon gelebt haben, ohne groß etwas zu machen. Als uns dann das Geld ausging, haben wir schleunigst angefangen, Starstrike II zu schreiben. Zuerst wollten wir nur noch ein Linien-Grafik-Spiel programmieren, doch nach einem Monat fanden wir einen Trick heraus, wie wir die ausgefüllten Flächen in genügender Geschwindigkeit realisieren können. Da haben wir alles in den Papierkorb geschmissen und noch mal von vorne angefangen. Starstrike II sah am Ende ganz anders aus, als wir es uns am Anfang vorgestellt hatten.« Nachdem die ersten beiden Realtime-Spiele eigentlich nur Kopien von bekannten Spiel-hallen-Automaten waren, sollte Starstrike II ein eigenes Spiel werden. Das Grundkonzept ähnelte dem ersten Starstrike; mehrere Action-Szenen wurden durch eine Rahmenhandlung zusammengehalten: »Weil die 3D-Grafik auf den 8-Bit-Computern aber doch etwas langsam ist, haben wir lange an den einzelnen Sequenzen geknobelt. Sie sollten grafisch eindrucksvoll sein, durften aber nicht zu viele Objekte verwenden. Sonst wären sie zu langsam geworden, um spielbar zu sein.« Da es für ein kleines Softwarehaus wie Realtime immer schwieriger wurde, den Vertrieb aufrechtzuerhalten und alle Händler zu beliefern, verkaufte man die Rechte der CPC-Version von Starstrike II an Firebird Software. Gleichzeitig bekam Realtime von Firebird den Auftrag, die Umsetzungen eines neuen ST-Spiels zu programmieren: »Starglider«. »Die Spectrum-Version von Starglider war das erste Spiel, das wir mit einem professionellen Entwicklungssystem, bestehend aus einem PC mit einem speziellen Spectrum-Assembler, geschrieben haben. Am Anfang konnten wir nicht glauben, wie schnell das Programmieren mit diesem PC ging.« Nun ist Realtime ja nicht das einzige Software-Haus, das 3D-Spiele programmiert. Gibt es andere 3D-Spezialisten. die Realtime bewundert? »Unserer Meinung nach ist das einzige Spiel, das 3D-Grafik wirklich optimal ausnutzt, »Driller« von Incentive. Das Spielprinzip ist gut ausgetüftelt. Eigentlich ist Driller nur ein Adventure, aber es ist spannend wie ein Action-Spiel. Da es bei Driller nicht so sehr auf Reaktion an- Auf 8-Bit-Computern wurde 3D-Grafik im Laufe der Jahre immer schneller und besser. Ist dort jetzt die Grenze erreicht und ist bei 16-Bit-Computern noch eine Steigerung zu erwarten? »Wir arbeiten jetzt seit gut fünf Jahren nur an 3D-Routi-nen. Wir wissen ziemlich genau. was ein Computer auf diesem Gebiet maximal leisten kann. Auf den Z80-8-Bit-Com-putern (CPC, Spectrum) haben wir die Grenze unseres Könnens erreicht. Wir arbeiten gerade an einem 3D-System für den C64, doch das wird auch nichts wesentlich Neues bringen. Der 3D-Spielemarkt wird in den nächsten Jahren voll im 16-Bit-Bereich liegen. << »Carrier Command war ein echtes Noch viel schneller geht die Grafik bei Carrier Command wohl nicht. Wir kennen nur wenige Leute, die schnelle 3D-Routinen für den 68000 geschrieben haben, und keiner von denen ist schneller als wir. Wir könnten unsere Grafikroutinen noch etwas tunen, könnten auch noch komplexere Objekte verwenden, aber aus anderen Gründen ist da jetzt eine Grenze erreicht: Carrier Command ist ein echtes Killer-Programm für den ST (und erst recht für die Programmierer). Es steckt so viel drin. Wenn du Carrier Command siehst, dann denkst du: Mein Gott, ist das 3D schnell, das muß ja die gesamte Rechnerzeit schlucken. Falsch. Selbst wenn überhaupt nichts auf dem Bildschirm zu sehen ist. schaffen wir maximal 17 Bilder pro Sekunde. Der Rest der Rechnerzeit, das sind über 50 Prozent, geht für die Spielstrategie drauf. Die Taktik des feindlichen Carriers, das Insel-Versorgungsnetz, die Bewegungen von mehreren Dutzend Fahrzeugen, all das wird in Echtzeit simuliert und schluckt etwa die Hälfte des Atari ST. Rein theoretisch könnte die Grafik also mehr als doppelt so schnell sein. Gut, es wird Verbesserungen in der 3D-Grafik geben, aber nur sehr kleine. In einem Jahr sind wir vielleicht noch mal 20 Prozent schneller, aber Wunder wird man sich nicht mehr erwarten können; erst recht nicht, wenn das Spiel selber sehr komplex ist und viel Rechnerzeit benötigt. Wir könnten heute ein absolut fließendes 3D. 25 Bilder die Sekunde, mit vielen komplexen Objekten programmieren, aber dann wäre keine Prozessorzeit mehr für das Spiel übrig.« Dies alles klingt etv/as unlogisch. haben doch die Programmierer weltweit über fünf Jahre gebraucht, um die 8-Bit-Computer richtig auszunutzen. Die komplexeren 16-Bit-Computer sollen da schon nach zwei Jahren ausgeschöpft sein? »Der große Unterschied zwischen 1983 und 1988 liegt darin, daß damals Computer ganz allgemein noch neu und die Programmierer noch sehr unerfahren waren. Heute bringen die meisten 16-Bit-Programmierer schon einige Jahre 8-Bit-Erfahrung mit. Sie wissen schon eine ganze Menge über effektives Programmieren. Es wird nicht noch mal einen solchen Quantensprung geben wie auf den 8-Bit-Computern.« Statt Studium lieber Spiele programmieren - Wo liegt das Geheimnis der Realtime-Programmierer. auf dem 3D-Bereich so führend zu sein? »Wir alle haben Computer-Technik studiert. Viele Spiele-Programmierer haben nur praktische Erfahrung, gewonnen aus dem »Hacken« auf ihrer Maschine. Sie wissen nur, was sie über den Computer wissen müssen. Wir hingegen haben einen tiefen theoretischen Hintergrund. Das gibt uns bei der Lösung von schweren mathematischen Problemen. wie sie bei 3D-Grafik-Routinen auftreten. einen gro Ben Know-how-Vorsprung. Solche Sachen kann man entweder auf der Uni lernen, oder man liest ein paar Jahre lang die richtigen Bücher, wie es beispielsweise Jez San gemacht hat. der -Starglider« auf dem ST programmierte. Viele von den nicht studierten Programmierern wollen sich das Leben einfach machen, suchen nach Program-mier-Abkürzungen. Die Amerikaner sind da besonders schlecht. Bei ihnen muß jedes Programm nachladen. Wenn das Programm nicht mindestens zehnmal auf Diskette zugreift. ist irgendwas falsch. Dabei läßt sich viel von dem Kram ohne Probleme in den Speicher packen, aber die amerikanischen Programmierer sind einfach zu faul, diesen etwas schwereren Weg zu gehen und ihr Programm so kompakt wie möglich zu halten. Auf dem Amiga sind die Programmierer besonders faul. Fast alle Amiga-Spiele könnte man auch auf dem C64 realisieren. Man nutzt zwar den zusätzlichen Speicher und die besseren Sound- und Grafik-Chips. aber das Spielprinzip hat immer noch 8-Bit-Qualität. Die Programmierer müssen nicht nur die Spezial-Chips, sondern auch den Prozessor besser ausnutzen, komplexere Programme schreiben, das wahre Potential des Computers ausnutzen.« << Andy Onions traut sich einiges zu. Er schreibt die Spectrum-Version von »Carrier Command«. Da stellt sich uns natürlich die ganz naive Frage, wie Carrier Command den ST nach den oben angegebenen Kriterien ausnutzen könnte, wenn sie doch gerade an einer Spectrum-Version arbeiten. Auf die Frage folgt erst mal wildes Gelächter, dann die vorsichtige Gegenfrage »Ist das eine Fangfrage?« und dann die ausführliche Erklärung: »Es ist ein großer Unterschied, ob du ein Spiel vom Spectrum auf den ST umsetzt und nur die Grafik etwas schöner machst, oder ob du eine Untermenge eines ST-Spiels auf einen Spectrum umsetzt. Bei Carrier Command setzen wir nur die Teile um. die auf dem Spectrum auch funktionieren. Auf den ersten Blick sehen sich die beiden Versionen sehr ähnlich, aber die Spectrum-Version ist so viel simpler als das ST-Original. In der ST-Version von Carrier Command geht eine ganze Menge Speicher für Details drauf. So bewegt sich beispielsweise die Kanone auf dem Carrier, die Schleusentore gehen auf und zu und die Vulkane spucken kleine Würfel aus. Auf all diese witzigen Details wird die Spectrum-Version verzichten. Außerdem ist das Insel-Netzwerk viel einfacher. Auf dem ST verwenden wir ein realitätsnahes, komplexes Modell, um die Inseln zu verwalten, Vorräte zu erzeugen und hin- und herzuschiffen. Auf dem ST braucht dieser Programmteil satte 64 KByte, inklusive aller Tabellen. Auf dem Spectrum haben wir eine simple Mini-Version des Insel-Netzwerks in 768 Byte gequetscht. Wer die beiden Versionen auch nur wenige Minuten spielt, wird sofort sehen, daß in der Spectrum-Version eine ganze Menge fehlt. Es wird wahrscheinlich auch eine C64-Version geben; die muß dann sogar völlig ohne 3D-Grafik auskommen und wird wohl ein 2D-Sprite-Spiel werden. Diese Umsetzung programmieren wir aber nicht selber. Das genaue Gegenteil kann man übrigens von Starglider behaupten. Wir haben die ST-Version von Starglider absolut originalgetreu, mit Ausnahme der Sprachausgabe. auf den Spectrum und den CPC umgesetzt - und wir hatten dann noch Speicher frei! Also haben wir Spezial-Missionen hinzugefügt und sogar neue Objekte und Gegner erfunden. In der Spectrum-Version ist tatsächlich mehr Spiel drin als auf dem Atari ST.« Warum ist der C64 für 3D-Spiele so schlecht geeignet? »Das bisher schnellste Vek-tor-3D auf dem C64 hat immer noch Mercenary. Wir arbeiten gerade an einem speziellen C64-3D-System, das etwas schneller werden sollte. Aber nicht viel, denn der C 64 hat gerade mal die halbe Rechen-Power eines Spectrum. Auf dem Spectrum schaffen wir maximal 37500 Pixel in der Sekunde. der C64 liegt unter 20000 Pixel in der Sekunde. Aber der C 64 hat noch andere Macken; so dauert das Löschen des Bildschirms unendlich lange. Die schnellste Bild-schirmlösch-Routine, die wir uns vorstellen können, schafft das gerade 47mal in der Sekunde. Bei jedem Bild geht also schon eine 47tel Sekunde nur für das Löschen drauf. Das bremst die ganzen 3D-Routi-nen schon gewaltig ab. Dann kommt noch einige Rechenarbeit, ein Gebiet, auf dem der C64 auch nicht der Schnellste ist. Wo sind die 3D-Koordinaten? Welche Linien sind verdeckt? Wo bewegen sich die Objekte hin? Wenn du da nicht ganz einfache Sachen programmierst, bist du schnell bei einem Bild pro Sekunde oder langsamer.« Zwischen Computer-Freaks tobt immer noch der Kampf ST gegen Amiga. Welcher der beiden Computer ist für 3D-Spiele besser geeignet? »In 3D-Spie-len ist der Amiga nicht schneller als der ST. Der Blitter kann uns höchstens beim Bildschirm-Löschen helfen, und der Prozessor, der die 3D-Arbeit tun muß. ist tatsächlich langsamer als auf dem ST. Der 32-Farben-Modus der Amiga ist nutzlos für uns, da würde 3D viel zu langsam werden. Wir können maximal 16 Farben verwenden. Also sind die beiden Computer praktisch gleichzustellen.« Was denken Programmierer, die sich um »echtes« 3D bemühen, über Spielhallen-Spiele wie »Space Harrier« und »Out Run«? »Dieses Semi-3D. bei dem Sprites vergrößert und verkleinert werden, ist ganz OK für bestimmte Action-Spiele. Die ließen sich mit echtem 3D gar nicht realisieren. Der Vorteil von Semi-3D ist, daß die Objekte viel schöner ausse-hen, weil sie gemalt wurden, und nicht berechnet werden. Dafür kannst du in einem Semi-3D-Spiel niemals in alle Richtungen fliegen oder ein Objekt von allen Seiten betrachten. Die Spiele sind also sehr eingeschränkt. Für Spiel-hallen-Automaten ist Semi-3D toll, aber auf Heimcomputern wird es sich wohl nicht durchsetzen.« Auf die Frage, was die vier denn vom neuen Computer Ar-chimedes halten, dem sagenhafte Eigenschaften angedichtet werden, kommt ein regelrechtes Sprach-Gewirr: »Ein Haufen Müll - Ist verdammt schnell - Ein sehr, sehr, sehr, sehr schneller Computer -Nicht so gut wie ein vernünftiger PC mit 80386-Prozessor und 24 MHz - aber viel billiger! - Der beste Computer, wenn man Preis und Leistung miteinander vergleicht - Der Prozessor ist nicht besonders toll - Ja, sie haben sich zu sehr am 6502 orientiert, haben die ganzen unlogischen Eigenschaften übernommen.« Um das Gewirr zu stoppen, fragen wir, wie schnell der Ar-chimedes denn in 3D-Dingen ist. Die Antwort: 900000 Pixel in der Sekunde, und das bei 256 Farben gleichzeitig. Das ist etwa 25mal schneller als ein Spectrum, zweimal schneller als ST und Amiga, die dann aber nur 16 Farben gleichzeitig auf den Monitor bringen. »Mit einem vernünftig aufgebauten Bildschirm-Speicher wären ST und Amiga doppelt so schnell. Hier haben sich wohl die Hardware-Entwickler etwas Arbeit gespart und den Grafik-Chip etwas einfacher gemacht. Dafür hat es die Software jetzt schwerer. Mit einem vernünfti-en Bildschirm-Speicher könnte man auf dem ST in alle Richtungen fließend scrollen, superschnelle. riesengroße Sprites darstellen und wahnsinnige Action-Spiele programmieren. Der vermurkste Bildschirm-Speicher bremst den ST mindestens um den Faktor 2, wenn nicht 3. Der Amiga ist da übrigens nicht anders.« Die Frage nach dem besten Computer für 3D-Spiele endet wieder in einer lautstarken Diskussion: »Wenn ich nicht auf dem ST programmieren, also eintippen und assemblieren müßte, würde ich am liebsten für den ST schreiben - Also ich weiß nicht, der ST hat doch kaum Vorteile gegenüber dem Amiga - Obwohl ein 80286-oder 80386-PC mit VGA-Karte und 256 Farben nicht schlecht wäre - Nein, der ist nutzlos. Unter VGA hast du nur einen Bildschirm und kannst nicht zwischen zwei Bildschirmen hin-und herschalten - Außerdem gefällt mir die Code-Segmentierung auf PCs nicht; also muß es ein 68000-Computer sein -Ein 8-MHz-68000 ist langsamer als ein 8-MHz-80286 -Richtig toll wäre es, auf dem Macintosh II zu programmieren. 16 MHz und Mathematik-Coprozessor, das macht 3D um so vieles einfacher - Der Archi-medes kann aber auch ohne Mathe-Prozessor sehr schnell rechnen - Ein einzelner T800-Transputer schlägt doch jeden 80386 und 68000 um Längen....« Schließlich einigen sich die vier doch auf den Macintosh II, dicht gefolgt von Archimedes und Atari ST. Bei der schwierigsten Maschine für 3D-Spiele gibt es aber keine Diskussionen: die MS-DOS-Computer. »Es gibt einfach zuviel verschiedene Modelle auf dem Markt, von superschnellen Hochlei-stungs-PCs bis zu Heim-PCs. die noch nicht mal die doppelte Rechnerleistung eines Spectrum haben. Ein Programm muß so geschrieben werden, daß es auf dem langsamsten PC läuft, deswegen kann es die schnelleren gar nicht ausnutzen. Dazu kommt der Trubel mit den -zig verschiedenen Grafikkarten, die zueinander inkompatibel sind, aber alle unterstützt werden wollen.« Auf die Frage, welche Spiele sie in den letzten Wochen gerne gespielt haben, kommen nur wenige Antworten. »Dungeon Master« hat allen gefallen, weil die Bedienung so logisch ist und die Programmierer an jedes Detail gedacht haben. Das Demo von »Intercep-tor« hatte sie auch beeindruckt, und sie warteten auf das fertige Programm. Die Grafik von »Xenon« fanden sie besonders schön, allerdings meinten sie: »Wenn uns jemand die Grafik malen würde, könnten wir das Programm wohl an einem Wochenende schreiben.« Mehr Titel fallen ihnen nicht ein und die Begründung dafür kommt sofort: »Wir sehen alles ganz stark von der technischen Seite. Wenn wir etwas spielen, dann fällt uns sofort auf: Das hier ist nicht sauber programmiert. Wir mögen manchmal die besten Spiele nicht, weil wir nur auf die Technik schauen und sagen: Das hätte man besser machen können. Wir lieben es geradezu, die Programme anderer Leute regelrecht auseinanderzunehmen, indem wir sie uns einfach nur anschauen. Nur durch 30 Sekunden Spielen kannst du eine ganze Menge Negatives über den Programmierstil eines Kollegen sagen.« Wird Realtime nur 3D-Spiele machen, oder könnten sie auch mal ein »normales« Spiel mit Sprites und Scrolling programmieren? »Oh ja, wir könnten das durchaus. Wir wollen sogar endlich mal ein Sprite-orientiertes 2D-Spiel schreiben. Es gibt da nur einen Haken: Wir können nicht zeichnen. Bei einem 3D-Spiel muß der Programmierer nicht zeichnen können. Für ein Sprite-Spiel bräuchten wir aber einen guten Grafiker. Dann stände dem aber nichts im Wege. Allerdings will ja auch niemand von uns etwas anderes als 3D. Und mit unserem guten Ruf kriegen wir für 3D-Programme wesentlich mehr Geld. Bei uns wissen Software-Firmen, daß sie kein Risiko ein-gehen, wenn wir ein 3D-Spiel programmieren.« Carrier Command war ein echter Hammer. Wie will Realtime das je überbieten? »Als nächstes machen wir 'E.P.T.', ein Weltraum-Handels-Action-Spiel, das sich ein wenig an 'Elite' anlehnen wird. Es wird allerdings viel größer, schöner und besser werden. Es kommt wahrscheinlich noch vor Ende des Jahres nur für 16-Bit-Computer. Wir sitzen da schon weit über ein Jahr dran. Der Name muß übrigens geändert werden. Wir haben vor kurzem den Film 'Fatal Attrac-tion - Eine verhängnisvolle Affäre' gesehen, und da ist in einer Szene eine große Schachtel zu sehen, auf der 'EPT' steht. EPT ist nämlich die amerikanische Abkürzung für 'Early Pregnancy Test - Früher Schwangerschafts-Test'. Und so können wir unser Spiel natürlich nicht nennen! Aber E.P.T.. oder wie es auch immer heißen mag, wird toll: sehr viel komplexer und realitätsnäher als Carrier Command. Dann denken wir noch daran, ein superschnelles 3D-Actionspiel ohne viel Strategie, nur für 16 Bit, zu programmieren. Bis die Jungs mit ihren neuen Projekten fertig sind, wird's noch eine Weile dauern.
|
