The Deadline - Special, Strategie, PC - 4Players.de

4Players.de Das Spielemagazin. Kritisch. Ehrlich. Aktuell. 4Players.de Das Spielemagazin. Kritisch. Ehrlich. Aktuell.

Um dieses Feature zu nutzen, musst du
"4Players pur" nutzen:

Du hast schon einen pur-Account? Dann logge dich ein!
Noch kein pur-Nutzer? 4Players pur – Zahl, was du willst!

Hinweis schließen.


Die Beta in Sichtweite

So sieht The Deadline im Unreal-Editor aus.
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 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.
Marcel hingegen baut ein paar provisorische Hintergrundkulissen, damit sich die Designer-Gruppe einen Eindruck davon verschaffen kann, was optisch am besten funktioniert. Ebenfalls auf der Arbeitsliste der Designer befindet sich das Interface: Man muss sich überlegen, was dem Spieler in welcher Form dargeboten wird. Das gilt auch für die Menüs, deren Struktur bereits über Baumdiagramme visualisiert wird.

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.
Am Anfang des abschließenden Freitagsmeetings wird erörtert, was seit dem letzten Treffen alles erreicht wurde. So führt Falco vor, dass Udo jetzt ein Item aufnehmen kann. Das Team applaudiert. Noch währenddessen schrauben einige der Developer an den Skripten herum und versuchen, Udo wieder das beizubringen, was er ein paar Stunden zuvor noch beherrscht hatte. Johannes hatte den Pfad, an dem sich der Roboter orientiert, schon implementiert - nachdem in der Design-Abteilung allerdings Änderungen am Modell Udos vorgenommen wurden, funktioniert die Bewegung nicht mehr. Erst während des Meetings gelingt es endgültig, das Problem wieder zu beheben. Das Projekt ist wieder einen kleinen Schritt weiter, etwas Erleichterung macht sich breit unter den Entwicklern.

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.

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...
'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:

"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

Es rappelt im Karton: Die Manöverkritik lässt die anfänglich gute Stimmung während des Meetings in den Keller sinken.
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. 

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?

Auch das gehört dazu: Die akribische Zeitplanung.
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.

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
Ein Mockup-Bild deutet an, wie das Spiel mal aussehen könnte. Von einem spielbaren Prototypen ist das Team aber noch weit entfernt.
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.

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'
    

Kommentare

schachblocki schrieb am
Hallo,
für diejenigen, die sich wundern, dass es mit "The Deadline" hier
nicht weiter geht: Das Spiel ist schon lange fertig, es müssen
allerdings noch einige Lizenzfragen geklärt werden.
Für die Ungeduldigen - es gibt bereits seit einiger Zeit ein Video
zum Spiel bei Youtube (unofficial trailer):
http://www.youtube.com/watch?v=SoghltLmkUQ&fmt=22
viel Spaß,
Marco
Franzis79 schrieb am
Ihr habt`s tatsächlich geschafft Jungs. Daumen hoch.
Black_Hand schrieb am
- Das ganze sollte etwas mehr nach Cartoon/Comic aussehen, bzw. müssten sich die Zombies mehr von Hintergrund abheben.
- Schaut euch die Beleuchtung an, ich sehe da ein Haufen Lichtquellen die Teilweise das ganze Mobiliar mit beleuchten was nicht nötig ist.
- ersetzt diese "Billy Regale" durch Quader mit einer entsprechend Textur (Foto von nem Regal mit Inhalt), bei der entfernung braucht es keine ausmodelierten Details...
Tumble\' schrieb am
Dungeon Defense ist keineswegs eines der ersten UDK Beispiele, sondern recht neu. Der Prototyp wurde am 4. Februar released, die Produktion startete Anfang Januar. Unser Konzept war Ende letzten Jahres bereits ziemlich final.
Abgesehen davon hat unser Spiel weder konzeptionell noch optisch sonderlich viel mit Dungeon Defense zu tun. Das wurde von einem, nach eigener Aussage, ziemlich erfahrenen Team gemacht. Die starteten also, anders als wir, nicht bei 0 und arbeiten auch im Script völlig anders.
Und da es keine Limitierung gibt, wie viele Spiele es pro Genre geben darf, mache ich mir darüber auch keine Gedanken. Solche Zufälle gibt es nun mal :)
schrieb am

Facebook

Google+