Aktuell im ForumZur Foren-Übersicht
Re: Hard Life addon
  Milchknilch
02.02.2017, 22:00
Re: Hard Life addon
  dusty
02.02.2017, 19:48
Re: Hard Life addon
  Milchknilch
01.02.2017, 23:24
Re: Hard Life addon
  dusty
01.02.2017, 21:07
Main
 
 
 
Preview
Aktuell
 
Supported Games
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sonstiges
 
 
 
Sonstiges
 
 
 
 
 
 
 
Counter
 
Header

1. Teil (5. März 2002)

Willkommen liebe Leser zum ersten Teil des Developer's Diary von UFO: Aftermath. Ich hoffe, Ihr findet dieses Tagebuch gleichermaßen aufschlussreich und unterhaltsam, denn ich hasse nichts mehr als die hype-erfüllten "Kauft-dieses-Spiel"-Tagebücher, die nichts anderes sind als selbstgefällige Ego-Trips von Spiele-Entwicklern, die meinen, jeder wäre an ihren unbedeutenden Launen interessiert.

Folglich habe ich nicht vor, viel über meine Arbeit als solche zu reden, sondern ausschließlich über das Spiel, an dem wir arbeiten. Ich werde versuchen, keine Zweifel, Fehler, fragwürdige Entscheidungen und ähnliche Dinge die bei einer solchen Entwicklung vorkommen, vor Euch zu verbergen.

Das soll natürlich nicht heißen, dass wir nicht mal Informationen zurückhalten. Ich werde versuchen, so offen und ehrlich zu sein, wie es mir unter diesen Umständen möglich ist.

Memoiren: Am Anfang war die Leere

Im Mai 2001 stellten wir Original War fertig. Es gibt viele Geschichten um die Zeit der Fertigstellung und sie alle sind richtig. Original War war etwas ganz besonderes für uns - es war unser erstes Großprojekt - und zu dieser Zeit hatten wir fast die Hoffnung aufgegeben, es jemals fertigzustellen. Aber gerade in solchen Momenten muss man weitermachen und genau das haben wir getan, sodass wir unseren Publisher letztlich doch noch die Gold-CD präsentieren konnten.

Schnitt: Einen Monat später, leeres Büro: Die Entwickler trudeln langsam wieder ein. Man beginnt, wieder miteinander zu sprechen. Genau in dieser Zeit rief mit Paul Whipp unser Produzent bei Virgin an und präsentierte mir seine großartige Idee, ein nicht nähere benanntes, aber natürlich super-wichtiges Großprojekt zu übernehmen. Zuerst habe ich mich wohl nur aus Höflichkeit neugierig gezeigt. Doch dann das: The Dreamland Chronicles: Freedom Ridge. Der geistige Nachfolger von X-Com. "Eure Detailverliebtheit zusammen mit Eurer Vorliebe für Strategiespiele, es passt perfekt", sagte Paul.

Doch wir zögerten noch. Sollten wir das Spiel eines anderen fertig stellen? Ist das nicht eine zu geringe Aufgabe? Oder eine zu große? Viel sprach dafür es zu tun - die Ehre, der Platz im Scheinwerferlicht, die Gelegenheit, die Herausforderung, und natürlich auch praktische Überlegungen: Es war ein Projekt, das schon an einen Publisher verkauft war, das einzige, was wir noch tun mussten war den Vertrag zu unterzeichnen und schon könnten wir uns an die Arbeit machen. Also sagten wir "Ja" und wir haben es nie bereut.

Tagebuch: Eine Stadt bauen

Letzte Woche sollten wir unseren Publisher wieder wie jeden Monat über den Stand der Dinge informieren. Unsere Auskünfte wurden mit Spannung erwartet, sollten wir doch dieses Mal darüber Auskunft geben, wie das Spiel letztlich in der taktischen Ansicht aussehen sollte (bisher haben wir nur eine flachen 2D-Draufsicht verwendet, um das taktische Spielgefühl zu simulieren).

