Dungeon Sounds

[csg]

Wie versprochen jetzt ein kleiner Einblick in die Entwicklung! Wenn Euch so etwas interessiert, können wir das gerne öfter bringen.

---

So gut wie jedes Spiel mit einer begehbaren Umgebung muss sich die Frage stellen, wie eigentlich die Räumlichkeiten gespeichert werden. Dungeon Sounds hat im Grunde 2 Bedingungen gehabt:

1. Es muss schnell programmiert sein, da für das Spiel zu Beginn nur ein Monat Zeit war
   
2. Es muss leicht änderbar sein, da das spiel schnell fertig sein muss

Die Möglichkeit einen Leveleditor zu programmieren fiel aufgrund der ersten Bedingung direkt flach. Alternativ hätten wir die Map natürlich direkt in den Code reinhauen können, das hätte die Karte aber schwierig zu editieren gemacht. Da unser Design teilweise täglich geändert wurde und wir nicht von Anfang an sagen konnten, wie die Spielwelt auszusehen hat, war das ebenso keine Möglichkeit für uns. Da die Welt an sich Tilebasiert ist ( nicht allerdings die Bewegung! ) haben wir daher einfach auf einen altbewährten Leveleditor zurückgegriffen, der es uns einfach gemacht hat einfach jedes Feld anders zu kodieren: Paint!

Die Spielwelt ist auf einer kleinen, gepixelten Textur beschrieben. Hier ein kleines Beispiel wie diese aussehen kann:

(Beispielhaft: Um das Spiel nicht zu verraten ist diese Karte nur zu Anschauungszwecken entstanden!)

Jede Farbe ist hierzu im Spiel anders kodiert: Die unterschiedlichen Grautöne stellen verschiedene Bodentypen da, die bunten Umrandungen beschreiben die Wände. Da die Karte bei jedem Spielstart geladen wird, sind schnelle Änderungen im Handumdrehen getan!

(Ansicht der Spielwelt aus der ferne im Spiel selbst: Die Tilestruktur ist klar zu erkennen! Es handelt sich nicht um die Welt die oben in der Textur zu sehen ist!)

Das reicht, um die Spielwelt halbwegs grob zu beschreiben. Allerdings wollten wir noch zusätzliche Objekte, wie zum Beispiel Vasen und Säulen, hinzufügen. Da auf der Karte jedes Feld durch eine Pixelfarbe definiert wird, können nur schwer weitere Elemente hinzugefügt werden. Es bleib uns also nichts anderes übrig, als weitere Objekte bei Spielstart mittels eines Skriptes zu erzeugen:

Code:

addObject( "TOPF", ( 231, 243), 3, 1, -1 );
addObject( "TOPF", ( 234, 243), 1, 1, -1 );

addObject( "SAULE", ( 231, 244), 1, 1, -1 );
addObject( "SAULE", ( 234, 244), 1, 1, -1 );

Die Skriptsprache, die zum einsatz kommt, schimpft sich übrigens KyaraScript und findet auch bei Zirkonia und Buntoki verwendung. Objekte werden hier einfach durch ihren Namen, die Position und ein paar weitere Parameter erzeugt.

Für die erste Version des Spieles reichte das. Nun ist uns aber aufgefallen: Die Spielwelt ist nach wie vor etwas leer, wir würden gerne noch mehr Elemente hinzufügen! Als erstes kam uns der Gedanke, Pflanzen an die Decke zu pappen. Hier war aber das Problem: Die ganzen einzelnen Ranken und Äste per Skript hinzuzufügen ist zu viel Arbeit! Alternativ hätten diese zufällig erzeugt werden können - Uns fiel aber auf, dass wir die Kontrolle darüber, wo in der Spielwelt Objekte plaziert werden, nicht abgeben wollten. Also erweiterten wir die Pixelkarte um eine weitere Ebene!

