F: Hast du mit anderen Engines gearbeitet, bevor du bei Conitec’s Acknex gelandet bist?
A: Vor etwa zehn Jahren gab es ein Programm "3D Construction Kit" einer britischen Softwarefirma namens Superscape, durch das ich mich sehr für das Arbeiten mit einer skriptbasierten 3D Spiele-Engine interessierte. Ich habe Genesis3D/Jet3D für ein paar Monate ausprobiert, bevor ich zu Conitec gegangen bin. Ansonsten arbeitete ich hauptsächlich mit „low-level graphics APIs“ wie IrisGL/OpenGL, DirectX.

F: Ich weiß dass du erst vor ein paar Jahren zu Conitec gekommen bist; wie hast du C-Script gelernt?
A: Durch Lesen des gedruckten Handbuches, dass mit der Sybex Extra Edition geliefert wird. Als ich es gelesen hatte, war eine Anzahl von Fragen noch immer unbeantwortet, daher kann ich einige Anfragen, die wir im „Blame the Manual" Forum sehen konnten, verstehen. Jedoch machte alles, nach einem zweiten Lesedurchgang und ein paar Testprogrammen, einen ziemlich guten Sinn. Für Neulinge empfehle ich den 7-Tage-Workshop und anschließendes Herumspielen mit dem Code, um zu sehen was die Änderungen bewirken.

F: Es gibt viele Benutzer, die gerne das SDK beherrschen würden. Welche Bücher würdest du empfehlen?
A: Das SDK selbst ist nur ein Interface zu den internen Datenstrukturen vom Gamestudio und den C-Script Funktionen. Ich glaube nicht dass man ein leeres SDK-Projekt erstellen kann und anschließend schaut, was man damit anstellt – man muss die Idee eines verblüffenden Grafikeffekts oder einer erweiteren Scriptfähigkeit haben und sich dann erst ans SDK wenden, um diese Idee einzubinden. Eine Sache die ich zur Zeit bearbeite ist die Möglichkeit, Gamestudio als Visualisierung für den Windows Media Player 9 zu benutzen – das wäre ein perfekter Kanidat, um mit dem SDK herumzuspielen und zu testen, ob es als Interface zwischen diesen beiden Anwendungen funktionieren kann. Ein anderes Projekt, dass ich wegen Zeitproblemen fallen lassen musste, war ein Schachspiel, das Gamestudio als Input/Output benutzt und sich zu einer Open Source Schach-Engine für die Zugberechnungen verbindet.

Ich habe keine Empfehlungen für gute Einführungsbücher in C aber hier ist eine Liste:
- Stroustrup- "The C++ Programming Language" (wenn man C kennt aber zu C++ wechseln will)
- Woo/Neider/Davis/Shreiner- "OpenGL Programming Guide (Red Book)"  (Einführung in 3D Grafik)
- Moeller/Haines - "Real-Time Rendering" (erweiterte Computergrafik, Spezialeffekt-Programmierung, High-End Rendering)
- Lengyel - "Mathematics for 3D Game Programming & Computer Graphics" (man kann die Mathematik nicht umgehen wenn man schöne Bilder erzielen will)
- Microsoft - "Visual C++ online help system"

F: Welche IDE / Programmiersprache (MSVCPP, Delphi, usw.) ist die beste für die Nutzung mit dem SDK? Warum?
A: MS Visual Studio C++ 6.0. Das Conitec Entwicklungsteam benutzt Visual Studio 6.0/ 7.0, daher ist dies die Plattform auf der wir die meisten Tests machen, und wenn Fragen im SDK Teil des Forums auftreten können wir zuverlässigere Antworten geben. Visual Studio 7.0 ist etwas überhäuft und man braucht mehr Aufwand um effizienten Code zu erstellen, aber beide funktionieren einwandfrei mit dem SDK.

