Puuh, dank der Übersetzung von Planescape: Torment bin ich mit den täglichen Updates "leicht" im Rückstand. Jetzt ist die erste Hürde der Übersetzung für Trumpfass und mich genommen und endlich habe ich wieder Zeit zum Update-übersezten. Hier mal drei Updates, an denen Ihr Euch gütlich tun könnt. Mehr folgen in Kürze J

Viel Spaß beim Lesen wünscht Euch wie immer

- Sermon

28.06.1999

Letzte Woche habe ich ein interessantes E-Mail von einem unserer Fans, Steve Carstensen, erhalten, der mich fragte, warum alle Spieleentwickler ihre eigenen Scripting Sprachen entwerfen und nicht auf bereits existierende Sprachen, wie Python, Scheme oder Lisp zurückgreifen. Das ist eine sehr gute Frage und auch habe mich schon lange mit dieser Frage beschäftigt. Heute möchte ich Euch also auf eine Reise in die Welt der Scripting-Sprachen mitnehmen und wie sie sich mit Spielen vertragen.

Der Kern der Frage ist jedenfalls, warum sich jemand die Zeit und Mühe macht, eine eigene Script-Sprache zu schreiben und zu implementieren, wenn es so viele fertige Scripting-Sprachen gibt, die man verwenden könnte. Das würde sehr viel Zeit einsparen – Zeit, die man für wichtigere Dinge verwenden könnte.

