Special:
hat wie fast alle Softwareprojekte ein großes Problem: Die Deadline.Tower Defense in sechs Wochen
Ein kurzer Rückblick: Für das laufende Semester des Kurses GD 1007 an der Mediadesign Hochschule Berlin hatten sich die Dozenten etwas Neues einfallen lassen. Statt an mehreren kleineren Projekten sollte die Klasse übergreifend an einem einzigen Spiel werkeln. Als Vorgabe wird das Tower Defense-Genre auserkoren, welches um ein frisches Element - sei es im Bereich Story, Gameplay, Setting oder Steuerung - erweitert werden soll. Die Richtlinie gibt es nicht ohne Grund: Das Basiskonzept ist bekannt und gut definiert. Die Studenten sollen sich zum einen nicht in Projekten bzw. Konzepten versteigen, die nicht innerhalb der gegebenen Zeit zu stemmen sind, zum anderen wird so eine Vergleichbarkeit gewährleistet, gilt es doch dann mehrere Ideen zu entwickeln.
Sechs Wochen hat das Team Zeit, um ein Tower Defense-Spiel zu entwickeln. Mehr dazu sowie zur Mediadesignhochschule im Interview mit Projektleiter Thomas Langhanki.
In der ersten Woche diskutierten die Beteiligten das Spielprinzip, seine Grenzen und Möglichkeiten ausgiebig. Mehrere Vorschläge werden in den Raum geworfen, Mindmaps entworfen - am Ende kristallisieren sich drei Konzepte heraus, um die sich Teams scharen: Farm Wars, Fungarius und Tower of Doom. Für jeden der Kandidaten muss ein detailiertes Regelwerk ausgearbeitet, Konzeptzeichnungen entworfen und Visualisierungen, die das ungefähre Aussehen des jeweiligen Spiels andeuten, produziert werden.
Von der Zeichnung zum Spiel
Prototypen existieren in dieser Phase nur auf dem Papier in Form von Dokumenten und Brettspielen - programmiert wird nicht. Erste Rückschlüsse können so bereits gezogen werden - z.B. wird im Falle von Tower of Doom auf die Idee verzichtet, die Spielfigur per Fahrstuhl zwischen Etagen wechseln zu lassen. Stattdessen erfolgt der Auf- bzw. Abstieg über eine Treppe, die am Ende jeder Ebene wartet. Das soll insgesamt etwas zugänglicher sein und den Spielfluss weniger stören.
Aus Ideen werden Zeichnungen und Konzepte, die visualisiert und in Gruppen verteilt werden müssen.
Das Weiterentwickeln der Ansätze, das Erstellen von Gamedesign-Dokumenten und das Definieren einer Art-Direction ist dabei aber nur ein Teil der Aufgabe - die Entwickler in spe sollen ihr Projekt auch entsprechend präsentieren und den anderen gegenüber verkaufen können. Der so genannte Pitch gehört schließlich auch zur Spieleproduktion, müssen Studios ihre Ideen doch Publishern oder anderen Geldgebern schmackhaft machen; in etwas größeren Teams wollen zudem erstmal die eigenen Kollegen überzeugt werden, bevor der nächste Schritt überhaupt gemacht werden kann.
Zeitdruck und Kompromisse
Nicht nur die Selbstvermarktung will gelernt sein, sondern auch das Scheitern. Der fehlgeschlagene Pitch gehört zum Geschäft. Und so wird sich auch ein Teil der Studenten von liebgewonnenen Konzepten trennen müssen, denn von Beginn an ist klar: Am Ende wird nur eines der Projekte durchgewunken werden. Die Entscheidung darüber obliegt sowohl den Studenten als auch den Dozenten. Jeder Teilnehmer hat einen virtuellen Geldbetrag (Studenten: 100; Dozenten: 300), den er bzw. sie am Ende der Pitchphase in die drei Projekte investieren und beliebig aufteilen darf. Das Konzept, das sich nach der Auszählung das meiste Kapital sichern konnte, wird auch umgesetzt werden.
Das erste Gerüst eines Leveldesigns: Es geht um Zombies, die ein mehrstöckiges Büro stürmen - mehr dazu in den First Facts.
Fungarius legt zum Auftakt der Erarbeitungsphase einen flotten Start hin und wird auch von Mitgliedern der anderen Teams als früher Favorit erachtet. Es geht um eine Invasion außerirdischer Mächte, einen wachsenden Blob und Türme, deren Farbe angepasst werden kann. Ländlicher geht es in Farm Wars zu, wo sich zwei verfeindete Farmen bekriegen. Im Gegensatz zum klassischen TD gibt es hier auch Basisbau-Elemente. Das Tower of Doom-Team ist es jedoch, welches letztendlich den Schlussspurt in Form des überzeugendsten Pitches hinlegt. Nach der Pause zum Jahreswechsel werden allen Beteiligten drei Wochen verbleiben, um die wesentlichen Features des nach dem gelungenen Pitch in The Deadline umgetauften Projekts umzusetzen.
Welche Engine soll es richten?
Die Grundpfeiler des Gamedesigns stehen, eine andere dringliche Frage harrt aber noch ihrer Beantwortung: Mit welcher Technologie soll das Spiel überhaupt umgesetzt werden? Ursprünglich hatte man sich bereits auf eine Engine festgelegt, die sich dann aber doch als weniger zugänglich als erhofft erweist. Nach mehreren Debatten wird schließlich entschieden, dass ein Teil der Studenten im Dezember zwei Alternativen evaluieren soll. Einige Zeit lang nehmen zwei Gruppen dort die Unity-Engine sowie das kurz zuvor veröffentlichte Unreal Development Kit unter die Lupe. Letzteres macht das Rennen.
Die Box der Entscheidung: Mit dem investierten 'Geld' wurde über die Projekte abgestimmt.
Das ist ungefähr auch der Zeitpunkt, an dem die MD.H bei 4Players anfragt, ob wir denn nicht Lust hätten, das Unterfangen zu begleiten. Nach einigem Abwägen sagen wir zu - die Aussicht, direkten und ungefilterten Zugang zum Team zu haben, dürfte es immerhin ermöglichen, sämtliche Aspekte einer solchen Produktion (samt ihrer Probleme) zu schildern. Heute haben wir als Auftakt der Berichterstattung First Facts zu "The Deadline" sowie ein Interview mit Projektleiter Thomas Langhanki im Angebot - falls ihr euch für ein Studium interessiert, bekommt ihr dort Auskunft über Anforderungen, Kosten und Perspektiven.
Im zweiten Teil der Reportage: Planung, Projektauftakt und Eingewöhnung
Zombies unter Zeitdruck
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 
Die Zombiemacher: Dieses Team hat sechs Wochen Zeit für das Spiel "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. |
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
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.
Diese Visualisierung wurde für das ursprüngliche "Tower of Doom" erstellt, das dann umgetauft wurde.
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.
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.
Das Problem: Sichtausschnitt & Skalierung passen nicht.
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
Die Beta in Sichtweite
Der Kurs GD 1007 der Mediadesign Hochschule hat die erste Woche der Vollproduktion hinter sich gebracht. Noch scheint man im Zeitplan zu liegen. Am Ende der Woche wird allerdings feststehen: Es wird richtig knapp. Die ersten drei der sechs geplanten Produktionswochen von The Deadline 
So sieht The Deadline im Unreal-Editor aus. sind ein kritischer Zeitraum. Die Vorgabe und die Zielsetzung sind eindeutig: Am Ende der dritten Woche muss das Projekt, das Mitte Januar größtenteils nur auf dem Papier existierte, nahezu Beta-Status ereicht haben. Sollten grundlegende Features dann noch nicht umgesetzt worden sein, droht der Griff zur Schere, denn die letzen drei Wochen der Produktion sind für den Feinschliff der Tower Defense eingeplant.
Die Designer werkeln munter vor sich hin und sind größtenteils damit beschäftigt, Grafik-Assets zu entwickeln. Das Gros der Objekte ist Mitte der Woche bereits modelliert, die meisten der Charaktere auch schon ordnungsgemäß mit einem Skelett versehen (das so genannte "Rigging"), damit sie animiert werden können. Erdi ist gerade dabei, einen Zombie herumschlurfen zu lassen, und versichert Alex, man werde die Animation auch ohne viel Aufwand auf die anderen Typen übertragen können. Bernd muss er hingegen noch eine andere Sitzpose verpassen - der in der Konzeptzeichnung dargebotene Schneidersitz des Hausmeisters erweist sich nämlich als etwas problematisch, 'clippen' die Polygone dabei doch gerne mal wild durcheinander. Texturiert ist kaum eines der Objekte - allzu viel Aufwand (und damit: Zeit) hat man dafür aber auch nicht eingeplant, da aufgrund des Cartoon-Stils keine hochgradig detaillierten Assets erstellt werden müssen.
Hintergünde, Interface & Bewegungen
 |
