Clonk Rage
Aus Clonk Wiki
NET2 war eine zu Clonk Endeavour parallel laufende Weiterentwicklung der Engine, bei der das Netzwerk- sowie große Teile des Kontrollsystem neu geschrieben wurden um besser auf die Anforderungen von Internetspielen einzugehen. Mittlerweile sind auch viele weitere neue Features dazugekommen. Die Weiterentwicklung wurde 2007 als Clonk Rage veröffentlicht.
Inhaltsverzeichnis |
Verbindungen
NET2 kann austauschbar sowohl mit UDP als auch mit TCP verbinden. Für den vollen Betrieb ist es optimal, wenn beide Verbindungen bestehen. In diesem Fall werden die zu übertragenden Pakete aufgeteilt in zwei Kategorien (Data für Daten, Msg für Nachrichten) und über beide Kanäle gesendet. Auf diese Weise ist garantiert, dass z.B. Ressourcenaustausch keinen allzu großen Einfluss auf den Chat hat.
Um möglichst große Vernetzung (Peer2Peer) zu erreichen, verbindet NET2 per default auf alle bekannten Adressen aller Clients, die über den Host verteilt werden. Auf diese Weise schaffen es Clients in fast allen Fällen, zumindest UDP-Verbindungen zueinander zu unterhalten (damit werden auch NATs umgangen, außerdem werden Clients im selben LAN in den meisten Fällen auch die direkte LAN-Verbindung zueinander finden).
Ist das Erreichen mehrer Clients mit UDP/Multicast möglich, so wird diese Technik zur bandbreitenschonenden Übertragung von allen global interessanten Paketen genutzt. Darunter fällt speziell das für das laufende Spiel entscheidende Control.
Lobby
Vor dem Spielstart bietet NET2 eine Lobby an, in der die Spieler zum Beispiel chatten, Teams wählen oder Spielstandsspieler übernehmen können.
Wie auf dem Screenshot zu sehen ist, benutzt die Lobby ein neues, komfortabel zu bedienendes GUI-System. Dieses wird auch an anderen Stellen im Spiel zu finden sein, und bietet so zum Beispiel Dialoge mit Abbrechen-Knopf, wo früher nur ein Abschuss der Engine oder gar Warmstart des Computers half
Control
Control (die Spielnachrichten) können in zwei verschiedenen Modi ausgetauscht werden: Zentralisiert oder dezentralisiert:
- Der zentralisierte Modus ist der klassische Modus des alten Netzwerksystems. Clients senden an den Server, der für jeden Control Tick ein ganzes Paket zusammenstellt und an alle Clients versendet. Dieses Verfahren ist relativ langsam (was die Übertragungszeiten angeht) und bedeutet für den Server größere Transferraten, ist dafür für Clients sehr ressourcenschonend und sehr einfach zu implementieren.
- Im dezentralisierte Modus dagegen sendet jeder Client an jeden Client direkt sein Control. Hat ein Client keine direkte Verbindung zu einem anderen Client, so wird über den Host "getunnelt" (in Wirklichkeit schickt der Client an den Server, an wen erfolgreich gesendet wurde, und der Host repliziert dann die Nachricht). Sind keine solche Tunnel im Spiel, sind die Übertragungszeiten somit ungefähr halb so groß. Dafür wachsen die Transferraten beim Client.
Außerdem neu sind in NET2 deaktivierte Clients, die sich in Bezug auf Control passiv verhalten - also nur empfangen, nicht senden. Diese sind dann "Zuschauer", die das Spiel nicht ausbremsen und ggf. etwas hinter dem Spiel hinterher hinken. NET2 aktiviert und deaktiviert Clients nach Bedarf, z.B. wird ein Client ohne Spieler nach einiger Zeit automatisch deaktiviert und bei Wiederbeitritt wieder aktiviert. Wird ein Client als Zuschauer markiert, bleibt er allerdings immer deaktiviert.
Ressourcen
Szenarien, Spielstände, Spieler und Objektpakete werden allgemein als "Spielressourcen" angesehen. Zu diesen Ressourcen wird bei Spielstart automatisch eine Checksumme kalkuliert, die allen Clients ermöglichen, zu überprüfen, ob sie eine identische (oder äquivalente) Version besitzen.
Stellt der Client fest, dass er sie nicht besitzt, so lädt er sich die entsprechende Ressource von allen Clients, die eine exakte Kopie haben, parallel herunter (so dass der Host nicht die komplette Last trägt). Während dem Laden können auch Clients voneinander laden, so dass theoretisch ein Mini-Peer2Peer-Netzwerk entsteht.
Laufzeitbetritt
Der Laufzeitbeitritt (LZB) hat ebenfalls eine Reihe von Verbesserungen erfahren. Zum einen konnte - auch mit Hilfe des Ressourcensystems - die Menge der zu übertragenden Daten drastisch reduziert werden (es wird nicht mehr das komplette Szenario übertragen, sondern nur "dynamische" Daten). Außerdem wird die Landschaft nicht in voller Farbtiefe übertragen, es werden ledeglich die groben Landschaftsdaten übertragen, aus denen sich der Client dann die Landschaftsgrafiken rekonstruiert.
Des weiteren ist es durch die Ermöglichung deaktivierter Clients möglich, den Laufzeitbeitritt voll asynchron statt finden zu lassen. Das heißt, dass das Spiel beim Host nur relativ kurz (zur Erzeugung des Spielstandes) stoppt, und dann weiter läuft. Sowohl die Übertragung des Spielstandes an den Client, als auch die Initialisierung der Engine beim Client, passiert bei laufendem Spiel. Der beitretende Client speichert während dieser Zeit alles Control und versucht dann nach Initialisierung der Engine, wieder aufzuholen. Hat er z.B. einen Spielerbeitritt angemeldet, so wird er nach Aufholen automatisch aktiviert und nimmt am Spiel teil.
Anleitung zum Beitritt
Ausgegangen wird von dem Beinhalten der regulären Engine UND der NET2 Engine im Clonk Ordner; ausserdem ist das Frontend geöffnet: Nachdem man sich (zB in #clonken) die IP-Adresse des Hostes erfragt hat und der Host bestätigt hat, dass mit NET2 gespielt wird, aktiviert man im Frontend die NET2 Engine indem man auf das Rechteck vor dem NET2 Engine Namen (zZ aktuell: Engine 4.96.0NET2 [222]) klickt. Dies wir dann grün. Als nächsten Schritt klickt man mit der rechten Maustaste auf das kleine Planeten-Symbol in der links unteren Ecke im Frontend und wählt "Direktbeitritt" aus. In das erscheinende Feld trägt man die IP des Hostes ein und bestätigt mit "OK".