Und wirklich, es wurde einer dieser Moment daraus, in dem alle bisher unverbundenen Elemente zusammengefügt werden und ein Ganzes ergeben. Ein Moment in dem alle Illusionen durch die nackte Wahrheit ersetzt werden. Damit man verstehen kann, worum es dabei eigentlich geht, muss ich ein wenig auf die Technik eingehen:

UFO: Aftermath unterstützt Zufallsmissionen, die auf der ganzen Welt stattfinden können. Der Spieler sieht ein halbes Dutzend Icons über den Globus verteilt, klickt auf eines davon und betritt eine Mission. Ein "Mission wird geladen ... bitte warten"-Bildschirm erscheint und eine dumme Animation wird abgespielt. Der Computer arbeitet in der Zwischenzeit wie verrückt - lädt die aktuelle strategische Situation, die Art der Mission, den Standort, die Jahres- und die Tageszeit, errechnet dann daraus die Landschaft und bevölkert sie mit gegnerischen Einheiten. Danach muss das Ganze sortiert werden, außerdem werden BSP-Bäume gezeichnet, die Karte ausgeleuchtet, Behälter platziert und noch viele andere Dinge. Für jedes 3D-Actionspiel habt Ihr für so etwas einen Level-Editors und braucht einige Stunden um all das umzusetzen. Wie lange wird es da dauern, um eine Mission zu laden?

Natürlich kann man das Rad nicht neu erfinden. Es ist nicht möglich, eine komplette, wirklichkeitsgetreue Landschaft in der Qualität, die wir heute gewohnt sind, innerhalb von 30 Sekunden zu generieren. Man muss einen Teil der Realitätsnähe opfern, um dafür die Geschwindigkeit zu verbessern. Die Frage ist nur, wo die Linie gezogen wird.

Wir entschieden uns - bei den Stadtmissionen - verschiedene Gebäude für jede Region der Erde zu kreieren, sie in ein bis zwei Felder große Grundelemente zu zerlegen (ein Feld entspricht 3 Fuß) und diese dann zu verwenden um Straßen zu erzeugen. Wir hätten dann eine Art von Editor oder Katalog, aus dem alle Elemente für eine bestimmte Region geladen würden (und das sind hunderte) und ein Designer hätte dann einige Regeln festgelegt, zum Beispiel dass zwei Elemente miteinander verwendet werden können, ein Element nur zweimal vorkommen darf, oder dass ein Element mindestens 5 Felder von einer Ecke entfernt sein muss - eben Dinge dieser Art.

Aber als wir die erste Szene bauten waren wir, nunja, enttäuscht - im wahrsten Sinne des (englischen ;-)) Wortes. Wir waren enttäuscht, weil wir nicht sahen, was wir erwartet hatten. Die 3D-Landschaften sahen wirklich gut aus - die Polygonzahlen, Texturenspeicher und Speicherzuweisungen funktionierten, so dass das Ganze kombiniert wirklich schmeichelhaft aussah. Aber unsere Landschaft war noch viel schmeichelhafter, mit einheitlichem Licht bemerkte man die wiederholten Texturen noch viel mehr als gewöhnlich.

