ENGLISH |
|
|||||||||
HOME |
|
|
||||||||||||||||||||||||||||||||||||||||
|
|
* Preisangaben für Lizenzen zum kommerziellen Publizieren. Stand von 2012. Alle Daten basieren auf Herstellerangaben - für die Richtigkeit wird keine Gewähr übernommen. Sollten Sie Unkorrektheiten in dieser Tabelle bemerken, melden Sie diese bitte an webmaster at conitec.net. |
Die aufgelisteten Features in der obigen Tabelle bedeuten nicht unbedingt, dass ein bestimmtes System 'besser' ist als ein anderes. Zwischen Engines mit scheinbar ähnlichen Features kann es große Unterschiede in Geschwindigkeit und Stabilität geben. F. Welche Spielentwicklungssysteme außer Gamestudio können Sie noch empfehlen? A. Autorensysteme: Unity (große Community); 3D-Sprachen: Blitz 3D (langsam, aber stabil und für kleine Spiele geeignet); Open Source Engines: Irrlicht (gut strukturierter und verständlicher C++ Code). F. Was ist ein Szene-Manager? A. Ein Szene Manager verbessert die Framerate, indem er nur die Objekte rendert, die sichtbar sind. Die ersten Szene Manager waren das Portal und das Octree System. Ein Portal-System benutzt Öffnungen wie Tore oder Fenster, um sichtbare von nicht sichtbaren Objekten zu unterscheiden. Ein Octree System teilt den Level in einen hierarchischen 'Baum' würfelförmiger Regionen und rendert nur den Inhalt der Regionen im Sichtbereich der Kamera. Wegen ihrer Einfachheit werden Portal- und Octree-System auch heute noch von einigen 3D Engines verwendet. Das ABT (Adaptive Binary Tree) System benutzt quaderförmige Regionen, deren Größe von der Geometrie des Levels abhängt, und ist damit effektiver. Das BSP-Tree System teilt den Level in unregelmäßige Regionen entlang von Wänden. Es rendert nur die Teile, die tatsächlich sichtbar sind, und ist damit das effektivste System besonders in Innenräumen. Für Außenlevel, wo ein BSP-Tree nur einen geringen Vorteil bietet, wird oft ein LOD (Level Of Detail) System benutzt, um die Framerate zu erhöhen. Es schaltet bei Objekten, die weiter von der Kamera entfernt sind, auf einfachere Formen um. Auf diese Weise reduziert sich die Gesamtzahl der pro Frame gezeichneten Polygone. Eine kurze technische Beschreibung des Szene-Managers der A7 Engine finden Sie hier. Q. Was ist ein Terrain-Renderer? A. Realistische Landschaften bestehen aus Millionen Polygonen und können nicht mehr wie ein normales 3D-Modell gerendert werden. Daher beinhalten manche Engines einen speziellen Terrain-Renderer, der das Terrain in kleine Parzellen ('Chunks') unterteilt. Die Detailliertheit der Chunks hängt von ihrer Entfernung zur Kamera ab. Nur die Terrain-Teile in der Nähe der Kamera müssen in den Computer-Speicher geladen und am Bildschirm dargestellt werden. Auf diese Weise lassen sich sehr detaillierte Landschaften theoretisch unbegrenzter Größe darstellen (Screenshots vom Gamestudio User-Forum). |
|
|
|
F. Was sind Shader? A. Shader geben der Spielegrafik eine neue Dimension. Sie beeinflussen Transformation, Beleuchtung und Rendern direkt auf der Vertex-, Pixel- und Bildschirm-Ebene. Ein Shader ist eine Art kleines Skript, das für jeden Vertex oder jeden Pixel direkt auf der 3D-Hardware ausgeführt wird. Dies gibt dem Entwickler völlige Flexibilität über die Darstellung von Oberflächen. Vertex- und Pixel-Shader können realistische Wellen auf einer Wasserfläche erzeugen, dem Spiel einen Cartoon-Look geben, Modelle mit Fell überziehen oder den Lavafluss eines Vulkans kontrollieren. Eine Reihe von modernen 3D-Engines unterstützen Shader. Shader-Unterstützung beinhaltet normalerweise eine Sammlung von Standard-Shadern sowie einen Editor, mit dem User individuelle Shader programmieren können. Manche Engines (wie A7) erlauben auch Postprocessing-Shader für Effekte wie in dem Unterwasserbild unten (Screenshots vom Gamestudio User-Forum). Wenn Sie mehr wissen wollen, laden Sie sich die Shader Workshops (englisch) mit einer Einführung ins Shader-Programmieren. |
|
F. Was ist ein Save/Load System? A. Ein solches System erlaubt das Abspeichern und Wiederaufnehmen von Spielständen. Es speichert den kompletten Zustand aller laufenden Skripte und aller Objekte und Variablen in eine Datei, wahlweise zusammen mit einem Screenshot. Dies ist nötig zum Wiederaufnehmen des Spiels zu einem späteren Zeitpunkt an der gleichen Stelle, oder zum Verlassen und Betreten verschiedener Spiel-Levels an beliebigen Positionen. Speichern von Spielständen hört sich zwar einfach an, ist aber 'tricky' und muss im Kern der Game-Engine implementiert sein. Ohne ein solches System müsste zum Abspeichern von Spielständen ein Skript geschrieben werden, welches jede einzelne Variable und den Stand jeder laufenden Funktion abspeichert - sehr umständlich und in der Praxis kaum möglich, außer für sehr simple Spiele. Die meisten kommerziellen Engines besitzen daher ein eigenes Save/Load-System. F. Was bedeutet 'Multiplayer' - und kann man damit ein MMOG produzieren? A. Engines können Multiplayerspiele auf unterschiedliche Weise unterstützen. Der einfachste Weg, der von manchen 3D-Sprachen angeboten wird, sind Befehle zum Senden von Daten per Netzwerk oder Internet zu anderen PCs. Bessere Engines bieten einen Mechanismus zum automatischen Synchronisieren von Leveln zwischen allen PCs, die mit einem Spiel verbunden sind. Manche Engines unterstützen auch die Aufteilung der Spielwelt in mehrere Zonen, die von zugeordneten PCs (Zone-Servern) gesteuert werden. Solche Zone-Systeme ermöglichen massive Multiplayer Online Games (MMOG) mit einer theoretisch unbegrenzten Zahl von Spielern. Die Gamestudio Pro Edition unterstützt ein MMOG geeignetes Zone-System. Einen Überblick über das Gamestudio Multiplayer-Konzept finden Sie hier. Allerdings erfordert ein MMOG einiges mehr als nur eine Game-Engine. Sie müssen einen Serverpark mit einem Portal-Server, mehreren Zone-Servern und einem oder mehreren Datenbank-Servern aufbauen. Die Produktion eines MMOG ist kein Hobbyprojekt und erfordert gute Programmierkenntnisse, ein gutes Team und nicht zuletzt ein ausreichendes Budget. F. Was ist eine Physik-Engine? A. Eine Physik-Engine berechnet Bewegungen, Rotationen und Kollisionsverhalten von Objekten gemäß den Regeln der Physik. Es ist nicht unbedingt notwendig, eine Physik-Engine für ein Spiel einzusetzen - einfache Physik-Regeln, wie Beschleunigung oder Abbremsung, lassen sich bis zu einem gewissen Grad auch per Skript programmieren. Diese Möglichkeit gibt es jedoch nicht mehr, wenn Objekte auf komplexe Weise zusammenstoßen, rollen, gleiten oder abprallen - wie etwa bei Autorennen oder Ballspielen. Eine Physik-Engine benutzt Objekteigenschaften wie Masse, Impuls, Drehmoment oder Elastizität, um Bewegungsverhalten mechanischer Prozesse zu simulieren. Dies sieht nicht nur viel realistischer aus, sondern ist für den Entwickler auch viel einfacher zu handhaben als das Schreiben von Bewegungsskripten. Bessere Physik-Engines erlauben die Konstruktion komplexer mechanischer Objekte (wie z.B. Fahrzeugen) aus Motoren, Gelenken, Angeln, Achsen und Schiebezylindern. Manche Engines unterstützen auch die Physik von Nicht-Festkörpern, wie etwa Flüssigkeiten (Screenshots vom Gamestudio User-Forum). |
|
Physik-Engines können von verschiedenen Herstellern käuflich erworben werden. Einige Entwicklungssysteme haben eine integrierte Physik-Engine, aber Vorsicht: Manche Systeme führen 'Physik' in ihrer Featureliste, bieten aber nur simple Beschleunigungs- oder Kollisionsfunktionen. F. Was ist ein Skript-Compiler? A. 3D-Systeme enthalten oft Skriptsprachen zum Steuern von Objekten im Spiel. Je mehr Dinge sich bewegen, desto mehr Skriptanweisungen müssen pro Sekunde ausgeführt werden. Viele ältere Skriptsprachen - z.B. LUA, Python, Angle Script, Torque Script usw. - verfügen über keinen Compiler, sondern sind interpretiert. Die Skriptanweisungen werden dabei in einen Zwischencode übersetzt, der dann während des Spiel vom Programm interpretiert wird. Da der Prozessor den Code Byte für Byte auswerten muss, laufen interpretierte Sprachen etwa zehnmal langsamer als compilierte Sprachen. Dies ist zwar für viele Anwengungen unerheblich, jedoch nicht für Computerspiele. Ein Skript-Compiler - wie z.B. lite-C - übersetzt die Sprache nicht in einen Zwischencode, sondern direkt in den Maschinencode des Prozessors. Da das Auswerten des Codes während des Spiels entfällt, laufen compilierte Skripte wesentlich schneller und beeinflussen die Framerate auch in großen Leveln mit hunderten von sich bewegenden Objekten kaum. Vorsicht: Manche Systeme führen 'Compiler' in ihrer Feature-Liste, meinen damit aber lediglich den Übersetzer in den Zwischencode und somit eigentlich das Gegenteil. F. Muss ich programmieren lernen, um ernsthaft Spiele zu entwickeln? A. Ja - egal was Sie woanders gehört haben. Einfache Spiele, wie 3D-Shooter, können Sie zwar auch ohne Programmieren zusammenbauen. Zur Realisierung von eigenen Spielideen und Effekten jedoch ist es notwendig, diese mit Skripten zu programmieren. Aber keine Sorge: Auch wenn Sie noch nie programmiert haben, können Sie sich mit Hilfe des lite-C-Tutorials in kurzer Zeit einarbeiten. F. Warum C und nicht BASIC / LUA / PYTHON ...? A. Eine C-basierte Sprache ist zur Spieleprogrammierung aus vielen Gründen besser geeignet. C-Code ist übersichtlicher, kürzer und einfacher zu verstehen als BASIC und läuft - da compiliert und nicht interpretiert - viel schneller als eine reine Skriptsprache wie LUA oder PYTHON. Wegen seiner Unterstützung von C++-Klassen kann lite-C direkt auf DirectX und Windows API Funktionen zugreifen und erlaubt damit die Programmierung komplexer Effekte, die in keiner anderen Skriptsprache möglich wären. Fast alle kommerziellen Spiele werden zur Zeit in C/C++ programmiert. Auch Spiele, die LUA oder PYTHON als Skriptsprache einsetzen, benutzen C/C++ für alle komplexeren Aufgaben wie Rendern, Physik und Effekte. Windows- und Grafikbibliotheken wie DirectX haben ein C/C++-basiertes Interface, und C ist auch die Grundlage der Shader-Sprache, in der 3D-Effekte gestaltet werden. Um die Sprache C kommt man in der Spieleindustrie nicht herum. F. Wie oft werden neue Features für Gamestudio entwickelt? Sind die Updates kostenlos? Sind sie abwärtskompatibel? A. Gamestudio wird ständig mit neuen Features ausgestattet - das ist es, womit wir im wesentlichen unsere Zeit verbringen. Sie finden den Plan für künftige Features unter den Beta und Forecast Links in unserem Forum. Normale Updates sind kostenlos und kommen alle paar Wochen heraus. Grosse Upgrades zu einer neue Engine-Generation ( A6 -> A7 -> A8) kommen im Abstand von einigen Jahren heraus und sind nicht gratis. Alle Updates sind kompatibel zur Vorgängerversion. F. Wie fehlerfrei ist die Software, und wie stabil laufen die damit produzierten Spiele? A. Wir sind ziemlich sicher, das Gamestudio das mit Abstand robusteste und fehlerfreieste Entwicklungssystem auf dem Markt ist, und treiben viel Aufwand, damit das so bleibt. Wenn Sie Spiele entwickeln, wollen Sie sich schließlich nicht auch noch mit Software-Bugs herumärgern. Bevor ein Update freigegeben wird, wird es von unserem Team von etwa 100 Beta-Testern - alles erfahrene Spielentwickler - monatelang intensiv geprüft. Danach wird es einem öffentlichen Beta-Test auf unserem Forum unterzogen, der normalerweise über 1000 Tester einbezieht. Erst dann steht es offiziell zum Download zur Verfügung. F. Welches war das erste kommerzielle Spiel, das mit 3D Gamestudio gemacht wurde? A. Die ersten kommerzielle Spiele waren die 3D Hunting-Serie von MacMillan. Sie wurden kurz nach Veröffentlichung der Version A4 Ende 1999 entwickelt und auf den Markt gebracht. Das Grizzly-Jagdspiel war das erste Gamestudio-Multiplayerspiel.
|
oP group Germany GmbH • Birkenstr. 25-27 • 63549 Ronneburg / Germany • info (at) 3dgamestudio.net |