|
|
|
|
Anstatt dass Objekte heller werden, sobald sie im Fokus des Spielers sind (was sowieso nie richtig funktioniert hat), erscheint nun ein rotierendes Fragezeichen darüber. Ich find's schön.
Nach einer kleiner Session mit meinen Brüdern haben die Goblins und auch Golem nun anständige Soundsamples. Auch Musik spielt jetzt im Hintergrund.
Interessanterweise sollte man mit VSL und dynamischen statischen Variablen äußerst vorsichtig sein. Nach mehreren Versuchen, Golem zum Sprechen zu bringen, war der Speicher voll, und die Festplatte sollte beim Neustart mittels CHKDSK untersucht werden. Zum Glück hab' ich Sicherungskopien gemacht ...
Für die Pfade der NPCs (Non-Player-Characters) hab' ich mir folgendes ausgedacht: Die Goblins und Golem bekommen jeweils getrennte Pfade. Die Goblins können kreuz und quer laufen, aber damit Golem einen etwas mehr roboterähnlichen Habitus erhält, soll er den Level nur in einer Art Schachbrett durchschreiten. Außerdem sollte er mit seinen staksigen Beinen keine wackligen Treppen steigen können.
Gesagt, getan, zwei Pfadnetze erstellt. Golem läuft auch wunderbar.
Nur leider fand Virtools wohl, dass es langweilig wäre, wenn alles funktioniert, und ließ daher die Goblins völlig willkürlich in Richtungen gehen, die der Logik nach gar nicht möglich sind.
Was ist passiert? Anscheinend ist der Buildingblock "Character Go To Node" verbuggt, denn wenn man seine Pfadpunkte auf mehrere Ebenen verteilt, stört es diesen gar nicht, wenn zwei Punkte nicht miteinander verlinkt wurden. So kommt es, dass ein Goblin anfangs einem Pfad (z.B. zu einer kaputten Maschine hin) folgt und zwischendurch einfach so gegen eine Wand rennt, weil der BB denkt, ein Knotenpunkt, der eigentlich weit über dem Goblin liegt, wäre ja viel näher. Obwohl er es nicht ist. Eigentlich ein interessantes Verhalten, nur leider völlig unpraktisch (und nicht deaktivierbar).
Folglich musste ich mir wieder selber was zusammenbasteln. Es ist recht störend, dass ich so oft damit beschäftigt bin, die Fehler von Virtools auszubügeln. Ganze zwei Tage hat es mich gekostet, aber immerhin laufen die Goblins jetzt einigermaßen korrekt durch die Gegend. Sollte es dennoch passieren, dass einer der kleinen Grünlinge nicht mehr weiter weiß, so wird seine KI praktischerweise dennoch ab und zu reaktiviert, weil ja die Maschinen recht oft kaputt gehen. Das funktioniert aber eben nur solange wie die Goblins reine Arbeiterbienen sind.
Nun ja, der aktuelle Stand ist somit: Virtools 2 : 1 Friedrich
Während meiner läppischen Versuche, Sounds, wie etwa Klapp-Geräusche der Tür und das Summen der elektrischen Lampen, einzubauen, fiel mir auf, dass Virtools zwar Minimum- und Maximum-Werte mittels des "Set Sound Range"-Bausteins zulässt, diese aber nicht den gewünschten Effekt haben. In der Hilfe steht einerseits, dass bei Entfernung des Listeners zur Soundquelle über dem Maximalwert der Sound nicht mehr zu hören ist (was nicht stimmt), andererseits, dass ab dem Maximalwert der Sound schlicht nicht mehr leiser wird. Letzteres stimmt leider und bedeutet z.B., dass man zwar angeben kann, der Sound soll bis drei Meter Entfernung bei voller Lautstärke zu hören sein und ab fünf Meter bei Minimallautstärke, aber die Minimallautstärke kann man nirgends angeben, die wird errechnet und fällt niemals auf null.
Nun kann man diese Min/Max-Werte auch per VSL angeben und bestimmen, dass ab dem Maximalwert der Sound gar nicht mehr zu hören ist, aber dann hat man einen unschönen Bruch im Gehörten. Bis fünf Meter geht der Sound langsam auf 40% runter, danach ist er plötzlich ganz weg. Das kann es auch nicht sein.
Also musste ich mir einen eigenen Play Sound Baustein basteln, der sich die Distanz des Listeners greift und die Lautstärke des Sounds "manuell" setzt. Meine Interpolation zwischen dem Min- und Max-Wert ist hierbei linear, aber das merken sowieso nur Audiophile (hoffe ich).
Mein selbst gestecktes Ziel, bis zum nächsten Mittwoch (also den 6. Juni) Goblins in mein Spiel einzubauen, die durch's Level laufen und mit denen Kwai interagieren kann, habe ich zum größten Teil erreicht, glücklicherweise. Zwar ist das mit der Interaktion weniger als nur rudimentär (wenn man auf einen Goblin klickt, bleibt er stehen und gibt ein Geräusch von sich), aber das Herumlaufen klappt ganz gut.
Ab und zu gehen nämlich im Gebäude verteilte Maschinen kaputt und senden eine Nachricht an die Gruppe Goblins. All jene der kleinen grünen Männchen, die nicht beschäftigt sind, rennen daraufhin zur Maschine. Der Goblin, der zuerst ankommt, repariert sie, die anderen gehen wieder zurück an ihre Plätze. Nach etwa zehn Sekunden geht auch er wieder zurück. Bis die Maschine wieder kaputt geht ...
Ich benutze hierbei Messages und Attribute. Zwischendurch kann Kwai einen Goblin ansprechen - seine eigentliche Aufgabe (entweder "ausruhen" oder "reparieren") vergisst der Angesprochene dann nicht. Schwierigkeit war hierbei, dass sich zeitgleich die Situation ändern kann und beispielsweise die Maschine, die der Goblin angesteuert hatte, inzwischen schon repariert wird. Deshalb fragt seine KI ständig ein Attribut der jeweiligen Maschine ab, ob sie denn schon besetzt ist oder nicht.
Eigentlich ist es ja gar nicht der Erwähnung wert, dass die Figuren im Spiel jetzt simple Schatten dank "Simple Shadow" Building Block besitzen.
Allerdings hab' ich dafür einen Tag gebraucht, das ganze überhaupt einzubauen. Weil Virtools 4 nämlich die herzige Eigenschaft hat, die Schatten einfach verschwinden zu lassen, sobald man a) eine zweite Kamera hat, die b) weit entfernt c) Grundlage für ein Render To Texture ist.
Richtig, weil ich in 500 Meter Entfernung eine Skydome habe, werden die Schatten nicht gezeichnet.
IST DOCH GANZ LOGISCH.
Kwai kann nun auch mit zwei Objekten im Level interagieren: er darf eine Maschine aktivieren und deaktivieren, sowie eine Tür öffnen und schließen. Auch hier wieder jede Menge Fallstricke. So löscht der Exporter _doch nicht_ Animationen mit nur einem Keyframe, auch wenn man dies einstellt. Da ich Maschine und Tür nämlich dynamisch einlade, muss ich sie natürlich erst an die entsprechende Position eines Helfers im Level rücken. Startet dann aber beispielsweise die Animation des Türöffnens, so befindet sich die Tür plötzlich wieder am Koordinatenursprung.
Zusätzlich musste ich erkennen, dass "Set Global Animation Step" nicht den gewünschten Einfluss auf "Play Global Animation" hat. Da ich ja z.B. die Animation des Türöffnens unterbrechen kann, um die Tür gleich wieder zu schließen, müsste ich bei Starten von "Play Global Animation", welches die Animation rückwärts abspielt, die aktuelle Animationsphase wieder benutzen. Geht aber nicht. Haje.
Die Bewegung des Spielers und der Kamera sind zwei sehr wichtige Themen, weshalb ich relativ viel Zeit damit verbracht habe (und sicherlich noch werde), was das Scripting betrifft. Die Kamera ist nun frei um die Spielfigur drehbar. Zusätzlich kann man per Mausrad näher an die Figur zoomen und auch wieder weg. Das Problem hierbei war natürlich vor allem, dass die Kamera nicht durch Hindernisse, vor allem Boden und Wände, hindurch rutschen sollte - dazu benutze ich einen einzelnen Strahl, der vom Kopf der Figur (bzw. dem Kamera-Target) aus zur Kamera geschossen wird und der guckt, ob sich etwas zwischen den beiden befindet. Wenn ja, wird die Kamera zum Spieler hin verschoben, bis sie vor dem Hindernis steht. Leider ist es etwas unperformant, diesen Strahl auf alle Objekte im Level hin zu testen, sodass er "nur" noch auf Objekte mit Floor-Attribut und auf Kollisionsobjekte reagiert.
Problematisch erwies sich auch die Steuerung Kwais. Ich wollte unbedingt, dass der Spieler mit der üblichen WASD-Steuerung sich in alle Richtungen bewegen kann. Um auf acht verschiedene Animationen verzichten zu können (vorwärts, seitwärts, rückwärts, und alles dazwischen), dachte ich mir, ich dreh' einfach die Figur entsprechend. Rennt sie also beispielsweise mittels "D" nach rechts, darf sich die Kamera natürlich nicht mitdrehen. Noch dazu muss der Spieler die Figur ja mittels Maus jederzeit nach links und rechts drehen können. Also komplexer als gedacht. Jedenfalls dreht sich Kwai nun nicht mehr per Unlimited Controller.
Für den Himmel hab' ich etwas mehr als einen Tag gebraucht ... Ich benutze eine zweite Kamera, die weit außerhalb des eigentlichen Levels ist und die die Drehung der Spielerkamera kopiert. Sie befindet sich innerhalb des in 3D Studio Max modellierten Himmels, der etwa fünf Units breit ist, und projiziert das, was sie sieht, auf eine Fläche, die an die Kamera des Spielers angeheftet ist. Diese Fläche wird stets als erstes gezeichnet, sodass nur dort, wo sich keine Geometrie befindet, der Himmel gezeichnet wird.
Diese Methode hat den Vorteil gegenüber einer Cubemap, dass ich den Himmel problemlos animieren kann. Überdies muss ich das Clipping, wie es bei einer riesengroßen Skydome, die das Level umschließt, nicht unnötig raufdrehen. Außerdem wird der Himmel auf diese Weise nicht vom Nebel beeinflusst (wenn ich das nicht will).
Hm, heißt es eigentlich "der Skydome", oder "die Skydome"?
|
|
|
|