| Das Modell des Hauptprotagonisten: Udo. |
Die Nutzeroberfläche ist es auch, die Lynn bei den 'Developern' auf Trab hält. So ist er gerade dabei, das Anzeigen des Countdowns umzusetzen - also die Zeit bis zum Eintreffen des Rettungshubschraubers. Und auch darum muss man sich erstmal kümmern: Wenn das 'Game Over' erreicht ist, wäre es schon recht praktisch, wenn der Spielbetrieb dann auch mal pausiert bzw. beendet wird. Wie auch bei anderen Aufgaben gilt hier, dass UnrealScript-Profis vermutlich nicht lange über diese Lösungen nachdenken müssten. Die Studenten, die sich erst seit Kurzem mit dem Unreal Dev Kit auseinandersetzen, müssen allerdings erstmal recherchieren und experimentieren.
Auf dem Rechner von Julius schwebt Udo immerhin schon von links nach rechts. Ein Teilerfolg, wenn auch nur ein kleiner; die 'W'- und 'S'-Tasten solle man mal lieber nicht drücken, merkt er fix an, da sich der Roboter dann leider entlang der Z-Achse in die Tiefe bewegt. Auch das Wechseln zwischen Stockwerken muss der Hauptprotagonist noch lernen, obwohl die Halbzeit der kritischen Phase der Produktion bereits erreicht ist.
Auch wenn wir das Projekt nicht 24 Stunden am Tag begleiten können, so ist doch zu spüren, dass die Stimmung in der zweiten Woche etwas anderer Art ist als noch zum Auftakt. "Besser als befürchtet, nicht so gut wie erhofft" - so fasst Alex seine Sicht auf den Stand der Dinge am Freitag der zweiten Woche zusammen. 80 Prozent der eingeplanten Objekte und Charaktere würden mittlerweile stehen, auch sei das Unreal Dev Kit insgesamt etwas zugänglicher als ursprünglich erwartet. Allerdings, so merkt der Grafik-Chef im Designer-Team etwas zerknirscht an, gebe es auch ein paar Kommunikationsprobleme innerhalb des Teams. Es wird nicht das einzige Mal sein, dass das Thema an diesem Tag zur Sprache kommen wird.
Es wird Klartext geredet
 |
