Gestern ging ich mit meinen Freunden aus der Medienlandschaft Abends aus. Dabei musste ich mal wieder feststellen, dass da unter uns immer wieder eine Aussage vor allem in Künstler-/Designerkreisen zu hören ist, die schlichtweg falsch und etwas besorgniserregend ist. “Ich bin nur User, Code schreiben hat mir halt noch nie Spaß gemacht” sagte beispielsweise ein Videoproducer mit einschlägiger Erfahrung in 3D Arts und Animation.

Wenn ihr mich fragt, am meisten stört mich dieses “nur” in seiner Aussage – “NUR”! Hiermit spricht er indirekt eine Grundproblematik aus, die hier mal genauer beleuchtet werden muss. Abgesehen davon ist natürlich auch die Aussage er sei User ganz grundsätzlich falsch. So, und jetzt folgt eine kleine Klarstellung über die Klassifizierung der Tätigkeitsfelder unter uns Medienschaffenden:

Entwickler und User

Wenn du ein Medienwerk erschaffst bist du selbst Entwickler und nicht “nur” User. Dabei spielt es keine Rolle ob du in schöner und inutitiv bedienbarer GUI mit drag and drop ein grafisches Werk anhand vieler Mausklicks erschaffst oder ob du in einer IDE anhand vieler Tastendrucke deinen objektorientierten Code produzierst. Klar ist der Eine des Anderen User, jedoch ist er in Folge dessen auch selbst Entwickler. Viel wichtiger ist außerdem, dass dies garnichts über die Qualität der jeweiligen Tätigkeit aussagt. Denn schließlich hat jeder Entwickler naturgemäß für seine Entwicklungen auch User. Das Ergebnis der Tätigkeit besagten Videoproducers wird beispielsweise ja auch wieder weiterverwendet bzw. konsumiert.

Das schlechte Gewissen

Das vielleicht etwas schlechte Gewissen, welches mit dem “nur” zum Ausdruck kommt, rührt daher, dass der Videoproducer mit der von ihm verwendeten Software möglicherweise schneller und manchmal auch härter an die Grenzen des für ihn Machbaren stößt als der Programmierer, der diese Software entwickelt. So ist halt das System. Je weiter oben du auf dem Entwicklerbaum sitzt, desto weniger kannst du im Alleingang etwas am Stamm bewegen. Aber hey, du bist stattdessen den Früchten des Schaffens, dem Ergebnisprodukt des ganzen Baumes auch etwas näher.

Grenzen der Programmierer

Das Programmierer grundsätzlich mehr Schaffensfreiheit haben ist im Grunde auch ein Trugschluss, denn diese stoßen nach oben hin irgendwann auch an eine Grenze, die Grenze ihrer Kreativität. Diese Grenze ist je nach Person etwas härter oder etwas weicher, aber in jedem Fall vorhanden. Schließlich kann man nicht alle Disziplinen auf höchstem Niveau verfolgen.

Was bringt mir als Programmierer beispielsweise die Fähigkeit anhand eines Schiebereglers in der Software alles steuern zu können, wenn ich erstens nicht einschätzen kann welche Anforderung aus sicht des Anwenders überhaupt an die Funktionalität des Reglers gestellt wird, und zweitens dann nichtmal wüsste wohin ich ihn schieben muss, damit das damit erzeugte Resultat stimmig wird, sofern ich ihn produktiv einsetzen würde. Es braucht also hierzu die kreativen Fachleute, die sagen was sie brauchen um wiederum ihren eigenen Bereich bedienen zu können.

Zum Stamm des Entwicklerbaums hin haben Programmierer auch klare Grenzen. Die Hardware können dann nämlich die wenigsten noch selbst entwickeln. In Bezug dazu finden sich dann diejenigen Programmierer die möglicherweise auch mal ein “nur” aussprechen.

Generalisten

Und wie siehts mit Generalisten aus? Generalisten könnte man unserer Metaphorik folgend als Fasern bezeichnen, die sich durch weite Teile des Baumes ziehen und diesen damit zusammenhalten. Sie sorgen für die nötige Stabilität des Baumes indem sie ihrem vielfältigen Tätigkeitsfeld entsprechend die Fähigkeit zur interdisziplinären Kommunikation wesentlich weiter ausprägen. Aufgrund der Bregrenztheit ihres einschlägigen Fachwissens sind sie sogar bei komplexeren Aufgaben in der Pflicht, den Austausch mit Fachexperten zu führen, wenn das Ergebnis höchstes Niveau erreichen soll.

Kommunikation ist das A und O

