Sorry, only avaiable in German, check back later for English version or use babelfish.
Bereits am Anfang wurde die Möglichkeit angesprochen, Grafikdefinition auf Clientseite zu speichern, um sie fuer die nächste Sitzung bereitzuhaben.
Dies hätte sicher Vorteile, wenn geringe Netzbelastung das oberste Gebot ist. Doch der Nachteil liegt auf der Hand: Sollte sich die Grafikdefinition für ein Objekt ändern, während der betreffende Spieler nicht online ist, ist es nicht möglich, den Client zu informieren. Dies müßte dann beim nächsten Login erfolgen. So wäre eine Datenbank nötig, die * für jeden Spieler alle Objekte speichert, die er bereits gesehen hat, * für alle Objekte die Zeit der letzten Änderung * für jedes Objekt und jeden Spieler ein Flag, ob der Spieler über eine Änderung informiert werden muß.
Sicher lässt sich mit Zeitmarken etc. eine Verringerung des Datenbestandes erzielen (für jeden Spieler die Zeit der letzten Information und für jedes Objekt die Zeit der letzten Änderung), doch hat man dann die Wahl, entweder bei jedem neuen Login dem Spieler sämtliche Änderungen im Block mitzuteilen (ein sehr großer Aufwand an Netzresourcen), oder es wird bei jedem Objekt, welches der Client darstellen soll, geschaut, ob der Client eventuell über Änderungen informiert werden muss.
So erhalten wir eine doppelte Datenhaltung: Das Mud müsste den Überblick über den derzeitigen Grafikdatenbestand aller Clients haben. Doch jeder Client hat bereits eine eigene Datenbank für alle Objekte, die er selber kennt. Ein regelmäßger Abgleich beider Datenbanken würde unserer Ausgangsforderung, den Kommunikationsaufwand zwischen Mud und Client zu minimieren, widersprechen.
Nicht vergessen werden darf die Notwendigkeit für den Clienten, die Client-Datenbanken für jedes Mud, für welches er eingesetzt wird, getrennt zu verwalten.
Alles in allem erscheint ein solches Konzept als zu aufwendig für den zu erwartenden Nutzen. Sollten die pro Grafik übertragenen Datenmengen (Zur Zeit maximal für eine vollständige Szene, wenn mit maximalen Identlängen von 256 Byte gerechnet wird: 33 Objekte mit je maximal 32 Polygonen zu je 32 Ecken zu je 4 Bytes: 33 * (256 + 32 * (2 + 32 * 4)) = 145728 Byte) wachsen, dann wird es vielleicht interessant, über dauerhafte Speicherung über Sitzungen hinweg nachzudenken, wie es beispielsweise im RIP der Fall ist.