Als wir mit Torment anfingen, habe ich mit dem Gedanken gespielt, eine andere Scripting-Sprache als die der Bioware-Infinity Engine zu verwenden. Ich interessierte mich da eher für Java oder VBScript (ein Teil von Microsoft's Visual Basic) und wollte schauen, ob diese Sprachen nicht eher unseren Bedürfnissen entsprächen. Beide Sprachen haben seit den Anfängen des Internets enorme Poularität erreicht und werden in unzähligen Webseiten verwendet. Als ich mir diese beiden Sprachen ansah, kam ich zu dem Schluß, daß sie in der Tat sehr gut auf unsere Bedürfnisse zugeschnitten waren – VBScript war da im speziellen sehr interessant. Also, warum haben wir letztendlich nun nicht VBScript für Torment verwendet? Weil ich einfach keine entsprechende "Virtual Machine" für diese Sprache finden konnte. Die "Virtual Machine" ist der Teil der Sprache, der den Code ausführt. Alle VM die ich fand, waren entweder zu groß, zu teuer, oder es wäre ein zu großer Aufwand gewesen, diese VM umzuschreiben. Da VBScript Eigentum von Microsoft ist, findet man darüber kaum Information und man darf sich den Code dieser VM nicht anschauen. Man könnte zwar den Internet Explorer ummodeln, aber das fiel für mich flach, weil ich dieses Programm einfach nicht mag.

Ich hab mir auch Python angeschaut und schnell herausgefunden, daß es kaum Information über das Sprach-Kernel gibt – also fiel auch diese Sprache flach. Schließlich entschieden wir uns für das Bioware Tool, obwohl das anfangs eine sehr unbefriedigende Lösung war.

Als wir erst einmal mit den Scripts anfingen, entfaltete die Bioware Sprache ihre wahre Schönheit. Die Stärke dieser Sprache, nennen wir sie einfach Isript – für Infinity Script – liegt in ihrer Einfachheit. Was mir an Java und VBScript nie so recht gefiel, war der Umstand, daß sie richtige Programmiersprachen sind und auch Programmierer verlangen, die mit ihnen umgehen können. Sinn und Zweck einer Scripting-Sprache wäre aber, daß jeder damit umgehen kann. Die Sprache muß leicht und schnell zu lernen sein und sie muß sehr intuitiv sein. Wichtigster Punkt aber ist – eine Scripting-Sprache muß SICHER sein!

VBScript und vor allem Java sind voll von potentiellen Fehlerquellen für den Scripter. Wenn die Sprache einen Fehler nach dem anderen hervorruft, tut man sich keinen Gefallen. Man muß sicherstellen, daß die Scripts nur "sichere" Dinge tun können, damit nicht das ganze Spiel wegen einem fehlerhaften Script lahmgelegt wird. Durch seinen sehr objektorientierten Zugang verleitet Java die Scripter dazu, sehr aufwendige Scripts zu schreiben. Ohne die nötige Erfahrung versetzt man genau auf diese Art und Weise seinem Spiel den Todesstoß. Die Sicherheit eines Scripts hat viel damit zu tun, wie die Implementierung funtkioniert und wie die Spielengine angesprochen wird – komplexe Sprachkonstrukte sind ein idealer Nährboden für fehlerhaft Scripte. Wir wollten diesen Umstand natürlich vermeiden und Iscript hilft uns da ganz besonders. Diese Sprache wurde speziell für die Infinity Engine geschrieben und ist sehr gut auf die Engine abgestimmt und sie folgt dem logischen Denkprozeß, dem man nachgeht, wenn man darüber nachdenkt, welche Dinge man berücksichtigen muß, wenn man verschiedene Elemente in das Spiel einbauen will. Mit nur ein paar Befehlen erweckt man ganze Gebiete im Spiel zum Leben, wo man bei Java, VBScript oder Python eine Menge an Code benötigen würde. Und jede Zeile Code kann Probleme hervorrufen...

Ich weiß nicht, ob diese Erklärung ausreichend oder befriedigend war, aber ich hoffe, daß sie Euch einen kleinen Einblick in den Prozeß der Entscheidungsfindung bezüglich der Scripting Sprache gibt. Man könnte selbstverständlich Teile von bereits vorhandenen Scripting Sprachen verwenden, aber meistens braucht man spezielle Versionen. Das ist eine der Grundregeln (und einer der größten Nachteile) in der Spieleindustrie. Nichts, was auf dem Markt erhältlich ist, ist für uns geeignet. Sind wir zu anspruchsvoll? Vielleicht, aber normalerweise werden Programmiersprachen und Hardwaretreiber nicht für Spiele geschrieben. Also wurden wir gezwungen, eigene Lösungen zu finden und wir sind nun an dem Punkt angelangt, an dem wir manchmal die Dinge verschmähen, die der Markt für uns bereitstellt, ohne großartig darüber nachzudenken. Wir wissen, daß wir für jedes Problem auch ohne deren Hilfe eine Lösung finden. Glücklicherweise hat sich die Situation in den letzten Jahren verbessert. Wir wissen, daß es Spiele gibt, die Java und VBScript verwenden. Vielleicht werden auch wir diese Sprachen in Zukunft verwenden – das wird dann der Fall sein, wenn uns Microsoft erlaubt, ihre Virtual Machines unter die Lupe zu nehmen.

Guido Henkel
Project Director

25.06.1999

Vor langer, langer Zeit gab es da einen Bauern, der wegen seiner Arbeit mit Tieren bekannt wurde. Ihr wißt ja wie das ist, die Leute neigen zu Übertreibungen, denn als sich die Geschichte über die Lande verbreitete, ging das Gerücht um, daß dieser Bauer sogar mit den Tieren sprechen konnte – und ihnen lehren konnte, zu antworten. Der König, der eifersüchtig war, weil dieser Bauer so große Aufmerksamkeit auf sich zog, bestellte den Bauern an seinen Hof und trug ihm auf, dem königlichen Schwein das Sprechen beizubringen. Sollte er dies nicht schaffen, würde er auf der Stelle hingerichtet werden.

"Ich werde dem königlichen Schwein das Sprechen beibringen" antwortete der Bauer "Aber ich brauche dafür 10 Jahre."
Auf dem Heimweg fragte der Sohn des Bauern seinen Vater: "Bist du verrückt?! Warum hast du dieser Sache nur zugestimmt?"
Der Bauer sage: "Sohn, vieles kann in zehn Jahren passieren. Ich könnte sterben. Der König könnte sterben. Oder das Schwein könnte lernen zu sprechen."

- Bauer Peterson

Guido und ich führten kürzlich eine Unterhaltung, in der wir darüber sprachen, was uns am meisten daran gefällt, in dieser Branche zu arbeiten. Für mich ist das Schönste daran, der Umstand, daß ich mit Träumern zusammenarbeiten darf. In unserer Branche geht es darum, Träume real werden zu lassen. Dinge, die sich vor zehn Jahren noch niemand vorstellen konnte, gelten heute als selbstverständlich und ich ertappe mich ständig dabei, wie ich mir vorstelle, wie wohl unsere Branche in 10 Jahren aussehen wird.

Ich kann mich noch gut erinnern, als ich mit ein paar Freunden mein erstes "Computerspiel" auf einer selbstgebastelten Kiste programmiert habe (das war 1978). Es handelte sich dabei um eine sehr böse Grafik (eine Nazi-Flagge), auf der langsam viele Einschußlöcher (schwarze Rechtecke) auftauchten (zufallsgeneriert). Wenn eine Kugel genau den Mittelpunkt der Flagge traf, stoppte das Programm und sagte einem, wie viele Schüsse auf die Flagge gefeuert wurden, bevor die Mitte getroffen wurde. Wenn man anschließend die Leertaste drückte, fing das Ganze wieder von vorne an. Wir sind manchmal stundenlang vor dem Schirm gesessen und haben uns dieses "faszinierende" Programm angeguckt. Ich und die anderen unserer "Wargamer" Gruppe saßen oft bis spät in die Nacht herum, spielten D&D und sprachen über unsere Träume, die wir bezüglich Spiele/Spieletechnologie hatten. Wäre es nicht cool, wenn man mit weit entfernten Leuten zusammen ein Spiel spielen könnte? Oder wäre es nicht toll, wenn man einen Dungeon entwerfen könnte, den man in 3D durchwandern könnte und wenn man die ganzen Monster und Schätze sehen könnte?

Was ich damit zum Ausdruck bringen möchte ist folgendes: Ich bin live dabei, wenn genau diese "Wäre es nicht toll wenn..." Diskussionen Wirklichkeit werden. Ein Tagtraum, den man heute träumt, könnte DAS Superspiel oder DIE Supertechnologie von morgen werden.

Meine Frau hat mir immer vorgeworfen, ich sei ein Träumer. Ich glaube es frustriert sie, weil ich noch immer glaube, daß Träume immer wahr werden können. Heute werde ich dafür bezahlt, daß ich aus Träumen Wirklichkeit mache. Was wird nur aus dieser Welt?

Greg "Big Tuna" Peterson
Black Isle Studios Marketing

24.06.1999

Hallo Leute,

Heute werde ich für Euch ein Update schreiben. Ich heiße Jake Devore und bin einer der drei Scripter, die an Planescape:Torment arbeiten. Wo soll ich anfangen? Das Projekt geht jetzt so schnell voran . . .

Ich werde Euch einfach erklären, was ein Scripter so alles machen muss. Meine Hauptaufgabe besteht darin, die KI (=Künstliche Intelligenz) Scripts zu schreiben, die es den Figuren in Planescape ermöglicht, auf ihre Umgebung zu reagieren. Die Designer sagen uns, wie sich eine bestimmte Figur im Spiel verhalten soll und wir schreiben dann den entsprechenden Code. Dieser Code ist bei der Infinity-Engine so ähnlich aufgebaut, wie Basic, nur ist er nicht so flexibel. Es gibt nur IF-THEN Befehle. Das kann zwar manchmal ziemlich frustrierend sein, hat aber auch seine Vorteile. Wenn die Scripts sehr kompliziert sind, ist es kein Leichtes, mit dieser Sprache zu arbeiten. Für die meisten Aufgaben ist diese IF-THEN Herangehensweise aber mehr als ausreichend. Für ein einfaches Script benötigt man nur so um die 5 Minuten. Es existieren auch keine Makros oder benutzerdefinierte Funktionen in dieser Infinity-Engine-Scripting-Sprache, was heißt, daß man jede Menge "Ausschneiden und Kopieren" Jobs zu bewältigen hat. Aber alles in allem ist es nicht allzu schwer, mit dieser Engine zurechtzukommen.

Nachdem das Script geschrieben wurde, muß man es kompilieren. Dieser Vorgang dauert normalerweise nicht allzu lange – das hängt natürlich von der Länge des Quellcodes für das jeweilige Script ab. Beim Kompiliervorgang passiert folgendes: das Script wird in den Engine Code übersetzt und komprimiert, damit das Ganze schneller läuft.

Wenn das Script einmal kompiliert wurde, wird es zum Resource Editor hinzugefügt. Der Resource Editor ermöglicht es der Engine, die benötigten Daten schneller zu finden. Wenn das Script einmal im Resource Editor gespeichert wurde, kann es der Scripter testen. Normalerweise machen wir einen schnellen Test der Scripts, um zu sehen, ob alles so läuft, wie es laufen soll, will heißen, wir greifen jemanden oder etwas an, oder führen bestimmte Aktionen – für die wir ein Script geschrieben haben – aus.

Wenn wir sicher sein können, daß alles richtig funktioniert, spielen wir die Daten in unser Version-Control-System ein. Sollten dann noch Probleme auftauchen, nehmen wir die eingespielten Files einfach aus dem System raus, bereinigen die Fehler, testen noch einmal und spielen sie anschließend wieder ein und dann wird das Spiel upgedatet.

Das ist eigentlich im Prinzip alles, was ein Scripter so macht. Wir machen diese ganze Prozedur für sämtliche Abschnitte im Spiel. Ich hoffe, mein News Beitrag war für Euch alle informativ – obwohl die meisten von Euch, die mit dem Lesen bis zu diesem Punkt vorgestoßen sind, sich wahrscheinlich gewünscht hätten, doch schon früher mit dem Lesen aufgehört zu haben.

Herzlichst,

Solltet ihr es noch nicht gemerkt haben, es gibt eine neue Umfrage. Ich bitte um kräftige Teilnahme *g*
Wenn ihr Fragen zu irgendwas habt, oder Verbesserungsvorschläge für die Page, oder sonst irgendwas vorbringen möchtet, dann könnt ihr übrigens ruhig im Forum posten ;o)

