Bachelor's Game
Langsam rückt sie näher: die Bachelor-Ausstellung der ZHdK – und damit der Abgabetermin meiner Bachelorarbeit. Noch gibt es einiges zu tun – aber bis dahin kann ich ja schon mal einige Informationen streuen.
- Die Ausstellung ist vom 10. bis 18. Juni 2011 täglich von 12–20 Uhr offen.
- Der Eintritt ist frei.
- Die Arbeiten in Game Design sind an der Aussstellungsstrasse 60, Zürich im dritten Stock (Raum 306) ausgestellt.
- Vernissage ist am 9. Juni, um 17 Uhr.
- Während der ganzen Ausstellung machen jeweils zwei der Bachelor-Studenten die Aufsicht. Man darf sie gerne ansprechen, wenn man nicht weiterkommt, oder nicht weiss, wie ein Spiel funktioniert.
Ich persönlich werde anwesend sein am:
- Freitag, 10. Juni, 16–20 Uhr
- Sonntag, 12. Juni, 12–16 Uhr
- Dienstag, 14. Juni, 16–20 Uhr
- Mittwoch, 15. Juni, 12–16 Uhr (neu!)
- Samstag, 18. Juni, 12–17 Uhr
Diese Liste wird laufend aktualisiert, wenn sich Änderungen ergeben sollten.
Tweet-Up
Twitterer aufgepasst: Janina und ich organisieren am 10. Juni ein Tweetup in der Ausstellung. Wer eine exklusive Führung will: Anmelden!
Noch viel mehr Informationen, Screenshots, Videos, Blogposts, Skizzen zu den ausgestellten Arbeiten finden sich auf unserer gemeinsamen Facebook-Page zur Ausstellung.
Das Wichtigste ist gemacht: die Partikel sind nun am richtigen Ort, werden zur richtigen Zeit angezeigt und verhalten sich für jeden Charakter ein bisschen anders. Schliesslich weiss man ja: Partikeleffekte machen 80% des Game-Design-Prozesses aus …
Wenn man den Spass mal beiseite lässt, so kann man zusätzlich bemerken, dass die meisten UI-Elemente inzwischen auch am richtigen Ort sind und das Dialogsystem ebenfalls funktioniert. Wieder.
Moment. Wieso "wieder"?
Weil, was ja irgendwie vorherzusehen war, ich die halbe Prompter-Klasse, die für das Dialogsystem zuständig ist, noch mal neu geschrieben habe. Nicht ganz ohne Grund. Denn ein wichtiger Teil meiner Arbeit diese Woche war, das letzte und endgültige Puzzleteil meines Emotionalen Modelles einzubauen: die Fähigkeit, die Reaktionen eines Spielers zu speichern und später wiederzugeben.
Coping Scheme Record/Replay System
Wie finde ich heraus, wie sich jemand gegenüber anderen verhält? Dies ist die Grundlage dieses Subsystems. Ich habe mich entschieden, zwei Achsen zu verwenden – eine möglicherweise zu vereinfachende Sicht, aber ich denke, dass sich beim Testen schnell herausstellen wird, ob diese beide Angaben genügen.
Die erste Achse ist die Empathie. Ein Agent kann sich eher mit-fühlend oder aber irritiert zeigen (und damit unfähig, die Gefühle des anderen zu verstehen). Die zweite Achse ist der Ton1. Dieser drückt aus, wie aggressiv oder defensiv die Aussage ist. Greift sie jemand anderes an oder ist sie zur Verteidigung da?
Die Aussagen besitzen in den meisten Fällen diese beiden Werte als Meta-Daten.
-
Möglicherweise ist dieser Ausdruck nicht nicht sehr präzise gewählt. Mir fiel jedoch zu der Zeit kein besserer ein, weshalb er geblieben ist. ↩
Eigentlich hätte ich das schon früher machen müssen (sagt man sich immer, natürlich). Tatsache ist wohl, dass ich mir angewöhnen müsste, auch scheinbar grosse Arbeiten einfach beginnen zu erledigen – oder sie zumindest konsequent in kleinere Aufgaben herunterzubrechen.
Jetzt aber steht einer der wichtigeren Teile meines Spiels: die Visualisierung der Emotionen der Spielerfigur – und damit das Element des Spiels, das einen grossen Anteil am endgültigen Aussehen des Spiels hat.
Jede der Figuren hat dabei eine eigen Visualisierung. Im Falle von Perry, der ersten Figur, die vom Spieler gespielt wird, gibt es noch keine konkreten Formen. Der Spieler soll an das Prinzip zuerst herangeführt werden, ohne dass er visuell gleich überwältigt wird. Das Spiel wird also zu Beginn aussehen wie jedes 3D-Spiel – bis der Spieler ein leichtes farbliches Wabern bemerkt, das ihn darauf hinweisen sollte, dass bei diesem Spiel nicht ganz alles wie bei einem "normalen" Spiel ist.
Spätestens zum Zeitpunkt, da er Luna spielt, sollte ihm das aber klar werden. Hauptfarbe von Luna ist Grün, und bei ihr tauchen deutlich Blumen auf.
Ähnliches gilt auch bei Thorin. Sein Thema ist das All, das auch bei seiner Visualisierung in der Form von Galaxien und Sternen auftaucht.
In beiden Fällen ist die Visualisierung ein Blick in die Gedankenwelt der Figuren – sie sind umgeben von dem, was ihnen wichtig ist.
Technisch basiert die Visualisierung auf den drei Achsen der Personal Emotion: Agitation, Evaluation und Control. Evaluation wird für die Färbung des Hintergrundes verwendet.
Noch knapp vier Wochen, und ich werde etwas abliefern müssen – etwas, das zumindest den Anschein macht, als wäre es ein Game. Wie vorauszusehen war, beginnt mir die Zeit langsam davonzulaufen. Ich musste also die vergangene Woche mal wieder meine Ansprüche zurückschrauben: In Rücksprache mit meinen Mentoren habe ich mich entschieden, die Figuren nicht zu modellieren und zu animieren, sondern bloss Billboards zu erstellen. Die zugrundeliegende Idee sollte damit trotzdem sichtbar werden – wenn auch mit etwas weniger grafischem Aufwand. Natürlich wurmt es mich ein bisschen, dass ich damit meine Modellier-Künste nicht unter Beweis stellen kann – aber die Tatsache bleibt: Die Zeit dazu habe ich schlicht nicht.
Nichtsdestotrotz habe ich mich entschlossen, die vergangene und kommende Woche mit der Arbeit an der Grafik zu verbringen: schlussendlich sieht man am Ende besser, wenn etwas visuell nicht da ist (oder schlecht gemacht ist), als wenn etwas nicht so toll programmiert ist wie es sein könnte (und damit meinen Ansprüchen genügen würde).
Aus diesem Grund habe ich mir die verschiedenen Elemente vorgenommen, die ich in der Zwischenzeit produziert habe, und diese noch einmal verbessert und verfeinert.
Das Modell des Innenhofes hat nun überall Eingänge und Fenster, die in die Wohnungen führen. Zusätzlich habe ich Pseudo-Modelle erstellt, die dazu da sind, diese Eingänge zu verschliessen, wenn dahinter nicht wirklich eine begehbare Wohnung liegt.
Manchmal sind es die kleinen Dinge, die nicht so recht von der Hand gehen wollen. Kleine Dinge wie etwa eine Fall-Off-Funktion, die mir vorschwebte: Die Emotionen sollen nicht einfach bestehen bleiben, sondern nach einer gewissen Zeit langsam wieder zurück zu einer neutralen Position gehen. Niemand ist über längere Zeit extrem sauer oder ungeheuer glücklich, in den meisten Fällen pendelt sich das wieder ein. Dasselbe sollte auch für meine Beziehungen zu anderen Menschen gelten.
Was sich so einfach anhört, ist dann schlussendlich doch ein bisschen komplizierter zu bewerkstelligen als gedacht, vor allem auch, wenn es zusätzlich darum geht, dass der Spieler eine mehr oder weniger genaue Rückmeldung bekommen soll, was gerade abläuft. Und natürlich zusätzlich auch noch darauf geachtet werden soll, dass diese Prozesse möglichst ressourcenschonend programmiert werden sollten.
Konkret heisst das, dass die visuelle Darstellung ändern muss, sobald ein gewisser Grenzwert erreicht ist. Solange ich aber den Wert nicht jeden Frame abfragen will, muss ich einen anderen Weg finden, einen solchen Wechsel auszulösen.
Da ich nun endlich herausgefunden habe, wie Events in C# funktionieren, habe ich mich entschlossen, dieses Problem mit Events zu lösen. Sobald etwas "interessantes" passiert, kann ich nun einen Event auslösen, der in der Folge einen Wechsel initiiert. Damit habe ich nun das erwünschte erreicht – trotzdem hat dies fast eine Woche gedauert (was eigentlich viel zu lange für eine solche Problemstellung ist).
Ansonsten ist leider nicht sehr viel passiert. Zeit, in den Endspurt zu gehen!
An die Level-Architektur werden verschiedene, sehr gegensätzliche Anforderungen gestellt.
Geschlossenheit
Zum einen muss es einen in sich geschlossenen Raum definieren – als ein Serious Game gibt es kein Budget, das eine Open-World-Architektur erlauben würde. Das Level muss also einen Ort darstellen, der in sich bis zu einem gewissen Grad in sich abgeschlossen ist, so dass der Spieler nicht zu schnell merkt, wie wenig "Freiraum" ihm eigentlich gegönnt ist. Je weniger Ein- und Ausgänge es gibt, die künstlich verschlossen werden müssen, um so besser.
Offenheit
Gleichzeitig muss das Level-Design auch offen sein – schliesslich sollen in der Umgebung verschiedenste Situationen ermöglicht werden, dabei darf das Level nicht "in den Weg" kommen, indem es allein durch sein Aussehen oder Verortung des Geschehens gewisse Situationen ausschliesst.
Erweiterbarkeit
Dies ergibt sich aus dem momentanen Entwicklungsprozess: Da ich bis zum Bachelor-Abgabetermin nicht ein komplettes Spiel abgeben kann, muss ich ein Level bauen, das zwar die Möglichkeiten aufzeigt, was darin geschehen könnte – ohne diese aber vollständig auszuschöpfen. Um zukünftige Erweiterungen möglich zu machen, muss ich Anschlussstellen einplanen, die ich später verwenden kann, um weitere Figuren, Geschichten oder Handlungsräume zu eröffnen.
Realisierung
Der Handlungsort des Spiels ist nun ein städtischer Wohnblock. Um einen Innenhof sind die Wohnungen gruppiert, die über Galerien zu erreichen sind.
Über den Mechanismus der Wohnungen ist es möglich, praktisch beliebig viele Figuren hinzuzufügen – wird eine neue Figur gebraucht, öffnet sich einfach eine neue Tür zu einer Wohnung, die in der Folge besucht werden kann.
Natürlich – zu planen, dass man innerhalb von knapp einer Woche es schafft, ein komplettes 3D-Level und zusätzlich drei Charaktere modellieren zu wollen, muss verrückt sein. Anscheinend bin ich es – denn nichts anderes hatte ich geplant.
Dem kam jedoch mein Perfektionismus zuvor: natürlich konnte ich nicht einfach mit dem Modellieren des Gebäudes beginnen – da musste zuerst ein Plan her (-1 Tag). Danach konnte mit Modellieren begonnen werden – und nach einem Tag stand das Grundgerüst. Bloss kann man es natürlich auch noch richtiger machen, als man es schon hat (-1 Tag). Und wenn man schon dabei ist, das Gebäude in Unity zu testen, kann man ja auch gleich noch den Baum erstellen, der im Hof steht (- 1/2 Tag). Und dann das Treppenhaus machen (was wieder eine Sache für sich selbst ist, und auch etwa einen Tag dauert).
Die Charaktere sind also immer noch nicht gemacht – daran werde ich mich nun die nächste Woche daran setzen müssen. Mal abgesehen von der Tatsache, dass ich nun noch um einiges mehr Zeit werde investieren müssen, um etwas zu produzieren, das meinen Ansprüchen genügt ...
Nichtsdestotrotz glaube ich, dass das Resultat doch einigermassen ansehlich ist – und hoffentlich auch funktionieren wird ...
Nach dem letzten Eintrag mit Überlänge gibt es dieses Mal nur ein kurzes Update.
Nach gut einer Woche des Rumprobierens steht das Emotions-System nun einigermassen.
Es ist nun möglich:
- Den Dialog-Optionen Meta-Daten über den emotionalen und Informationsgehalt mitzugeben.
- Diese Meta-Daten auszulesen, und vom Charakter interpretieren zu lassen – mit der Möglichkeit, dass jeder Charakter anders reagieren kann.
- Dass Charaktere, die in "Hörweite" sind, den Informationsgehalt der Aussage "mithören" und darauf basierend ihre Einstellung zum Sprecher verändern.
- Einem Charakter eine emotionale Basis-Ausrüstung auf den Weg zu geben – damit wird es in Zukunft auch möglich sein, diese Informationen zu speichern und wieder von der Festplatte zu lesen, und damit sein Verhalten wiederherzustellen.
Noch nicht implementiert sind folgende Dinge:
- Coping Scheme Record/Replay Subsystem: Noch werden die Aktionen des Spielers nicht aufgezeichnet und wiedergegeben.
- Fall-Off: Die Emotionen sind im Moment noch fix und noch nicht von der Zeit abhängig.
Auch das System, dass die Emotionen eines Charakters dem Spieler angezeigt werden, ist mehr oder weniger da – mit einer gewichtigen Ausnahme: noch reagiert es nicht sofort auf Änderungen der Werte. Gerade dies wäre aber wichtig, um dem Spieler wertvolles Feedback zu geben. Hier werde ich noch daran arbeiten müssen.
Die nächste Woche wird sich aber vorerst ausschliesslich um die Assets drehen: sowohl der Innenhof, in dem das meiste spielt, sowie ein bis zwei Charaktere müssen entstehen, sonst stehe ich am Ende zwar mit tollem Code hier, aber keinem Spiel …
Das Emotionsmodell ist wahrscheinlich der komplizierteste Teil des Spiels. Das erklärte Ziel ist, Figuren zu gestalten, die emotional auf verschiedenste Inputs reagieren. Das Problem besteht natürlich darin, dass Menschen nicht notwendigerweise vorhersehbar reagieren – oder, um es mit einem Song von Björk auszudrücken: "If you ever get close to a human being, get ready to get confused".
Das Emotionsmodell ist ein Versuch, diese Unvorhersehbarkeit in geordnete Bahnen zu lenken und in Zahlen auszudrücken.
Eine Recherche hat hierbei schnell ergeben, dass auch die Wissenschaft nicht sehr viel besser mit Emotionen auskennt. Eine Suche nach "Grundemotionen" führt etwa auf Wikipedia, die verschiedene Listen anführt, die zwischen 8 und 48 Elemente enthalten.1 Dies drückt sich dann auch aus in der Tatsache, dass der Vorschlag des World Wide Web Consortiums für einen XML-Standard zur Kodierung von Emotionen nicht ein fixes Vokabular vorschreibt, sondern die Möglichkeit bietet, verschiedenste Vokabulare einzubeziehen2 (dies im Gegensatz zum Vorläufer HUMAINE, das noch eine solche fixe Liste implementierte3).
Okay, dieser Titel ist natürlich in höchstem Masse gesucht – aber schlussendlich habe ich doch vor allem an den Triggern gearbeitet.
Zum einen ging es darum, dem Spieler eine Möglichkeit zu geben, mit seiner Umwelt zu interagieren. Dies wird nun ermöglicht, indem die Objekt anzeigen, was mit ihnen gemacht werden kann, wenn man sich ihnen genügend nähert.
Eine erste Version dieses Scripts erlaubte dabei nur eine einzige Aktion durchzuführen (was in den meisten Fällen auch ausreichen wird); eine erweiterte Version des Scripts erlaubt es nun aber auch, einem Objekt mehrere Aktionen zu geben, die ausgeführt werden können.
Dies scheint auf den ersten Blick wenig zu sein – tatsächlich habe ich aber diese Woche noch ein erstes Treppenhaus modelliert; sowie begonnen, Skizzen der Umgebung zu machen, wie sie dann modelliert werden soll (was, ironischerweise, schon bedingt, dass ich das Treppenhaus noch einmal etwas umbaue).
Die nächste Woche wird sich vor allem darum drehen, eine erste rudimentäre KI für die Agenten zu bauen, sowie möglicherweise verschiedene andere Aspekte des Codes aufzuräumen und für die weitere Arbeit vorzubereiten.
Eine Fixierung des Settings sowie eines Emotions-Modells wird ebenfalls nächste Woche statt finden – deshalb gibt es diese Woche nicht viel theoretischen Hintergrund. Das meiste wird in einer Woche folgen.
Nach einer doch eigentlich erfolgreich verlaufenen Präsentation diese Woche, wo ich vor den Kommilitonen meine Fortschritte vorgestellt habe, und dabei eigentlich feedbackmässig nicht allzu schlecht weggekommen bin, habe ich den Rest der Woche vor allem darauf verwendet, am visuellen Stil zu arbeiten. Hätte sich dieser als nicht machbar erwiesen, hätte da schleunigst noch ein neues Konzept her müssen. Glücklicherweise scheint dies nicht der Fall zu sein.
Particles
Dank der Hilfe von Mario von Rickenbach, der mir freundlicherweise die Scripts gegeben hat, die einen möglichen Weg für Compositing und Blendung in Unity aufzeigten, konnte ich ein System aufbauen, mit dem ich das Aussehen des Levels komplett umfärben kann.
Im Moment arbeite ich mit verschiedenen Layers, die von eigenen Kameras aufgenommen werden, und dann mit einem Composite-Shader zusammengerechnet werden. Die Layer sind im Moment folgendermassen aufgebaut:
- Layer 1: Farbe für Weiss (färbt alle hellen Stellen des Levels ein)
- Layer 2: Farbe für Schwarz (färbt alle dunklen Stellen des Levels ein – damit kann ich z.B.
Dialog-System
Das Ziel der letzten beiden Wochen – das Dialogsystem – ist nun effektiv fertiggestellt und funktionsfähig, wie das folgende Video zeigt.
XML oder Plain Text?
Nichtsdestotrotz war ich schon wieder drauf und dran, das gesamte System über den Haufen zu werfen.
Während des Debuggens des System fiel mir auf, wieviele Calls ausgelöst werden, um bloss ein Attribut oder ein Element zu finden. Was praktischerweise in einer Methode verpackt ist, ruft im Hintergrund einen ganzen Rattenschwanz an anderen Methoden nach sich, bis schlussendlich das gewünschte Objekt zurückgegeben wird. Es ist also am Ende kein Wunder, dass bei der Game-Programmierung oft weiterhin reine Text-Files verwendet werden: sie sind um einiges ressourcenschonender zu verarbeiten.
Angesichts der Tatsache, dass mein Spiel auch in der Schule gespielt werden soll, wo ich nicht mit Computern rechnen kann, die besonders schnelle Prozessoren und Grafikkarten haben, muss ich bis zu einem Grad darauf achten, dass ich nicht zu ausschweifend programmiere.
In dieser Woche habe ich weniger Fortschitte gemacht als in den letzten Wochen. Ich habe mich Anfang der Woche vor allem mit Partikeleffekten für den Kampf beschäftigt (Chilisosse, Tofustückchen). Nachdem diese recht einfach zu implementieren waren habe ich mich der Animation des Hauptcharakters zugewendet. Mit grossen Hoffnungen auf ein Pluginscript für Vertexanimationen in unity3d (welche nicht direkt unterstützt werden) habe ich meinen Tofu auf diese Art animiert. Nach zwei Tagen Testen und Basteln musste ich diese Möglichkeit begraben und habe den Charakter noch einmal mit Bones animiert, was viel mehr Probleme gemacht hat als die einfach Vertexanimation. ABer nun ist diese Animation im Spiel und ich kann mich in der nächsten Woche der Grafik und Animationen für die Gegner (Köche) zuwenden.
Mein Eintrag kommt etwas verspätet da ich am Freitag den Autosalon in Genf besucht habe. Da ihn aber eh niemand lesen wird ist das eigentlich auch egal... ;)
In der zweiten Woche des Bachelors kam mir, im Gespräch mit meinem Mentor-Dozenten Florian, die rettende Idee zu meinem Spielinhalt. Das muss ich etwas weiter ausführen. Bisher hatte ich viele Elemente angedacht: Man sollte entdecken, reden, Quests machen, kämpfen, Gegenstände einsammeln, Rätsel lösen... etc. Ich habe aber keine Balance zwischen diesen Elementen gefunden, keine Möglichkeit diese für mich so zu verbinden das sie Sinn machen. Jetzt habe ich beschlossen mich weitgehend auf ein Element, eine Art von Hack'n'Slay, weitgehend zu beschränken. Das Kämpfen steht jetzt im Vordergrund. Dafür werden Dialoge, Story und Items vernachlässigt.
In welchen Hack'n'Slay Games kämpft man vor allem, und welche Unterschiede gibt es dort? Zwei gegensätzliche Vertreter sind mir eingefallen, und zwar "Diablo", in welchem man vor allem durch den Kampf Gegenstände einsammeln kann, und "God of War", in welchem man keine Gegenstände sammeln kann, der Kampf aber abwechslungsreicher ist. Ich habe mich dann für die "God of War" Variante entschieden. Das klingt jetzt recht gross und brutal, aber mal gucken was mein kleiner Tofu dann später alles kann, jetzt wo ich mich vor allem auf verschiedene Kampftechniken und Gegner konzentriere.
Daraus resultierend habe ich mich näher mit dem Kampfsystem beschäftigt. Wenn man schon fast nur Kämpfen kann, dann muss dieser Kampf auch interessant und abwechslungsreich sein. Momentan habe ich eine Art Auflade-System wie bei "Secret of Mana" adaptiert. Dieses wird ausgiebig getestet.
In other news: Diese Woche kümmere ich mich im Bluteffekte.
Da bei meinem Spiel auch ziemlich viele Dialoge vorkommen (um genau zu sein: die meisten Inhalte würden über Dialoge vermittelt werden), brauche ich auch ein Dialogsystem, das ich verwenden kann. Dafür bin ich auf die Suche gegangen nach schon vorhandenen Editoren, um zu sehen, ob ich diese verwenden kann.
Diese Suche ist dabei nur von begrenztem Erfolg gekrönt gewesen. Eine Nachfrage auf gamedev.stackexchange.com führte zur Antwort, die ich schon halbwegs befürchtet hatte: es gibt keine Editoren, weil schlussendlich sämtliche Entwickler ihr eigenes Dialogsystem aufbauen, die jeweils andere Formate und damit eigene Editoren verwenden.
Trotzdem gibt es einige Editoren, mit denen man möglicherweise arbeiten könnte.
Chat Mapper
Chat Mapper scheint auf den ersten Blick das ideale Tool zu sein, um den Dialog zu schreiben. Vor allem auch die Tatsache, dass das Programm ein XML-File exportieren kann, scheint verlockend. Tatsächlich scheint der Editor ganz passabel zu sein, um Dialoge auszutesten. Leider hat das Programm auch einige Nachteile. Als Scripting-Sprache wird LUA verwendet, die in Unity leider nicht sehr viel bringt.