Wisst Ihr, was ein "Lightmap" ist? (Falls ja, lasst diesen Absatz aus) Wenn man zum Beispiel eine 3D-Pyramide erzeugt, fertigt man zunächst ein Modell an (für eine simple Pyramide wären das 4 Dreiecke). Danach wird eine Textur hinzugefügt. Die Pyramide hat vier gleiche Seiten, weshalb man einfach dieselbe Textur für jede der Seiten verwenden kann - dies spart kostbaren Grafikspeicher. Nun sieht unser Modell aber von allen Seiten genau gleich aus, und das ist gleichermaßen unrealistisch und hässlich. In der Wirklichkeit hat selbst ein sehr homogenes Objekt hellere und dunklere Flecken - weil das einfallende Licht für gewöhnlich nicht homogen ist. Jetzt haben wir zwei Möglichkeiten: Entweder man lässt die Ausleuchtung von der Hardware berechnen, legt fest an welchen Koordinaten eine Lichtquelle ist, in welche Richtung sie zeigt, in welcher Farbe usw. und lässt dann die Beleuchtung der Szene berechnen - oder man verwendet ein Lightmap. Das ist im Grunde eine zweite Textur, die über die erste gelegt wird. Der Punkt ist, dass sie nur aus Graustufen besteht (sie erhellt oder verdunkelt nur die darunter liegende Textur) und deshalb eine sehr viel geringere Auflösung haben kann (die Grafikkarte wird das verschleiern und feine Übergänge erzeugen), was natürlich Speicher spart. Lightmaps werden normalerweise bevorzugt, da die Hardware-Lichtquellen in ihrer Anzahl begrenzt sind und meist noch für andere Zwecke gebraucht werden.

Es war nun also klar, dass wir vorberechnete Lightmaps einsetzen würden und andere Dinge konnten angegangen werden. Nun, das Spiel wird um die hundert Missionen haben (in der längsten Einstellung). Sagen wir ein Drittel davon findet in Städten statt. Das wären dann etwa 30 Städte. Jetzt gibt es in jeder vielleicht 5 verschiedene Stadtteile mit einzigartiger Architektur, dann hätten wir im schlimmsten Falle 5 x 30 = 150 Städte. Gut, realistisch gesehen sind es etwa um die 100, denn es ist unwahrscheinlich, dass alle Missionen in der selben Region stattfinden werden. Warum also nicht 100 Stadtlevels bauen und auf die CD packen? Das wäre natürlich ein großes Opfer im Namen der Detailverliebtheit, aber würde das irgend jemanden interessieren? Die meisten Spieler starten ein Spiel, spielen es dann durch und würden deshalb ohnehin einige Wiederholungen sehen.

Aber Entwickler haben auch ihren Stolz. Wir wollen sagen können, dass es "unendliche Möglichkeiten" gibt, und "unendlich" heisst zumindest mal dreihundert. Wir einigten uns also auf einen Kompromiss. Die Designer werden die kleinen Segmenten dafür verwenden sogenannte "Blocks" zu bauen; das kann ein Gebäude sein oder auch mehrere, umgeben von Strassen oder freiem Gelände. Jeder dieser Blöcke wird individuell ausgeleuchtet und das Lightmap vorberechnet und gespeichert. Ein Stadtlevel wird dann erzeugt, indem diese Blocks kombiniert werden. Mit ein paar hundert Blocks pro Region und einer durchschnittlichen Levelgröße von 5x5 Blocks haben wir genau 242.519.269.720.337.121.015.504 verschiedenen Möglichkeiten. Selbst mit einer großen Fehlerspanne war das für mich endlos genug (da ist ein klitzekleiner Fehler in dieser Rechnung, bemerkt ihn jemand?)

Nach diesem Abstieg zurück zu dem magischen Moment als wir die ersten Block-basierenden Level geladen haben und ja, es hat funktioniert! Es sah wirklich gut aus! Natürlich gibt es immer noch Fehler, da sind Löcher, wo keine sein sollten, einige andere Felder sind verdreht, aber die Atmosphäre ist schon da. Das kriechende, schmutzige Gefühl einer verwüsteten und verratenen Welt, die Aura der Gefahr, sich bewegende Schatten nah an der Grenze deiner Wahrnehmungskraft.

Ich schweife ein wenig ab und beginne schon, mein Versprechen der Objektivität zu brechen, es ist vielleicht besser wenn wir für heute aufhören.

Ich freue mich darauf Euch im nächsten Teil wiederzusehen!

Martin Klima, ALTAR Interactive




Ihr habt einen Fehler gefunden, eine Frage oder Anmerkungen zur Seite?
Mailt uns oder schreibt etwas ins Forum!