- Trumpfass

Und wieder mal ein Update für die Seite. Im Folgenden findet Ihr News Segmente, und zwar von Colin McComb, von Guido "Letterman" Henkel, Big Tuna hat auch wieder einiges zu sagen und zuletzt erklärt uns Dan Spitzley, wie man beim Programmieren Fehler vermeidet (ich hoffe ich hab jetzt niemanden vergessen J ).

Also, bis dann

- Sermon

22.06.1999

"Natürlich hat er ein Messer. Er trägt immer ein Messer. Wir alle haben Messer. Wir schreiben das Jahr 1183 und wir sind Barbaren!"
- Katherine Hepburn in "The Lion In Winter"

Obwohl ich immer versuche, daß mein Zitat einen direkten Bezug zu meinem Update hat, konnte ich mich diesmal nicht zurückhalten . Ich mußte dieses Zitat einfach verwenden, obwohl es mit dem, über das ich heute erzählen möchte, nichts zu tun hat.

"Worüber werden wir heute sprechen Colin?"

Ich werde heute über die unbesungenen Helden dieses Projektes sprechen. Sie sind die Leute, die entscheidende Designelemente beisteuern, da es ihr Job ist, die Welt zum Leben zu erwecken und sie real aussehen zu lassen. In anderen Worten, ihre Arbeit ist subtil aber absolut essentiell. Ich spreche von den technischen Designern. Ich spreche von Scott Everts, Dave Hendee und Jason Suinn.