Links ist die zusätzliche Karte für die platzierten Pflanzen: Pro Feld wird durch die Farbintensität bestimmt, wie stark der Pflanzenwuchs auf dem Feld ist! So sind saubere Übergänge zwischen den Feldern möglich und die Vegetation kann gezielt für Effekte platziert werden.
Diese zusätzliche Karte ist ebenso im Spielordner und wird bei Spielstart geladen. Das ist in der Tat keine schöne Lösung mehr, aber das war die beste Idee ohne das Mapsystem nochmal neu zu schreiben.

Im Spiel sehen die Ranken dann zum Beispiel so aus:

[Schotti]

Ich steh total auf solche Dev-Einblicke! Da kann gerne mehr von kommen!

Kannst du noch ein paar vertiefende Worte drüber verlieren, wie aus dem Paint-Leveleditor die fertige Spielwelt wird? Ich finde den Prozess super spannend. Die Raumhöhe wird wahrscheinlich bei jedem Tile gleich sein, oder?

[csg]

Schotti, ich beantworte deine Frage die Tage in einem weiteren Post, dafür muss ich aber etwas ausholen!

Heute gibt es noch mal etwas Musikfutter: Ein paar der Lieder, die im Spiel erlernbar sind:

[csg]

ab sofort ist am Wochenende immer Dungeon Sound Devlog! Versprochen

Dungeon Sounds hatte in der ersten Fassung noch ein großes Problem - Heute geht es um Sound!

Das Spiel arbeitet natürlich mit 3d Sound, dieser ist aber bisher nur sehr einfach gehalten: Der Zuhöhrer ( Spieler ) empfängt die Soundquellen in der Umgebung, wobei die Lautstärke abhängig von der Distanz ist. Ganz davon abgesehen, dass wir natürlich mit einem sehr stark vereinfachten System von Akustik arbeiten ( Es gibt keine Reflektion oder andere Effekte ), hat dieses System in keinster Weise die Umgebung mit einbezogen. Betrachtet man folgenden Fall, wird das Problem schnell deutlich:


(Der Kreis kennzeichnet die Soundreichweite des Gegners, das Ohr ist der spieler)

Geräusche gehen durch alle Objekte, was gerade bei Wänden zu problemen führen kann. Dadurch können Gegner gehört werden, die unter Umständen noch sehr weit von einem weg sind. Das ist problematisch, weil es in Dungeon Sounds vorrangig um Musik und Geräusche geht, also muss vor allem dieser Apsekt gut funktionieren.

Als Lösung besitzt nun jeder Charakter eine Hörreichweite die sich effektiv am Spielgitter orientiert. Jedes Mal, wenn ein Charakter sein Feld wechselt, wird der abgedeckte Bereich seines Gehörs neu berechnet:


Die Zahl beschreibt wie viele Felder die Reichweite noch machen kann und verteilt sich demnach immer weiter auf die angrenzenden Felder. Je niedriger die Zahl, desto leiser ist ein Geräusch auf diesem Feld zu hören.

Wenn der Gegner nun ein Geräusch macht, wäre dies nicht vom Gehör des Spielers abgedeckt und daher nicht zu hören.

Der Vorteil dieses Systems ist, dass die abgedeckte Reichweite nur neu berechnet werden muss, wenn der Charakter sein Feld verlässt. Nachteilig ist allerdings, dass es in diesem System keine Lautstärke gibt: entweder etwas ist in Hörreichweite, oder nicht. die Lautstärke der Geräuschsquelle beeinflusst nicht das Gehör, dessen Reichweite ja gleich bleibt. Das ist aber okay, weil Dungeon Sounds in dieser Richtung kein Gameplay vorsieht.

Natürlich ist dises System streng genommen nicht richtig:



Das Bild zeigt,dass die Ausbreitung über die Felder in diesem Falle eher die Form eines Vierecks, als die eines Kreises annimmt. Falsch ja, aber da Dungeon Sounds überwiegend in engen Gängen spielt und alle Charaktere ständig in Bewegung sind, ein Effekt der vom Spieler nicht wahrgenommen werden wird.

Und ich hab Schotti nicht vergessen, nächstes wochenende bekommst du einen ausführlicheren Post!

[Schotti]

