Spielinfo Bilder Videos

Zombies unter Zeitdruck

Die Zombiemacher: Dieses Team hat sechs Wochen Zeit für das Spiel "The Deadline".

Innerhalb von drei Wochen soll das Team das Spiel vom Papier in den Beta-Status hieven. Innerhalb von drei Wochen müssen alle angedachten Features umgesetzt und spielbar sein; die Zeit danach soll nur noch dazu dienen, die Spielbalance anzugehen und Feinarbeiten zu tätigen. "Tower of Doom" wird umgetauft und heißt jetzt The Deadline - in doppelter Anspielung auf die Zeitvorgabe für das Projekt sowie den Strom von Zombies im Spiel. Dass man mit der Abkürzung dann auch noch dem Genre die Ehre erweist, ist natürlich kein Zufall.

Die Klasse ist aufgeteilt in zwei Gruppen. Die 'Designer' - Jaron, Alexander, Sebastian, Vito, Marcel, Thomas, Erdi, Marian, Waldemar, Anna, Julian und Waldemar - kümmern sich um das Regelwerk sowie die für The Deadline benötigten Assets wie die Charaktere, Objekte und Sets. Die 'Developer' - Benjamin, Mats, Julius, Falco, Johannes und Lynn - dürfen sich um die Implementierung dessen kümmern, was da vom anderen Teil des Teams geliefert wird.

Der Projektstart beginnt erstmal mit einer Umstrukturierung: Der Aufbau der Klassenräume in der MD.H ist für den Lehrbetrieb angelegt - nicht für Teamprojekte dieser Art. Bei den Designern beginnt man daraufhin fix, sämtliche Arbeitsplätze in einer Kreisform aufzustellen, bei den Codern ist die U-Form das Modell der Wahl. Fix wird außerdem ein Teil der Zwischenwand entfernt, um die räumliche Trennung zwischen den beiden Abteilungen zu überwinden.

Klare Strukturen, kleine Teams

Die Geburt eines Roboters: Udo: Konzept, erster Entwurf und aktuelle Fassung.

Jaron, der schon bei Tower of Doom mitmischte, übernimmt die Funktion des Projektleiters. Alex hält im Grafikbereich die Fäden in der Hand, während Benjamin bei den Developern die koordinierende Instanz wird. Es fällt schwer, darüber hinaus feste 'Stellenbeschreibungen' zu geben. Beispielsweise beschäftigen sich Waldemar und Erdi mit Zombies, während Thomas an den Shadern schraubt, um den gewünschten Cartoon-Look des Spiels zu erreichen. Im Laufe des Projekts werden aber so gut wie alle Teammitglieder mehrere Aufgaben erledigt und auch dort ausgeholfen haben, wo gerade Not am Mann ist - wie das bei kleinen Gruppen so üblich ist. In großen Studios hingegen werden Schritte wie das Modellieren, Animieren und Texturieren jeweils von separaten Spezialisten durchgeführt.

Adomat - eigentlich Sebastian - ist für den Hauptcharakter zuständig, den umtriebigen Roboter Udo - eigentlich U-do-I-51337. Schon ein paar Tage vor dem offiziellen Projektbeginn hatte er sich hingesetzt und ein auf Marians Konzeptzeichnungen fußendes 3D-Modell entwickelt. Welches allerdings nicht überall Anklang findet, da es schon etwas zu technisch aussieht und nicht ganz dem gewünschten Comic-Stil entspricht. Mittlerweile hat er bereits ein neues Modell entwickelt. Die Kritik am alten Entwurf sei durchaus berechtigt gewesen, merkt Adomat an. Das Gefühl, dass das Verwerfen seines ersten Werkes doch ein klein wenig an ihm nagt, wird man allerdings nicht so ganz los.

Korrekturen und Feintuning

Diese Visualisierung wurde für das ursprüngliche "Tower of Doom" erstellt, das dann umgetauft wurde.

Korrekturen sind auch bei Vito fällig, welcher quasi die Kulissen für das Bürohaus bastelt. Dank seiner detailverliebten Arbeit warten die Umgebungsobjekte mit Extras auf, die im eigentlichen Spiel aufgrund der Entfernung der Kamera wohl kaum oder gar nicht wirklich zur Geltung kommen können, wohl aber Performance fressen würden. Viel Freude bereitet ihm der Griff zur sprichwörtlichen Schere wahrscheinlich nicht, während er da Details kürzt und die Anzahl der Polygone reduziert.

Die 'Developer' fangen derweil an, die ersten Skripte zu produzieren. Julius darf sich z.B. damit auseinandersetzen, die Bewegung des Roboters in den Levels umzusetzen und kommentiert leicht entgeistert, dass man der Unreal Engine dann doch anmerke, dass sie primär auf Shooter ausgelegt ist. Es sei kein Problem, einem Charakter eine Waffe in die Hände zu legen und diesen ballernd durch die Gegend laufen zu lassen. Die Herausforderung, ein Objekt wie Udo völlig von der Physik befreit entlang eines Pfades (Spline) schweben zu lassen, sei deutlich weniger trivial.

Das Problem: Sichtausschnitt & Skalierung passen nicht.

Die Technologie ist durchaus mächtig. Aber das Team, welches sich erst seit einem knappen Monat mit ihr auseinandersetzen konnte, betritt ständig Neuland und verbringt viel Zeit damit, in der Dokumentation und im Netz zu recherchieren. Der eine oder andere hätte auch nichts dagegen gehabt, mit der Unity-Engine zu arbeiten, die man vor Projektbeginn ebenfalls in Betracht gezogen hatte. Das Unreal Dev Kit lockte jedoch zum einen mit dem Verbreitungsgrad der Technologie - Erfahrung im Umgang mit den Werkzeugen und der Skript-Sprache dürfte sich im Lebenslauf durchaus als hilfreich erweisen bei kommenden Bewerbungen. Zum anderen kann das UDK problemlos und ohne Umwege für nichtkommerzielle Projekte und im schulischen Bereich eingesetzt werden. Auch bei Unity gibt es eine 'educational license', deren Konditionen aber erst auf Anfrage mitgeteilt werden und Verhandlungssache sind.

Eine weitere Baustelle, die am Ende der ersten Woche bewältigt werden will: Der derzeitige sichtbare Ausschnitt hat nicht viel mit dem ursprünglichen Entwurf gemein. Das Gebäude ist deutlich breiter, und statt drei Etagen sind gar bis zu fünf zu sehen - einzelne, aber notwendige Details würden so kaum erkennbar sein. Damit ist klar: Sowohl bei der Levelskalierung als auch bei der Kamerapositionierung gibt es reichlich Tuningbedarf.

Im dritten Teil der Reportage: Sand im Produktionsgetriebe