Fangen wir mit Sott Everts an. Sein Job ist es, Charaktere und die generellen Animationen ins Spiel zu bringen (bitte verzeiht meine extreme Vereinfachung seines Jobs – er ist ein absoluter Zauberkünstler in Sachen Grafik, alles was er anfaßt wird zu Gold). Er hat laut seinen Aussagen schon "soviel Mist gebaut, daß er das meiste davon schon wieder vergessen hat". Euch ist sicher schon oft aufgefallen, daß die allgemeinen Charaktere in einem Spiel alle gleich aussehen und absolut dieselbe Farbpalette benutzen. Scott's Aufgabe ist es, für jeden einzelnen dieser Charaktere eine eigene Farbschablone zusammenzustellen und es dann zu ermöglichen, daß wir diese Farben verändern können, um sogar die trivialsten Stadtbewohner im Spiel einzigartig zu gestalten. Da es von diesen Leuten tausende gibt, ist Scotts Arbeit für uns sehr wichtig. Ohne Scott E., der diese Aufgabe erledigt, wäre das Spiel ziemlich farblos. Sorry, das mußte gesagt werden.

Laßt uns nun zu Dave Hendee übergehen. Außer daß er wie ein Verrückter Ping Pong spielt, ist er noch verantwortlich für Search Maps, Height Maps und Clipping (das letztere zusammen mit Jason Suinn, Derek Johnson und Dennis Presenell) – er wird sich bald um die Charakterplazierung kümmern und uns mit dem Abschnitt-Design aushelfen. Search Maps sind die unsichtbaren "Überzüge", die auf dem Hintergrund aufliegen und festlegen, welche Abschnitte der Charakter begehen kann und welche nicht. Eine Search Map verhindert zum Beispiel, daß ein Charakter über Mauern und Gebäude einfach hinweglaufen kann. Clipping gehört zu der Search Map dazu – das Clipping sagt dem Computer, an welchen Stellen der Charakter "vorne vorbeiläuft" oder "hinten vorbeiläuft". Dave stellt auch sicher, daß die Height Maps funktionieren und das Ganze im Spiel richtig aussieht. Es sieht wirklich blöd aus, wenn's nicht richtig gemacht wird. Dave macht seine Arbeit richtig, also sieht's auch nicht blöd aus.