| An dieser Wand steht, wer was bearbeitet. |
Was sich allerdings nicht ändert, ist der skeptische Gesichtsausdruck der beiden anwesenden Dozenten Thomas Langhanki und Marco Block-Berlitz. Die Lehrkräfte, die das Projekt nur in beratender Funktion begleiten, da die Studenten die Produktion selbst planen, ausführen und koordinieren sollen, stellen jetzt wichtige Fragen. Dem in der Lehre für den Bereich Gamedesign verantwortlichen Langhanki bereitet eine Sache gewaltige Kopfschmerzen: Nach zwei Dritteln der Produktionsphase ist The Deadline immer noch nicht spielbar.
Warum noch nicht spielbar?
Benjamin, der Leiter der Developer-Gruppe schildert die beiden großen Herausforderungen, die sein Team zu meistern hat, bis es so weit ist: Zum einen müsse man die Zombies endlich in das Spiel integrieren und diese wie geplant durch das Bürohaus laufen lassen. Zum anderen sei die Interaktion mit den Objekten noch eine Baustelle, die ihrer Bearbeitung harrt. Laut seiner Schätzung werden die Developer für jedes der Probleme zwei Tage benötigen - einen Tag für das Nachforschen in Foren und in der Dokumentation, einen Tag für eine funktionierende Umsetzung des Ganzen. Frühestens am Donnerstag sei also mit einer Version zu rechnen, in der die grundlegenden Spielelemente wie vorgesehen ihre Arbeit verrichten. Auch wolle man die Trigger optimieren, da man derzeit zu viele davon verwendet und so die Fehleranfälligkeit des Spielgeschehens deutlich erhöht. Außerdem müssen die Programmierer im Gegensatz zu den anderen Kameraden nebenbei noch Aufgaben für einen anderen Kurs erledigen.
Langhanki quittiert die Prognose mit einem Kopfschütteln und hält jene Planung für ein waghalsiges Kartenhaus, das man sich da gerade aufbaue. Sobald man diese Ziele erreicht habe, würden sich unausweichlich neue Probleme ergeben, die man dann nicht mehr lösen könne. Auch verstehe er nicht, wieso das Team schon Trigger überarbeiten soll, wenn es Features gibt, die noch nicht eingebaut wurden. Das Hoffen auf eine Punktlandung am Freitag der dritten Woche sei in dieser Form unrealistisch.
'Good cop, bad cop' gibt es heute nicht bei den Dozenten, denn auch Block-Berlitz rüttelt an den Fundamenten dessen, was da wie ein Wolkenschloss auf ihn wirkt. Informationen könne man doch bitte auch am Wochenende recherchieren und müsse damit nicht erst am Montag anfangen. "Ich frage mich auch, warum ich hier noch keine Schlafsäcke sehe", fährt er fort. Während seines Studiums habe man für gewisse Projekte und Aufgaben auch schon mal Überstunden schieben müssen, so der promovierte Informatiker, der die Anwesenden nochmal erinnert: 
Adomat und seine Mütze sprechen mit Jaron...ob das angesichts der Manöverkritik hilft? Die Stimmung ist nach den ersten Analysen des Status quo nicht mehr so gut...
"Ihr wusstet, dass es schwierig werden wird, und habt euch dieses Ziel gesetzt. Ihr habt diese Planung gemacht. Jetzt müsst ihr auch zusehen, wie ihr das hinbekommt."
Das Dozenten-Duo stellt klar, dass man nicht vorhat, die vereinbarten Deadlines zu verschieben. Das, was nicht innerhalb der nächsten sieben Tage umgesetzt wird, fliegt gnadenlos raus. Zur Not müsse man halt Kürzungen vornehmen. Adomat kann sich nicht so recht vorstellen, wo man denn am Konzept von The Deadline den Rotstift ansetzen würde. "Kürzen geht immer", entgegnet Langhanki in einer Tonart, die als kurioser Cocktail aus Aufmunterung und Süffisanz daherkommt. Nicht immer sei der Griff zur Axt etwas Schlechtes.
Keineswegs möchten die beiden Lehrkräfte den Developern die volle Verantwortung für den derzeitigen Stand des Projekts zuschieben, werden doch jetzt auch die Designer in die Pflicht genommen. "Im Gegensatz zu den anderen bewegt ihr euch weitgehend auf bekanntem Terrain", gibt Langhanki der 'Kreativabteilung' zu denken. Die Developer hingegen würden dank des UDKs ständig mit ihnen noch nicht vertrauten Problemfeldern konfrontiert. Man solle sich also mal überlegen, wie man den Kollegen etwas aushelfen könne, gebe es doch beispielsweise diverse Dinge, die man schon über die Animationen lösen könnte, statt auf die Skript-Arbeit anderer zu vertrauen. Die Runde nickt, und Waldemar erklärt sich bereit, enger mit der anderen Abteilung zusammenzuarbeiten.
Wenn die Abstimmung fehlt
In vielen Firmen und Projekten sind nicht die verwendeten Hardware- und Softwarebestandteile die Ursache vieler Verzögerungen - oftmals sind es Störungen in der Kommunikation zwischen den Leuten, die sich als wahrer Problemherd erweisen. Und das ist auch im Falle von The Deadline nicht anders. 
Es rappelt im Karton: Die Manöverkritik lässt die anfänglich gute Stimmung während des Meetings in den Keller sinken.
Vor dem Projektbeginn hatte man ein an Scrum angelehntes System als Organisationsmethode auserkoren. Scrum, welches in der einen oder anderen Form mittlerweile bei vielen Spieleschmieden zum Einsatz kommt, unterteilt den Produktionsablauf in Sprints genannte Zyklen. Innerhalb jener Sprints - bei The Deadline jeweils eine Woche - muss das Team bestimmte Ziele erreichen, die es sich vor dem Sprint selbst gesetzt hat. In täglichen Meetings, den Daily Scrums, trifft sich das Team, um zu besprechen, was erledigt wurde, was noch zu erledigen ist. Die Daily Scrums dienen dazu, das Team zu synchronisieren und potenzielle Flaschenhälse, Unstimmigkeiten oder Freiräume in der Entwicklung aufzuzeigen.
Im Falle der von uns begleiteten Produktion wurde jene Funktion der täglichen Treffen allerdings durch einen Umstand ad absurdum geführt: Der Großteil des Teams ist in der Früh oft nicht anwesend und trudelt erst später ein. Im Allgemeinen ist das Antreten zur 'Arbeit' abhängig von der Motivation der Beteiligten, gibt es doch keine Anwesenheitspflicht für die Studenten der MD.H. Einzig eine vorher getroffene Vereinbarung gilt für die Studenten: Wer zu oft fehlt, wird nicht in den Credits von The Deadline aufgeführt und darf in diesem Semester stattdessen andere Aufgaben lösen.
Ohne Überstunden geht nichts?
Langhanki moniert dann auch das Fehlen vereinbarter Kernarbeitszeiten und schaut Vito an. Der ist nämlich dem Vernehmen nach selten vor 11 Uhr anzutreffen, findet das aber unproblematisch, da er doch dafür länger arbeite. Sehr förderlich für das Team sei das aber gerade in der aktuellen Situation nicht, predigt wiederum Langhanki. Letztendlich wird sich das Team darauf verständigen, spätestens 9:30 Uhr vor Ort zu sein.
Auch das gehört dazu: Die akribische Zeitplanung.
Die Diskussion über die Probleme im Projekt animiert auch einige andere Studenten dazu, ihre Unzufriedenheit kund zu tun. Die momentane Kooperationsbereitschaft von Thomas kann vorsichtig als 'wenig ausgeprägt' beschrieben werden, nachdem die Developer in der aktuellen Version die von ihm erarbeiteten Grafik-Settings ungefragt überschrieben haben. Auch generell seien dort seine Vorschläge erstmal ignoriert worden, obwohl sie sich später als richtig erwiesen hätten, murmelt er noch schultzerzuckend, während er sich zu seinem Rechner begibt, um wenigstens dort den aktuellen Look des Spiels vorführen zu können.
Das Fehlen von Absprachen sowie die Missachtung von vereinbarten Namenskonventionen für Dateien sind allerdings auch den Developern ein Dorn im Auge. So verweist man beispielsweise auf die Zeit, die man benötigt hat, um den Charakter wie wieder vorgesehen durch die Level schweben zu lassen, nachdem eine Änderung des Modells die bereits gefundene Lösung zerschossen hatte.
Kritk an allen Ecken und Enden
Block-Berlitz meldet sich wieder zu Wort und lässt durchblicken, dass er sich von Seiten der Designer etwas mehr Vorarbeit erhofft hätte. Während sich die Developer schon einen Monat mit dem Unreal Dev Kit auseinandergesetzt haben, hätten sie
vor zwei Wochen erst bei Null angefangen. Das Ergebnis: Die für die Integration der Daten und die Umsetzung der Vorgaben zuständigen Mitglieder des Teams hätten erstmal darauf warten müssen, dass überhaupt Material angeliefert wird, mit dem sie arbeiten können. Auch an Dummy-Objekten, mit denen man schon frühzeitig experimentieren hätte können, mangelte es wohl. Beim Design-Team verweist man darauf, dass einige der Studenten Anfang Januar noch damit ausgelastet waren, Klausuren aus dem Vorjahr nachzuschreiben. Ein Mockup-Bild deutet an, wie das Spiel mal aussehen könnte. Von einem spielbaren Prototypen ist das Team aber noch weit entfernt.
Von Developer-Seite wird noch ein weiterer Kritikpunkt genannt, der sich organisatorisch bemerkbar macht: Da beide Teile des Teams bisher stets auf die gleiche Deadline für einen Sprint hinarbeiten, sei es vorgekommen, dass die Designer ihr Material irgendwann am Freitagnachmittag ablieferten. "Uns bleiben dann quasi nur noch 15 Minuten, um das alles einzubauen", merkt Julius etwas überspitzend an. Langhanki stimmt zu und empfiehlt Alex & Co., zumindest das Gros der Daten zukünftig schon am Donnerstag bereitzustellen. Beim Design-Team ist man sich der Problematik bewusst und verspricht, dementsprechend umzuplanen.
Die Stimmung am Ende des Meetings ist spürbar gedrückt; der Versuch Jarons, ein paar motivierende Wort zu finden, scheint zumindest in diesen Minuten nicht zu fruchten. Alle Anwesenden wissen: Um auch nur das Minimalziel zu erreichen, muss das Team jetzt gewaltig aufs Gaspedal drücken. Die sechs Tage bis zur Beta-Deadline werden arbeitsreich. Sehr arbeitsreich.
Nach der Besprechung plaudere ich noch etwas mit Thomas Langhanki. Es sei ganz gut, dass es endlich mal etwas gerappelt habe und einige Probleme angeprochen wurden, sagt er und schiebt allerdings gleich nach: "Ich bin mir aber nicht sicher, ob es schon ausreichend geknallt hat." Ob er sich in diesem Moment wirklich einen größeren Streit im Team gewünscht hat, ist nicht klar. Klar ist rückblickend allerdings: Drei Tage später wird er ihn bekommen.
Im vierten Teil der Reportage: Beta-Endspurt und ein 'Nebenkriegsschauplatz'
Der wichtige Weckruf
In der zweiten Woche der Produktion hatten die Studenten zwar einige Fortschritte gemacht, waren dabei aber auch zur Erkenntnis gekommen: Mit Dienst nach Vorschrift wird man das Projekt The Deadline nicht erfolgreich beenden können. Neben der Zeitnot hatten die vergangenen Tage auch einige Abstimmungsprobleme im Team offenbart, die vor allem im Meeting am Freitag zum Vorschein kamen. War das ein wichtiger Weckruf?
Wie in Schreibtrance bringe ich als fliegender Reporter in der Nacht zum Montag die ersten Artikel zu Papier. Erst wird es spät, dann wird es früh. Es ist der Ansporn, die von mir selbst gewählte Deadline für den Auftakt der Berichtserie über das MD.H-Projekt einzuhalten, der mich am Rechner hält. Und das Wissen darum, am nächsten Tag aber auch ausschlafen zu können. Das ist zumindest der Plan. Nach knapp vier Stunden Schlaf wird dieser jedoch von einem lärmenden Telefon zerklingelt:
"Hier gibt es gerade Riesenstress", flötet Thomas Langhanki vom anderen Ende der Leitung und murmelt knurrend etwas über Namen und Logos. Sollte uns (4Players) jemand einen offiziellen Teamnamen genannt haben, so wäre es doch ganz hilreich, falls wir den aus dem Bericht raushalten würden. Sonst könnte die Sache "explodieren". Ich willige ein - auch deshalb, weil im ersten Artikel eigentlich keinerlei Name erwähnt wird.
Ein Vorstoß wird zum Bumerang
Der Beobachter ist ein Teil des Experiments, heißt ein altes Sprichwort in Wissenschaftskreisen. Das ist auch im Fall von The Deadline 
So sieht The Deadline aus, als die Beta-Ziellinie erreicht wird. Hier das erste Animationsvideo! nicht anders, denn angesichts der nahenden Berichterstattung über ihr Spiel bricht im Design-Team am Wochenende (ohne unser Wissen) plötzlich Hektik aus: Aufgrund der anstehenden Enthüllung möchte man dort auch rechtzeitig mit einem offiziellen Logo sowie einem Teamnamen präsent sein - etwas, das normalerweise in dieser Phase der Produktion keine hohe Priorität haben würde und dürfte. Das Hauptproblem: Der Rest des Teams bekommt davon nicht viel mit und fühlt sich auch dementsprechend übergangen. Wegen der Logogestaltung hätte es zudem während des Wochenendes auch unter den Designern Streit gegeben, ist von den Dozenten zu hören.
Am Freitag Abend wären immerhin die Leute, die auf Skype verfügbar waren, über das Logo informiert worden; eigene Anmerkungen seien aber wohl "eher ignoriert worden", heißt es da aus der Developer-Abteilung von mehreren Mitgliedern. Als sie dann später über den Teamnamen in Kenntnis gesetzt werden - einige erfuhren es dem Vernehmen nach am Sonntagabend, andere wohl am Montagmorgen - ist der Bogen endgültig überspannt. Es kracht. Erst ein mehrstündiges Meeting kann die Gemüter etwas beruhigen. Es wird beschlossen, zukünftig Design-Treffen abzuhalten, in denen Vertreter beider Fraktionen mitwirken sollen.
Es ist kein optimaler Start in eine Woche, in der doch alle am gleichen Strang ziehen müssen, um das Ziel zu erreichen. Zu den politischen Herausforderungen innerhalb des Teams kommen zudem noch gesundheitliche, fegt doch eine Erkältungswelle durch die Klasse, der sich kaum einer der Beteiligten entziehen kann. Einige husten, einige schnupfen, während sie da vor ihren Rechnern sitzen.
"Das Haus war weg"
Das Einführen von Kernarbeitsszeiten zeigt seine Wirkung: Einzig der leicht vergrippte Vito darf aufgrund der Umstände weiterhin etwas später antreten. Trotz der widrigen Umstände und des Streits am Montag ist Mitte der Woche dann doch Licht am Ende des Tunnels zu sehen. "Dadurch, dass die Developer sich schon am Wochenende mit den Baustellen auseinander gesetzt haben, hatten sie ihren Durchbruch schon am Dienstag", merkt Projektleiter Jaron Mitte der Woche an. Auch würden sich die vereinbarten Design-Meetings auszahlen. Kürzere Meilensteine würden allerdings auch manchmal mehr Hektik in die Abläufe bringen und den Informationsfluss etwas stören.
Fummelei: Marcel baut "Splines" in die Hausblöcke.
Anfang der Woche habe er mit Alex die Daten etwa aufräumen wollen und dabei auch ein paar Dateien entsprechend der ursprünglichen Namenskonventionen umbenannt. Prompt wurden diese nicht mehr von den anderen Paketen gefunden: "Tja, da war dann halt plötzlich das Haus weg. Und als wir das wieder hatten, haben uns immer noch die Kollisionen gefehlt." Für die Reparaturarbeiten habe man knapp zwei Stunden benötigt, merkt Jaron seufzend an, bevor er doch etwas schmunzelt.
Rückblickend lächeln kann auch Benjamin, dessen Abteilung mehr als einen Tag darauf verwendet hat, den Zombies endlich das Laufen beizubringen. Trotz bestehender Pfade und entsprechender Animationen hätten sich die Untoten geweigert, das Bürohaus sachgemäß zu betreten. Nach etlichen Experimenten und Nachforschungen habe man dann herausgefunden, dass es bei UnrealScript einen simplen 'walk on floor'-Befehl gibt, der das Problem behebt - hier ein erstes Animationsvideo.
An anderer Stelle gibt es frische Lösungsansätze: Statt eine Animation für das Öffnen des Aktenschrankes zu produzieren, sei es doch viel einfacher, den Anfangs- bzw. Endzustand des Modells zu nehmen und die Zwischenzustände morphen zu lassen. Auch für das Anbringen der Upgrades (Kleber, Feuer, Beamer) an die 'Türme' habe man einen Ansatz gefunden: Dies werde über Sockets an den Modellen verwirklicht; so werden in der Unreal Engine Waffen an Charakere gepappt.
Mehr Ordnung im Design
Die Abläufe in der Designabteilung seien mittlerweile geordneter, findet Benjamin. Da die Developer das Unreal Dev Kit jetzt recht gut beherrschen würden, gebe es weniger Problemfelder. Mittlerweile könne man dadurch auch zwei Entwickler an eine Aufgabe setzen, was die Zeit bis zur Lösung deutlich verkürzen würde. Probleme technischer Art muss man hingegen noch beim Versions-Kontroll-System beheben: Um Flaschenhälse zu vermeiden habe man allen Teammitglieder beliebigen Zugriff auf die Daten gewährt. Es sei dadurch allerdings vorgekommen, dass Dateien verschwanden, nachdem sie von mehreren Leuten gleichzeitig bearbeitet wurden.
Die Mischung aus langer Arbeit und Erkältungen hinterlässt auch in den Gesichtern einiger Studenten ihre Spuren.
Friemelige Arbeit steht auf Marcels Speiseplan. Er ist u.a. zuständig für das Einbauen der Splines - der Pfade, an denen sich sowohl Udo als auch die Zombies im Bürogebäude orientieren. Gelegentlich wird das schon mal zur Millimeterarbeit, wenn die verwesenden Ungetüme beim Treppenaufstieg nicht hängenbleiben sollen. Und gibt es größere Änderungen an jenen Modellen, so darf Marcel auch die Splines wieder anpassen. Jene Pfade sind auch einer der Hauptgründe dafür, dass sich der Luxuswunsch der Entwickler, vielleicht auch zufallsgenerierte Level bieten zu können, zumindest momentan nicht umsetzen lässt. Zwar kann das Design-Team diverse Gebäudeblöcke erschaffen, die man dann beliebig stapeln kann. Wie man dann aber die darin vorhandenen separaten Splines per Skript zu einem einzigen verknüpft, ist den Developern zumindest derzeit nicht bekannt.
Die Punktlandung der "Random Guys"
Am Nachmittag trifft sich das gesamte Team, um endlich gemeinsam über das zu entscheiden, was Tage zuvor reichlich Ärger verursacht hatte: Man kürt eines der von Anna entwickelten Logos für The Deadline. Als Name für das Team setzt sich 'Random Guys' (je nach Geschmack: 'Zufallstypen' oder 'zufällige Typen') durch. Noch knapp 48 Stunden bleiben dem Team bis zur Implementierung der wesentlichen Features. "Ich würde sagen, wir bleiben hier, bis man uns rausschmeißt. Um dann nach Hause zu gehen und dort weiterzumachen", gibt Jaron als Parole aus.
Falco informiert sich auf 4Players.de über den Stand des Projekts.
Der Turbo, den die Random Guys in den vergangenen Tagen eingelegt haben, macht sich bezahlt: Am Freitag haben die Studenten dann auch tatsächlich größtenteils das erreicht, was vor einer Woche noch in weiter Ferne schwebte. Das, was im Spiel zu sehen ist, ist noch nicht übermäßig hübsch oder geschmeidig, auch die Menüs und Anzeigen gehören eher der Kategorie 'Platzhalter' an - Feinschliff war allerdings auch nicht das Ziel der ersten drei Wochen. Udo kann mittlerweile Stifte einsammeln und Türme aktivieren; die Zombies latschen zielsicher durch das Gebäude. Mit den Upgrades harrt allerdings noch ein Element seiner Umsetzung, da die Sockets noch nicht so ganz funktionieren, wie man sich das vorgestellt hatte. Bis zum Anfang der nächsten Woche werde aber auch jenes Problem aus der Welt geschafft sein, ist man sich sicher.
Marco Block-Berlitz, der genau sieben Tage zuvor noch mahnend in Erscheinung treten musste, hat in diesem Meeting nur lobende Worte für die Studenten übrig. "Das, was ihr hier erreicht habt, konntet ihr nur als Team schaffen", so ein Fazit. Man habe innerhalb von drei Wochen ziemlich viel auf die Beine gestellt. Auch der ebenfalls anwesende Julian Kücklich (4Players-Leser
 |
| The Deadline wird im abschließenden Freitagsmeeting vorgeführt. |
Ziel: Levelbau, Animationen, Effekte, Sounds
Nach einem kurzen Rückblick werden dann auch die Weichen für die verbleibenden drei Wochen gestellt. Das Design-Team wird sich z.B. um das Bauen der Level - geplant waren vier bis fünf - kümmern müssen. Auch fehlen noch diverse Assets wie Objekte, Animationen und Partikeleffekte, die integriert werden sollen. The Deadline ist derzeit zudem völlig stumm; spätestens in der fünften Woche sollen Sounds und Musik eingebunden werden.
Bei den Developern soll zuerst der Kehrbesen geschwungen werden, verkündet Benjamin. Aufgrund der knappen Zeit seien viele Teile des Codes nach dem "quick'n'dirty"-Prinzip entstanden. Kommentiert habe man auch nur wenig. Mats verzweifelt leicht an den Triggern, die man derzeit im Spiel hat. Pro Gebäudeecke würde es einen Trigger für das Ändern der Kamera geben - und zwei, die den Kamera-Schalter wieder zurücksetzen in Abhängigkeit von der Richtung, in die man geht. Dies sei aber ein extrem
 |
| Beta-Ziel erreicht: Frodo (Mats) feiert mit einem Fläschchen Bier. |
Mehr werden es zumindest an diesem Freitag auch nicht mehr - nach dem geglückten Schlussspurt lehnen sich die Random Guys erstmal etwas zurück und genießen das Bier, das Lynn per Rucksack mitgeschleppt hat.
Alex kündigt sogleich an, erstmal ordentlich auszuschlafen. Er, der auch schon zum ursprünglichen Tower of Doom-Team gehörte, hat in dieser Woche zweimal völlig durchgearbeitet und hat an den anderen Tagen frühestens um 4 Uhr den Weg ins Bett gefunden. Der Design-Lead hatte allerdings dem Vernehmen nach auch in den zwei Wochen zuvor bereits ordentlich Überstunden geleistet. Dementsprechend glücklich, aber auch müde begibt er sich ins Wochenende.
Der Beta-Stress ist überstanden - jetzt bleiben den Studenten noch drei Wochen, um aus dem Rohmaterial ein rundes, zugängliches und ausbalanciertes Gesamtwerk zu schaffen. Wer nicht bis zum nächsten Bericht warten will, sollte einen Blick auf das just eingerichtete Blog des Teams werfen.
Im fünften Teil der Reportage: Optimierungen und der Blick auf die Zielgerade.
Die Zielinie - So nah und doch so fern
In der letzten Woche der ersten Produktionshalbzeit hatte der Kurs GD 1007 an der Mediadesign Hochschule Berlin alle Kräfte mobilisieren müssen, um den eingeplanten Meilenstein zu erreichen. Das Zwischenziel wurde knapp erreicht - wer jedoch glaubt, der Rest der Produktion wird ein Spaziergang, der irrt.
Nach dem Spurt ist vor dem Spurt
Auch nach drei Wochen gibt es zahlreiche Baustellen. Eine davon ist das User-Interface, denn von den Anzeigen für Upgrades und Countdown mal abgesehen gibt es am Anfang der zweiten Halbzeit noch keinerlei Feedback, das der Spieler erhält. Ob es um das Aktivieren von Büro-Equipment, Objekthinweise oder simple Partikeleffekte geht - sie fehlen derzeit und rücken deswegen in den Fokus der Random Guys. 
Alex experimentiert mit Level-Sets herum.
Ein weiteres Schwergewicht auf der 'To-do'-Liste der Developer: Der Zombie-Generator. Bis dato werden die untoten Zeitgenossen per Knopfdruck in die Welt gebeamt, wenn die Entwickler sie für Testzwecke benötigen. In der finalen Fassung hingegen müssen sie natürlich nach Skript-Vorgaben aus einer (ebenfalls noch nicht integrierten) U-Bahn-Station ins Geschehen maschieren. Das vorläufige Ziel: Es soll mehrere Sets mit Gruppen geben, aus denen zufällig und in Abhängigkeit von der Spielphase welche ausgewählt und zusätzlich zu einer festgelegten Zombie-Linie auf den Spieler losgelassen werden.
Designer und Developer gehen munter zu Werke und können in den ersten Tagen einige der Punkte auf der Liste abhaken. Das Ziel, am Ende der vierten Woche eine Version zu haben, die auch von Außenstehenden gespielt werden könnte, verfehlt man jedoch. Spätestens jetzt dürften die Beteiligten wohl froh darüber sein, dass es sich 'nur' um ein Studienprojekt handelt - bei einer kommerziellen Produktion könnte der Geldgeber (also in der Regel der Publisher) vertraglich vereinbarte Zahlungen einbehalten angesichts der Unpünktlichkeit des Partners.
Das Interface verdient sich nämlich auch am Ende der Woche das Prädikat 'under construction'. Ein Teil der geplanten Rückmeldungen fehlt nach wie vor; ein Teil ist nicht aktuell und verwirrt unbedarfte Nutzer u.a. mit falschen Steuerungshinweisen, was prompt von Thomas Langhanki moniert wird.
Das Weitergeben an Dritte wäre momentan aber auch aus technischen Gründen nicht möglich - die Developer arbeiten immer noch daran, erstmal die entsprechenden Pakete zu bauen und eine Version von The Deadline zu 'kochen', die auf anderen Rechnern installiert werden kann.
Mats konnte dem Spiel immerhin die geplante Trigger-Diät verpassen: Statt durch insgesamt drei Trigger pro Gebäudeecke wird das Schwenken der Kamera jetzt über die Position verwirklicht, die Udo relativ gesehen zu einem bestimmten Objekt innerhalb des Levels erreicht.
Zombies mit Kollisionsboxen.
Konzeptueller Nebelwerfer
Dass es dem Gamedesign-Dokument an Umfang und Ausführlichkeit mangelt, hatten die Dozenten schon etwas früher kritisiert. Die dadurch resultierenden Unklarheiten erweisen sich in Kombination mit nur wenig gepflegten Schriftstücken, mangelnder Kommunikation und dem Stille-Post-Effekt als Hürden, die The Deadline beim Einbiegen auf die Zielgerade gelegentlich leicht ins Straucheln bringen.
Upgrades lassen sich zuerst nur direkt beim Aktivieren eines Aktenschranks, Stuhls oder Ventilators an das Objekt anbringen. So jedenfalls hatte man bei den Developern den Arbeitsauftrag verstanden. Für die Designer hingegen scheint klar: Udo soll aktivierte Objekte jederzeit - also auch später - aufwerten können.
Auch an anderer Stelle wird doppelte Arbeit fällig. Für alle Bürogegenstände gilt: Sie sind immer nur für eine bestimmte Zeit in Betrieb und verschwinden danach wieder in den Hintergrund. Der Interpretation der Developer-Gruppe zufolge beginnt dieser Timer jeweils mit der Aktivierung eines Objekts durch Udo. Von den Gamedesignern kommt nach der ersten Implementierung allerdings die Ansage: Der Deaktivierungs-Timer sollte doch erst nach dem ersten Kontakt mit einem Zombie gestartet werden.
Zumindest in der Theorie wären beide Missverständnisse eigentlich vermeidbar gewesen. Die Praxis sieht allerdings anders aus - und resultiert in Korrekturen, die nicht mal fix innerhalb von fünf Minuten getätigt werden können.
Erst in der fünften von sechs Wochen wird final entschieden, was eigentlich passieren soll, wenn Udo einen Aktenschrank aktiviert, während ein Untoter an diesem vorbeiläuft. Nachdem man die beiden Optionen etwas länger erörtert hat - der Zombie fliegt aus dem Gebäude (wird also eliminiert) vs. der Gegenstand lässt sich in jenem Moment nicht aktivieren -, einigt man sich auf eine Kombi-Lösung: Normale Gegner werden rausgeschubst, dicke blockieren den Schrank hingegen.
Ebenfalls etwas mehr Arbeit als geplant verursacht der Feuerschaden, den man Untoten mit dem Feuerzeug-Upgrade verpassen kann. Brennende Zombies sollen auch ihre Kollegen anstecken können, heißt die Vorgabe aus der Design-Abteilung. Ein etwas mürrischer Kommentar von den Developern, die das dann umsetzen dürfen: "Ich bin mir jetzt nicht so sicher, wo das Konzept jetzt eigentlich herkommt. Ich glaube, vor zwei Wochen gab es das noch gar nicht."
Es darf gekürzt werden
Dass das Team nach dem knappen Erreichen des Bergfestes vielleicht etwas übermütig geworden ist und sich schon mit der Kür beschäftigt hat, bevor die Pflicht überhaupt abgeliefert wurde, sehen die Studenten in der fünften Woche selbst ein. Man habe plötzlich einige neue Einfälle gehabt, anstatt sich auf die wesentlichen Dinge zu konzentrieren, so Jaron, der Projektleiter. Konzepte wie ein Bossgegner oder die speicherbare Highscore-Liste werden vorerst wieder in die Mottenkiste gepackt. Und die wird erst wieder geöffnet, wenn/falls das Soll abgearbeitet werden konnte. Durch den 'Feature Freeze' soll auch das Eröffnen neuer Problemherde eingedämmt werden.
Wenn ein Projekt in Not gerät, bleiben für gewöhnlich zwei Alternativen: Es müssen mehr Ressourcen zur Verfügung gestellt oder Anforderungen gestrichen werden. Da sich das Team innerhalb weniger Tage nicht wundersam vermehren kann und der Termin für den Projektabschluss in Stein gemeißelt ist, sind die Konsequenzen relativ eindeutig. Dabei werden nicht nur die oben genannten Zöpfe abgeschnitten, auch an andere Stelle muss der Rotstift gezückt werden. Nachdem man zwei Wochen zuvor schon einsehen musste, dass man innerhalb der Produktionszeit keinen Generator für Zufallslevel umsetzen können wird, legen die Random Guys jetzt fest: Statt der ursprünglich anvisierten vier bis sechs Karten soll es nur noch drei geben. Auch von der Idee eines geskripteten Tutorials verabschieden sich die Studenten.
Im Mini-Meeting wird beschlossen: Keine Zeit für Extra-Features!
Erhitzte Gemüter
Von Aufregern, die das ganze Team erfassen wie der Logo- und Namensstreit vor zwei Wochen, sind die Entwickler in der Zeit danach größtenteils verschont geblieben. Einige zwischenmenschliche Reibereien gibt es naturgemäß dennoch hier und da bei hier nicht näher benannten 'Zufallsjungs'.
Dass einer der Designer den Umstand, dass ein von ihm erarbeitetes Werk von den Developern noch nicht in die aktuelle Version integriert haben, mit einem leicht knurrigen 'Fick dich' quittiert, sorgt in jener Abteilung nicht unbedingt zur Freude.
Zwischen zwei Mitgliedern des Design-Teams war es Tage zuvor hingegen fast zu Handgreiflichkeiten gekommen. Bei der Schulleitung war man angesichts des Vorfalls nicht allzu sehr angetan und erteilte den Streithähnen einen Verweis. Es sei an dieser Stelle angemerkt, dass die beiden kurze Zeit später wieder quietschvergnügt nebeneinander saßen.
Erregte (und dementsprechend lautstark geführte) Diskussionen gab es auch an anderer Stelle. Erst mit einer Aussprache wird schließlich der drohende Ausschluss eines anderen Teammitglieds abgewendet. Unmut anderer Art gibt es bei dem einen oder anderen Entwicklern wegen der Datenbestände. Aufgrund des unsachgemäßen Zugriffs auf gemeinsame Daten - sprich: ohne korrektes Update - sind beim Zurückschreiben schon mehrmals bereits vorhandene Dateien überschrieben und geleistete Arbeit zunichte gemacht worden. Das Wiederherstellen der Assets ist zwar möglich, kostet aber Zeit und Nerven.
Die aber werden in den letzten sieben Tagen der Produktion benötigt, ist die Planung doch auch nach dem Griff zur Schere nach wie vor ziemlich heikel. Auch am Ende der fünften Woche gibt es keine Version, die man einfach auf anderen Rechnern installieren kann. Johannes, der in den Tagen zuvor krank das heimische Bett gehütet hatte, äußert dann auch im Freitagsmeeting sein Unverständnis darüber, dass sich kein anderer in der Zwischenzeit seiner Baustelle angenommen hat. Dort wartet nämlich mit dem Zombiegenerator gleich noch ein weiteres Problem auf seine Bewältigung.
Bisher ist The Deadline noch völlig stumm, da weder Sounds noch Musik eingebunden wurden. Lynn hat sich zwar schon etwas mit dem Thema auseinandergesetzt - vorzeigbare Ergebnisse gibt es jedoch noch nicht. Dass nicht einfach schon mit Dummy-Effekten und -Musik gearbeitet wurde, versteht Marco Block-Berlitz allerdings nicht so recht. Auch Benjamin merkt an, man müsse doch überhaupt mal austesten, an welchen Stellen der Spieler letztendlich akustisches Feedback präsentiert bekommen werden soll.
Studenten aus anderen Kursen dürfen The Deadline schon mal antesten, um Feedback zu liefern.
Block-Berlitz wiederum rät dem Team, sich doch schnellstens um das Bauen einer installierbaren Version zu kümmern. Es nütze niemandem etwas, falls stattdessen noch das eine oder andere weitere Feature implementiert werden kann. "Ihr habt dann trotzdem kein Spiel!", heißt es da mit Verweis auf das vereinbarte Ziel, ein Stück Software zu erschaffen, das nach dem Abschluss der Produktion auch anderen zur Verfügung gestellt werden könnte.
Ebenfalls mit reichlich heißer Nadel gestrickt ist das Tuning des eigentlich Spielgeschehens. Aufgrund der technischen und inhaltlichen Baustellen gibt es hier bisher kaum Erfahrungswerte. Zwar wurden vereinzelt Studenten aus anderen Klassen für kurze Testsessions rekrutiert - wirkliche Aussagen über die Praxistauglichkeit dessen, was lange nur auf dem Papier existierte, wird man aber erst in der letzten Woche treffen können. Spielraum für größere Korrekturen wird es dann allerdings nicht mehr geben.
Bis dahin müssen die Designer auch Fragebögen erarbeitet haben, um das Feedback der Tester systematisch erfassen zu können. Deren Meinung wird in den letzten Tagen maßgeblich sein, haben Debatten in den vorherigen Tagen doch bereits aufgezeigt, dass zumindest einige der Entwickler dazu tendieren würden, The Deadline zu schwierig zu gestalten für Außenstehende.
Julius übernimmt hingegen die Verantwortung für das Erstellen von Testfällen in seiner Abteilung, sieht er doch ein anderes Problem: Bisher waren die Developer nahezu ausschließlich damit beschäftigt, Dinge umzusetzen. Die Suche nach Fehlern habe dagegen kaum stattgefunden. Sein Fazit: "Wir haben ziemlich viele Sonderfälle. Na ja, eigentlich besteht das Ganze fast nur aus Sonderfällen. Es gibt garantiert massig Bugs im Code."
Freitagsmeeting: Die Stimmung war auch schon mal besser.
Viel, sehr viel Tuning- und Testbedarf, nicht gar so wasserdichte Skript-Konstruktionen sowie diverse, noch nicht bewältigte Herausforderungen - die finale Woche der Produktion wird den Studenten vor allem eines nicht bieten: Freizeit.
Im nächsten Teil: The Deadline trifft auf die Deadline.
The Deadline nähert sich der Deadline
Die letzte der insgesamt sechs Wochen ist angebrochen und den Random Guys verbleiben nur noch ein paar Tage Zeit, das Projekt wie geplant abzuschließen. Einmal mehr müssen sich die Studenten voll ins Zeug legen, um die von ihnen selbst gesteckten Ziele noch erreichen zu können. Einmal mehr musste das Wochenende herhalten, um verlorene Zeit aufzuholen und noch offene Baustellen angehen zu können.
Der Zusatzaufwand macht sich an mehreren Stellen bemerkbar: Das Beleuchtungsproblem aus der vergangenen Woche wurde behoben, benutzbare Objekte sind endlich wieder erkennbar. "Wir haben außerdem das Interface optimiert. Na ja, eigentlich haben wir die Codebasis dafür fast komplett neu geschrieben", merkt Benjamin noch an. Die Steuerung reagiere jetzt deswegen u.a. deutlich fixer auf die Eingaben des Nutzers.
Ein weiterer Punkt auf der 'To-Do'-Liste, der endlich abgehakt werden kann: Der Generator für die Zombiewellen funktioniert wie vorgesehen. Waldemar, der im Bereich Gamedesign das Heft in der Hand hält, fängt an, Listen mit Gruppen zusammenzustellen, aus denen dann abhängig vom jeweiligen Countdown zufällig Zombie-Trupps ausgewählt und in die Abschnitte integriert werden.
Nach sechs Wochen Produktionszeit sind viele der Studenten reif für die Ferien
Um etwas Abwechslung in die Welt der Untoten zu bringen, haben sich die Designer noch ein schnell ein paar neue Typen ausgedacht. Jetzt gibt es z.B. einen feuerresistenten Untoten, der mit einem Feuerwehrhelm daherkommt. Immun gegen die lähmende Wirkung des Beamers sind hingegen die verwesenden Zeitgenossen, die eine Sonnenbrille tragen. Zusätzlichen Code habe man dafür nicht schreiben müssen, wirft Jaron ein. Man hat sich bereits vorhandene Eigenschaften bzw. Variablen zu Nutze gemacht; Sonnenbrille und Helm seien flott modelliert worden.
Stiftung Zombietest
Da die Developer mittlerweile auch eine Version 'kochen' können, lässt
Video: Auf einer finalen Team-Sitzung werden die letzten Hürden besprochen.
sich The Deadline auch problemlos auf anderen Rechnern installieren. Seit Anfang der Woche wird das Spiel von Studenten aus anderen Kursen der MDH Berlin durchgetestet. Das bisherige Feedback: "Viele Bugs waren uns natürlich schon bekannt. So sind die Animationsfehler, die auftreten können, doch ziemlich häufig aufgefallen." Beispielsweise fliegen beim Aktivieren (der dann herumschwingenden) Ventilatoren noch Modell und Sockets auseinander. Das Ergebnis: Die Partikeleffekte nach dem Anbauen eines Upgrades sitzen nicht korrekt. Kurze Zeit später hat man das Problem dann aber im Griff.Allerdings gewinnt man durch die Testsessions auch noch andere Erkenntnisse. "Das Spiel ist den Leuten entweder zu schwer - oder viel zu leicht." Jene Feststellung ist auch einer der Gründe dafür, dass sich die Random Guys nun dazu entschließen, doch insgesamt sechs Level zu bauen. Auch hier gilt: Völlig neue Inhalte und Assets sollen und dürfen nicht mehr erstellt werden - jede der eingeplanten drei Karten soll doppelt verwendet und mit unterschiedlichem Equipment sowie Zombiewellen versehen werden.
 |
| Wenn sich mehrere Leute vor einem Bildschirm sammeln, gibt es entweder etwas frisch Implementiertes zu sehen - oder ein Problem. |
Auch für den Aufbau der Level hat das Feedback der Tester einige Implikationen. Man habe die Möbel alle etwas mehr in die Mitte gerückt; das Benutzen von Objekten, die nah am Rand (und damit: nah an der Kameradrehung) stehen, habe sich als etwas knifflig erwiesen. Last but not least: Die Bewegungsgeschwindigkeit Udos und der Zombies wurde als Resultat der Fragebogenauswertung angepasst. Sowohl der Roboter als auch die Zombies bewegen sich jetzt etwas flinker durch das Bürogebäude.
Es werde Schall
Im Bereich Sound & Musik ist Licht am Ende des Tunnels zu sehen. Effekte und Lieder könnten jetzt im Wesentlichen abgespielt werden, sagt der an dieser Stelle etwas über Nacht-und-Nebel-Aktionen sinnierende Benjamin am Mittwoch. Ohne Risiko ist die späte Umsetzung natürlich nicht: "Sollten sich morgen irgendwelche Probleme bei der Umsetzung ergeben, dann haben wir keine Zeit mehr, das zu fixen. Dann bleibt The Deadline ohne Sound." 
Kurze Beratung über das Einbinden von Sounds
Marian und Vito sind dafür zuständig, dass die Form nun auch mit Inhalten gefüllt werden kann. Den ganzen Montag hindurch hat sich das Duo die über 200 zur Verfügung stehenden Sound-Samples angehört, um sich einen ersten Überblick zu verschaffen. Am Dienstag machen sich die beiden daran, die besten Effekte auszuwählen, am Tag darauf beschäftigt man sich dann damit, diese für das Spiel anzupassen bzw. für die Einbindung vorzubereiten.
Julius und Thomas haben sich in den Tagen zuvor mit der Performance des Spiels auseinandergesetzt - derzeit sind die Anforderungen der Software den Entwicklern nämlich etwas zu hoch. Mit dem testweisen Abschalten der Schatten habe man immerhin schon mal zehn Frames pro Sekunde gewinnen können; als deutlich ressourcenhungriger erweist sich allerdings das Post-Processing der Unreal Engine, also das nachträgliche Versehen der gerenderten Grafik mit Effekten. Thomas, der Shader-Spezi des Teams, beginnt sich daraufhin Gedanken über mögliche Optimierungen zu machen. Am Donnerstag Abend sollen alle Bausteine integriert sein, damit eine Version gebaut werden kann, gibt Jaron als Ziel aus. Freitag wolle man sich nur noch Feinarbeiten und Korrekturen widmen. 
Die Random Guys nehmen die Performance des Spiels unter die Lupe
Fast am Ende
Es ist Freitag - und die vom Projektleiter ausgegebene Parole erweist sich als frommer Wunsch. "Wir haben sechs Level - allerdings sind nur zwei davon auch wirklich getestet", heißt es da. Die Last-Minute-Implementation und die fehlenden Tests rächen sich jetzt etwas; wohlgemerkt nicht nur hinsichtlich der Feinabstimmung des Schwierigkeitsgrads.
Nachdem sich die beiden in den Tagen zuvor u.a. mit dem Ressourcenhunger des Spiels auseinandergesetzt haben, müssen Thomas und Julius beim Einbau der weiteren Inhalte feststellen, dass einige der anderen Level deutlich weniger performant sind als das Material, das bereits früher spielbar vorlag. Auf Julius' Rechner läuft The Deadline in jenen Karten mit 28 bis 30 Bildern pro Sekunde - kein berauschender Wert angesichts dessen, was da unter der Haube seine Rechners (Quadcore-CPU, 3 GB RAM samt potenter Grafikkarte) steckt.
Auf mittelprächtigen Rechnern dürften die Zombies also spürbar ruckliger durch die Gegend geistern. Eine Stunde lang bemüht man sich noch, die Ursache dafür zu finden, Am späten Mittag ist jedoch klar: Innerhalb des offiziellen Zeitrahmens wird sich das Problem nicht mehr beheben lassen. Kurz nach 14 Uhr ist es dann so weit: The Deadline trifft auf seine Deadline.
Bis zur letzten Minute werden noch eifrig Fehler behoben
Die Abschlusspräsentation
Mit der finalen Version geht es in die Abschlusspräsentation, der neben den Dozenten auch noch diverse Leute aus anderen Studiengängen beiwohnen. Da diverse Inhalte und einige kleinere Funktionen noch im Laufe des Tages in das Spiel hineingebastelt wurden, blicken auch die Entwickler selbst gespannt auf das, was da nun per Beamer auf die Wand geworfen wird. Als dann die Zombies in das Gebäude einbrechen und die ersten Grunz- und Stöhngeräusche in den Raum schallen, bricht dann auch lautes Gelächter aus - viele der Anwesenden hatten jene von einigen Mitgliedern des Teams aufgezeichneten Samples noch nicht gehört.
Es ist deutlich zu sehen, wie nach sechs Wochen Produktionszeit die Anspannung von den Studenten abfällt. Es wird gescherzt, es wird gegrinst, als Adomat, der The Deadline vorführt, sich an einem der höheren Level versucht und gnadenlos überrannt wird - allzu oft bekommt ein Game Over-Bildschirm wohl keinen Szenenapplaus spendiert. Das Wissen um den Abschluss des Projekts und darum, dass man sich am kommenden Wochenende mal nicht mit den Untoten auseinandersetzen muss, tut sein Übriges.
Am Ende der Produktionszeit hat The Deadline den Stand einer fortgeschrittenen Beta. Wäre das Projekt ein Boot, so würde es den Stapellauf problemlos überstehen, ohne gleich unterzugehen. Komplett sturmtauglich ist es allerdings nur begrenzt, da viele Teile erst kurz vor der Taufe installiert wurden und dementsprechend unerprobt sind. Dass die Karten zu spät fertig wurden und damit nicht ausreichend hinsichtlich der Spielbalance und der Performance getestet werden konnten, ist allen Beteiligten klar. Von Seiten der Dozenten war schon zuvor angeprangert worden, dass es lange Zeit nur einen dedizierten Level-Designer bei den Random Guys gab.
Wirklich unzufrieden ist jedoch niemand in diesem Moment. Der Stapel dessen, was nicht oder nicht wie geplant erreicht wurde, ist verschwindend klein gegenüber dem, was die Random Guys in diesen sechs Wochen tatsächlich auf die Beine gestellt haben. Jarons einleitendes Fazit lautet dann auch: "Eine Sache kann man schon mal sagen: Wir haben es geschafft, als Team zusammenzuarbeiten, obwohl viele nicht geglaubt haben, dass das funktioniert."
Die Zombies schlufen endlich los - wenn auch nicht ganz so performant wie erhofft
Die Zielflagge wird gewunken
Auch von den Dozenten gibt es viele anerkennende Worte, war ihnen doch bewusst, wie ambitioniert das Vorhaben doch eigentlich war, war ihre zwischenzeitliche Skepsis angesichts verpasster Meilensteine doch nicht nur gespielt gewesen. Aus Sicht der Lehrkräfte hat das Team noch die Kurve gekriegt und das Projekt erfolgreich abgeschlossen. Nicht nur wegen des Ergebnisses - im Mittelpunkt stand schließlich auch die Erfahrung, die die Studenten sammeln sollten. Von denen hatten schließlich die meisten bisher nur in Kleingruppen zusammengearbeitet. Und keiner von ihnen hatte zuvor die Unreal Engine und UnrealScript verwendet. Fast alle Problemen, die die Studenten in den Wochen zuvor meistern mussen, begegnet man in der einen oder anderen Form auch im späteren Produktionsalltag. Nicht eingeplanter Zusatzaufwand, der durch die Einbindung oder Entwicklung neuer Technologie verursacht wird, gibt es schließlich in der Regel überall, wo Neuland betreten wird.
Auch in Sachen Kommunikationsproblemen sind die Random Guys beileibe kein Sonderfall - je größer eine Firma ist, desto größer ist auch das Potenzial, dass es genau in diesem Bereich hakt. Angesichts der Tatsache, dass die Studenten in dieser Konstellation noch nicht kooperiert hatten, waren zwischenzeitliche Ungereimtheiten und daraus resultierende Konflikte nahezu unvermeidbar. Eher entscheidend und herauszuheben ist der Umstand, dass diese auch konstruktiv bewältigt werden konnten. Ob teamweiter Streit um Namen sowie Logos oder eine Beinahe-Schlägerei - nichts davon hinterließ dauerhafte Spuren in Form tiefer Gräben zwischen den involvierten Parteien. Auch darauf können die Random Guys durchaus stolz sein.
Nachträglich ist man bekanntermaßen immer schlauer, und so ist dann auch einer der Einwürfe: "Wenn wir das, was wir jetzt wissen, bereits am Anfang gewusst hätten, dann wären wir nach drei Wochen fertig gewesen." Für uns als Spielmegazin war die Begleitung des Projekts ebenfalls ein interessantes Experiment, hatte die Mediadesign Hochschule Berlin doch einen uneingeschränkten Zugang zum Team zugesichert und das trotz unserer kritischen Beobachtung eingehalten. Im Laufe der sechs Wochen konnte ich das Team jederzeit (ohne Ankündigung) besuchen, beliebigen Meetings beiwohnen, Interviews führen oder den Studenten einfach bei der Arbeit über die Schulter schauen. Das Berichten über Streitereien und Verweise dürfte dem Vernehmen nach bei dem einen oder anderen MDH-Angestellten leichte Kopfschmerzen verursacht haben - des Risikos und unseres Ansinnens, auch die Reibungspunkte in der Produktion zu beleuchten, war man sich allerdings im Vorfeld bewusst.
Per Kontextmenü werden Möbel mit Upgrades versehen
Untote im Anmarsch
Die Studenten dürfen sich derweil ihre wohlverdiente Auszeit genehmigen - einige von ihnen werden allerdings auch in den Ferien noch etwas umtriebig sein: The Deadline hat noch eine weitere Deadline zu bewältigen. Um den 19. März herum sollen die Zombies nämlich auch auf die Öffentlichkeit losgelassen werden. Die letzte größere Hürde wurde schon gemeistert, nachdem die Rechtsabteilung der MDH grünes Licht für den Release gegeben hat. Dort musste verständlicherweise überprüft werden, dass das Team auch die Rechte an den im Spiel eingebundenen Assets (bis hin zur Schriftart) hat bzw., dass diese frei verwendet werden dürfen, so dass nicht der Fall sein sollte. Bis zum Stichtag wollen die Random Guys noch ein wenig an der Spielbalance drehen, wenn möglich etwas an der Performance feilen und den einen oder anderen kleinen Bug ausmerzen. Ebenfalls noch eingebunden werden müssen für den Release notwendige Dokumente wie Steuerungshinweise und eine kurze Beschreibung des Projekthintergrunds - nicht jeder, der sich das Spiel herunterladen wird, dürfte sich vorher mit seiner Entstehungsgeschichte auseinandergesetzt haben.
Das letzte Kapitel in der Geschichte von The Deadline ist mit dem Abschluss unseres Entwicklungsberichts vielleicht aber noch gar nicht erzählt: Einige der Studenten spielen durchaus mit dem Gedanken, das Projekt zu einem größeren Spiel auszubauen, so die Anspielversion denn gut aufgenommen wird. Aus Sicht der Mediadesign Hochschule wäre das kein Problem - Steine würde man den angehenden Entwicklern in diesem Fall nämlich nicht in den Weg legen. In der näheren Zukunft dürfte allerdings kaum einer von ihnen Zeit dafür haben - im kommenden Semester werden die Bachelor-Arbeiten geschrieben.
Wir werden euch in zwei Wochen hoffentlich die Demo des Spiel anbieten können. Wer die Wartezeit bis zum Eintreffen der Untoten mit etwas Bildmaterial überbrücken will, wird in unserer Galerie fündig, wo es einige Impressionen aus der Abschlussversion gibt.
Die Random Guys - obere Reihe (v.l.n.r.): Anna, Vito, Adomat, Thomas, Marcel, Julian, Waldemar, Julius, Jo, Mats, Benjamin, Alex.
Untere Reihe: Jaron, Marian, Erdi, Lynn, Falco
Du musst mit einem 4Players-Account angemeldet sein, um an der Diskussion teilzunehmen.