Yeah, ein neuer Devlog! Das sieht nach einer klassischen Pathfinding-Lösung aus, die euer Akustik-Problem super löst! Ich denke auch, dass der Wegfall der Geräuschlautstärke vernachlässigbar ist. Mit welcher Frequenz stoßen eure Gegner gefährliche Geräusche von sich?

[...]
Und ich hab Schotti nicht vergessen, nächstes wochenende bekommst du einen ausführlicheren Post!

...

[V-King]

Ich hab gehört, das Spiel soll voll den guten Soundtrack haben, mit schönen Grafiken und toller Programmierung, hab ich gehört!

Mal ein Angebot von mir an dich, csg: Ich würde, falls gewünscht, nochmal über die Songs drüber gehen und etwas anpassen, besonders Lautstärke-technisch, weil da einiges ja irgendwie lauter ist als anderes Zeug. Und natürlich würde ich den Soundtrack erweitern, wenn die Notwendigkeit dazu besteht
[ ] Ja
[ ] Nein
[ ] Vielleicht
[ ] Nur knutschen

[csg]

Mit welcher Frequenz stoßen eure Gegner gefährliche Geräusche von sich?

...

Gegner machen sich fast ununterbrochen bemerkbar - genau wie der Spieler geben sie Musik von sich!

Mal ein Angebot von mir an dich, csg: Ich würde, falls gewünscht, nochmal über die Songs drüber gehen und etwas anpassen, besonders Lautstärke-technisch, weil da einiges ja irgendwie lauter ist als anderes Zeug. Und natürlich würde ich den Soundtrack erweitern, wenn die Notwendigkeit dazu besteht

...

[X] Ja

! Wir arbeiten grad noch an der Technik, den Graphiken und auch ganz allgemein noch an ein paar verrückten Ideen, die uns so gekommen sind. Aber wenn du Lust hast, würden wir uns natürlich freuen wenn du noch mit im Boot bist!
Ich melde mich dann bei dir!

[CensedRose]

Also ich freue mich immer mehr auf das Spiel!
Die Sounds klingen schon mal sehr gut und ich bin gespannt, was es noch alles an Songs geben wird ^^
Vor allem gefällt mir auch diese Grafik, die man so nicht oft sieht.

Wann können wir in etwa mit einer Demo oder einer VV rechnen?
(Sry, falls ich hier eine Frage stelle, die es schon zu hauf gab.)

[Sabaku]

Wann können wir in etwa mit einer Demo oder einer VV rechnen?
(Sry, falls ich hier eine Frage stelle, die es schon zu hauf gab.)

...

Im Startpost gibt es noch Versteckt eine Verlinkung auf die noch ziemlich klunkige Version vom Indie Game Maker Contest damals, falls du die Pferde gar nicht mehr halten kannst.

[csg]

Dungeon Sounds ist nun multiplayer!


.... also, nur theoretisch, sorry.

Heute erzähle ich von einem neuen Spielfeature, das ich das erste mal in Dark Souls gesehen habe. Seitdem wollte ich es schon immer mal kopieren, endlich ist der Tag gekommen! Ähnlich wie in der Vorlage kann man nun in Dungeon Sounds die Phantome anderer Spieler sehen, die an den gleichen stellen vorbeigekommen sind und den Dungeon erkunden. Man sieht sie aber nicht nur, man hört sogar die Lieder, die sie gespielt haben als entferntes Echo.

Diese mysteriösen Phantome erscheinen im Spiel leuchtend blau und verblassen, wenn man ihnen zu nahe kommt.



Nun ein wenig zur technischen Lösung des ganzen:

Das Spiel logt ab sofort die eigenen Daten ( Position und gespielte Noten ) der letzten 60 Sekunden als ein Segment. Ist dies voll, werden die gesammelten Daten gebündelt und an einen Server geschickt. Jedes Segment wird einem Spielquadranten, die eine Reichweite von 10x10 Feldern haben, zugeordnet.
Nun schickt das Spiel jede 2 Minuten eine Anfrage an den Server, ob in dem aktuellen Quadranten des Spieles denn nicht mal ein Spieler vorbei gekommen ist. Wenn dem so ist, schickt der Server das entsprechende Segment des Spielers ( 60 Sekunden! ) zurück zum Spieler und zeigt sie an.