Zum Schluß Jason Suinn. Ich habe keine Ahnung was er macht, um Dampf abzulassen. Vielleicht kocht er ja was. Vielleicht schlägt er Leute zusammen. Alles was ich weiß ist, daß er ein Kongreßabgeordneter ist. Er ist ziemlich schmal-lippig. Eins ist sicher: ohne ihn würdet Ihr im Spiel nirgends hinkommen. Er fügt die einzelnen Karten zusammen und stellt sicher, daß die Tore dorthin führen, wo sie auch hinführen sollen. Wenn er seinen Job nicht machen würde, würden wir alle in der Leichenhalle festsitzen, wir wären nicht in der Lage die Stufen rauf- und runterzulaufen und wir würden Sigil nie zu Gesicht bekommen. Jason hat früüüher ca. 50 % des Clippings gemacht, hat Search Map Sounds hinzugefügt und die Hälfte der Height Maps gemacht. Er hat auch bei den einzelnen Abschnitten mitgearbeitet, den Inventory Items und er hat sich all die Behälter und verschlossenen Türen im Spiel ausgedacht. Viel Arbeit, aber Jason macht das mit Links.

Die Arbeit dieser Leute ändert sich ständig und entwickelt sich mit den Bedürfnissen des Projektes weiter. Die Story Designer kümmern sich um ein paar Hauptaufgaben; diese Jungs arbeiten sozusagen im Untergrund des gesamten Spiels. Was sie machen ist absolut lebensnotwendig für das Spiel. Vielleicht fällt Euch während des Spielens nicht auf, was diese Jungs geleistet haben, aber Ihr würdet's absolut merken, wenn es nicht da wäre. Technische Designer werden oft stiefmütterlich behandelt – aber das ollte nicht so sein. Ohne sie wären unsere Spiele nur halb so gut.

Oh, übrigens: Herzlich willkommen Scott Warner und Kihan Pak. Sie sind unsere brandneuen Designer. Scott haben wir uns von der Qualitätssicherungs-Abteilung ausgeliehen und er wird sich um die Plazierung der Monster und die Bewegungsabläufe kümmern. Er wird auch ein Paar Dialoge einstreuen, nur um das Ganze etwas aufzulockern. Kihan war ein Produzent bei einer anderen Abteilung aber er hat das hektische Leben gegen die etwas ruhigere Gangart eines Projektes, welches in den letzten Geburtswehen steckt, eingetauscht. Willkommen an Bord, Leute.

Colin McComb
Level 12 Designer (mit Goth Stronghold)

21.06.1999