Alle Entwickler unseres Baumes sind also voneinander abhängig und auf Kommunikation und Zusammenarbeit angewiesen. Generalisten bieten eine großartige Chance die Kommunikation zu fördern und außerdem den Blick fürs Ganze zu behalten. Dieses kommunikative Umfeld sollten wir alle gemeinsam so gut es geht ausgestalten, denn die Fähigkeit zum Dialog sichert und stabilisiert die Position jedes Einzelnen. Somit profitieren alle, sogar der Endanwender, der letztlich die Qualität des Ergebnisses all unseres Schaffens zu schätzen weiß.

Nicht „nur“ Negativ

Um noch einmal auf die einleitende Aussage zurückzukommen, man erkennt hierin natürlich nicht nur Zweifel sondern auch den Wunsch des Entwicklers nach mehr Generalität ausgehend vom eigenen Fachgebiet. Diese Interpretation des „nur“s ist sehr positiv. Es ist nämlich für jeden von uns wichtig, sich nicht in seinem Fachgebiet einzusperren. Gerade der schnelllebige Medienbereich fordert uns regelrecht heraus über den eigenen Horizont hinaus blicken zu können um zumindest die nötige Kompetenz für den interdisziplinären Dialog mitzubringen und die Hintergründe für den eigenen Anwendungsbereich besser zu verstehen.

Fazit

Lasst uns in Zukunft bitte keine qualitativen Unterschiede mehr, aufgrund unseres Tätigkeitsfeldes als solches, machen. Die einen finden ihre Begeisterung eben für das eine und die anderen für das andere, fertig, aus, abgehakt! Jetzt wendet sich bitte jeder wieder seiner Leidenschaft zu und vergisst das “nur” endgültig. Keiner muss sich für seine fachlichen Grenzen rechtfertigen, wenn er seinen Platz gewissenhaft ausfüllt und hin und wieder über den Tellerrand blickt.

Heute reise ich nach Stuttgart und besuche die FMX, eine wichtige europäische Konferenz zu den Bereichen Animation, Effects, Games und Interactive Media. Am Donnerstag werde ich eine Präsentation über KI in Unity geben. Diese basiert auf den Erfahrungen, die ich während meiner Bachelorarbeitszeit gewonnen habe.

Im Einzelnen werde ich die wichtigsten Aspekte der aktuell verfügbaren KI Pakete der Unity Community vorstellen und zeigen inwieweit ich diese für mein Projekt ergänzt habe. Im Anschluss präsentiere ich finale die Version der Simulation.

Ich freue mich bekannt geben zu können, dass meine Bachelorarbeit nun abgeschlossen ist und am 11. April in der Hochschule abgegeben wurde. Im praktischen Teil der Bachelorarbeit entwickelte ich nun eine Anwendung die das Leben auf einem Marktplatz simuliert. In diesem Rahmen sind die computergesteuerten Charactere in der Lage die folgenden Verhaltensweisen zu zeigen: zufällig umherlaufen, “untätig” stehen bleiben, sich auf eine Bank setzen, einkaufen gehen und dynamisch einen Dialog starten.

Die Umsetzung basiert hauptsächlich auf den drei KI Lösungen aus der Unity Community: Behave (AngryAnt), UnitySteer (Arges Systems) und A* Pathfinding (Aron Granberg). In Ergänzung zu diesen Paketen entwickelte ich verschiedene Erweiterungen für die Simulation.

Der Schwerpunkt lag dabei auf der Entwicklung eines Containment Behaviors nach dem Vorbild des Steering Erfinder Craig Reynolds. Dieses Verhalten erlaubt es dem Agenten Hindernissen mit beliebiger Oberflächenform auszuweichen. Ergänzend zum theoretischen Ansatz von Reynolds ermöglicht das Verhalten auch den Umgang mit konkaven Hindernisoberflächen. Ergänzend ist es nun auch möglich die Containerlinie des Verhaltens dynamisch anhand des A* Grids erzeugen zu lassen, dass vom A* Pathfinding Paket verwendet wird. Auf diese Weise wird die Containerlinie automatisch angepasst, sofern eine Änderung in der Weltgeometrie vorgenommen wurde.

In den nächsten Wochen werde ich einen tieferen Einblick in meine Arbeit geben und habe vor, einen stable release des Containment Verhaltens in der Community zu veröffentlichen.

Ich freue mich heute einen weiteren Fortschritt meiner Bachelorarbeit präsentieren zu können. Im Rahmen einer überaus bereichernden Kooperation mit der ehemaligen Multimediastudentin der Hochschule Ansbach Christina Ziem wurde der gestalterische Rahmen meines Simulationsprototypen geschaffen.