F: Wie sollten wir unsere Levels designen um die Framerate hoch zu halten?
A: GameStudio bietet eine Vielzahl von Features für spezielle Aufgaben – wenn man sich jedoch auf ein paar beschränkt kann man damit große Wirkung bei der Framerate erzielen. Der Map-Compiler der die Levels vom WED ins effizientere Format für Gamestudio übersetzt, nimmt an dass man labyrinthartige Innenlevels erstellt. Wenn man WED benutzt, um riesige Außenlevels zu erstellen wird die Framerate sinken, deshalb sollte man im WED nur die groben Umrisse erstellen und den Rest durch Terrains hinzufügen. Benutze L oder U – geformte Korridore zwischen Räumen – für gewöhnlich nimmt der Map-Compiler dies als Hinweis, die Räume getrennt zu bearbeiten. Wenn man einen geraden Gang zwischen zwei Räumen hat, ist die Wahrscheinlichkeit hoch dass sie als einzelner, großer Raum betrachtet werden, was die Framerate erneut reduziert. Betreffs Details – erstelle keine Türknöpfe, Schrauben, Leitern usw. als Teil deines Hauptlevels, dies kann Einfluss auf die Rendergeschwindigkeit der näheren Räume haben (die möglichen Compiling-Fehler lassen wir mal außen vor). Stattdessen sollten Details als seperate Map-Entities oder MDLs erstellt werden. Wenn man Wert auf korrekte Schattengebung dieser kleinen Details setzt, sollte man zumindest das Detail – Flag für diese kleinen Blocks setzen. Eine sehr wichtige Empfehlung: Benutze LOD wenn möglich. Wenn der Spieler in einem Flugzeug über einen Wald fliegt gibt es keinen Grund 500–Polygon–Bäume zu benutzen. Andererseits, wenn der Spieler landet und zum Baum läuft (um das böse Eichhörnchen zu fangen), sollte man einen 2000 – Polygon Baum benutzen, oder die Anwender werden sich über die Grafikqualität beschwerden. Trotz AGP Ports ist ein Haupt-Flaschenhals der Grafikkarten immer noch der Transfer der Texturen vom Mainboard-RAM ins Grafikkarte-RAM. Um den Einfluss dieser Transfers zu minimieren, sollte man es unterlassen zu viele Texturen oder Lightmaps zu verwenden. Wiederverwerte Texturen so oft wie möglich, stelle sicher dass deine Texturen quadratisch sind und Vielfache von Zwei in Höhe und Breite. Wenn es mehrere Styles in deinem Level gibt, halte sie getrennt, zum Beispiel könnte es in deiner Alien-verseuchten Raumstation Texturen mit metallenen Oberflächen geben, aber auch organische Strukturen. Wenn du einen Gang hast, der einerseits Metallwände, aber auch organische Texturen benutzt, dann müssen beide Texturen zur selben Zeit im RAM der Grafikkarte sein. Mit wenig Texturspeicher kann eine wechselnde Nutzung von diesen beiden Texturen das Spiel verlangsamen. Begrenze deinen Gang auf Metalltexturen, dann beginne nach einer U-Kurve deinen organischen Teil des Levels. In der U-Kurve könnte es einen Geschwindigkeitsverlust geben, aber es wird weniger RAM in den beiden Hälften des Levels benutzt.

F: Lohnt es sich eine Dual-CPU für das Builden der Levels zu kaufen?
A: Für kleine Entwicklerteams löhnt sich ein Multiprozessorsystem nicht. Es werden vier Schritte vollzogen: Erstellung der Geometrie, Portalgenerierung, Visibility-Berechnung und das Lighting. Zur Zeit benutzt nur die Visibility-Berechnung mehrere Prozessoren, aber bei den meisten Levels ist dieser Schritt der langsamste und kann auf langsamen PCs Tage dauern. Der Schritt kann jedoch übersprungen werden: Gamestudio läuft tadellos ohne Visibility-Informationen (es rendert dann den ganzen Level wie es auch WED tut). Das erzeugt normalerweise einen großen Performanceeinbruch – aber wenn man nur die aktuelle Ausleuchtung kontrollieren will macht dies ja nichts. Um die Visibility-Berechnung zu verhindern, wähle „Testmap“ anstatt von „Levelmap“ beim Builden aus. Wenn dann das Projekt fertig ist, builde das Level mit aktiviertem „Levelmap“, um überall die höchste Framerate zu erzielen. Da dies nun gesagt ist: Wenn man an einem hochkarätigen Titel arbeitet und die Levels oft auf hervorragende Geschwindigkeit überprüfen will, können diese Buildvorgänge sehr häufig nötig sein, sogar im frühen Entwicklungsstadium. In diesem Fall macht es tatsächlich Sinn ein Multiprozessorsystem zu benutzen. Ein Kunde hat die folgenden Berechnungszeiten für das gleiche Level festgestellt: Einzelner Prozessor: 6 Stunden, Dual Prozessor: 4.2 Stunden, Quad Prozessor: 2.1 Stunden

F: Welche Features planst du in der näheren Zukunft zum wmp2wmb Compiler hinzuzufügen?
A: Eine der hauptsächlichen Veränderungen die wir planen ist das Ersetzen der BSP (Binary Space Partition) -Struktur und vielleicht die Entfernung der Portal-Informationen. Zur Zeit stellt der Map-Compiler sicher dass nur Polygone in dem Raum gerendert werden, in dem der Spieler ist. Das ist gut für langsame PCs, aber mit schnelleren Grafikkarten macht es Sinn auch die Nachbarräume zu rendern, weil dies die CPU entlastet, die nun mehr Platz für sinnvollere Berechnungen wie KI oder Sound hat. Als kleiner Bonus bedeutet dies eine gewaltige Reduzierung der Build-Zeit, bessere Shadowmaps und vielleicht sogar die Möglichkeit, Geometrie während dem Spiel hinzuzufügen.