Wißt Ihr, es wird immer schwieriger mit neuen Updates für diese Seite aufzuwarten. Deshalb wollte ich mit Euch einige Geheimnisse meines Jobs teilen.

Hier also eine Top 10 Liste der Dinge, die ich an diesem Job liebe und hasse!

Die Top-5 der Gründe, warum ich es liebe, ein Project Director zu sein:

1. Ich bekomme all diese tollen Computerspielemagazine gratis
2. Ich werde fürs Spiele spielen bezahlt
3. Ich habe die Möglichkeit etwas zu erschaffen, was die Leute mögen
4. Ich habe die Möglichkeit viele wirklich interessante Leute zu treffen und die Möglichkeit, diese einfach anzurufen
5. Ich erliege der Illusion, hier das Sagen zu haben

Und nun die Top-t der Gründe, warum ich es hasse, ein Project Director zu sein:

1. Ich habe keine Zeit zum Lesen all der geschenkten Computerspielmagazine
2. Meetings, die niemals enden wollen
3. Ich muß schlechte Neuigkeiten dem Vorstand überbringen
4. Das Fehlen von Gratis-Autos (letztendlich gibt’s ja auch Rennspiele, oder?)
5. Ich erliege der Illusion, hier das Sagen zu haben

Wie Ihr sehen könnt, ist das eine recht ausgeglichene Sache. Ein Project Director zu sein kann eine Menge Spaß machen, aber glaubt mir – es kann auch eine richtige Qual sein. Ihr glaubt meine Liste ist Scheiße? Nun, dann schaut Euch mal an, was für Top-10-Listen Harald Schmidt jede Nacht so aufstellt – ist auch nicht sonderlich interessant.

Okay Leute, ich muß jetzt wieder weg, aber nächste Woche gibt's wieder ein Update.

Guido Henkel
Project Director

18.06.1999

Kämpfe niemals mit einem Schwein. Du wirst nur dreckig und dem Schwein gefällt's.
- Bauer Peterson

Diese Woche gibt's aus der Marketing-Perpektive tolle Planescape:Torment Neuigkeiten. Im Mai ist das Spiel in die Top-20-Liste der am sehnlichsten erwarteten Spiele für dieses Jahr gerutscht. Wie wissen wir das? Nun, wir starten jeden Monat unsere eigenen Kundenbefragungen um festzustellen, welchen Einfluß unser Marketing hat. Das bringt mich nun zu dem Thema, über das ich heute im Marketing Update sprechen möchte.

Viele Leute sehen im Marketing nur eine handvoll Aktivitäten ohne den Einfluß auf den Markt zu würdigen, den wir erreichen wollen. Also, das Marketing hat folgende Aufgaben: erstens mal die Aufmerksamkeit auf ein Produkt zu lenken und zweitens, eine positive Kaufabsicht beim Kunden hervorzurufen. Eine großartige Sache beim Marketing ist die, daß man diese Ziele leicht messen kann. Zum Beispiel: Diablo II – jemals davon gehört? Natürlich! Wirst Du's kaufen? Viele von Euch werden mit einem "Ja" antworten. Die Schwierigkeit dabei ist es herauszufinden, wie jedes einzelne Marketingprogramm diese beiden Faktoren beeinflussen kann und einen Marketingplan zu erstellen, der genau zu dem Zeitpunkt, zu dem das Spiel im Handel erhältlich ist, ein Höchstmaß an Interesse und Bekanntheit erzeugt. Aus langjähriger Erfahrung wissen wir, wo ein Titel auf der Bekanntheits- und Kaufabsichtsskalq 12, 6, ... Monate vor seiner Veröffentlichung stehen sollte, um eine bestimmte Menge an Einheiten zu verkaufen. Wenn der Bekanntheitsgrad dem Plan voraus ist, werten wir das als gutes Zeichen, aber wenn er hinter dem Plan herhinkt, starten wir eine Reihe von Maßnahmen, um dem Titel etwas auf die Sprünge zu helfen.

