Weil es bereits einen letzten Eintrag gibt, hier ein Post-Scriptum:
"Hals über Kopf" hat auf der Devmania 2010 den zweiten Platz bei den Projektvorstellungen belegt - Dritte wurde Jana mit "Ketonauten", absoluter Gewinner wurde das Team von Dreamworlds mit "Splitterwelten".
Zudem gewann ich mit meinem Diplomprojekt in der Kategorie Multimedia den SAE Alumni Award 2010. Dieser ist unter anderem mit einem iMac dotiert.
Das Spiel und auch der Editor kann übrigens auch auf meiner Website heruntergeladen werden.
Nun denn. Das Diplom ist geschafft, die Mühsal liegt hinter mir. Die Präsentation lief erstaunlich gut - Bewertung war 1,0. Auch für den schriftlichen Teil, sowie für den Prototypen gab es jeweils eine 1,0. An dieser Stelle ein großes Dankeschön an Professor Bernd Hanisch, an Daniel Ackermann, an Jana, an meine Eltern, an meine Brüder Ludwig und Paul, und an den #gamedev.ger - ohne euch wäre das alles nicht so toll gewesen und geworden.
Während ich dies schreibe, sind die Videos noch nicht online, aber schon bald kann man sich die Präsentation und einige Szenen aus dem Spiel angucken, auf YouTube oder Vimeo.
Nach dem schriftlichen Teil der Diplomarbeit ist nun auch der Werksbericht online.
Mittels diesem habe ich einen Monat vor der Präsentation mein Spieleprojekt (sowie den zugehörigen Editor) ausführlichst erläutern müssen. Der Bericht war dann auch Grundlage für die Bewertung des praktischen Teils des Diploms.
Da die letzten Wochen leider nicht sehr viel Zeit/Muße zur Erstellung von Tagebucheinträgen übrigließen, zum Ausgleich ein paar Screenshots von dem, was ich beinahe als finales Produkt bezeichnen möchte. (Final in Bezug auf die Präsentation, natürlich. Die findet übrigens am 05.07.2010, 13 Uhr, im Hörsaal des Medienzentrums in Neuwerk 1, 06108 Halle/Saale, statt.)
Vor längerem habe ich mich daran versucht, dem Zeitstopp-Effekt eine interessante Optik zu geben. Nach einigen glücklosen Versuchen mit einem Refraction-Shader (erster Screenshot) hatte ich mich darauf konzentriert, die Umgebung um den Spieler herum lediglich einzufärben (Zwischenstand zweiter Screen).
Im Endeffekt wird innerhalb der Zeitstopp-Blase nun alles desaturiert, also schwarzweiß (drittes Bild). Um das ganze etwas zu verstärken, habe ich die Grautöne außerdem mit einem Post-Effect zur Hervorhebung von Kanten kombiniert - diesen Compositor fand ich bei den OGRE-Beispielen.
Der vierte Screenshot zeigt also den finalen Stand des Zeitstopp-Effekts.
Vielen Dank an dieser Stelle an CodingCat für seine Unterstützung!
Ich habe mir, als eine Art zusätzliche Unterstützung für meine Pipeline, zwei Scripts gebastelt, welche in 3dsmax zur Anwendung kommen. (Sie wurden also in MaxScript geschrieben.)
Das erste ist für's Exportieren da:
Mit einem Klick habe ich dann meine Objekte im Spiel. Das Script nutzt hierbei die Scripting-API von OgreMax. Da OgreMax ein Szenen-Exporter ist, legt es bei jedem Klick auch eine .scene-Datei an, die ich nicht benötige (genauso wenig wie die Materialenbeschreibungs-Datei) - mein Script löscht sie daher.
Etwas komplexer wurde mein Script durch die Tatsache, dass ich Objekte mit unterschiedlichen Material IDs habe, auf denen aber keine echten 3dsmax-Materialien liegen - OgreMax fasst solcherlei Teil-Objekte dann automatisch zusammen (mit einem Material namens "NoMaterial"). Daher muss mein Script Meshes selbst erst einmal aufsplitten, bevor sie exportiert werden.
Mein zweites Script ist eigentlich eine (ständig wachsende) Script-Sammlung, mit kleinen aber feinen Funktionalitäten:
Wichtig ist vor allem die "Distributing"-Gruppe - schnell und einfach lassen sich dann kleinere Assets auf einem größeren Mesh entlang der Oberflächennormale verteilen, mit zufälliger Skalierung und Rotation. Das kann dann so aussehen aus wie auf diesen Bildern:
Ygnes ist nun so gut wie fertig. Sie ist sozusagen der "erste Offizier" auf dem Inselschiff (oder Erster Maat, der genaue Titel ist im Grunde egal), auch wenn es nicht militärisch angehaucht sein soll. Auf jeden Fall ist sie nicht nur die rechte Hand des Kapitäns, sondern auch seine Ehefrau. In meiner offiziellen Beschreibung im Konzept habe ich sie vor allem als streng und herrschaftlich charakterisiert, und versucht, dies in die Umsetzung miteinfließen zu lassen.
Von den Skizzen her gefällt mir die rechts oben am besten ("Piratestyle!"), sie war am Ende meine hauptsächliche Vorlage.
Die Bilder im Ganzen zeigen, was zu einem Characterdesign so dazu gehört: Skizzen, Modellierung, Unwrapping (in Roadkill, zum Vorbereiten der Texturierung), Rigging und Skinning (d.h. mit Knochen ausstatten), Animation. Die Textur ist auch beinahe fertig, kann jedoch jederzeit überarbeitet werden.
Da Ygnes in meinem Konzept über und über mit Efeu bedeckt ist, habe ich ihr der Einfachheit halber grüne Haut gegeben; denn das es würde den Aufwand kaum rechtfertigen, jede Menge Blätter zu modellieren - zumal ich sowieso einen eher einfachen Stil anstrebe, wie man sieht.
Die ersten beiden Screenshots demonstrieren übrigens, dass sich Ygnes auch schon in den Prototypen einbauen lässt, allerdings noch ohne Animation. Denn dafür muss ich erst alle Animationsphasen, die ich erstellt habe, in einer einzigen Datei in Reihenfolge bringen und dann entsprechend exportieren. Diese Aufgabe spare ich mir für den Moment, in dem ich Ygnes auch tatsächlich als Story-Element in meinem Präsentations-Level brauche.
Nebenbei kann man auf dem allerersten Screen auch erkennen, welcher Unterschied hinsichtlich Körpergröße zwischen ihr und dem Protagonisten besteht. Dieser Unterschied ist nicht zufällig, sondern wurde auf Größenvergleichs-Skizze links bereits geplant. Es wäre langweilig, wenn alle Figuren gleich groß wären - eine Lehre, die auch ganz nett im Manga Zeichenkurs von Akira Toriyama und Akira Sakuma erklärt wird.
Ygnes ist übrigens die erste Frau, die ich jemals modelliert habe ...
YouTube und Vimeo halten ein neues Video bereit, welches zwei Special Items zeigt (Gravitationsportale und Dimensionswechsel) sowie die Tatsache, dass ich Schatten in den Prototypen eingebaut habe.
Wie auch auf dem ersten und dritten Screenshot zu sehen, wird der Schatten durch PSSM (Parallel-Split Shadow Maps, eine Demonstration findet man hier) dargestellt. Das dritte Bild zeigt auch die meiner Meinung nach schöne Kombination von PSSM und SSAO - da stört es mich auch nicht, dass die Schatten recht hart sind und keinerlei weiche Kanten besitzen. Im Grunde passt das auch zu der Optik, die ich anstrebe.
Leider habe ich zur Zeit noch einige Probleme mit OGREs Schattensystem, sodass oftmals Objektschatten ganz oder teilweise verschwinden, vor allem, wenn sich diese Objekte relativ weit weg befinden.
Die anderen Screenshots zeigen übrigens meine Experimente mit einem Glow-Shader (gefunden im OGRE-Forum), sowie dem "Radial Blur" Post-Effect, der als Beispiel-Compositor im OGRE-SDK vorhanden ist. Das letzte Bild kombiniert die beiden Effekte zudem mit einem Kolorationsshader, der die dargestellte Szene in Falschfarben taucht. Diesen musste ich mir selbst schreiben, da ich nichts vergleichbares gefunden hatte.
Zusammen ergeben die drei Effekte die Optik des Dimensionswechsels. Der Wechsel in eine Paralleldimension ist für den Spieler nützlich, um bestimmte Hindernisse zu überwinden; Glow, Blur und Farbwechsel zeigen jedoch, dass der Dimensionswechsel nicht permanent ist.
Im Video werden überdies Gravitationsportale veranschaulicht, welche vom Spieler erstellt werden können. Das Portal selbst ist noch eine reine Testgrafik, es fehlen auch noch subtile Partikeleffekte.
So ein Portal kann sehr mächtig sein, aber auch gefährlich. Lässt man es in die falsche Richtung zeigen, landet man unvermeidlich im Nichts und muss von vorne beginnen.
Nun folgt eine kleine Zusammenstellung des Werdegangs der Hauptfigur. Sie ist diejenige Figur, die der Spieler steuert, wodurch sie ein gewisses Identifikationspotential besitzen sollte. Entgegen üblicher Konventionen habe ich mich dagegen entschiedenen, einen strahlenden Helden zu kreieren. Stattdessen wollte ich einen anfänglichen Niemand und Nichtsnutz haben, der im Laufe des Spiels über sich hinaus wächst.
Vorstellbar wäre sogar eine graduelle Veränderung des Modells (bzw. der Textur), so wie in "Shadow of the Colossus", um die Veränderung des Charakters nachvollziehbar zu machen. Wobei in SotC die Spielerfigur mit jedem Level schmutziger und verderbter wurde ... eine Herangehensweise, die ich faszinierend finde.
Als Hintergrundgeschichte für den Helden des Spiels habe ich mir überlegt, dass er ein Adliger ist - also durch Bücher gebildet und etwas hochnäsig. Allerdings ist er kürzlich verarmt, eventuell so sehr, dass er seinen Adelstitel verkaufen musste. Erstmals muss er in seinem Leben hart arbeiten, um seinen Magen füllen zu können.
Die ersten vier Skizzen (Reihenfolge der Bilder ist von links nach rechts!) zeigen anfängliche Überlegungen zum Aussehen des Protagonisten, wobei die vierte sehr spät entstanden ist. Gleich nach dieser zeichnete ich das fünfte Bild, welches für mich am ehesten den Charakter widerspiegelte, den ich darstellen wollte. Darauf folgten dann einige Proportionsstudien, wobei ich die achte Skizze, auf dem der Held des Spiels gar zu unmotiviert und unförmig aussieht, als zu übertrieben empfinde.
Die Zeichnung davor ist mein persönliches Leitbild für das Aussehen des Helden, vor allem, was die Proportionen betrifft - die Beine sind so lang wie der Oberkörper, die Körperhöhe ist insgesamt recht gering und ein kleines Bäuchlein demonstriert den vormaligen Wohlstand. Das zusammen ergibt einen scheinbar unscheinbaren Anti-Helden mit Ambitionen zu Abenteuer und Selbstverwirklichung; ein wenig wie der kleine Hobbit Bilbo Beutlin von Tolkien.
Das Gewächs auf dem Kopf, zu guter Letzt, dient der Wahrung des durchgängigen Konzepts des Spiel.
Die letzten drei Bilder zeigen den Prozess des Modellierens. Interessanterweise entsteht das Grundmesh relativ schnell. Die meiste Zeit wird üblicherweise in die Details investiert, und die permanente Nachjustierung einzelner Vertices, für die schönere Gesamtform. Vor allem die Silhouette ist wichtig.
Bevor ich dieses Modell nun unwrappe, rigge, skinne und animiere, werde ich erst einmal an die anderen Figuren modellieren und animieren.
Denn es hat sich gezeigt, dass während des komplexen Prozesses der Character-Erstellung immer wieder Fehler offenbar werden, die man anfangs hätte vermeiden müssen; beispielsweise hätte dort noch ein Edge-Loop hingehört, hier ein paar Vertices und drüben ist das Skinning falsch. Da der Protagonist die wichtigste Figur ist, will ich erst einmal mit den sekundären Modellen üben.
Der dritte der Screenshots zeigt eine Testszene, die ich angefertigt habe; hier werden verschiedene physikalische Eigenschaften ausprobiert. Denn man kann im Editor von Dynamikon nun endlich Dinge wie Reibung und Restitution (Rückgabe) eines dynamischen oder statischen Objekts einstellen. Setzt man beispielsweise die Restitution eines Balls und des Untergrunds auf eins, kommt besagte Kugel nie mehr zu Ruhe, da sie auf ewig nach oben springt - fantastisch elastisch!
Ansonsten gibt es auf YouTube und Vimeo ein neues Video zu meinem Projekt. Gezeigt wird kurz und knackig, was die letzten Tage an Features hinzugekommen ist:
NPCs sind halbwegs fertig, denn nun kann man mit ihnen reden. Mit dem Dialogsystem an sich bin ich noch nicht ganz zufrieden. Neben kleineren Bugs und der natürlich zu überarbeitenden Optik muss ich mir noch Gedanken dazu machen, wie ich Sprachausgabe integrieren möchte. Am wichtigsten ist aber, dass auch für Zuschauer klar wird, wer gerade spricht; aber ich werde vermutlich keine Zeit für deutliche Sprechanimationen haben. Daher wären vielleicht sprechblasenartige Symbole gut.
Es existiert nun ein Inventar, in das der Spieler Power-Ups verstauen kann. (zweiter Screenshot) Momentan ist dies eine einzelne Leiste mit festen Slots; da ich aber auch ein generelles Inventar für trivialere Gegenstände haben möchte, wird es noch mehr aufgeteilt werden.
Damit man überhaupt was verstauen kann, habe ich das erste Power-Up eingebaut, das mir auch sehr am Herzen lag: das Zeitstopp-Extra. Es hat noch keine eigene Grafik, deswegen sieht es im Video recht abstrakt aus. Bei diesem nützlichen Power-Up jedenfalls entsteht um die Spielfigur eine Blase, in der alle Gegenstände und NPCs quasi einfrieren. (erster Screenshot) Hoffentlich schaffe ich es im nächsten Monat, dies mit ein paar interessante visuelle Effekten zu garnieren.
Man sieht überdies, dass ich die Möglichkeit in den Editor implementiert habe, Partikeleffekte und Lichter einzufügen. (vierter Screenshot) Dafür wollte ich - wie schon damals bei den Triggern - eigentlich eine eigene Objektart einführen. Im Endeffekt habe ich diese Funktionalität jedoch bei den Point-Objekten eingefügt.
Als nächstes großes Ziel für den Prototypen steht die Machbarkeitsprüfung für eine Paralleldimension an. Das wird sich jedoch etwas länger hinziehen, da ich mich erstmal dem grafischen Teil etwas mehr widmen sollte.
Ein neues Video (YouTube, Vimeo) demonstriert, dass die einzelnen Funktionalitäten der Schwarzen Löcher inzwischen vollendet sind, mehr oder weniger. Folgendes wird gezeigt:
Mehrere Gravitationssphären lassen sich miteinander verknüpfen, sodass Zylinder entstehen, oder sogar ganze Ketten. (Letzteres ist im Video nicht zu sehen.) Dabei kann definiert werden, ob die Enden dieses Zylinders abgerundet sind oder nicht. Es wird vom Prototypen sogar berücksichtigt, dass die Sphären unterschiedlich groß sind.
Statt nur Kugeln gibt's auch Quader.
Man kann statt einer Gravitation, die auf einen Punkt oder einer Linie ausgerichtet ist, nun auch einfach eine allgemeine Richtung angeben. Somit ist es möglich, den Spieler ohne Mühe die Wand hochlaufen zu lassen.
Ein Schwarzes Loch kann auch an ein dynamisches Objekt geheftet werden, es bewegt sich also fortan mit. Im Video wird dies durch eine Kugel demonstriert, die magnetähnliche Eigenschaften besitzt.
Last but not least kann einem Schwarzen Loch ein Script zugewiesen werden, sodass bei Betreten oder Verlassen des Lochs interessante Effekte im Spiel auftreten können.
Eigentlich wollte ich solcherlei "Trigger" als eigene Objekte im Editor haben, aber es war zu verlockend, den Schwarzen Löchern selbst die Scriptfähigkeit zu verleihen. Trigger wurden damit überflüssig. Es fehlte lediglich noch die Möglichkeit, die gravitationsverändernde Fähigkeit eines Schwarzen Lochs auszuschalten, was jetzt ebenfalls implementiert wurde. Damit verliert die Namensgebung zwar endgültig ihren Sinn, aber es gibt momentan wichtigeres ...
Auf meinem internen Wochenplan steht nun vor allem das Zeichnen und die Stilsuche an. Danach soll man im Spiel Dinge aufsammeln und ins Inventar tun können. Das wäre die Vorarbeit für Power-Ups im Spiel; als erstes würde ich diesbezüglich den Zeitstopp (meine eigentliche Grundidee für dieses Projekt!) umsetzen wollen.
Zuguterletzt ein paar Screenshots zum Thema Schwarze Löcher, als Bonus.
Was mich bei meinen sphärischen Gravitationszonen, d.h. den Schwarzen Löchern, immer etwas stört, ist der doch recht abrupte Wechsel der Perspektive des Spielers, sollte er er in eine solche hineingeraten. Um das ganze abzuschwächen, wollte ich lange Zeit den Leveldesigner (also mich) bestimmen lassen können, welche Minimal- und welche Maximalstärke ein solches Loch hat, und wann die Maximalstärke beginnt.
Beim Versuch der Implementierung dieser Faktoren haben sich jedoch zwei Dinge gezeigt. Erstens mag es für die kugelige Form der Schwarzen Löcher noch relativ einfach einzubauen sein, für die zylindrischen und kubischen jedoch würde ich erstmal vor weiterem Kopfzerbrechen stehen. Und zweitens stellt sich der gewünschte Effekt des sanften Übergangs dann doch nicht so ein, als dass sich weiterer Aufwand in dieser Richtung lohnen würde. Also habe ich die drei Werte kurzerhand gegen einen einzigen Stärke-Wert getauscht.
Immerhin sind die Schwarzen Löcher dadurch auch fast fertig. Es gibt nun auch kubische Formen, sowie einfache direktionale Gravitationsmanipulation, damit die Spielfigur in einem bestimmten Gebiet an der Wand laufen kann und Objekte dort auch liegen bleiben.
Außerdem habe ich ein weiteres Problem gelöst, das auftrat, wenn die Spielfigur sich ganz nah am Rand eines Schwarzen Lochs aufhielt: Durch die längliche Form des Character Controllers passierte es oft, dass die Figur ständig hin und her wackelte, weil sie in einem Frame vom Schwarzen Loch beeinflusst wurde (sie also in Richtung dessen Zentrums gezogen wurde), und im nächsten Frame nicht mehr (sich die Gravitationsrichtung der Figur also wieder normalisieren wollte).
Dies geschieht nun nicht mehr, weil ich das Kollisionsobjekt der Spielfigur, das vom Schwarzen Loch beeinflusst wird, einfach gegen eine Kugel ausgetauscht habe. Der Rest blieb unangetastet.
So, mal ein (relevantes) Update für dieses Blog. Und zwar hatte ich mich, wie allgemein bekannt, bis zum Anfang des Monats fast nur noch mit meiner schriftlichen Arbeit beschäftigt, dessen so genannte Screenversion man nun hier herunterladen und lesen kann.
Wie von Anfang an geplant hatte ich mich mit einigen Bestandteilen eines Computerspiels beschäftigt: Gameplay, Interface, Story, Sound, Leveldesign und Physik. Im Nachhinein wundere ich mich selbst ein wenig, warum ich nicht auch die generelle grafische Gestaltung besprochen habe, zumal es da viele interessante Beispiele für gäbe. Andererseits halte ich den Faktor Grafik sowieso schon für viel zu überrepräsentiert (v.a. in den Spieletestzeitschriften), da es bei vielen Spieleentwicklern inzwischen anscheinend nur noch darauf ankommt, schöne Screenshots und Trailer machen zu können. Anders kann ich mir die fortschreitende Regression hinsichtlich Gameplay und Story nicht erklären. Aber ich schweife ab.
Nicht wirklich geplant war, dass das Konzept, welches man auch hier im Blog lesen kann, letzten Endes nur im Anhang der Diplomarbeit zu finden sein würde. Allerdings bin ich sowieso schon beinahe über die maximale Seitenzahl gekommen - und dennoch gäbe es noch viel zu sagen. Insgesamt bin ich mit meiner Arbeit nicht wirklich zufrieden - aber froh, dass dieser Teil nun hinter mir liegt. Ich bereue jedoch, keine Zeit mehr für einige Gestaltungsrichtlinien von "Dynamikon" gehabt zu haben. Außerdem mag ich den Arbeitstitel immer noch nicht, aber Namensfindung stand und steht gerade weit hinten an.
Nach drei Wochen jedenfalls widme ich mich endlich wieder meinem Prototypen - diese Zeit der Erholung musste leider sein, unter anderem möchte ich über Spiele ja auch nicht nur schreiben, sondern sie auch selbst mal ausprobieren ..
Momentan sitze ich daran, die bereits im Dezember angefangenen Schwarzen Löcher abzuschließen: Gravitationszylinder und -kuben müssen eingebaut werden, sowie ein fehlerfreies Verhalten, wenn sich eine Spielfigur im Grenzbereich aufhält. Zudem muss definiert werden, was passiert, wenn ein beliebiges Objekt ein Schwarzes Loch wieder verlässt.
Da das ganze sowieso immer mehr Zeit frisst als man denkt, habe ich auch gleich mal einen Wochenplan angefangen, der sich demnächst aber auch wieder ändern wird. Das liegt daran, dass ich mir erst einmal bewusst werden muss, welche Abschnitte meiner Story ich eigentlich umsetzen will. Dazu werde ich wohl als nächstes eine Menge Skizzen produzieren; leider habe ich das Zeichnen allgemein seit langem sträflich vernachlässigt und muss daher erst einmal wieder meine Zeichenhand trainieren.
Nach den Schwarzen Löchern soll das Feature "Zeitstopp" umgesetzt werden. Ob ich danach tatsächlich noch Paralleldimensionen implementiere, wird sich allerdings erst noch zeigen. Wichtiger wäre mir mindestens eine Art an Gegner. Auf jeden Fall sollte ich gewisse Effekte, wie Schatten und Partikel, nicht vergessen und sie möglichst früh in den Prototypen einbauen.
Und das ist nur der Part, der durch die Programmierung zustande kommt. Zwei bis drei Figuren und eine Menge Prefabs müssen ja nebenbei modelliert werden, um die Level, die dann entstehen, auch mit Inhalt zu füllen.
Fortsetzung folgt.
Huch, das sieht ja aus wie das, was ich machen will. Nur etwa eine Billion mal besser. Aber ich benutze ja nicht DX11, sondern nur DX9c - kein Wunder!
Rudimentär habe ich mal die Schwarzen Löcher in den Editor eingebaut. Dazu gibt es auch ein Video, wieder mal auf YouTube (schlechte Qualität) und Vimeo (gute Qualität). Es zeigt auch kurz das Aufheben und Werfen von Gegenständen.
An der Darstellung und Bearbeitung der "Holes"-Objekte muss noch gefeilt werden. Es wird von der Übersicht her so oder so problematisch, sobald ein Objekt sich in einem anderen befindet, also sollte es irgendwann so eine Art Ebenen-Modus geben.
Bis Anfang Februar habe ich für weitere Arbeiten am Prototypen leider keine Zeit - die schriftliche Arbeit verlangt meine vollste Aufmerksamkeit. Eigentlich wollte ich die Arbeit an den Schwarzen Löchern ja bis dahin beenden, aber es kommt ja doch immer anders als man denkt.
Obwohl es nicht wirklich benötigt wird, habe ich jetzt die Möglichkeit in den Prototypen eingebaut, ihn mit einem Controller zu steuern. (Nur das Spiel; nicht den Editor.) Das wollte ich schon damals bei Über Leben und Sterben machen, bin aber nie dazu gekommen.
So wirklich gut funktioniert es allerdings nicht, da müsste noch stark getweakt werden. Die Sache ist allerdings nicht wichtig genug, als dass ich allzuviel Zeit hineinstecken werde.
In der Kürze der Zeit hier ein kleines Update. Momentan sitze ich daran, dem Spieler die Möglichkeit zu geben, Gegenstände aufheben und bewegen zu können.
Das ist irgendwie schwieriger als gedacht. Folgende Probleme haben sich ergeben:
Das Wie: In jeder Physikengine kann man die physikalisierten Objekte mittels so genannter Constraints miteinander verbinden (auf diese Weise können beispielsweise Türen gebastelt werden, die auf- und zuschwingen). Der Plan war, dass ich mit einem solchen Constraint das angewählte Objekt an die Spielfigur hefte. Leider ergaben sich daraus eine Menge Problemfelder (Gewicht, Drehung, etc.), die ich nicht wirklich lösen kann. Darum wich ich auf ein mehr oder weniger einfaches Anpassen der Position aus.
Da die Position des gehaltenen Objekts jeden Frame neu gesetzt wird, kann es ganz einfach durch Wände geschoben werden - ein ziemlich übler Nebeneffekt. Daher passe ich jetzt nicht die Position direkt an, sondern gehe einen Umweg über die Geschwindigkeit (Linear Velocity). Zusätzlich wird per "Ghost Object", welches nur für Kollisionsdaten existiert, geprüft, ob sich der Gegenstand nahe einer Wand befindet. Wenn ja, wird die Geschwindigkeit reduziert - ein Durchdringen wird dadurch unwahrscheinlich.
Ein anderes Problem war, dass das Objekt, einmal in Händen gehalten, ganz einfach einen NPC in die Höhe steigen lassen konnte. Schlimmer noch beim Player Character, der permanent nach oben beschleunigt wurde. Zudem konnten andere dynamische Objekte, die herumlagen, in den Boden gedrückt werden. Ich umging diese Probleme, indem ich die Collision Mask anpasste.
Es bestehen noch immer Schwierigkeiten bei sehr langen oder generell sehr großen Objekten, die nun in den Spieler hineinragen können. Hier muss wahrscheinlich die Rotation angepasst werden. Zudem sollte eine Begrenzung eingebaut werden, ab welchen Ausmaßen Gegenstände überhaupt getragen werden können, oder es wird einen Flag geben, der bestimmt, ob ein Objekt vom Spieler aufhebbar ist.
Sollte dieser Part einmal abgeschlossen sein, gibt es vielleicht wieder ein Video. Eigentlich wollte ich ja lediglich einen Dialogmodus in den Prototypen einbauen, aber es ist gut, wenn die Funktion "Benutzen" sowohl bei NPCs als auch bei Gegenständen bereits jetzt vorhanden ist.
Da es sich als doch leichter als gedacht herausgestellt hat, präsentiere ich noch ein zweites Video innerhalb kürzester Zeit!
Dieses Mal ist die Vimeo-Version gegenüber der von YouTube definitiv zu empfehlen. Vimeo hat es nämlich nicht so sehr gestört, dass ich den Film in einer geringeren Auflösung als letztes Mal aufgenommen habe - man kann sogar die Beschriftung der Buttons des GUI lesen.
Das Video demonstriert, dass es NPCs gibt, dass es Dummys (bei mir "Points") gibt, und dass die NPCs nun von Punkt zu Punkt laufen können.
Um die Quasi-Fertigstellung meines Player Character Controllers zu feiern, habe ich mir die Mühe und endlich mal ein Video gemacht, welches ein wenig den aktuellen Stand meines Editors zeigt.
Auf YouTube kann man sich das Video in suboptimaler Qualität angucken - immerhin hat YouTube nach nur drei Anläufen überhaupt was hochgeladen und konvertiert. Vimeo hingegen hat die Bildqualität besser hingekriegt; dafür gibt es aber streckenweise merkwürdige Artefakte und der Film wird ein wenig zu schnell abgespielt.
Ich frag' mich immer, warum bei allen anderen Menschen die eingestellten Videos blendend bis in Ordnung aussehen. Bei mir hingegen nicht mal mittelmäßig. Was soll's.
Das Filmchen zeigt im Grunde nicht viel, nur, dass man Objekte erstellen, verschieben, skalieren und rotieren kann. Zudem gibt es einen Testmodus, sodass man die aktuelle Szene sofort ausprobieren kann.
Als nächstes müssen die Schwarzen bzw. Weißen Löcher eingebaut werden, dann bin ich endlich wieder ungefähr auf dem Stand von vor drei Monaten ... Allerdings werde ich mich eher erstmal an eine Erweiterung der NPCs machen. Die sollen herumlaufen (rudimentär) und natürlich angesprochen werden.
Auch wenn ich selbst nicht hundertprozentig zufrieden damit bin, habe ich mal die Geschichten, die ich speziell für mein Spieleprojekt erfunden habe, online gestellt.
Der Inhalt sind vor allem die Hintergrundinformationen und die Handlung des Spiels. Ersteres ist wichtig für denjenigen, der sich die Geschichten ausdenkt, die im Universum von "Schwere in der Schwebe" spielen; das Zweite ist wichtig für den Spieler. Und um mir selbst Vorgaben zu machen, ich welche Richtung meine Character- und Level-Designs gehen, habe ich mir auch noch verschiedene Figuren und Missionen ausgedacht.
Mein Spiel hat jetzt - rein konzeptionell - ein mehr oder weniger festes Grundgerüst, und hätte ich die Zeit, würde ich mich sofort daran setzen, es weiter umzusetzen. Aber momentan steht noch das an, was eigentlich vor dem Konzept kommt: der schriftliche Teil meiner Diplomarbeit.
Nun ist es so, dass sich das Konzept jederzeit noch ändern kann; rein aus Zeitgründen werden es aber wohl keine fundamentalen Veränderungen mehr werden. Insgesamt hatte ich beim Schreiben oft das Gefühl, mir die Geschichten förmlich aus den Fingern zu saugen, daher freue ich mich eigentlich auf die etwas "handfestere" Arbeit des Recherchierens und Erörterns.
Es fehlt jetzt, für das Konzept, noch der Teil, der sich mit dem Design beschäftigt. Obwohl ich eigentlich früher damit fertig werden wollte, ist es auch nicht schlecht, wenn sich dieser Abschnitt etwas mehr hinzieht und über mehrere Monate verteilt. Immerhin ist es der wichtigste Part, und immer mal ein bisschen Abwechslung von der ganzen Theorie wird mir gut tun.
Ein paar neue Screenshots, teilweise nichts weiter als Spielerei, im Grunde nichts spannendes.
Interessant sind v.a. das vierte und fünfte Bild. Theoretisch sollten die beiden komplett gleich aussehen - der Level (wie im dritten Screenshot zu sehen) wurde in beiden Fällen resettet und die Physiksimulation gestartet. In der Praxis hat sich gezeigt, dass Determinismus zwar auf jeden Fall vorhanden ist, aber nicht so wie erwartet: Zwei "Endstadien" (d.h. Position aller physikalisierten Objekte, sobald sie in Ruhe sind) wechseln sich bei jedem Reset ab. Warum das so ist, weiß ich allerdings nicht; und da mein Spiel von einem hundertprozentigen Determinismus nicht abhängig sein dürfte, ist es glücklicherweise nicht wirklich relevant.
Die beiden letzten Screens zeigen, was ich in diesem Monat angefangen habe: den Einbau von Figuren in den Editor. Ein Character ist stets eine Nichtspieler-Figur und als solche mit einem so genannten kinematischen Physikkörper ausgestattet. Auf diese Weise können NPCs beispielsweise nicht weggeschubst werden, ob nun direkt oder mittels geworfener Objekte.
Per Script kann man einen beliebigen Character in einen Player verwandeln, sodass dieser zur Steuerung innerhalb des Spiels verwendet wird. Der Physikkörper ist in diesem Fall nicht kinematisch - somit muss der Spieler aufpassen, dass er gefährlichen Flugkörpern ausweicht.
Damit ist das Thema Characters zwar noch lange nicht abgeschlossen, aber immerhin.
Minecraft (s. auch hier und hier) besitzt einen äußerst simplen, aber gerade dadurch irgendwie sehr ansprechenden Grafikstil. Da bekomme ich Lust, mein Spiel eventuell in einer ähnlich minimalistischen Optik zu gestalten.
Tatsächlich wurde ich schon von mehreren Leuten, die meinen Prototyp mit den Testgrafiken gesehen haben, gefragt, ob ich diesen reduzierten Grafikstil beibehalten werde. Eigentlich wollte ich dies nicht, aber je mehr Zeit verstreicht, desto mehr frage ich mich, ob ich es schaffe, neben einem funktionierenden Spiel auch noch detailreiche Inhalte zu erstellen.
Die pixeligen Texturen und die einfache Geometrie von Minecraft sehen dagegen nach einem interessanten Mittelweg aus (natürlich nur meiner bescheidenen, C64-vorbelasteten Meinung nach). Selbstverständlich würde mein Spielprojekt nicht genau so aussehen, denn ich habe ja auch einen Anspruch an Story und Characterdesign, den Minecraft als Multiplayer-Spiel nicht hat.
Sehr hübsch ist in der Hinsicht auch der Stil von LOVE. Durch den Einsatz von Posteffect-Shadern und den Verzicht auf Texturen kommt eine sehr eigenwillige Optik zustande, die ich bisher von keinem anderen Spiel kenne. Die einzige Merkwürdigkeit bei LOVE ist der Noise-Effekt, der selbst eine statische Szenerie auf unangenehme Weise unruhig werden lässt.
Insgesamt aber ein Ansatz, den ich berücksichtigen will.
Ich habe mir jetzt auf Origo ein SVN Repository für mein Projekt einrichten lassen. Das mag etwas übertrieben klingen für ein Ein-Mann-Projekt, ist aber im Grunde extrem nützlich, schon allein des Backups wegen.
Origo gefällt mir außerdem noch gut, weil man gleich einen simplen Bugtracker mit dazu bekommt, ein Wiki, einen Blog, ein Forum ... Das meiste davon werde ich verständlicherweise nicht nutzen. Das tolle aber ist, dass Origo nicht unbedingt verlangt, dass man sein Projekt Open Soure oder sonstwie öffentlich macht. Außerdem ist ein schweizerisches Unternehmen, d.h., Englisch und Deutsch sind gleichermaßen "erlaubt".
Ein SVN Repository wollte ich auch deswegen haben, weil ich jetzt zum Arbeiten in den Keller der Universität gezogen bin: Da ich es mir trotzdem nicht nehmen lasse, ab und zu daheim an meinem Projekt zu basteln, hätte ich ständig die aktuellsten Daten auf einem USB-Stick hin und her transportieren müssen. Dank SVN ist alles, was ich momentan benötige, ein Internetzugang, um mein Projekt zu synchronisieren.
Momentan sitze ich von Zeit zu Zeit an der Hintergrundgeschichte für mein Spiel. Am Anfang sah es so aus, als würde ich einfach ein paar der Fakten, die ich mir im Voraus überlegt hatte (verrückte Physik, gewisse Pflanzen als Ursache, zersplitterter Planet aus Auswirkung, schwebende Inseln, etc.) ausformulieren und zusammen bringen, ohne allzu prosaisch zu werden.
Das Problem ist, dass damit zwar einiges über die Welt gesagt wird, aber so gut wie nichts über die Bewohner und ihre Sprache, über die Zeitrechnung, das aktuelle Zeitalter und über Flora und Fauna. All dies ist aber ebenso wichtig, um eine interessante Geschichte entwickeln zu können, die konsistent ist und konform mit anderen Geschehnissen gehen.
Also ist es jetzt mein Ziel, die "Hintergrundgeschichte" nicht mehr als eine Art Abhandlung zu formulieren. Stattdessen wird es einzelne Unterkapitel mit Themata geben, die meiner Meinung nach den signifikantesten Einfluss auf eine Welt und eine darauf existierende Kultur besitzen. Momentan sind das:
Eigenart der Sprache und wichtige Bezeichnungen
Zeitrechnung und aktuelles Zeitalter
Wichtige Ereignisse im Laufe der Zeit
Landkarte der Welt
Bewohner der Welt
Flora und Fauna
Weniger wichtige, aber dennoch interessante Fakten bekommen ein Extra-Kapitel.
Update 15.10.: Ich habe die genannten Punkte jetzt fast alle untergebracht (bis auf "Sprache"), aber wie anfangs geplant in einem sehr knappen Beschreibungstext. Mir fehlt z.Zt. das Wissenschaftliche dabei; das ganze könnte jeder geschrieben haben. Würde ich mir noch mehr aus den Fingern saugen würde das diesen Eindruck noch viel mehr verstärken.
Im Großen und Ganzen brauche ich auch gar keine Hintergrundgeschichte; ein paar Fakten reichen völlig. Viel wichtiger ist jetzt eine (ebenfalls knappe) Handlung, die mich auf die zu designenden Charaktere und Levels einschwört.
Die zweite Hälfte des Konzepts ist jetzt einsehbar: die Spielelemente. Dabei handelt es sich vor allem um eine Konkretisierung der doch eher abstrakten und allgemeinen Aussagen, die unter "Spielmechanik" getroffen wurden. Letztere wurde übrigens etwas verändert und ausgebaut.
Fehlen nur noch die dritte und vierte Hälfte ... nämlich Story und Design. Bei der Story wird nochmals alles spezifiziert (z.B., wen man eigentlich spielt, und welchen Figuren man so begegnet). Das Kapitel Design behandelt natürlich Stil und Aussehen des Ganzen.
Meine TODO-Liste vom letzten Mal sieht nun so aus:
Testgrafiken erstellen- Das Konzept weiterschreiben, es fehlen
die Spielelemente,das Design, die Hintergrundstory und der Plot. - Die Stückliste muss angepasst, zudem ein Zeitplan erstellt werden.
- Der Prototyp muss erweitert werden.
Eine Gliederung für den schriftlichen Teil der Diplomarbeit muss vorbereitet werden.
Es wird so langsam.
Da dieses Tagebuch nur den praktischen Teil behandelt, werde ich die Gliederung und alles weitere, was die Theoriearbeit betrifft, wohl eher nicht online stellen.
Nach der letzten Konsultation bei meinem betreuenden Professor (bezüglich der Gliederung meiner schriftlichen Arbeit), habe ich endlich mal wieder die Muße, ein wenig zu schreiben.
Zur Zeit arbeite ich ab und zu mal an dem bereits erwähnten Ingame-Editor. Wie man auf den Screenshots sieht, kann das Verschieben, Rotieren, Skalieren von Objekten jetzt auch mittels "Gizmos" ausgeführt werden. Das Vergeben von neuen Meshes, Shapes und Materialien ist ebenfalls möglich. Nicht im Bild: Das Erstellen, Löschen und Kopieren von Gegenständen, sowie ein halbwegs funktionierendes Undo/Redo.
Im Grunde ist die Implementierung eines Editors für ein Projekt dieser Größe eigentlich sinnlos, weil unnötig zeitraubend. Andererseits muss ein Großteil der Funktionalität, die ich für den Editor basteln muss, am Ende sowieso vorhanden sein. Überdies hat es mir nochmals ein paar Ideen zum sinnvolleren Codedesign geliefert - auch wenn der Editor selbst nicht gerade sauber programmiert wird. Hauptsache, er läuft mehr oder weniger, und ich kann am Ende schnell ein paar Levels basteln. Je weniger Schritte die Pipeline bedarf, desto besser.
(Was man auf den Screenshots eventuell ebenfalls sieht: Ich habe AntTweakBar zugunsten einer einfacheren Debug-Anzeige entfernt.)
In letzter Zeit habe ich zwei (sehr gute und daher empfehlenswerte) Spiele gespielt, deren stärkstes Gameplay-Element Physik ist.
Zum einen wäre da Penumbra - Black Plague. Man spielt eine unbewaffnete Person, die ihren Vater sucht und in einen unterirdischen Komplex eingesperrt wurde. Setting und Gameplay sind sehr auf gruslig getrimmt, mit allen klassischen Elementen: permanente Dunkelheit, Rost und Dreck, Schockeffekte, Fieberträume, Stimmen im Kopf, um Gegner müssen geschlichen werden (da sie nicht besiegt werden können) und das ständige Gefühl der Einsamkeit.
Einige der Rätsel müssen mittels Physik gelöst werden. Beispielsweise kann ein Stromkasten geöffnet werden, indem man einen schweren Gegenstand aus einem anderen Raum trägt und ihn gegen die Tür schlägt. Eine andere Tür öffnet sich nur, wenn es Feueralarm gibt - also entzündet man ein Fass voll brennbarem Material durch ein Funken sprühendes Kabel und schiebt es unter die Sprinkleranlage.
Bisweilen lässt sich das Spiel leider auch auf die typischen Schalter- und Schieberätsel herab. In einem virtuellen Traum sollte ich menschliche Arme, die aus der Wand wuchsen, in der richtigen Reihenfolge aufrichten.
(Die beiden Screenshots kommen von hier.)
Das andere, in Bezugs aufs Gameplay recht ähnliche Spiel, ist Research&Development, eine kostenlose Modifikation für den Ego-Shooter Half-Life 2, die auch in dessen Universum spielt. Abgesehen von der so genannten "Gravity Gun" ist man auch in diesem Spiel unbewaffnet, sodass man sich auf Köpfchen und die Physikengine Havok verlassen muss.
Der Hauptunterschied zur Penumbra ist - neben der kürzeren Spieldauer (etwa 4 Stunden) - die Story: man steuert seine Figur durch eine Art postapokalyptische Außenwelt. Zwischendurch baut man sich sogar sein eigenes kleines Auto zusammen.
Auch wenn Research&Development als "point'n'click adventure in an FPS engine" beschrieben wird, so sind doch einige Situationen von Glück und Geschick abhängig. Zum Beispiel gibt es Stellen im Spiel, in denen Zombies mit Granaten werfen - fängt man diese nicht schnell genug auf und wirft sie zurück, muss man oft einen gespeicherten Spielstand bemühen.
(Zwei der drei Bilder stammen von diesem Blog.)
Das Interessante an den beiden Spielen ist, dass sie hauptsächlich Physik der realen Welt imitieren (wenn man mal von einigen Ausnahmen absieht, z.B. von der Wirkung der "Gravity Gun": kraftvolles Anziehen und Abstoßen von schweren Gegenständen). Das ist verständlich, weil ihre Settings unsere Welt nachahmen, und weil es auf diese Weise für den Spieler leichter ist, die meisten Rätsel zu lösen.
Daher ist es für mein Projekt wichtig, dass ich dem Spieler erläutere, WARUM die Physik plötzlich anders funktioniert (z.B. veränderte Gravitationsrichtung). Auf diese Weise sollte er stets Spielsituationen richtig bewerten können. Alles andere würde Frust erzeugen.
Da ich bis jetzt nichts über das Thema "Interface" geschrieben habe, will ich das jetzt mal nachholen. Auf dem Screenshot sieht man dabei die drei Arten an Menüs, die mich zur Zeit begleiten. Jedes der Fenster lässt sich ein- und ausblenden.
Unten links befindet sich das Hauptmenü. Es ist das einzige der drei, das später auch der Spieler zu Gesicht bekommen wird (natürlich nicht in dieser Gestalt). Momentan kann man hier vor allem die Bildschirmeinstellungen verändern. Wechselt man den Renderer (Direct3D oder OpenGL), muss man das Spiel allerdings neu starten.
Um dieses Menü anzuzeigen benutze ich Hikari, eine Bibliothek, die es erlaubt, Flash-Inhalte in OGRE darzustellen. Auf diese Weise werde ich recht einfach anspruchsvolle Menüs erstellen können.
Links oben sieht man eine Art Debug-Fenster, erstellt mittels AntTweakBar. AntTweakBar ist unabhängig von OGRE, daher war der Einbau etwas schwieriger (und ist es noch). Aber dank diesem leicht anpassbaren Fenster kann ich mir schnell und übersichtlich diverse Variablen innerhalb meines Programmcodes anzeigen lassen. Es ist sogar interaktiv, sodass ich diese Variablen auch unmittelbar verändern kann, so ich denn will.
Selbstverständlich wird das fertige Produkt dieses Fenster nicht beinhalten.
Den aktuellen Stand meines Ingame-Editors sieht man ganz rechts auf dem Screenshot. Das meiste davon ist noch Fake, aber das Darstellen und Ändern der Eigenschaften Masse, Gravitation, Position und Rotation eines ausgewählten Objektes (erkennbar an der roten Wireframe-Box) funktioniert bereits relativ problemlos. Als nächstes steht hierbei das Hinzufügen und Löschen von Objekten auf dem Plan.
Mittels dieses Menüs werde ich innerhalb der Applikation neue Level erstellen und vorhandene ohne Umwege bearbeiten können; was das Testen einer Spielsituation wesentlich vereinfachen sollte.
Natürlich müssen die eigentlichen Meshes bereits in 3D Studio Max oder einem anderen 3D-Modeller gebaut worden sein - mehr aber auch nicht.
Jetzt sollte ich aber mal aufhören, mich vor der Erweiterung und Bearbeitung meines Konzepts zu drücken ... So viel zu tun, so wenig Zeit!
Vor etwa ein, zwei Monaten war ich mal wieder im OGRE Forum unterwegs - frisch gestärkt mit meinen tollen Ideen zu Gravitation und Physikrätseln - als mir dort ein Projekt auffiel: Quanta.
Der Entwickler dieses Spiels macht nicht nur etwa dasselbe wie ich (Manipulation der Gravitation), sondern bastelt auch noch wesentlich bessere "Testgrafiken" als ich (wirklich sehr professionell).
Zum Glück geht mein Projekt in eine etwas andere Richtung, sonst würde mich dieser Fund etwas deprimieren ...
Einige Bilder zum Thema Gravitationsmanipulationen, die meisten noch mit der alten Grafik. Die Schwarzen und Weißen Löcher sind auch per LUA Scripts erstellbar, sodass das Testen inzwischen recht schnell von der Hand geht.
Denkbar wären mit diesem System auch "magnetische Objekte", die eben alle anderen Gegenstände anziehen, die sich in einem gewissen Radius zum "Magneten" befinden. Fragt sich nur, ob sich das zu einem Gameplay-Element ausbauen lässt.
Als nächstes steht leider wieder etwas theoretische Arbeit an. Das Konzept ist sehr abstrakt und muss durch die Abhandlungen bezüglich "Spielelemente" und "Design" konkretisiert werden. Außerdem möchte ich das Grundkonzept noch etwas erweitern, z.B. durch die Existenz von Parallelwelten.
Ich hab' es - schon vor einiger Zeit - geschafft, ein relativ robustes System einzubauen, mit dem ich Schwarze und Weiße Löcher erstellen kann. Das bedeutet, sollte die Spielfigur (oder ein anderes Objekt) in den Wirkungsradius geraten, wird sie von einem Punkt oder auch einer Linie angezogen.
Sieht teilweise sehr spaßig aus.
Zur Erklärung: Auf dem kleinen Bild sieht man ein Schwarzes Loch (Character wird "hineingesogen"), in dessen Zentrum eine nichtdynamische Kugel sitzt. Auf diese Weise wirkt es so, als ob die Kugel eine eigene Anziehungskraft hat.
Ich bin jetzt endlich dazu gekommen, ein paar Testgrafiken zu erstellen. Diese sind sehr einfach gehalten, beinahe texturlos mit den Hauptfarben grau (für statische Dinge) und orange (für dynamische Objekte).
Der Testlevel erhielt eine einfache Textur mit Linien, die dazu geeignet sind, Maßstäbe richtig zu erkennen. Dadurch, dass die UV-Koordinaten des Levels zusätzlich noch auf einen Meter genormt wurden, kann ich Entfernungen und Relationen viel besser einschätzen.
Die Objekte, die zum Testen der physikalischen Eigenschaften dienen (Kisten, Kugeln, Kapseln, Zylinder) sind leicht aufgemotzte Grundkörper. An ihnen muss vor allem sofort die Position und Rotation erkennbar sein.
Ich habe mit Absicht etwas Zeit in diese Ästhetik gesteckt, damit zukünftige Screenshots einfach "hübscher" sind. Der theoretische Teil des Diploms sollte nämlich auch Bilder aus dem Prototypen haben, damit ich bestimmte Konzepte besser veranschaulichen kann. Und es wäre ziemlich unvorteilhaft, wenn diese zu sehr nach "Programmer's Art" aussehen würden, wo doch schon mein Prototyp sehr nach "Designer's Coding" aussieht.
Mit leichten Zweifeln im Hinterkopf habe ich mal die erste Hälfte des Konzepts hochgeladen: das Gameplay. Die Zweifel rühren daher, dass ich das Gefühl habe, ein Spiel beschrieben zu haben, dass sowieso schon längst existiert. Auf der anderen Seite ist mir aber auch klar, dass ich im Grunde gar kein völlig neues Spiel mit lauter Innovationen basteln möchte, nicht in diesem Fall.
Logisch ist allerdings, dass das Konzept keinesfalls endgültig ist. Bis zum Ende des Projekts werden noch jede Menge Änderungen ihren Weg in den Text finden. Zumindest hoffe ich das.
Die nächsten Schritte sehen in etwa so aus:
- Testgrafiken erstellen (Modelle, Texturen) - damit ich ansehnlichere Screenshots erstellen kann. Die Testgrafiken sollten simpel sein, von daher ist ein karikierender Stil wahrscheinlich.
- Das Konzept weiterschreiben, es fehlen die Spielelemente (Definitionen der Charaktere, Power-Ups, Level, etc.), das Design, die Hintergrundstory und der Plot.
- Die Stückliste muss angepasst, zudem ein Zeitplan erstellt werden.
- Nebenbei muss der Prototyp erweitert werden. Bis zum Beginn des praktischen Teils der Diplomarbeit im Februar will ich ein halbwegs funktionierendes Framework haben, bei dem ich nur noch Anpassungen machen muss.
- Der schriftliche Teil muss vorbereitet werden. Daher muss ich mir den eigentlichen Inhalt und eine Gliederung überlegen.
Uff.
Wie in jedem Prototypen, den ich bisher erstellt habe, ist die Frage nach einer gefälligen Kamera eine besonders wichtige. Wie schon geschrieben, habe ich es mir etwas leichter gemacht, indem ich es mir schwerer gemacht habe: anstatt nur Ego-Perspektive oder nur Third-Person-Perspektive einzubauen, ist bis jetzt beides implementiert. (Zusätzlich gibt es noch ein Debug-View-Modus, der ähnlich der Steuerung von 3dsmax funktioniert.)
Da sich die grundlegende Steuerung in beiden Modi nicht sonderlich unterscheidet (die Figur bewegt sich mit denselben Tasten), ist es auch gar nicht so kompliziert, zwischen beiden zu wechseln.
Hier mal eine grobe Darstellung des aktuellen "Character Controllers". Er besteht (auf Physikseite) vor allem aus einer stets aufgerichteten Kapsel (B), an dessen unterem Ende ein Raycast dafür sorgt, dass eine gewisse Distanz zum Boden gewahrt wird (gut für Treppen und Schrägen). An der Kapsel hängt (auf Grafikseite) ein unsichtbarer Node (C), an dem sich wiederum das Mesh der Figur (A) ausrichtet. Außerdem kleben - vereinfacht gesagt - an (C) mehrere Dummys auf Augenhöhe (D), die die Rotation und Position der Kamera regeln. Am hierarchisch gesehen letzten dieser Dummynodes schlußendlich ist die Kamera geheftet, welche je nach Perspektive entweder direkt in der Kapsel steckt, oder sich hinter der Figur befindet. Wenn zweiteres der Fall ist, prüft ein permanenter Test auf seiten der Physik, ob sich zwischen Figur und Kamera ein Hindernis befindet (z.B. eine Wand). Die Kamera wird dann gegebenenfalls nach vorne geschoben.
Diese Beschreibung ist grob vereinfacht. Tatsächlich gibt es noch einige "Zwischendummynodes", die dafür sorgen, dass die Bewegungen der einzelnen Hauptnodes nicht zu abrupt wirken. Außerdem ist in der Third-Person-Perspektive ein Dummy wichtig, der eine weiche Drehung regelt, wenn der Spieler seitwärts oder rückwärts läuft (dafür gibt es keine eigenen Animationen, stattdessen drehe ich die Spielfigur einfach).
Es ist ziemlich wahrscheinlich, dass sich an meinem System noch so einiges ändern wird. Vor allem die Konstruktion aus Kapsel und Raycast ist sehr fragwürdig, aus zwei Gründen. Erstens rutscht die Spielfigur an Kanten zu schnell ab (da sie ja nur auf einem einzelnen Punkt steht), zweitens springt der Spieler sehr oft - besonders in Kombination mit Gravitationsänderungen - stark in die Höhe.
Bleibt die Frage, ob sowohl Ego-Perspektive als auch Verfolger-Perspektive am Ende erhalten bleiben. In Bezug auf das Model der Spielfigur verdoppelt sich der Aufwand fast, zumal sich nicht wenige Animationen unterscheiden werden, beispielsweise muss in der Ego-Perspektive dennoch eine Animation für Seitwärts- und Rückwärtslaufen erstellt werden. Schlimmstenfalls verzichte ich einfach ganz darauf, ein Mesh darzustellen, wenn man sich in der Ego-Perspektive befindet.
Eventuell machen einige Physikrätsel nur Sinn in der einen, andere wiederum nur in der anderen Perspektive. Der andere Grund dafür, warum ich zögere mich für eines von beiden zu entscheiden, ist, dass die Spielbarkeit insgesamt vielleicht leidet, wenn man nur eine Sicht-Option besitzt. So oder so ist noch viel Testerei nötig.
Zur Zeit bin ich dabei, ein ausformulierteres Konzept zu erstellen. Dabei stieß ich unweigerlich auf die Frage, wie denn der Protagonist, d.h. die Spielfigur, aussehen soll.
Aber das Aussehen ist ja noch das Nebensächlichste. Will ich einen coolen Character, der permanent einen derben Spruch auf Lager hat? Oder soll es eine naive junge Frau sein, die die Umgebung erkundet? Vielleicht ein undefinierbares Alien mit Roboterarmen und Rädern? Ist man eher gutherzig, eher böse?
Eine andere Möglichkeit wäre ja, den Spieler mittels Konfigurationsmenü selbst entscheiden zu lassen. Allerdings halte ich das für zuviel Aufwand (auch wenn mir das etwas Verantwortung abnehmen würde), und vor allem für ein Spiel dieser Konzeption unpassend. In dem Rollenspiel "The Elder Scrolls 3: Morrowind" ist es äußerst sinnvoll, keinen vordefinierten Protagonisten zu haben, da bei diesem Spiel der Nutzer in seinen Entscheidungen generell sehr frei ist, und eine beliebige Rolle ausfüllen darf.
Aber bei einem linearen Jump'n'Run ist Individualisierung schlicht sinnfrei. Mir persönlich hat es schon weder bei "Arx Fatalis" noch bei "Deus Ex" (beides Actionspiele mit Rollenspiel-Elementen) irgendetwas gebracht, zwischen fünf Köpfen entscheiden zu können - der spielerische Mehrwert hielt sich doch arg in Grenzen.
Bei einigen Spielen kann man sich auch zwischen Mann und Frau entscheiden, beispielsweise bei "Star Trek: Voyager - Elite Force" (wo man sich etwas Mühe gespart hat, indem man den Spieler "Alex" getauft hat) oder auch bei "Deus Ex: Invisible War" (bei dem interessanterweise auch Nebencharaktere je nachdem ihre Persönlichkeit wechselten). Auch hier sehe ich nur bedingt einen echten Mehrwert; an mir selbst konnte ich jedenfalls nicht beobachten, dass ich mich mit einem männlichen Charakter mehr identifizieren kann als mit einem weiblichen. Da spielen andere Sachen eine Rolle, vor allem glaubwürdige Handlungen der Spielfigur.
Wie dem auch sei. Ich werde die Spielfigur wohl fest definieren, in derselben Art, wie man sie bei "Thief" oder "Outcast" vorfindet. Dort steuert man sehr markante Persönlichkeiten, die bestimmte Situationen auch gern mal sarkastisch kommentieren.
Man könnte den Spieler auch eine zwar äußerlich vorgeschriebene, aber innerlich "leere" Figur steuern und sie mit Leben und Persönlichkeit füllen lassen. Bis zu einem gewissen Grad gibt es das bei "System Shock" oder "Half-Life" (beides sehr gute Spiele). Aber als Designer würde ich momentan doch gern einen echten Charakter kreieren, auf den (eventuell vorhandene) andere virtuelle Personen reagieren.
"Deus Ex" hat übrigens die Handlungen des Spielers analysiert und je nachdem einige Dialoge angepasst. Ist man beispielsweise im ausufernden Explorationsdrang auch mal in die Frauentoilette gelaufen, wird dies vom Chef später mit gerümpfter Nase angemerkt. Das ist ein tolles, weil überraschendes Feature - aber bedeutet leider auch ziemlichen Mehraufwand.
Es ist fast schon peinlich, wie einfach es war, nullsquareds SSAO Compositor einzubauen. Anfangs hatte ich ein paar Probleme (siehe erster Screenshot), die aber schnell beseitigt werden konnten - auch dank der Beiträge in dem verlinkten Thread. (Compositors sind übrigens so eine Art Post-Effects in OGRE.)
Der SSAO (Screen Space Ambient Occlusion) Effekt ist nicht hundertprozentig korrekt, an bestimmten Stellen verschwindet der Schatten einfach oder es kommt zu einem Flimmern - aber so oder so haben die Objekte gleich viel mehr Tiefe und vor allem Bezug zu ihrem Untergrund. Den Unterschied zwischen ausgeschaltetem und eingeschaltetem SSAO sieht man auf dem zweiten und dritten Screenshot.
Hoffentlich wird das nicht die einzige Art an Schatten im Prototypen bleiben. PSSM (Parallel-Split Shadow Maps) wären noch sehr gut, vor allem für die angedachten Außenlevel.
Es bereitet zur Zeit einfach nur kindliche Freude, durch mein eher unattraktives Testlevel zu rennen und per Tastendruck unterschiedlich große Kisten und vor allem Kugeln zu erstellen. Die Begeisterung über Kugeln, die Abhänge, Kanten und Schrägen hinunterrollen ist ebenso ungebrochen wie die beim Umherschieben von mehreren Kisten gleichzeitig.
Mein Fazit, begünstigt durch die Maxime "es soll Spaß machen": Egal wie, aber es müssen Kugeln und Kisten ins Gameplay. Für einen wahren ball pool reicht die Performance aber vermutlich nicht.
"Psychonauts" (2005) ist ein sehr unkonventionelles Spiel. Ich kenne nur die Demo-Version (deren Gameplay mich leider eher abschreckt), aber das Level "The Milkman Conspiracy" fasziniert mich immer wieder - schon allein die Art und Weise, wie dank der verwirrenden physikalischen Eigenschaften die Umgebung den Hintergrund bildet, ist hochgradig inspirierend.
Nebenbei bemerkt ist es trotz meiner persönlichen Abneigung sehr traurig, dass das Spiel "Psychonauts", entwickelt vom bekannten Designer Tim Schafer, kein großer Erfolg gewesen ist.
Eine der Inspirationen für meine Spielidee ist ein uraltes Videospiel von 1996 für die Playstation 1: "Jumping Flash". Selbst habe ich es nie gespielt, aber mein Bruder besitzt beide Teile.
In "Jumping Flash" steuert man eine Art riesigen Roboterhasen, der verschiedene schwebende Inseln bereist und sie von bösen Mächten befreit. Das geschieht, indem man bestimmte Objekte einsammelt, die ihrerseits auf kleineren schwebenden Inseln liegen. Über den speziellen Sinn dahinter werde ich jetzt nicht diskutieren, es ist eben ein japanisches Spiel ...
Ich fand vor allem die dargestellte Welt, und die Art und Weise, wie man sie erkundet, sehr schön. Man kann einen Mehrfachsprung ausführen und so die Inseloberfläche aus einem gefühlten Kilometer Entfernung betrachten. Die Detailfülle fand ich damals sehr beachtlich, und auch die Gesamtpräsentation fühlte sich einfach sehr stimmig an. Ein ähnliches Spielgefühl zu erreichen wäre nett, aber vermutlich nicht ganz das, was zu meinem Spiel passen würde; das Nachdenken hat in diesem eher actiongeladenen Titel nicht so viel Platz.
Leider findet man kaum annehmbare Screenshots von dem Titel.
Nicht unwichtig ist es übrigens, Tools zu haben, die einem nervige Aufgaben abnehmen - darum habe ich mir innerhalb von ein paar Tagen dieses kleine Tagebuch-System in PHP programmiert. Etablierte Systeme (z.B. Wordpress) schienen mir zu aufgebläht für meine Zwecke. Und bei den Wikis, wie Jana und ich sie früher verwendet hatten, vermisste ich teilweise einige Funktionalitäten.
Zugegebenermaßen habe ich nicht wirklich nach brauchbaren Alternativen gesucht. Meine PHP-"Fähigkeiten" zu erweitern schien mir ein interessantes Nebenprojekt. Sollte ich Vergleichbares aber jemals wieder basteln wollen, würde ich mir vermutlich auch mal MySQL aneignen.
Ein frühes Testlevel wurde in den Prototypen eingebaut, und auch gleich mal ein Testcharacter. (Die Figur stammt aus Omertà.) Wichtig ist erst einmal, herauszufinden, welches Terrain welche Physikrätsel begünstigt bzw. welche Physikrätsel welches Leveldesign benötigen.
Momentan kann der User die Taste G drücken und verändert damit seine persönliche Gravitation. Insgesamt hat das schon jetzt einen sehr eindrucksvollen Effekt, wenn man plötzlich auf der Wand läuft, und Kugeln und Kisten so aussehen, als ob sie verrückt spielen, da sie - natürlich aus Sicht des Spielers - seitwärts fallen ...
Weiterhin ist es möglich, zwischen Ego- und Third-Person-Perspektive zu wechseln. Da ich mir selbst noch unsicher bin, welchen Blickwinkel ich verwenden werde, hilft mir diese Funktion, Situationen in dieser Hinsicht sofort testen zu können.
Wie bei jedem Projekt fängt alles erstmal mit Kisten, Quadern und Boxen an. Vornehmliches Ziel zu Beginn war der Aufbau eines relativ einfach erweiterbaren Frameworks.
Dazu muss vor allem die Kommunikation zwischen Grafik- und Physik-Engine reibungslos funktionieren, aber auch Sachen wie Eingabe, (grafisches) Interface und später einmal Musik und Sound sollten klar voneinander abgetrennte und gegliederte Aufgabenbereiche sein, damit innerhalb des Programms kein Chaos entsteht. Ich arbeite hierbei vor allem darauf hin, den Wust an Programmzeilen noch in einem Jahr verstehen zu können ...
Auf den Screenshots sieht man vor allem, wie der OGRE (das Fundament für die Grafik) letzten Endes einfach nur das darstellt, was Bullet (die Physik-Engine) ihm vorgibt. Die Linien sind hierbei Interna von Bullet - solange sie synchron sind zu den dazugehörigen Meshes, ist auch alles in Ordnung.
Als nächstes: Zeit für etwas Interaktion!
Um meinen Betreuern (und letzten Endes auch mir selbst) meine Spielidee richtig vermitteln zu können, habe ich diese PDF (1,66MiB) mit Eckdaten, Vorüberlegungen, Skizzen und Zielsetzungen erstellt.
Da für mich, zumindest bei der anfänglichen Planung des Projekts, das Gameplay an erster Stelle steht, habe ich mir erstmal nur interessante Fähigkeiten für den Spieler überlegt.
- So könnte er Gegenstände in die Luft werfen, im richtigen Moment die Zeit anhalten, und auf diese Weise den Gegenstand als Plattform benutzen, um einen Abgrund zu überwinden. Dies war übrigens die erste Idee, die ich hatte, und mit der mein Diplomprojekt geboren wurde.
- Auch könnte es Portale geben, die den Gravitationsvektor des Spielers verändern.
- Oder aber er würde die Fähigkeit erhalten, sich in eine Kugel oder ähnliches zu verwandeln, um einen Abhang runterzurollen.
All dies sind nur sehr frühe Ideen, die sich erst noch als sinnvoll erweisen müssen.
Meine Vision der Spielwelt beinhaltet vor allem schwebende Inseln. Diese sind früher ein einziger Planet gewesen, der aber durch sonderbare (man könnte sagen: magische) Pflanzenzüchtungen in viele kleine Teile explodiert ist.
Besagte Pflanzen sind nun überall zu finden; diese kann der Spieler nutzen um diverse Fähigkeiten erlangen, z.B. die Manipulation des eigenen Gravitationsvektors.
Die Handlung des Spiels selbst würde nun folgendermaßen lauten: Man heuert auf einer Art Postkutsche an (die natürlich eine fliegende Insel ist) und arbeitet sich langsam nach oben, indem man verschiedene Missionen bewältigt.
Hier ein paar meiner frühesten Zeichnungen in Bezug auf Charaktere. Sie sind entstanden, als mir selbst noch nicht klar war, ob und wie ich denn Figuren im Spiel einbauen würde. Sicher, einen Protagonisten wird es auf jeden Fall geben - selbst wenn das Spiel tatsächlich rein in Ego-Perspektive gespielt werden würde. Aber ob der Spieler auf NPCs (Non-Player Characters) treffen wird, weiß ich noch nicht.
So oder so aber ist das Zeichnen von Charakteren sehr gut, um sich selbst das Setting vorstellen zu können. Eine schöne Idee war da die Figur, die statt dem Kopf einen Vogelkäfig auf dem Hals haben würde - der Vogel darin würde dann das Sprechen übernehmen. Das ist auf jeden Fall ein Einfall, den ich ausbauen werde.