F: Kannst du uns ein paar Tipps für die Anfänger unter uns geben?
A: Beginne klein. Wenn du dein erstes Spiel ähnlich, aber besser als Grand Theft Auto 3 machen willst, wirst du dazu bestimmt sein zu scheitern. Benutze die Templates. AUM und die Tutorials liefern Spiel-Templates mit – es braucht nur etwas Fantasie um sie in vollwertige, unterhaltende Titel umzuwandeln. In den guten alten Zeiten konnte eine einzige Person Programmieren und die Grafiken erstellen, und das für einen erstklassigen Titel! Heute arbeiten Teams von 20 oder mehr Leuten vollzeit für die Produkte die wir in den Regalen sehen. Wenn die Leute von deinem Leveldesign begeistert sind, aber sich vor deinen C-Script Fähigkeiten schütteln – zieh es in Betracht dich mit einem C-Script Zauberer zusammenzutun, sowie einem Musikgenie, um ein gut abgestimmtes Team zu bilden. Gehe Schritt für Schritt vor. Wenn du einen 1st Person Shooter, ein Rennspiel und ein Rollenspiel zur gleichen Zeit entwickelst, ist es wahrscheinlich dass keins davon fertig wird. Setze Meilensteine um sicher zu gehen, dass du und deine Teammitglieder immer noch auf dem richtigen Weg sind – zu viele Teams brechen auseinander, weil es kein klares erreichbares Ziel für jedes Mitglied gibt. Bleibe informiert. Lese das Benutzerforum. Lese AUM. Wenn du es dir leisten kannst, abonniere das Game Developers Magazine, oder gehe zu www.gamasutra.com und lese die Artikel. Charles River Media hat sich als der Verleger mit den meisten spiel-orientierten Büchern von hoher Qualität durchgesetzt.

F: Bitte geb uns ein Beispiel wie die neue Physikengine unseren Projekten weiterhilft.
A: Aus der alltäglichen Erfahrung haben wir bestimmte Erwartungen an die Realität. Wenn ich zum Beispiel gegen meinen Bürotisch stoße, ist es sehr wahrscheinlich dass sich der Tisch etwas bewegt. Trotzdem scheint jeder Tisch in allen Spielen die ich bisher gesehen habe an den Boden festgenagelt. Daher „verrät“ die fehlende Physik alle grafischen Neuerungen der letzten Jahre.

Non-lineares, nicht vorhersehbares Gameplay: Eine oft vernommene Kritik über aktuelle 1st Person Shooter ist, dass sie zu linear seien. Im Grunde genommen läuft der Spieler einen vordefinierten Pfad ab, macht vordefinierte Dinge und gewinnt. Warum sollte man nicht etwas MacGyverismus zum Spiel hinzufügen? Hier einige Beispiele: Ich weiß dass die Wache hinter der geschlossenen Tür bald anfangen wird, den Korridor zu abzusuchen. Glücklicherweise bemerkte ich den Stuhl im nahgelegenen Raum, deshalb greife ich mir den Stuhl und stelle ihn unter den Türknauf, um zu verhindern dass die Wache den Raum verlässt. Dann, unter Benutzung der eben gewonnenen Zeit, staple ich alle Fässer die ich im Level finden kann auf einen Haufen, vorsichtig auf einem schmalen Brett balanciert. Die ahnungslose Wache kommt aus der Tür gerannt, rennt in meinen Auslöser, der die Fässer hinüberfallen lässt und ihn damit überrollt. Einige Gamedesigner werden mit dieser Idee nichts anfangen können, weil sie riesige Lücken erzeugt, intensives Testen verlangt und fehleranfälliger ist. Trotzdem denke ich dass vorhersagbare Handlungen für Actionfilme vorbehalten werden sollten und von Computerspielen fern bleiben sollten.

Kürzere Entwicklungszeiten: Wenn du jemals probiert hast ein C-Script für einen einfachen, realistisch rollenden Ball, der mit Objekten auf dem Boden kollidiert, zu schreiben, dann wirst du wissen dass es eine echte Herausforderung sein kann. Wenn mehrere Objekte miteinander interagieren sollen wird es immer komplizierter und zeitaufwändiger. Vergleiche dies mit der benötigten Zeit, um diese Möglichkeit mit der Physikengine umzusetzen: Es braucht nur ein paar Zeilen Code, und alles andere wird von Gamestudio übernommen. Hier ist der physikrelevante Code für die Bowlingkugel aus dem Demovideo:

action InitBall {
   phent_SetType(my, PH_RIGID, PH_SPHERE); // make it a physics object- sphere shaped
   phent_SetMass(my, 5, PH_SPHERE); // weighs 5 kg
   phent_SetFriction(my, 70); // rolling friction 70%
   phent_SetElasticity(my, 50, 10); // 50% bounciness when moving faster than 10 quants/sec
   phent_SetDamping(my, 20, 20 ); // 20% damping
}

function InitPhysics {
 temp.x=0; temp.y=0; temp.z=-380; // corresponds to earth gravity factor 9.81
 ph_SetGravity(temp);
}

Vielen Dank, Marco.