Natürlich habe ich noch nicht darüber gesprochen, was NACH der Veröffentlichung eines Spiels so passiert. Zu diesem Zeitpunkt spricht die Qualität des Spiels für sich selbst via Spieletests in Fachmagazinen, Mundpropaganda, etc. Einige Dinge können nun passieren; erstens, das Spiel kann BESSER sein als erwartet – in diesem Fall ist die Marketingkampagne dem Spiel nicht gerecht geworden und man hat einen sogenannten "Sleeper Hit" Titel. Dagegen gibt es auch die Situation, wo das Spiel "over-hyped" wurde und SCHLECHTER ist, als es in der Marketingkampagne dargestellt wurde und der große Ansturm auf das Produkt ausbleibt (wir kennen da alle ein paar solcher Fälle). Im optimalen Fall will man erreichen, daß die Marketingkampagne den Leuten das Spiel schmackhaft macht, die als Zielgruppe gelten und es nicht über oder unter seinem Wert gehandelt wird.

Mein Herz hängt sehr an Planescape:Torment und ich habe das Glück, an Titeln abeiten zu können, von denen ich glaube, daß sie sehr erfolgreich sein werden (letztes Jahr habe ich eine Wette gewonnen, als ich bei einem Verkaufsmeeting gesagt habe, daß sich Baldur's Gate mindestens 400.000 mal verkaufen wird). Es macht Spaß sagen zu können "Ich hab Euch's ja gesagt", wenn ich so beobachte, wie Torment immer bekannter wird, denn aus der Perspektive eines Spielers muß ich sagen, daß ich wirklich an dieses Spiel glaube. Tief in meinem Herzen denke ich jetzt "Es ist auch Zeit", denn ich beobachte das Marketing wie ein Falke und ich habe IMMER das Gefühl, daß ich nicht genug mache um den Fans zu zeigen, wie toll dieses Spiel werden wird.

Es wird wirklich verdammt cool werden.

Greg "Big Tuna" Peterson
Black Isle Studios Marketing

17.06.1999

Treue Leser,

wie wir alle wissen, scheint sich in der Branche ein Trend durchzusetzen, daß man Spiele halbfertig veröffentlicht und später die Probleme mittels Patches beseitigt. Wir alle mussten uns mit sowas schon auseinandersetzen. Ich spiele auch gerne und hasse es, ein Spiel erst dann wirklich spielen zu können, wenn der Patch dafür veröffentlicht wurde. In meiner Funktion als Chefprogrammierer im Torment Team verspreche Ich Euch, daß ich mein Möglichstes tun werde, um sicherzustellen, daß das Spiel so stabil wie möglich läuft, wenn Ihr es in Euren Händen haltet. Diese Woche erzähle Ich Euch etwas darüber, welche Maßnahmen ich treffe, um Bugs zu vermeiden. Viele dieser Dinge sollten für Programmierer zum Allgemeinwissen gehören, aber Ihr wärt erstaunt wenn Ihr wissen würdet, wieviele Programmierer diese Dinge übersehen, während sie in ihrem eigenen "Programmierstil" arbeiten.

ALLES DESIGNEN

Bevor ich auch nur eine einzige Zeile Code schreibe, überlege ich mir GENAU, was ich erreichen möchte. Ich arbeite vorher immer ein Design für ein Stück Code auf einem Blatt Papier aus, bevor ich den Compiler überhaupt anrühre. Einfach draufloszuprogrammieren, ohne die Abläufe durchzugehen, kann später schlechte Auswirkungen auf den Programmierprozeß haben. Ich muß mir überlegen, ob das Stückchen Code, welches ich gerade schreibe, mit anderen Teilen des Codes zusammenarbeiten muß, oder ob es später mit anderen Features verbunden werden muß. Wenn man im Voraus plant, spart man sich später Einiges an Kopfschmerzen. Stellt Euch ein System vor, welches einem Charakter auf dem Bildschirm sagt, er soll auf einen anderen Charakter zugehen. Nachdem die KI gecheckt hat, daß da ein Bewegungsbefehl notwendig ist, könnte man den Befehl direkt zu dem Charakter senden. Wenn das Spiel aber dann Multiplayer-fähig sein soll, muß man einplanen, daß man den Bewegungsbefehl über das Netzwerk zum Gamehost und dann zu den Guests schicken muß. Diese Dinge müssen also alle rechtzeitig berücksichtigt werden. Wenn man den Code dann im Nachhinein ändern muß, um neue Features einzubauen, schleichen sich unweigerlich Bugs ein, ganz egal wie toll der Programmierer ist.

Ein anderer Grund, warum man vorher auf Papier designen sollte ist, daß viele Algorithmen eine ganze Reihe an speziellen Fällen eingebaut haben müssen, die auf Anhieb nicht augenscheinlich sind. Wenn man diese Dinge im Code nicht berücksichtigt, steigert sich die Chance drastisch, daß sich Bugs in den Code einschleichen. Wenn man sich die Zeit nimmt und alle seine Inentionen aufschreibt und alle möglichen Eingaben berücksichtigt, die während der verschiedenen Spielphasen möglich sind, muß man sich unter Umständen vielleicht später gar nicht mehr um den Code kümmern.

BRING ES ZU ENDE

Ich habe herausgefunden, daß einer der Hauptgründe für Bugs der ist, daß man unabsichtlicherweise ein Stückchen Code nicht fertigstellt und danach darauf vergißt. Das mag sich jetzt blöd anhören, aber bei all den Ablenkungen, die so ein stinknormaler Arbeitstag so mit sich bringt, passieren solche Dinge ständig. Wenn man den ganzen Tag hektisch von einer Sache zur anderen springt, hat man gute Chancen, daß einige dieser Code-Stückchen duch den Rost fallen. Mein Rat also, wenn Ihr an einer Sache arbeitet, bringt sie auch zu Ende. Haltet Euch nicht mit anderen Sachen auf, die Euch dazwischenkommen, denn sonst wird der Code nie fertig. Jaja, manchmal gibt es eben Dinge, die wichtiger als das sind, an dem Ihr gerade arbeitet. Wenn sowas passiert, mach ich mir eine kleine Notiz, auf der ich vermerke, wo ich gerade war und ob es irgendwelche speziellen Dinge bei diesem Stückchen Code zu beachten gibt. Wenn ich mich dann meiner alten Arbeit widme, kann ich genau wieder dort loslegen, wo ich aufgehört habe. Auf diese Art und Weise ermögliche ich auch den anderen Programmierern an meinen Daten rumzuwerkeln, da die Anzahl meiner Dateien, die aus dem Source Control-Modul ausgeklinkt sind auf ein Minimum reduziert sind (Ihr erinnert Euch sicher an mein letztes Update).

SCHREIBT ALLES MIT

Wann auch immer ich an eine unerledigte Sache oder an ein paar Zeilen ungeschriebenen Codes denke, schreibe ich das in ein Text-Dokument, welches ich mir auf den Windows-Desktop lege. Diese Liste wird auch in der Source Control abgespeichert, sodaß sie auch alle anderen Programmierer lesen können. Das ist wieder eine Lösung, wie man verhindert, daß Dinge vergessen werden. Diese Liste kann ganz schön lang werden, aber auf diese Weise stellt man wenigstens sicher, daß nichts vergessen wird. Viele dieser Dinge werden dann wieder von der Liste gestrichen, weil sie nicht wichtig sind. Aber man merkt wenigstens, daß man sich Gedanken um diese Dinge gemacht hat, bevor man beschlossen hat, daß sie unwichtig sind.

AUSPROBIEREN

Zuguterletzt, wenn ein Stück Code geschrieben wurde, dürft Ihr nicht einfach annehmen, daß er funktioniert. Und Ihr solltet Ihn auch nicht einfach ein paar mal im Spiel ausprobieren. Schaut Euch den Code Stück für Stück im Debugger an und findet heraus, was jede einzelne Zeile macht. Ich kann Euch gar nicht sagen, wieviele Bugs ich auf diese Weise schon gefunden habe. Wenn Ihr den Algorithmus durchgeht (speziell dann, wenn er viele Schleifen und so enthält) seid Ihr gezwungen zu verstehen, wie der Hase läuft.

Ich hoffe dieses Update zeigt Euch, daß wir hier im Torment Team Stabilität und Korrektheit wirklich groß schreiben.