Fertig!

[csg]

Neues aus der Gruft!

Wir sind nach wie vor dabei die Atmosphäre im Spiel zu verdichten, also gibt es ab sofort: Kerzen!

Wer sich noch an den Post über unser Mappingsystem erinnert, dem fällt sicher auf: Einzelne Kerzen zu platzieren ist gar nicht mal so einfach! Da wir Objekte eigentlich nur auf einem Tile-Raster mittels Skriptbefehl aufstellen können war uns schnell klar, dass wir so nicht weiterkommen. Unsere Vorstellung war, ganze Räume mit Kerzen zu schmücken und so die Stimmung deutlich zu erhöhen.

wie sind wir also vorgegangen? Ich präsentiere, Kerzentexturen:

Ähnlich wie wir unseren Dungeon mittels einer Textur speichern, verfahren wir mit den Kerzen. Jeder graue Punkt erzeugt eine Kerze im Spiel, wobei die Helligkeit des Pixels bestimmt, wie hoch die entsprechende Kerze platziert wird.

Die Kerzentextur ist quasi eine detailreichere Variante der Dungeonkarte und wird im Spiel einfach über diese drauf gelegt. Im Bild sieht man gut, wie die Textur ( die in diesem Fall eine Fläche von 3x3 Dungeontiles abdeckt) in das Spiel integriert wird. Durch die höhere Auflösung können so genauer die Kerzen plaziert werden. In einer Kerzentextur wird ein Feld mit 20x20 pixel beschrieben, theoretisch könnten also 400 Kerzen paziert werden.
Die Größe der Kerzentextur ist übrigens variabel, muss nur jeweils durch 20 teilbar sein. eine Kerzentextur kann also ein einzelnes Feld, oder einen ganzen Raum abdecken!

Ein Kerzenareal wird dynamisch mittels einer Skriptzeile eingebunden:

Code:

addCandleArea( String path, Int maxheight, int candleType, Vec2 position, Int id);

Parametererklärung:
path Pfad zur Kerzentextur
maxheight Höhenmodifikator - er bestimmt, wie hoch eine Kerze maximal plaziert werden kann. Die tatsächliche Höhe wird interpoliert von Schwarz (0) bis Weiß (Höhenmodifikator).
candleType Kerzentyp. Wir haben sowohl Weiße (0), als auch rote (1) Kerzen.
position Position des Areals auf der Dungeonkarte
id Id des Objektes, um es später anzusprechen und zu modifizieren.

Großartig! damit ist alles erklärt!
Nein halt, vielleicht ist dem ein oder anderen aufgefallen, dass die Kerzentextur noch eine weitere Information speichert. Die Farbe, die eine Kerze umgibt, legt fest, wie spät sie entzündet wird.

Mittels des skriptbefehls

Code:

lightCandle(Int id, bool ignite);

Ist es möglich die Kerzen per Skript zu aktivieren. Dies war uns wichtig für Cutscenes oder wenn Räume betreten werden! Die Kerzen werden zeitversetzt aktiviert, je nach Farbwert, der sie umgibt: Die roten Bereiche werden später aktiviert, als die grünen. Durch saubere Verläufe in der Textur können schöne Effekte erzeugt werden, hier ein letztes Beispiel:

die dazugehörende Kerzentextur:

Bis nächste Woche!

[Schotti]

Ich finde es sehr beeindruckend, wir ihr mit eurem "Paint"-Leveleditor angefangen habt und diesen nach und nach durch weitere Funktionen erweitert! Die Kerzentextur ist ein schönes Beispiel, wieviele verschiedene Informationen man über Farben in einem Bild codieren kann. Danke für den Einblick!

Die Kerzen sind ein atmosphärischer Zusatz und werten das Gruftfeeling sehr auf! Habt ihr mal über herabtropfendes Wasser nachgedacht mit passendem Platschgeräusch? Das ist doch ein schöner Dungeonsound!