Christina erstellte Lowpoly-Häuser im barocken Stil und Lowpoly-Marktstände. Dabei hatte sie ein Auge darauf, dass sich die Umgebung trotz vieler schöner Details zugunsten der Non-Player-Character optisch zurück nimmt. Dem geschickten Einsatz von Lightmap und Normalmap ist es zu verdanken, dass die Modelle trotz geringster Rechnenleistung nun ein sehr attraktives Äußeres erhalten haben.

Im Gegenzug für ihre Leistung habe ich Christina die technische Umsetzung ihres neuen Onlineportfolios abgenommen. Die Inhalte können nun von ihr bequem über das Content Management System Typo3 eingepflegt werden. Die Seite glänzt durch ein ausgefallenes Design und bietet einige schicke Javascript-Effekte.

Die Anfangs noch scherzhafte Idee der Arbeitsteilung entwickelte sich schnell zu einer ernstzunehmenden Kooperation mit echtem Erfolg für beide Seiten.  Heute geht das neue Portfolio online und ich freue mich die kommenden Simulationsversuche in neuer Umgebung starten zu dürfen.

In letzter Zeit habe ich mich viel mit der Aufnahme, Aufbereitung und der Verwendung von Motion Capture Daten in der Gameengine beschäftigt. Bezogen auf die Planung und Organisation der MoCap-Aufnahmen erschien mir dieser Artikel auf gamasutra.com am wertvollsten, da er relativ viele Bereiche von der Konzeption bis hin zum Umgang mit den MoCap-Darstellern abdeckt.

Momentan stehe ich vor der Situation, dass ich, um rechtzeitig meine Bachelorarbeit abschließen zu können, den Aufwand für manche Bereiche, so klein wie möglich halten will. Deshalb kam mir meine letzte Entdeckung sehr gelegen.

Die Carnegie Mellon University (CMU) stellt online eine sehr umfangreiche freie MoCap Datenbank zur Verfügung. Die Qualität der enthaltenen Aufnahmen ist außerdem zum großteil wirklich gut.

Und als sei das noch nicht genug, gibt es sogar noch eine MotionBuilder-Variante aller MoCap-Daten der Universität auf cgspeed.com.

Nachdem ich alle MoCap-Daten heruntergeladen habe und die ein oder andere Animation in Motionbuilder getestet habe, stand ich vor dem Problem die von mir erwählten Animationen für die Gameengine aufbereiten zu müssen.

Das heißt konkret:

• Position des Characters auf dem Ursprung
• Blick des Characters in negativer Z-Richtung
• Die Bewegung des obersten Joints (Hüfte) wird auf die Y-Achse beschränkt
• Die MoCap-Animation muss so beschnitten werden, dass sie in einer Schleife laufen kann
• Der Bildsprung zwischen erstem und letzten Frame der Schleife muss entfernt werden

Für all diese Anforderungen und noch viel mehr gibt es ein sehr praktisches freies Tool: bvhacker. Man kann damit zwar nur BVH-Dateien (Biovision Format) bearbeiten, aber da ich nun ohnehin die Animationen der CMU-Datenbank verwende, ist es in meinem Fall genau das richtige.

Nachdem der Loop erstellt wurde, muss man die Animation nurnoch dem eigenen Character zuweisen. Das sollte dann aber in MotionBuilder relativ schnell erledigt sein.

Vorerst werde ich mit bereits etablierten KI-Methoden versuchen, meinem Ziel gerecht zu werden. Darunter fallen unter anderem die Hierarchical Finite State Machine zur Steuerung des reaktiven Verhaltens der Agenten, Behavior Trees zur Steuerung planmäßigen Verhaltens oder Pathfinding- und Steering-Algorithmen für die glaubhafte Bewegung durch die virtuelle Welt. Die kreative und technische Herausforderung für mich ist dabei, ein Konzept zu entwickeln und umzusetzen, dass die theoretischen Ansätze der Spiel-KI-Forschung so miteinander kombiniert und konfiguriert, dass ein glaubhaftes Verhalten im Rahmen des Gamedesigns erreicht wird.

Neben der theoretischen Ausarbeitung des Konzepts, habe ich vor, einen Simulations-Prototypen zu entwickeln, der die Funktionsweise des entwickelten Konzepts unter Beweis stellen kann oder zumindest in der Lage ist noch bestehende Schwachstellen aufzudecken. Die verwendeten Animationen sollen im Motion Capturing Studio der Hochschule Ansbach aufgezeichnet werden.

Für die gesamte Umsetzung des Prototypen verwende ich folgende Werkzeuge:

• Gameengine: Unity
• Modeling: MAXON Cinema 4D
• Bildbearbeitung: Adobe Photoshop
• Animation: Autodesk MotionBuilder
• Programmierung: Microsoft Visual Studio