|
|
| Home /
Inhalte /
MOH Pacific Assault /
Entwicklertagebücher
|
|
Inhalte - MOH Pacific Assault |
Entwicklertagebücher |
Diese Artikel wurden von verschiedenen Entwicklern bei Electronic Arts Los Angeles (EALA) verfasst und behandeln die Entwicklung
von Medal of Honor Pacific Assault im Detail. Sie sind in der Originalsprache auf der offiziellen
Seite verfügbar. Wir bedanken uns bei Electronic Arts Deutschland für die Übersetzung aller
Artikel. Eine geringfügige Überarbeitung der Texte und Titel erfolgte durch Raymond. Zum Lesen der Artikel jeweils auf das Icon klicken. Wenn alle
geöffnet sind, können Sie mit einer Betätigung der Taste F5 alle wieder schließen.
Tagebücher der Entwickler / Designer:
» Multiplayer-Design
von Ed Moore - Multiplayer Design Lead
Originaltitel: Multiplayer Developer Diary #1
Herzlich willkommen zur ersten Ausgabe meines Entwickler-Tagebuchs. Ich heiße Ed Moore und bin Multiplayer Design Lead für Medal of Honor
Pacific Assault™. Ich habe schon früher Artikel geschrieben, die veröffentlicht wurden, aber dies hier soll persönlicher werden und mehrere Folgen
umfassen. Es ist das erste Mal, dass ich so etwas mache, und deshalb hoffe ich, dass ihr es mit mir aushaltet.
Ich habe mir gedacht, dass es ein guter Anfang wäre, wenn ich erzähle, wie Spiele von Beginn meiner Kindheit an, mein Leben bestimmt haben. Ich kö
nnte von ein paar Spielen erzählen, die mich stark beeinflusst haben, während ich größer wurde, und von den Ereignissen berichten, die mich zu einer
beruflichen Laufbahn im Videospielsektor bewogen haben.
Zu einigen meiner frühsten Erinnerungen aus der Kindheit in New Jersey und später außerhalb von Boston gehören Videospiele am Atari 2600 und Atari
800. Ich muss wohl ungefähr fünf gewesen sein, als ich suchend durch das Great Underground Empire of Zork streifte, während meine Finger die
Tastatur umklammerten und ich die ganze Zeit Angst hatte, meine Laterne könnte mich im Stich lassen und der schreckliche Grue würde mich im Dunkeln
verschlingen. Obwohl die Grafik jämmerlich primitiv war, war ich begeistert, wie einen die Fantasy-Rollenspielwelten von Ultima in ihren Bann ziehen
konnten und wie detailreich die Spiele aufgebaut waren. Bis heute bin ich der Ansicht, dass der nicht-lineare Aspekt des Designs und die ethischen
Untertöne von Ultima IV und Ultima V ihrer Zeit um Jahre voraus waren.
Ich war damals auch ganz verrückt nach Sega. Während die anderen coolen Typen auf dem Schulhof sich über die Suche nach dem Master Sword aus Legend
of Zelda austauschten, gehörte ich zu den wenigen Kids, die Bildchen an den Heftrand kritzelten, um den chronologischen Ablauf meiner Fortschritte
vom Master System solcher Klassiker wie Phantasy Star und Space Harrier festzuhalten.
Als mein älterer Bruder dann einen Amiga 1000 in die Hände bekam, konnte ich in grafischen Epen wie Defender of the Crown versinken und die
exotischen, unwirklichen Welten von Shadow of the Beast und Flashback erleben. In dieser Zeit war ich auch den Sierra Quest-Spielen erlegen, und als
es darum ging, die Abenteuer von Space Quest und King's Quest zu bestehen, waren es doch die hervorragend geschriebenen Geschichten, die
historischen Rahmenhandlungen und die liebevollen Personenbeschreibungen von Spielen wie dem Adventure/Rollenspiel-Hybrid Quest for Glory II,
Conquests of Camelot und Conquests of the Longbow, die meine Fantasie wirklich gefangen nahmen.
Als ich Junior an der Highschool war, schrieb und produzierte ich eine eigene Videospielsendung über eine lokale Kabelstation. Das war Jahre bevor
ähnliche Sendungen ins Fernsehen kamen (Schreibt euch das hinter die Ohren Adam Sessler und Morgan Webb!). Doch als ich Final Fantasy II auf dem
Super NES spielte und den fantastischen Soundtrack und die mitreißende, wenn auch ziemlich schlecht übersetzte Geschichte erlebte, erkannte ich,
dass ich Geschichten in Form von Videospielen erzählen wollte. Im Herbst 1993 schrieb ich mich an der Hofstra University in New York ein. Eigentlich
wollte ich meine Kenntnisse übers Fernsehen vertiefen und einen Abschluss in Kommunikation mit dem Nebenfach Informatik machen. Ich hatte mich für
einen Computerkurs, Programmieren in Pascal, eingeschrieben. Aber als ich dann mitbekam, dass Programmierung nicht etwas völlig Abgehobenes war, das
nur der Weltraumforschung vorbehalten war und ich das tatsächlich lernen könnte, entschied ich mich, einen Abschluss in Informatik zu machen. Meine
Gründe dafür waren sehr einfach - ich stellte mir vor, dass ich dann das Rüstzeug hätte, meine eigenen Videospiele zu machen, wenn ich dabei das
Schwierigste, das Programmieren, selbst übernahm. Damals gab es noch nicht die Möglichkeit, einen Abschluss in Computerspielentwicklung zu machen -
was für ein Glück haben dagegen die aufstrebenden Kids heute!
Während meiner Uni-Jahre, in denen meine Sicht durch den bernsteinfarbenen Boden von Bierhumpen etwas verschwommen und die von stark erhöhtem
Kaffeekonsum bestimmt waren, um nächtelange Lernorgien durchzustehen, wurde ich Zeuge der Entwicklung, die die Industrie auf dem Spielesektor
machte. Das Cartridge-System, das bisher den Spielkonsolenmarkt beherrscht hatte, wurde fallen gelassen, als die Playstation ihren Siegeszug antrat.
Die Titanen der alten Garde, Sega und Nintendo, hatten ausgedient und es kam Sony mit seiner beeindruckenden Playstation, die 3D und Full-Motion
darstellen konnte und Videospiele unwiderruflich in den Blick der Öffentlichkeit rückte. Die kinoähnlichen Welten von Final Fantasy VII und Metal
Gear Solid zeigten mir, dass die Kommunikationsmedien des 21. Jahrhunderts salonfähig geworden waren und ich wollte dabei sein.
Mein erster Job nach der Uni war bei einem kleinen Entwickler in New York City. Ich war als Level Designer für ein Playstation-Spiel namens Monkey
Magic zuständig - ein wirklich bescheidener Berufsstart! Es waren magere, harte Jahre - ich verbrachte täglich vier Stunden in Zügen und U-Bahnen
und pendelte nach Manhattan, um dort einen 12-Stunden-Job zu machen. Das Gehalt, das ich dafür bekam, reichte kaum, um meine Ausgaben für Miete und
Lebensmittel, ganz zu schweigen von Kreditkartenrechnungen oder Darlehen zu bestreiten. Es heißt, jeder müsse in diesem Geschäft draufzahlen und ich
bildete da keine Ausnahme. Mein Job war nichts Besonderes, doch die Möglichkeit, so schnell nach der Uni in einer so aufregenden Stadt wie New York
City, die vor Ideen nur so überquoll, an einem Konsolenspiel zu arbeiten, begeisterte mich.
Doch mein Leben verlief nicht ohne Rückschläge. 1999 verlor ich unerwartet meinen Job in der Stadt und saß arbeitslos und ohne Auto auf Long Island
fest. Keine gerade tolle Situation, doch wie meine Mutter zu sagen pflegt: "Wenn eine Tür sich schließt, öffnet sich eine andere". Es war mir
gelungen, zu einem Bewerbungsgespräch bei den Looking Glas Studios in der Nähe von Alewife Station am Ende der Roten Linie in Cambridge,
Massachusetts, eingeladen zu werden. Das war nur ein paar U-Bahnstationen von den mit Efeu überwucherten Ziegelbauten von Harvard und MIT entfernt.
Meiner Meinung nach war Looking Glass wohl das wichtigste und innovativste Spielentwicklerstudio im Nordosten der Vereinigten Staaten. Ich hatte das
Gefühl, wenn ich es schaffen sollte, meinen Fuß in die Tür der Macher von so legendären Klassikern wie Thief und Ultima Underworld zu setzen, dann
hätte ich es erst einmal geschafft. Doch zuerst musste ich zeigen, was ich draufhatte - ich bekam den Auftrag, ein Level zu entwickeln, um meine Fä
higkeiten zu beweisen.
Dieser Sommer wurde unvergesslich für mich - ich verbrachte endlose, schwüle Nächte in einem Appartement ohne Klimaanlage auf Long Island vor meinem
PC, wo ich mich mit Entwickler-Tools herumschlug und in irgendwelchen Foren herumlungerte, während ich versuchte, mich aus eigener Kraft aus dem
Sumpf der Arbeitslosigkeit zu ziehen. Aber wie verlockend waren die Aussichten, die ich hatte! Half-Life, Starcraft, System Shock 2 - Diese
Klassiker beflügelten meine Fantasie und boten eine willkommene Unterbrechung der harten Arbeit und langen Stunden, die ich damit verbrachte, meine
eigenen Level zu entwickeln.
Im September 1999 zahlte sich meine Hartnäckigkeit endlich aus. Ich kriegte einen Job bei Irrational Games als Co-Developer für System Shock 2. Das
war ein Riesenerfolg für mich - ich durfte mit den kreativen Köpfen zusammenarbeiten, die solch ein bemerkenswertes Spiel geschaffen hatten! Also
packte ich meine Sachen und sagte meinem Leben und meinen Freunden in New York Lebewohl - ich war wieder in Boston und würde meinen Traumjob
antreten.
-- Ed
Und das nächste Mal ... Ed in der großen Stadt!
» Spiele und Leben -
Ursprünge eines Multiplayer Lead Designers #2
von Ed Moore - Multiplayer Design Lead
Originaltitel: Games and Life - Origins of a Multiplayer Lead Designer #2
Während ich am zweiten von acht Teilen des Entwicklertagebuchs schreibe, habe ich mir gerade eben die PC-Demo von Thief anschauen können. Das
kommt irgendwie gerade zur rechten Zeit, wenn man bedenkt, dass ich einen großen Teil meiner beruflichen Laufbahn dem Studio und den Köpfen gewidmet
hatte, die dieses Projekt ursprünglich begonnen hatten. Wahrscheinlich fragen sich jetzt alle, was das denn eigentlich mit Medal of Honor zu tun
haben soll. Nun, wenn da nicht Looking Glas und die innovativen First-Person-Spiele für den PC gewesen wären, die man dort entwickelte, sodass ich
viel Erfahrung sammeln konnte, hätte ich meinen Fuß vielleicht nie in die Tür von EA bekommen und wäre auch nie der Multiplayer Lead Designer von
Medal of Honor geworden.
Im Herbst 1999 trat ich meinen Job als Level Designer bei Irrational Games an. Es handelte sich um ein aufstrebendes Entwicklerstudio, das sich bei
Looking Glas eingemietet hatte und mit ihnen zusammen System Shock 2 entwickelte. Der Begriff Klubtollhaus beschreibt das Gebäude, in dem Looking
Glas hauste wahrscheinlich am besten. Es steht dem MIT sowohl räumlich als auch inhaltlich sehr nahe und viele der wichtigsten Entwickler waren
ehemalige MIT-Studenten. Die Kerle waren wirklich schlau, aber puuuuh, die machten nicht oft sauber - die Küche war richtig dreckig und der Geruch
von schalem Bier und Pizza hing in der Luft (da sind bestimmt die Augenbrauen von ein oder zwei Chefs hochgegangen). Wie zu erwarten, schmückten die
Wände Bilder von rehäugigen Manga-Girls und kantige Cyberpunk-Kunst. Spät abends, wenn nicht mehr überall Licht brannte, hätten sogar die verrückten
PSI-Monkeys aus System Shock 2 nicht fehl am Platze gewirkt.
Während meiner Zeit bei Looking Glas und Irrational lernte ich viel über die Multiplayer-Funktion. Unreal Tournament war damals gerade sehr populär
und obwohl ich bei einem meiner Jobs auf Long Island schon mal bei Quake II in den Deathmatch-Modus reingeschaut hatte, muss ich ehrlich gestehen,
dass UT wahrscheinlich das erste Multiplayer-Spiel war, in das ich mich wirklich verliebte. Unvergessliche Maps wie Facing Worlds und Lava Giant
sorgten für stundenlangen Spaß mit meinen Kollegen, und ich kämpfte mich durch alle Modi wie Domination, Capture the Flag und Assault. Ein anderes,
bei meinen Kollegen sehr beliebtes Spiel war Rainbow Six: Rogue Spear. Wenn wir uns zu einer gemeinsamen Runde zusammenfanden, die den Code-Namen "
Rogue Beer" trug, gehörte immer der Pizza-Lieferservice dazu und ein schneller Gang durch die eisigen Straßen von Boston zum Pakistaner an der Ecke,
um ein paar Kisten Bier zu besorgen.
Die vielen talentierten Mitarbeiter bei Looking Glas und Irrational inspirierten einen bei der Arbeit und die Entwickler, die die Seele des Studios
waren, sorgten für eine kreative, vielfältige, gebildete und kulturelle Atmosphäre im Studio, die sich auch in den Spielen widerspiegelte: dunkel,
brütend, künstlerisch-ästhetisch und wundervoll. Man lief nicht den kommerziellen Erfolgen hinterher (ob das immer richtig war, bleibt
dahingestellt) und weitete die Möglichkeiten des Mediums so sehr aus, wie es nur wenige andere Entwickler getan haben. Die Gelegenheit, mit diesen
Leuten zu arbeiten und Einblick in ihre Gedankenwelt zu erhalten, wird für mich immer unvergesslich sein. Es steht mir nicht zu, mich als ein
wichtiger Teil von ihnen zu bezeichnen oder sie sogar in irgendeiner Form zu vertreten - doch ob sie sich nun an mich erinnern oder nicht - ich bin
dankbar, dass ich die Chance gehabt habe, dort zu arbeiten, ehe es zu der traurigen Schließung von Looking Glas im Frühjahr 2000 kam. Die
Erfahrungen, die ich dort sammelte, haben mich zu einem besseren Spieleentwickler gemacht, auch wenn ich nur kurze Zeit dort gewesen bin.
Während meiner Zeit in Massachusetts kam es auch zu meiner ersten Begegnung mit dem Original von Medal of Honor auf PlayStation®. Am lebhaftesten
erinnere ich mich dabei an die KI, die hervorragende Steuerung im Stile von Goldeneye und die Musik. Michael Giacchinos Komposition rief mir Szenen
aus den Indiana-Jones-Filmen in Erinnerung und die Soundeffekte waren beeindruckend und mitreißend. Die Machart der KI überraschte einen, denn man
rechnete nicht mit dem beeindruckenden Spiel auf der Klaviatur der Erwartungen. Wer würde schon Momente wie diese vergessen, wenn eine Exekution
ansteht und plötzlich der Helm wegfliegt? Oder der Feind eine für ihn bestimmte Granate zurückschleudert? Wirklich starker Tobak.
Doch ich würde lügen, wenn ich sagte, dass in Boston alles perfekt war. Obwohl Irrational (und meinem Job) das Schicksal von Looking Glas erspart
blieb, lebte ich nach zwei Jahren immer noch am Stadtrand und frequentierte das "Hotel Mama", um Geld zu sparen. Ich hatte einige Ziele, die ich mir
gesteckt hatte, erreicht. Ich hatte zwar einen Teil meiner Schulden bezahlt und mir ein Auto gekauft, doch ich war sowohl privat als auch beruflich
frustriert und enttäuscht. Lange hatte ich mit dem Gedanken gespielt, nach Kalifornien zu ziehen und meine Karriere als Spieleentwickler dort
fortzusetzen. Ich hatte einen Punkt in meinem Leben erreicht, wo die Vorstellung, alles aufzugeben, um an einen unbekannten Ort zu reisen, einen
seltsam verrückten, klischeehaften Reiz auf mich ausübte. Das Ganze erinnerte irgendwie an einen Fantasy-Roman oder ein schlecht umgesetztes RPG für
eine Spielkonsole. Es mag übertrieben klingen, aber ich erkannte, dass das Einzige, was mich von diesem Schritt abhielt, die Angst vor dem
Unbekannten war. Ich wollte mir nicht sagen lassen, dass ich keinen Mut gehabt hatte, und mich mein Leben lang fragen, was wohl gewesen wäre, wenn…
Also traf ich eine der wohl verrücktesten Entscheidungen meines Lebens. Im Dezember 2001 kündigte ich meinen Job bei Irrational und fing an, mich
auf meine Reise quer durch das ganze Land vorzubereiten. Ich erinnere mich, dass ich in dem Jahr nicht in der Lage war, mich zu entspannen und
Weihnachten zu genießen, während sich so viele Unwägbarkeiten vor mir auftürmten. Mit viel Angst, aber bestimmt genauso hohen Erwartungen verließ
ich Boston in einem Kleinbus. Für die Reise quer durch Amerika brauchte ich elf Tage. Ich fuhr über New York, New Orleans, San Antonio, El Paso,
Phoenix, den Grand Canyon und Las Vegas. Als ich in Vegas ankam, war ich mehr oder weniger pleite, und ich kann euch sagen - Vegas macht keinen Spa
ß, wenn man nichts Bares in der Tasche hat. Aber es war dann nur noch eine Fahrt von viereinhalb Stunden, um von diesem Sündenpfuhl aus mein Ziel zu
erreichen: Los Angeles.
-- Ed
Und das nächste Mal - Abgebrannt und fertig in LA - der "crazy-sunshine-city", Ed bekommt die große Chance bei Medal of Honor.
» Tagebuch eines Single
Player Designers #1
von Tom Hess - Game Designer
Originaltitel: Single Player Designer Diary #1
Ich heiße Tom Hess und bin Entwickler bei Electronic Arts - Los Angeles. Ich bin jetzt seit zwei Jahren bei EA und habe sowohl an Medal of
Honor Allied Assault™ Breakthrough als auch Medal of Honor Pacific Assault™ mitgearbeitet.
Ich erinnere mich daran, früher Level selber entwickelt und innerhalb einer Woche fertiggestellt zu haben. Doch jetzt ist das nicht mehr so. Es sind
viele Schritte notwendig, bis man das ganze Inventar für ein Spiel erstellt hat. Wir sind auf Modelle angewiesen, die von unserem Art Departement
hergestellt werden.
Wenn das Modell physikalischen Gesetzen unterliegt, muss es von unseren Ingenieuren arrangiert werden. Das Verfahren ist viel umfangreicher und
dauert deutlich länger. Es gibt einen ständigen Informationsaustausch zwischen Künstlern, Animateuren, Ingenieuren und Geräuschspezialisten. Es ist
Aufgabe des Entwicklers, alle Aspekte in die Arbeit einfließen zu lassen, sodass die Wirkung, der Look und die Spielsituation zustande kommen, die
der Entwickler ursprünglich im Sinn hatte. Ein ganzes Team war von Nöten, um die E3-Demo zu verwirklichen, und sie wurde großartig.
Seitdem wir die Schlacht von Henderson Field für unsere E3 Demo nachstellten, war unser Hauptanliegen, die Darstellung der Flugzeuge richtig
hinzukriegen. Im E3-Level waren mehr als 50 Flugzeuge zu sehen, die alle unterschiedliche Manöver durchführten. Wir erstellten jede Menge von
Holodecks, um die Flugzeuge im Flug wie richtige Flugzeuge aussehen zu lassen. Ein Holodeck ist eine kleine Map, auf der wir die Funktionalität
eines Spielelements testen, ehe wir es in den endgültigen Level einbauen. Auf die Weise stellen wir sicher, dass es keine drastischen Auswirkungen
auf unsere Framerate hat oder sonstige unerwartete Probleme mit sich bringt. Nachdem wir mehrere Wochen an den Flugzeugwerten gefeilt hatten, legten
wir allen Eigenschaften der Flugzeuge die Spezifikationen echter Flugzeuge zugrunde. Wir hatten Flugzeuge, die unter Beschuss waren, Bomber im
Sturzflug, hochfliegende Bomber und einen ganzen Haufen von Flugzeugen, die gerade unterschiedliche Manöver fliegen. Wir hatten ein Holodeck für
Flugzeuge im Luftkampf und setzten hierfür eine neue KI für Luftkampf ein. Wir hatten über 100 Flieger, die sich ein Luftgefecht lieferten.
Die Flugzeuge waren nicht das einzige neue, coole Detail, an dem wir arbeiteten. Wir mussten Objekte entwerfen, die mit dem Spieler interagierten.
Zu den kleineren Gegenständen gehörten Töpfe, die durch die Gegend flogen, wenn man auf sie schoss, umfallende Reifenstapel und Reifen, die
wegrollten, sowie Fensterläden, die von Pfosten gehalten wurden, die man wegschießen konnte.
Mit am besten gefielen mir die auf der Erde herumliegenden Blechtonnen. Man konnte auf den Boden schießen, sodass die Tonne sich drehte und in
Richtung des Gegners zeigte. Sobald sie in Stellung gebracht war, konnte man den Deckel wegschießen und die Tonne würde in die Richtung fliegen, in
die sie zeigte. Manchmal flog sie genau in den Gegner hinein und ließ ihn hochgehen. Manchmal flog sie aber auch am Gegner vorbei und traf ein Gebä
ude, das dann in die Luft ging. Jedes Mal passierte etwas anderes. Wir bedienen uns jetzt der Havoc-Engine und können bestimmte Spielbereiche
dadurch viel natürlicher aussehen lassen. Statt vorbestimmter Explosionen, die die Deckung an vorher festgelegten Punkten auffliegen lässt, wird die
Deckung jetzt jedes Mal an einer anderen Stelle sein. Der Spieler wird darauf reagieren und sich die passende Deckung suchen können.
An normalen Arbeitstagen beschäftige ich mich mit dem Spielverlauf und schreibe Scripts. Wir setzen Deckungsobjekte und Deckungspunkte auf die
gleiche Weise ein wie in Medal of Honor Allied Assault™. Deckungsobjekte sind Modelle, die so eingebaut werden, dass sie von der KI als Auslöser für
eine Deckungsanimation genutzt werden können, wenn sie sich in der Nähe befindet. Damit die Deckungsobjekte richtig genutzt werden, richten wir drum
herum Deckungspunkte ein. Deckungspunkte sind Teil der automatischen Wegfindung der KI und enthalten die Information, dass dieser Punkt als Deckung
genutzt werden kann. Das Neue dabei ist, dass wir jeden Bereich von Punkten zu Truppenpunkten zusammenfassen. Dadurch bleiben die Soldaten zusammen,
wenn sie sich von Truppenpunkt zu Truppenpunkt weiterbewegen.
Während eines Gefechts wird der eigene Trupp alle Bewegungen und taktischen Entscheidungen davon abhängig machen, wie die Truppenpunkte angelegt
sind. Sowohl der eigene als auch der gegnerische Trupp werden militärische Manöver wie das seitliche Umgehen anwenden, um den anderen aus seiner
Stellung zu vertreiben. Damit die KI ein bestimmtes Gebiet seitlich umgehen kann, muss man dafür sorgen, dass links und rechts dieses Gebietes
Truppenpunkte sind.
Mit zu den wichtigsten Dingen beim Level-Design in Medal of Honor Pacific Assault gehört, eine Gefechtsgegend so zu planen, dass alle
Truppenbewegungen möglich sind. Wenn die Truppenpunkte richtig gewählt wurden, kann man einige sehr schöne und interessante Schlachten schlagen.
Nun, das war erst einmal alles. In den nächsten Wochen werde ich noch mehr zu erzählen haben. Ich muss mich jetzt um die anderen Level von
Guadalcanal kümmern.
-- Tom Hess
» Tagebuch eines Single
Player Designers #2
von Mike Roloson - Game Designer
Originaltitel: Single Player Designer Diary #2
Hallo Leute. Ich heiße Mike Roloson und bin Game Designer für Medal of Honor Pacific Assault . Ich arbeite seit nunmehr zwei Jahren am Projekt
Medal of Honor mit und gehöre zu den wenigen hartnäckigen Mitarbeitern, die es geschafft haben, sich mit Zähnen und Klauen aus der Test-Abteilung
heraus in eine Position als Entwickler hochzuarbeiten. Denjenigen, die sich immer noch abstrampeln und versuchen, einen Job als Entwickler zu
ergattern, kann ich nur sagen, dass es die Mühe wirklich wert ist. Ich empfinde das, was wohl ein Maler fühlen muss, wenn er eine neue Art von
Leinwand entdeckt hat.
Im Moment läuft die Produktion auf Hochtouren und unser Studio ist wirklich ein toller Anblick. Der Termin für die Fertigstellung rückt immer näher
und jeder einzelne Mitarbeiter "platzt" fast vor Betriebsamkeit - alle klotzen jetzt ran, bleiben lange bei der Arbeit und versuchen, schnell noch
alle möglichen Kleinigkeiten in das Spiel einzubauen, ehe wir anfangen, auf die Bremse zu treten und dem, was wir da geschaffen haben, den letzten
Schliff zu geben. Ich liebe diese Phase des Projektes, wenn die Luft vor Energie förmlich vibriert und die Leute sich gegenseitig inspirieren.
Aber diese Branche hat auch ihre Schattenseiten - während der heißen Phase des Projektes gerät das Gleichgewicht zwischen Arbeit und Privatleben vö
llig aus dem Lot. Wenn man seinen Job liebt und einem das Projekt sehr am Herzen liegt, ist eine 80-Stunden-Woche kein Problem. Doch wenn man so ein
Pensum schaffen will, muss alles andere erst einmal auf Eis gelegt werden. Die dreckige Wäsche bleibt liegen, die Wohnung wird nicht mehr geputzt,
man kommt nicht mehr zu seinen Lieblingsspielen, die bessere Hälfte vereinsamt und all die Dinge, die man normalerweise gern macht und die die Pers
önlichkeit eines Menschen ausmachen, bleiben außen vor. Glücklicherweise beginnt sich in der Hinsicht allmählich etwas zu ändern. In den
Entwicklerhäusern setzt sich eine reifere Handhabung und Durchführung von Projekten durch, was zum einen die Lebensqualität der Spieleentwickler
verbessert und zum anderen auch Entwicklungsstrategien erlaubt, die vorhersehbarer sind und sich besser planen lassen. Glückliche und zufriedene
Menschen machen großartige Spiele, und das ist doch das Einzige, was zählt, nicht wahr, meine Freunde?
Also lasst mich jetzt ein bisschen was über Medal of Honor Pacific Assault erzählen. MOHPA ist cool. MOHPA ist heiß. Wenn ihr MOHPA das erste Mal
erlebt, werdet ihr vor Begeisterung in die Hose machen. Naja…hoffentlich ersparen wir euch diese Peinlichkeit - aber ernsthaft - es bestehen gute
Chancen, dass das Spiel selbst die außergewöhnlich hohen Erwartungen der eingefleischtesten Fans von Allied Assault erfüllen wird. (Ja genau, du
bist gemeint!).
Bei MOHPA steht der Trupp im Mittelpunkt. Den ganzen Feldzug über kämpfst du zusammen mit einer festen Gruppe aus Marines und dein Überleben hängt
bei der Bewältigung unterschiedlicher taktischer Situationen von dieser Gruppe ab. Die Zeiten, in denen man lahme, charakterlose KI-Typen durch den
gesamten Level schleifen musste, die noch nicht einmal in der Lage waren, einen Flugzeugträger zu treffen, sind vorbei. Deine Kameraden verarzten
dich, beschützen dich, warnen dich, wenn Gefahr droht, und helfen dir, wenn es darum geht, ein Manöver durchzuführen und Ziele zu erreichen. Das
heißt aber nicht, dass man sich entspannt zurücklehnen kann, während sie die ganze Arbeit machen. Sie sind zuverlässig, aber sie können nicht alles.
Es gibt Level, in denen man seinen Trupp verlässt und sich durchs Unterholz kämpft, um dann plötzlich festzustellen, dass man auf einmal ganz allein
dasteht, von der Seite angegriffen wird und in Strömen blutet.
Die feindlichen Trupps sind genauso weit fortgeschritten und wir haben unser Level-Design daran anpassen müssen. Anstatt die Gegner einzeln zu
platzieren und dann zu versuchen, die Bewegungen oder Angriffsmuster zu koordinieren, werden die Trupps jetzt als Ganzes ins Spiel gebracht. In der
Regel wird nur noch ein einzelnes Ziel definiert, ehe man sie dann einfach laufen lässt. Entsprechend der Vorgehensweise des Spielers und des Trupps
des Spielers werden die gegnerischen Trupps je nachdem, was sie für angebracht halten, unter Feuerschutz vorrücken, sich zurückziehen oder
Flankenbewegungen durchführen. Dadurch wird der Entwickler zu einer Art "Hauptmann", der das Timing und die Richtung des Angriffs bestimmt, ohne
sich dabei Gedanken über komplizierte Einzelbewegungen machen zu müssen.
Wir können die KI in den taktischen Bereichen des Levels auch gegen sich selbst antreten lassen, um herauszufinden, wie deren Reaktionen ohne das
Eingreifen des Spielers in den Verlauf aussehen würden. In einem Level konstruierte ich zum Beispiel die Situation, dass der alliierte Trupp sich in
einer Maschinengewehrstellung gegen mehrere aufeinander folgende Angriffswellen des Gegners verteidigen musste. Beim ersten Versuch hielt sich mein
Trupp aus sechs alliierten Soldaten vierzig angreifende Japaner ohne Hilfe des Spielers vom Leib. (Es sind schließlich Marines.) Nach einer Ü
berarbeitung der Deckung und Änderungen am Schwerpunkt und am Ablauf des Angriffs fielen meine Alliierten in ihrem Fuchsbau ziemlich schnell dem
Bajonett zum Opfer. Jetzt komme ich ins Spiel und fange an, den Feind niederzumähen, um dann aber ziemlich schnell genauso wie meine Gefährten durch
ein Manöver, das ich nicht vorher konstruiert hatte, aufgespießt zu werden. Ich versuche es noch einmal und darf wieder die Radieschen von unten zä
hlen. Dritter Versuch…ich schieße mein MG leer, jage fünfzig Kugeln durch mein Thompson und stehe dann plötzlich einem angreifenden japanischen
Hauptmann gegenüber, dessen Katana auf mich zusaust. Während ich noch fluche und auf den Button für den Reload hämmere, donnert ein alliierter
Kamerad ihm den Gewehrwehrkolben seines Karabiners gegen die Schläfe, sodass er zu Füßen meines Kameraden und Kommandanten, Frank, zusammenbricht.
Ich finde das klasse. Und ihr mögt es doch auch, wenn es zur Sache geht, oder?
Denjenigen unter euch, die noch mehr über die inneren Abläufe in der Spieleindustrie erfahren möchten, kann ich die Website der International Game
Developers Association (http://www.igda.org) empfehlen. Es gibt nichts Besseres.
Tschüss bis zum nächsten Mal,
-- Mike
» Tagebuch eines
Software Engineer Designer
von Keith Schaefer - Software Engineer
Originaltitel: Software Engineer Developer Diary #1
Guten Tag, alle miteinander. Ich heiße Keith Schaefer und arbeite als Engineer an Medal of Honor Pacific Assault mit. Ich bin vor allem für die
Entwicklung unseres physikalischen Systems zuständig. Es wird niemanden verwundern, dass ich von Haus aus Physiker bin (sogar mit Abschluss), aber
ich bin eine Zeit lang unterschiedlichen Jobs in der Computerbranche nachgegangen, ehe ich zu EA kam. Bei meinen verschiedenen Jobs hatte ich mit
CAD-Software, business-to-business Web-Software und einem Börsenprogramm in Echtzeit zu tun, ehe ich zu meinem Job im Spielbereich kam. Ich brachte
drei Spiele mit einem anderen Entwickler heraus und arbeitete an einem FPS-Projekt, das eingestampft wurde, bevor ich die Gelegenheit bekam, für EA
an MOHPA mitzuarbeiten.
Ich kann euch sagen … das neue Gebäude von EA hier in Los Angeles ist viel schöner als jedes andere, in dem ich je gearbeitet habe. Ich sitze in
einem geräumigen Abteil (nein, es ist kein abgeschlossener Büroraum, aber zumindest sitze ich ganz allein da drin) und schaue aus meinem Fenster auf
Playa del Rey. Auf der anderen Seite vom Hof befinden sich ein hauseigenes Fitnessstudio, ein Sportplatz sowie Basketball- und Volleyballplätze. Vor
Ort befinden sich außerdem eine Cafeteria, ein Coffeeshop und selbstverständlich ein Spielraum mit einigen Arcade-Games, einem Billardtisch und
mehrere Konsolen mit den neusten und tollsten Spielen. EA versucht wirklich, seinen Mitarbeitern allen erdenklichen Komfort zu bieten.
Doch genug von mir und meinem Arbeitsplatz! Ihr wollt was über MOHPA hören und ich will über Physik reden. Bei Medal of Honor geht es um
Infanteriegefechte - es ist kein Strategiespiel oder ein Platformer. Deshalb benutzen wir die Physik nicht wie bei Half Life 2 zur Erweiterung der
Spielmöglichkeiten, sondern wir setzen Physik ein, um die Spielumgebung so realistisch und interaktiv wie möglich zu machen, sodass man förmlich in
das Spiel eintauchen kann.
Dafür müssen möglichst viele Dinge zu unterschiedlichen Bewegungen wie rollen, fallen, explodieren und treiben animiert werden, damit man das Gefühl
bekommt, die Welt würde auf alles, was der Spieler tut, reagieren. Um dies zu erreichen, entschieden wir frühzeitig Havok® einzusetzen statt selber
eine ganz neue physikalische Engine zu entwickeln. Aber nicht, dass jetzt Missverständnisse aufkommen - es ist immer noch mit sehr viel Arbeit
verbunden, eine von anderen programmierte Engine wie Havok in einen bereits vorhandenen Code einzubauen. Glücklicherweise wurden wir von den Machern
von Havok hervorragend unterstützt. Es steht fest, dass wir ohne deren Hilfe untergegangen wären.
Wo ich gerade vom Untergang spreche … da der Kriegsschauplatz der Pazifik ist, kommt Wasser in unserem Spiel eine besondere Bedeutung zu und es ist
wichtig, dass sich Objekte im Medium Wasser korrekt verhalten. Wenn ein japanischer Soldat in einem Gefecht neben einem Fluss fällt, wird er ins
Wasser stürzen, erstarren und dann flussabwärts treiben.
Wird ein Flugzeug über dem Meer abgeschossen, wird es ins Wasser stürzen, wobei der Rumpf sofort versinkt, während leichtere Tragflächenteile auf
der Oberfläche treiben.
Im Spiel werden auch viele Gefechte bestritten und wir haben uns alle Mühe gegeben, um so viele Objekte wie möglich auf die verschiedenen Waffen
reagieren zu lassen. Schieß auf eine Schaufel und einen Eimer und die Gegenstände werden über den Boden kullern.
Wenn man eine Handgranate in einer Hütte hochgehen lässt, kann man sehen, wie die Sprengstoffschweife ein Nachbargebäude treffen. Und man sollte es
sich lieber zweimal überlegen, ehe man diese Granate in ein Treibstoffdepot wirft!
Und schließlich haben wir uns noch verschiedene Objekte ausgedacht, die wir unbedingt in das Spiel einbauen mussten, weil sie so viel Spaß machen -
aber um herauszufinden, was es damit auf sich hat, wird man wohl noch warten müssen, bis wir das Spiel ausliefern!
Das ist in aller Kürze, was im letzten Jahr so gelaufen ist. Jetzt muss ich aber wieder zurück an die Arbeit, um dieses Spiel fertigzubekommen! In
ein paar Wochen werde ich über die neusten physikalischen Entwicklungen berichten. Bis dahin kann man sich auf das nächste Entwicklertagebuch von
meinem Kollegen, dem Ingenieur Jason Gregory, in zwei Wochen freuen.
-- Keith
» Tagebuch eines
Engineer Developer
von Jason Gregory - Software Engineer
Originaltitel: A Day In The Life Of An Engineer: Part 2
Hallo, ihr treuen Fans von Medal of Honor! Ich heiße Jason Gregory und bin einer der Engineers, die an der neusten Fortsetzung dieser Ehrfurcht
gebietenden Spielreihe, Medal of Honor Pacific Assault , mitarbeiten. Wie ihr wisst, wird MOHPA bald in den Regalen stehen, und unser ganzes
Entwicklerteam hat das vergangene Jahr sehr hart gearbeitet, damit es so kommt. Da ihr bestimmt den ersten Artikel in dieser Reihe gelesen habt,
wisst ihr auch, dass mein Kollege Keith Schaefer und ich versuchen, euch einen Eindruck davon zu vermitteln, wie die Mitarbeit an einem Projekt wie
MOHPA aus Sicht eines Engineers aussieht.
Keith hat ja bereits von den nagelneuen Büroräumen von EA hier in Playa del Rey erzählt. Deshalb werde ich dazu nicht mehr so viel sagen - außer
dass ich ganz wie er der Meinung bin, dass es nicht zuletzt wegen des ultramodernen Geländes großartig ist, bei EA Los Angeles zu arbeiten. Aber die
Arbeitsumgebung ist wirklich nur der Anfang. Ich bin erst seit einem guten Jahr bei EALA angestellt; aber ich muss sagen, dass hier die
talentiertesten und professionellsten Leute arbeiten, mit denen ich je im Job zu tun gehabt habe - ob es sich dabei nun um einen Engineer, einen
Designer, einen Mitarbeiter aus dem Bereich Art oder einen Manager handelt. Und ihr könnt mir glauben, dass ich mir darüber ein Urteil erlauben
kann, denn ich habe in den letzten zehn Jahren entweder in Vollzeit als Angestellter oder als Berater bei rund 20 Firmen gearbeitet. Ich erkenne
also ein gutes Team, wenn ich es sehe!
Ihr fragt euch wahrscheinlich, wie das so ist, ein "Spieleprogrammierer" zu sein. Es ist auf jeden Fall immer wieder eine Herausforderung und viel
harte Arbeit. Diese Arbeit macht aber auch riesigen Spaß und es handelt sich um eine lohnende Aufgabe. Dieser Job gleicht aus drei Gründen keinem
anderen Job als Software Engineer:
1. Spiele sind sehr datenintensiv. Ein typischer PC-Titel von heute besteht aus vielen Gigabyte von Art-Elementen - 3D-Modellen (auch
Drahtgittermodelle genannt), Oberflächenstrukturen, Animationen, Kleinsteffekten (particle effects), Klängen, Musik - und die Liste ist noch längst
nicht zuende. All diese Elemente unter einen Hut zu bekommen - ganz abgesehen davon, dass man sie ja erst einmal erschaffen muss - ist eine wahre
Herkules-Arbeit
2. Spiele müssen gut laufen. Sie müssen richtig gut laufen. Technisch gesehen fallen Spiele in die Kategorie "soft real-time Systeme". Wir
sprechen hier von "real-time", weil wir uns nicht den Luxus gönnen können, drei Tage an einem Element zu feilen, aus dem letztendlich nur zwei
Sekunden Action werden. Und wir sagen "soft", weil niemand stirbt, wenn wir mal für eine Weile unter 30 Frames pro Sekunde fallen! Es ist wirklich
eine Riesenherausforderung, Code für so eine große Menge von Daten zu schreiben, der dann auch noch in Echtzeit läuft.
3. In der Spielebranche begegnet man einer einzigartigen Verschmelzung von Technologie und künstlerischen Aspekten. Als Spieleprogrammierer
muss man ein gestandener Engineer sein, der gleichzeitig einen ausgeprägten Sinn für Ästhetik hat; denn Vieles von dem, was wir machen, hat direkten
Einfluss darauf, wie glaubwürdig unser Spiel rüberkommt und wie raffiniert es überhaupt wirkt. Wo sonst kann man den ganzen Tag damit verbringen,
komplizierte, überwiegend mathematische Algorithmen aufzustellen, die dazu dienen, dass Bäume und Büsche sich ganz natürlich - und wunderschön - im
Wind wiegen. (Mein Kumpel Keith Schaefer hat genau das getan, als er das bewegliche Laubwerk von MOHPA programmierte).
Als Spieleentwickler ist man technologisch immer auf dem neusten Stand, weil wir es bei unserer Arbeit mit so einer großen Bandbreite von
technischen Bereichen zu tun haben. Da gibt es neben der Mathematik (viel Mathematik!) die Theorie des Software-Engineering, 3D-Grafiken,
Mikroprozessor-Architektur, Netzwerktechnologie, Physik, KI, Animation und Datenbanken (um die schier unglaubliche Menge von künstlerischen Details,
die das Inventar des Spiels ausmachen, überhaupt noch handhaben zu können). Diese Liste ließe sich noch endlos weiterführen. Man muss das Lernen
also auf jeden Fall lieben, wenn man in diesem Beruf arbeiten will.
Jetzt sagt ihr wahrscheinlich: "In Ordnung, wir haben begriffen, dass es einzigartig, anspruchsvoll und aufregend ist, als Spieleprogrammierer zu
arbeiten. Aber was tut ihr Typen eigentlich den ganzen Tag lang?" Das ist eine gute Frage! Ich bin in erster Linie für den Code zuständig, der
unsere 3D-Modelle und die Charakteranimationen zum Leben erweckt. Aber alle aus unserem Team sind auch dazu aufgerufen, immer auszuhelfen, wenn
Bedarf besteht. Deshalb arbeite ich auch häufig an den Tools, helfe beim Rendern oder der Physik-Engine, vertiefe mich in den KI-Code oder helfe
einfach meinen Kollegen beim Debuggen von irgendeinem Code. Der Tagesablauf eines Spieleprogrammierers kann jeden Tag anders aussehen. Manchmal
sitze ich nur den ganzen Tag und schreibe Code, teste und debugge. Dann gibt es wieder Tage, an denen ich die meiste Zeit in Meetings verbringe und
mit meinen Kollegen aus den Bereichen Engineering, Design, Animation und/oder Art Ideen diskutiere. Und dann sind da noch die Tage, an denen ich die
meiste Zeit nachdenke (und mir Notizen mache). Tatsächlich bin ich sogar der Meinung, dass der Beruf des Software-Engineers zu 80% daraus besteht,
sich Gedanken zu machen…und diese Gedanken mit seinen Kollegen zu diskutieren (damit einem noch mehr Ideen kommen!) Letztendlich ist
Computersoftware doch nur ein winziges Stück eines Denkprozesses, den man kodiert hat, sodass man ihn immer wieder "abspielen" kann.
Gestern betrieb ich zum Beispiel fast den ganzen Tag lang mit einem guten Freund und Kollegen, John Versluis, Pair Programming. (John ist ein
unglaublich talentierter Tool-Programmierer, der für die mit 3D Studio MAX bearbeiteten Art-Elemente von MOHPA zuständig ist.) Das Pair Programming
ist ein Konzept aus der Extreme Programming (XP)-Methode. Wir saßen beide vor Johns Computer und es übernahm immer derjenige das "Steuer", der über
den jeweiligen Code besser Bescheid wusste. Am Ende des Tages hatten wir einen Teil eines Systems gegen Code aus 3D Studio MAX ausgetauscht und in
die Engine eingearbeitet.
Ich werde später noch genauer auf die coolen Technologien eingehen, die wir bei Medal of Honor Pacific Assault eingesetzt haben. Für den Moment
reicht es, zu sagen, dass dieses Spiel einfach Ehrfurcht gebietend sein wird! Es hat viel Spaß gemacht, bei MOHPA mitzuarbeiten, und ich freue mich
schon darauf, euch in den nächsten Artikeln zu erzählen, wie wir dieses unglaubliche Spiel entwickelt haben. Bis zum nächsten Mal!
-- Jason
|
|
|
|
|