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

7. Teil (28. Dezember 2002)

Willkommen liebe Leser, zur siebten Folge dieses Developer Diary, mit dem ich versuchen will Euch Freud und Leid der Entwicklung von UFO: Aftermath näher zu bringen. Als erstes das obligatorische Dankeschön an alle, die unser Spiel unterstützen, vor allem an diejenigen, die sich in unseren Foren auf www.ufo-aftermath.com beteiligen und uns laufend mit frischen Ideen versorgen.

Dieses Mal widme ich mich den Gedanken über den Taktikmodus, zerstörerischen Ideen, Echtzeit-Lightmaps und ich werde den Namen unseres Publishers enthüllen: CENEGA publishing [http://www.cenega.com/], mit Sitz in Prag, Tschechien. Dies ist eine brandaktuelle Information, die ich quasi noch beim Hochladen tippe, also wartet für nähere Informationen bitte auf die nächste Folge.

Tagebuch: Die Quadrate einer Stadt

Die letzte Folge dieses Tagebuchs handelte von der geeigneten Darstellung der Kämpfe, z.B. davon wie man auf bescheidene und unzweideutige Weise darstellen kann, wer der Angreifer und wer das Ziel ist. Als wir uns mit diesem Problem beschäftigten, mussten wir außerdem einen der Grundsätze in Frage stellen, die wir uns setzten, bevor wir uns an die Arbeit machten: Die Tatsache, dass das Spiel auf Quadrate aufgebaut werden sollte.

Lasst mich das erklären. Ursprünglich, damals in längst vergangenen Zeiten, als Titus noch für die Entwicklung zahlte, war UFO: Aftermath für eine Entwicklungsdauer von 16 Monaten konzipiert, von der Design-Idee bis zum vollständigen und komplett durchgetesteten Spiel. Das ist nicht besonders viel Zeit und deshalb, und um die Dinge für uns leichter kontrollierbar zu machen, haben wir uns entschieden, statt eines komplett in 3D gehaltenen Spieles ein Spiel zu entwickeln, dass auf Gittern basiert.

In einem Spiel mit solch einem Gittersystem (auch Quadersystem) ist der komplette Raum in einzelne Quadrate eingeteilt, die in unserem Fall 3x3 Fuss umfassten. Bewegungen sind immer nur von einem Quadrat zum anderen möglich, d.h. man kann zum Beispiel nicht die Ecke eines Quadrates als Ziel auswählen. Wenn sich Soldaten bewegen, überqueren sie natürlich die Grenzlinien zwischen diesen Quadraten, und wenn das Spiel gerade in diesem Moment angehalten wird, dann steht der Soldat auf einmal genau zwischen zwei dieser Gitterquadrate. Dort kann er aber gar nichts tun - wenn ihr ihm nun befehlt zu schiessen, wird er zunächst seinen Schritt beenden, sich also in die Mitte des nächsten Quadrates bewegen und erst von dort aus anfangen zu schiessen.

Diese Herangehensweise hat viele Vorteile - sie macht es sehr viel einfacher, die taktischen Feinheiten zu steuern (Wegpunkte, Kollisionen, Pausen, etc.) und macht damit das Spielen einfacher (entweder man kann irgendwo hingehen, oder man kann es nicht, man muss es auf jeden Fall nicht zwanzigmal versuchen und darauf hoffen, dass man vielleicht den richtigen Pixel anklickt um sich dann in einer Position wiederzufinden, in der man den Gegner sehen, aber nicht von ihm gesehen werden kann. Das Ganze sieht auch besser aus (alle Animationen passen genau, da Einheiten stets nur eine bestimmte Entfernung zurücklegen können) und ist vor allem die Lösung, die von den meisten rundenbasierenden Taktikspielen eingesetzt wird (X-Com, Jagged Alliance, Incubation, etc. etc.).

Ursprünglich wollten wir deshalb dieses auf Quadraten basierende System für alle das Gameplay betreffenden Features einsetzen: Wegfindung, Sicht- und Schusslinien. Dabei wurden jedoch die Nachteile des Gittersystems deutlich: Während man die Wege über Quadrate sehr gut planen kann (was übrigens einer der Gründe war, weshalb wir das System überhaupt einsetzen wollten), ist es viel zu ungenau wenn es um Schusslinien geht. Wir hatten für jedes Quadrat einen Wert angegeben, der seine Undurchsichtigkeit angab, also wie sehr es die Sichtlinie behindert. Für ein leeres Quadrat ist er 1, für ein Quadrat auf dem etwa ein Haus steht 0. Für ein Quadrat mit, sagen wir, einem Baum, ist er 0.5. Das bedeutet, wenn jemand hinter einem Baum steht, dann gibt es zwar die Möglichkeit, auf ihn zu schiessen, allerdings mit einem Abzug, da er ja zum Teil verborgen ist.

So kann es allerdings leicht passieren, dass man ein paar Kugeln durch den Baumstamm hindurchfliegen sieht. Oder sogar durch die Ecke eines Hauses oder ein Auto, dass vor einem Soldaten steht. Das kann man natürlich als vernünftige Abstraktion betrachten. In einem im Grundsatz rundenbasierten Spiel kann der Spieler nicht von uns erwarten, dass wir ihm genau zeigen, wie die Situation aussieht, wir zeigen ihm lediglich eine schematische Beschreibung, mit all den Informationen die er für seine strategischen Entscheidungen benötigt.

Die andere Möglichkeit wäre, dies als unakzeptabel zu betrachten. Der Spieler baut seine Entscheidungen darauf auf, was er sieht und wenn er nun ein Auto vor seiner Spielfigur sieht, dann erwartet er eben nicht dass er schiessen oder beschossen werden kann.

Dafür haben wir uns entschieden. Wir verfolgen verschiedene Strahlen vom Beobachter zum Ziel und errechnen daraus, ob es eine mögliche Strecke gibt, über die ersterer letzteren sehen oder unter Beschuss nehmen kann. Während das Spiel also gitterbasiert bleibt, müssen wir uns nicht mit den Schwierigkeiten herumschlagen, die ich weiter oben angesprochen habe.

Tagebuch: Und es ward Licht

Die treusten Leser werden sich noch an die Lightmaps erinnern, die wir sehr ausführlich in der ersten oder zweiten Folge dieser Serie behandelt haben. Ursprünglich hat es sehr lange gedauert, diese Lightmaps zu generieren und wir hätten nicht gedacht, dass wir es schaffen würden, sie in Echtzeit neu zu berechnen. Das hätte ernste, aber lösbare Probleme mit zerstörbaren Objekten geschaffen (sagen wir, ein Zaun wirft einen Schatten und dieser Zaun wird zerstört - dann sollte natürlich auch der Schatten verschwinden. Wir hätten deshalb für jedes zerstörbare Objekt einen vorberechneten Lightmap-Patch habe müssen) und außerdem Leuchtstäbe völlig ausgeschlossen oder auf Hardware-Lichter reduziert.

Der vorgebildete Leser, der schon weiss was Hardware-Lichter sind, kann diesen Absatz gerne überspringen, alle anderen lesen weiter. Wenn eine Grafikkarte ein Polygon darstellt (ein Basiselement jeder 3D-Szene), beim sogenannten Shading, dann berücksichtigt sie dabei mehrere Dinge: am wichtigsten ist die Textur, zum Beispiel ein Bild, das auf das Polygon gemalt ist (oft gibt es für jedes Polygon mehrere Texturen mit gegenseitigen Abhängigkeiten und Verschmelzungen, das würde hier jedoch zu weit führen). Dann kommt das Licht - man kann der Grafikkarte "sagen" dass es eine Lichtquelle in einer bestimmten Farbe gibt und in welche Richtung sie leuchtet. Die Karte berechnet nun das Licht für ein Polygon unter Berücksichtigung seiner relativen Position zur Lichtquelle (Polygone die der Lichtquelle gegenüber stehen sind heller ausgeleuchtet als die, die parallel zu ihr liegen). Das sind also die Hardware-Lichter; das wichtigste bei ihnen ist, dass sie keine Schatten werfen können - wenn es ein Polygon zwischen der Lichtquelle und dem Polygon gibt, das gerade berechnet wird, dann kümmert sich die Grafikkarte nicht darum. Der Programmierer muss dies selbst in die Hand nehmen und der Karte sagen, dass sie kein Licht auf das Polygon im Schatten werfen soll. Offensichtlich kommt es dabei zu Problemen, wenn ein Polygon nur zum Teil im Schatten liegt - man kann die Hardware-Lichter nicht nur halb anschalten. Dieses Problem kann zum Teil über Pixel-Shader gelöst werden, allerdings setzen die meisten Leute auf Lightmaps. Hardware-Lichter werden dann nur noch dort verwendet, wo Lightmaps nicht vorteilhaft sind, entweder weil ihre relative Position nicht im Voraus berechnet werden kann (z.B. bei den Soldaten in UFO: Aftermath) oder weil sie selbst wieder neue Lichtquellen sind (z.B. fliegende Raketen etc.).

Wie auch immer, unsere Programmierer haben wirklich gute Arbeit geleistet und es geschafft, die Berechnung der Lightmaps um einige Größenordnungen zu beschleunigen. Das macht eine Echtzeitberechnung des Lichtes möglich - Ihr könnt einen Leuchtstab werfen, seinen Flug verfolgen und wenn er landet, beleuchtet er das Gebiet um sich herum mit absolut lebensechten Schatten - es sieht unglaublich aus!

Ich hoffe, Ihr werdet es mögen.

Martin Klima, ALTAR Interactive




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