Monday, January 30th, 2023

Quest’n Goblin Entwicklertagebuch – Teil 3: Die coreX3D Technologie

0

Quest-n-Goblins_LogoBald startet das Browergame Quest’n Goblin in die Closed-Beta Phase. Nach dem wir euch auf der gamescom 2012 den letzten Einblick in das Spiel geben konnten, geben uns nun die Entwickler mit ihrem dritten Tagebucheintrag einen tieferen Einblick ins Spiel. Diesmal dreht sich alles rund um die eingesetzte coreX3D Technologie. Viel Spaß mit dem dritten Teil des Quest’n Goblin Entwicklertagebuch:

Dungeons und Höhlen, mysteriöse Sümpfe und Wälder voll von Schätzen, aber auch angriffslustigen Spinnen, Geistern und Monstern, die es zu schlagen gilt. Das ist die Welt von Quest’n Goblins. Hier vollbringen Gamer Höchstleistungen, wenn sie die Schätze sammeln und Level für Level bestreiten. Dabei steht ihnen eine Armee schlagkräftiger Goblins zur Seite. Für ein perfektes Spielerlebnis sorgt jedoch auch die Technologie im Hintergrund, die Höchstleistungen vollbringt. Denn was vielen nicht bewusst ist: Hinter jedem erfolgreichen Spiel steht auch eine komplizierte Technik, die das Spiel zu dem macht, was es ist – in diesem Fall: die coreX3D Engine.

Die coreX3D Technologie ist eine reine Multiplayer-Engine. Sie wurde von Beginn an mit dem Fokus auf Multiplayer designt. Wie z.B. auch bei Diablo3 ist der Singleplayer-Modus nur eine Spezialform des Multiplayer-Modus. Die Art der Simulation unterscheidet sich jedoch grundsätzlich von anderen Multiplayer-Engines. Denn frühere Multiplayer-Engines beruhen auf einem Client/Server-Prinzip, wobei der Server (dedicated oder als Modul auf einem der Clients) das Game und die Daten simuliert. Die resultierenden Daten werden in kurzen Abständen zu allen Clients verschickt.

Nachteil dieser Vorgehensweise ist die Notwendigkeit einer guten Netzwerkverbindung. Man braucht einen niedrigen Ping und eine hohe Bandbreite, um das hohe Datenaufkommen in entsprechender Frequenz zu versenden.

Die coreX3D Technologie geht hier einen anderen Weg: Jeder der Clients verfügt über einen eigenen Simulationsteil. Dieser ahmt das Spiel nach, übermittelt die berechneten Daten an den Visualisierungsteil des Spiels, womit die Simulation letztendlich als Grafik – in Form vom Starten der Partikelsysteme, das Starten der Sounds etc. darstellt.

Damit das funktioniert, müssen die einzelnen Simulations-Engines über dieselben Ausgangsdaten verfügen, um auch denselben Stand des Games, unabhängig voneinander errechnen zu können.

Die Problematik dabei: Um gleiche Ergebnisse zu liefern, müssen die Simulationen auf allen Rechnern gleich verlaufen. Nicht-lineare Prozesse können schon bei kleinen zeitlichen Differenzen zu unterschiedlichen Ergebnissen führen. Über die Zeit hin ist es möglich, dass sich diese Fehler verstärken.

Ein Beispiel für eine solche Simulation ist z.B. ein Kampf in Quest’n Goblins. Ein Charakter und seine Goblins bekämpfen mehrere Gegner (oder andere Spieler). Das Game muss hier genau festhalten, wer welchen Schaden bekommt. Um unterschiedliche Ergebnisse zu vermeiden, dürfen die einzelnen Simulationen nicht auseinanderlaufen, sodass die Ergebnisse auf verschiedenen Rechnern gleich sind – die CoreX3D Technologie ermöglicht dies optimal. Um dennoch das Vorkommen kleinerer Unterschiede im Simulationsergebnis so gering wie möglich zu halten, müssen die Simulations­prozesse auf den einzelnen Clients zusätzlich synchronisiert werden. Es gilt, Ergebnisse miteinander abzugleichen und Unterschiede in der Simulation zu finden – die Clients sind dazu gezwungen, sich auf einen gemeinsamen Stand zu einigen.

Der große Vorteil dieser Struktur ist der erheblich reduzierte Netzwerktraffic – im Vergleich zu herkömmlichen Multiplayer-Engines ist der Datenversand weitaus geringer. Es hat sich außerdem gezeigt, dass die Simulation präziser und weniger anfällig für kurzzeitige Netzwerkprobleme ist. In einem Spiel wie beispielsweise Diablo 3 passiert es zeitweilig, dass der eigene Character durch ein Lag stirbt. Durch einen kurzzeitigen Verbindungsabriss kommen beim Diablo-Server keine Daten vom Spieler mehr an. Dies führt dazu, dass der Spieler in der Simulation des Servers nur dasteht und Schaden nimmt. Ist die Verbindung wiederhergestellt, ist das Resultat dieser Simulation erkennbar.

Die coreX3D Technologie kann diese Problematik nicht vermeiden, aber ihre Wahrscheinlichkeit reduzieren. In der Entwicklung führt dies zu einem erhöhten Aufwand, da Simulationsseite und Visualisierungsseite im Source Code klar voneinander getrennt sind, aber viel miteinander kommunizieren müssen. Die coreX3D Technologie verfügt entsprechend über eine eigene Scriptsprache namens SL, die diese Vorgänge erheblich erleichtert.

Ein Großteil des Codes von Quest’n Goblins ist deshalb in SL geschrieben. Näher auf ihre Struktur einzugehen, würde den Rahmen dieses Artikels sprengen. Nur so viel: Sie wurde im Hinblick auf die typischen, bei der Spieleentwicklung auftretenden Probleme, und für die besondere Struktur der coreX3D Technologie geschrieben. Ihre Syntax erinnert stark an Java und C++.

Von nun an sollen aber wieder die Spielcharaktere die Hautrolle spielen.


Weitere Beiträge:

Was meinst du?

Teile hier deine Meinung mit ...