Spielinfo Bilder Videos

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

Alex experimentiert mit Level-Sets herum.

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.

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.

Zombies mit Kollisionsboxen.

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.

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.

Im Mini-Meeting wird beschlossen: Keine Zeit für Extra-Features!

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.

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.

Studenten aus anderen Kursen dürfen The Deadline schon mal antesten, um Feedback zu liefern.

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.

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.

Freitagsmeeting: Die Stimmung war auch schon mal besser.

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."

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.