@@ -79,20 +79,20 @@ Zum Schluss, als das ganze Design des Prototypen stand, wurden überall noch die
### 5.2.2 Department "Entwicklung"
Um das Entwickeln zu vereinfachen entstanden schon sehr früh 2 Ausgabezeilen, welche hauptsächlich zum Debuggen genutzt wurden. Dabei wurde die Obere für Multiplayerspezifische und die Untere für Clientspezifische Outputs genutzt. Diese Debugzeilen haben dann jedoch auch ins fertige Spiel geschafft und wurden zu Statusleisten umfunktioniert. Das Design blieb jedoch sehr rudimentär und diente am Ende des Projektes vor allem für das Feintuning der Character Werte, welche die Spieler nun sehen können. Es war eigentlich noch geplant diese mit Icons zu ersetzen und eventuell auch gerade zu rücken um es Optisch etwas ansprechender zu machen und nicht nur Zweckmäßig zu sein. Uns war es als Entwickler jedoch nichtmehr möglich diese auf zu bereiten und gerade zu rücken, da wir kurz vor der Medianight mehr damit beschäftigt waren Bugs zu suchen, zu finden und zu beseitigen.
Um das Entwickeln zu vereinfachen entstanden schon sehr früh 2 Ausgabezeilen, welche hauptsächlich zum Debuggen genutzt wurden. Dabei wurde die Obere für Multiplayerspezifische und die Untere für Clientspezifische Outputs genutzt. Diese Debugzeilen haben dann jedoch auch ins fertige Spiel geschafft und wurden zu Statusleisten umfunktioniert. Das Design blieb jedoch sehr rudimentär und diente am Ende des Projektes vor allem für das Feintuning der Character Werte, welche die Spieler nun sehen können. Es war eigentlich noch geplant diese mit Icons zu ersetzen und eventuell auch gerade zu rücken um es optisch etwas ansprechender zu machen und nicht nur Zweckmäßig zu sein. Uns war es als Entwickler jedoch nichtmehr möglich diese auf zu bereiten und gerade zu rücken, da wir kurz vor der Medianight mehr damit beschäftigt waren Bugs zu suchen, zu finden und zu beseitigen.
Die Umgebung sollte ein wichtiger Bestandteil des Spiels werden. Daher sollte zu Beginn des Spiels eine neue Karte generiert werden, die aus einer neuen Anordnung der vier Biome bestand. Dadurch muss sich der Spieler jedes mal auf die neuen Bedingungen einlassen und kann nicht über die Runden hinweg die Karte auswendig lernen.
Alex baute zunächst einen Prototyp für die Mapgeneration. Dieser basierte auf dem Aneinanderlegen von Kacheln die jeweils zu einem Biom gehörten. Die Kacheln werden dabei wie in der späteren Version durch einen Noise erzeugt und in eine Normalisierte Höhenkarte umgerechnet (Bsp. alles über höhe == 0.5 wird zu Sand, alles darunter wird zu Wasser). So war es möglich beliebig viele Biome mit ein zu binden und diese bei bedarf auch jederzeit zu erweitern.
Später entwickelte Olivia mit diesem Vorbild einen Shader, welcher einen besseren Übergang zwischen Biomen erlaubte. Grundlage ist eine Noise Textur, welche vorher in C# generiert und an den Shader übergeben wird. Über Grenzwerte wird bestimmt, welche Biom in welchem Bereich angezeigt wird.
Die Umgebung sollte ein wichtiger Bestandteil des Spiels werden. Daher sollte zu Beginn des Spiels eine neue Karte generiert werden, die aus einer neuen Anordnung der vier Biome bestand. Dadurch muss sich der Spieler jedes mal auf die neuen Bedingungen einlassen und kann nicht über die Runden hinweg die Karte auswendig lernen.
Alex baute zunächst einen Prototyp für die Mapgeneration. Dieser basierte auf dem Aneinanderlegen von Kacheln die jeweils zu einem Biom gehörten. Die Kacheln werden dabei wie in der späteren Version durch einen Noise erzeugt und in eine normalisierte Höhenkarte umgerechnet (Bsp. alles über Höhe == 0.5 wird zu Sand, alles darunter wird zu Wasser). So war es möglich beliebig viele Biome mit ein zu binden und diese bei Bedarf auch jederzeit zu erweitern.
Später entwickelte Olivia mit diesem Vorbild einen Shader, welcher einen besseren Übergang zwischen Biomen erlaubte. Grundlage ist eine Noise Textur, welche vorher in C# generiert und an den Shader übergeben wird. Über Grenzwerte wird bestimmt, welches Biom in welchem Bereich angezeigt wird.
Um die Bäume und Tiere zu generieren wird der gleiche Noise algorithmus genutzt. Hierbei wird jedoch ein anderer Maßstab genommen um eine neue Noise Höhenkarte zu erstellen. Diese wird danach genutzt um zu entscheiden ob etwas generiert wird oder nicht. Außerdem wird sie an der Stelle mit der Eigentlichen Karte verglichen um in jedem Biom die Biomspezifischen EyeCandys zu generieren.
Um die Bäume und Tiere zu generieren wird der gleiche Noise Algorithmus genutzt. Hierbei wird jedoch ein anderer Maßstab genommen um eine neue Noise Höhenkarte zu erstellen. Diese wird danach genutzt um zu entscheiden ob etwas generiert wird oder nicht. Außerdem wird sie an der Stelle mit der eigentlichen Karte verglichen um in jedem Biom die Biomspezifischen EyeCandys zu generieren.
Damit diese nicht wie in einem Raster angeordnet sind werden sie noch um einen zufälligen Offset in x und y richtung verschoben.
Um eine Beliebige Anzahl an EyeCandy Objekten zu erhalten werden diese wie im Bild gezeigt an den Grid Manager übergeben und verwaltet und einen guten Überblick zu behalten.
Um eine Beliebige Anzahl an EyeCandy Objekten zu erhalten, werden diese, wie im Bild gezeigt, an den Grid Manager übergeben und verwaltet um einen guten Überblick zu behalten.
@@ -100,9 +100,9 @@ Um eine Beliebige Anzahl an EyeCandy Objekten zu erhalten werden diese wie im Bi
**Nebel**
Um die Umgebung noch interessanter und wichtiger für das Spielverhalten zu machen, entschieden wir uns die Karte in Nebel zu hüllen. Die Helden können diesen Nebel temporär entfernen indem sie hindurchlaufen oder schießen.
Hierfür erstellte Olivia einen weiteren Shader. Dafür verwendete sie zwei Gradient Noise Texturen in welche verschieden stark reingezoomt wurde und mit verschieden starker Offset Änderung. So konnte der Effekt von sich bewegendem, wabernden Nebel erzielt werden. Zudem konnte man die Farbe des Nebels mithilfe von zwei Color werten von Außen beeinflussen.
Hierfür erstellte Olivia einen weiteren Shader. Dafür verwendete sie zwei Gradient Noise Texturen in welche verschieden stark reingezoomt wurde und mit verschieden starker Offset Änderung. So konnte der Effekt von sich bewegendem, wabernden Nebel erzielt werden. Zudem konnte man die Farbe des Nebels mithilfe von zwei Color Werten von Außen beeinflussen.
Die Durchlässigkeit des Nebels (oder der Alpha Wert) wird durch verschiedene Bedingungen beeinflusst. Der Nebel soll nicht überall gleich dicht sein, daher ließ Olivia die zwei oben genannten Noise Texturen mit in die Alpha Berechnung einfließen. Das sollte allerdings nur einen leichten Einfluss haben. Die sogenannte LightMap sollte den größten Einfluss haben. Die Lightmap sorgt zum Beispiel dafür, dass dort wo die Helden stehen kein Nebel ist. Für den Shader ist die LightMap nur eine schwarz-weiße Textur, welche vom Alpha-wert des Nebels abgezogen wird. Das heißt an den Stellen wo die Textur weiß ist, ist der der Nebel nicht sichtbar.
Die Durchlässigkeit des Nebels (oder der Alpha Wert) wird durch verschiedene Bedingungen beeinflusst. Der Nebel soll nicht überall gleich dicht sein, daher ließ Olivia die zwei oben genannten Noise Texturen mit in die Alpha Berechnung einfließen. Das sollte allerdings nur einen leichten Einfluss haben. Die sogenannte LightMap sollte den größten Einfluss haben. Die Lightmap sorgt zum Beispiel dafür, dass dort wo die Helden stehen kein Nebel ist. Für den Shader ist die LightMap nur eine schwarz-weiße Textur, welche vom Alpha-Wert des Nebels abgezogen wird. Das heißt an den Stellen wo die Textur weiß ist, ist der der Nebel nicht sichtbar.
Um die Lightmaptextur zu generieren und an den Shader zu übergeben erstellte Olivia eine CalculateFog Klasse. Hier wurde zu Spielbeginn eine neue schwarze Textur erstellt. Wir entschieden uns für eine geringe Auflösung der Textur. Das sorgte zwar für relativ eckige Übergänge zwischen Nebel und Licht, aber eine höhere Auflösung wäre mit mehr rechenaufwand verbunden.
Die Helden senden ihre Position konstant an die Klasse. Dadurch werden die Pixel in der Lightmap im Umfeld der Spieler auf weiß gesetzt. Das selbe passiert bei den Pfeilen des Rangers.
