Living Worlds: natürliche Komplexität |
Das wertvollste Ergebnis der Living-Worlds-Arbeiten ist ein Satz von Grundkonzepten, mit denen die Problematik einer Cyberspace-Infrastruktur und die daraus resultierenden technischen Anforderungen artikuliert werden können. Die wichtigsten Konzepte wurden in den Definitionen einiger Grundbegriffe zusammengefaßt: Pilot/Drone, Avatar/Bot, World/Szene/Zone - alles bezogen auf ein zentrales Hauptkonzept, die MUtech (für multi-user technology). Wir wollen diese Grundideen kurz vorstellen, denn zusammen machen sie deutlich, wieso VRML in Living Worlds an fundamentale Grenzen stößt.
Die Grundstrukturen: ein Überblick |
Als erstes muß man sich darüber im
Klaren sein, daß die Gemeinsamkeit im GevU-Begriff technisch
gesehen eigentlich eine Simulation ist. Letztendlich sitzt jeder
Beteiligte vor einem einzigen Rechner, der sein persönliches Abbild
der gemeinsamen Szene darstellt. Die GevU hat dafür zu sorgen,
daß dieses Abbild mit allen anderen Abbildern adäquat
synchronisiert wird, die gleichzeitig auf den anderen beteiligten
Client-Rechnern angezeigt werden. Diese Situation wird in Abbildung 15.7
veranschaulicht. Abbildung
15.7
Living Worlds - Grundmodell
Die vorgeschlagene Living-Worlds-Architektur weist sämtliche Verantwortung für die Szenensynchronisation einer neuen Komponente zu, die man MUtech nennt (für multi-user technology). Damit wird die gesamte Funktionalität, die Zustandsänderungen an verteilten Objekten durchführt, synchronisiert und den Zugriff auf Objektverhalten steuert, konzeptuell und technisch isoliert. Diese Strategie hat mehrere Vorteile:
Was ist aber mit dem Szeneninhalt? Es irritiert, daß der Schlüsselbegriff Avatar im obigen Bild nicht vorkommt. Und was ist unter den Bezeichnungen Pilot und Drone zu verstehen?
Die meisten proprietären GevU-Implementierungen gingen davon aus, daß es in einer Cyberspace-Szene grundsätzlich nur zwei Objektklassen zu behandeln gibt:
a) Avatare, die
keine permanten Bestandteile der Szene sind, und sich willkürlich
bewegen können (da sie von Menschen live gesteuert werden)
und
b) Objekte, die als
Teile der Szene entworfen und gespeichert werden und deren Verhalten
für den Szenenautor deshalb vorhersehbar ist (da er sie selbst
programmiert).
Die Living-Worlds-Untersuchungen haben aber gezeigt, daß diese Klassifizierung nicht aufrecht zu halten ist. Beispiele wie die blaxxun Chatbots oder Claras Kanarienvogel, also Avatar-ähnliche, aber Programm-gesteuerte Objekte, verwischen das Bild von der einen Seite. Die prinzipielle Möglichkeit, als einzelner Benutzer gleich mehrere Objekte mehr oder weniger live zu steuern (z.B. einen virtuellen Hund, dessen Kunststücke man gerne vorführt, der aber alleine in der Szene verbleiben kann, auch wenn sein Herrchen sie verläßt), lockert die Grenze auf andere Weise auf. Solche Überlegungen haben dazu geführt, daß die Living-Worlds-Gruppe folgende Differenzierungen festhielt:
Tabelle 15.1
Living-Worlds-Objektklassen
Ein Objekt mit mehreren Instanzen auf verschiedenen Clients, deren Zustand und Verhalten synchronisiert werden. | |
Instanz eines verteilten Objekts, dessen Zustand und Verhalten auf die anderen Instanzen (die Drohnen) übertragen wird. | |
Instanz eines verteilten Objekts, das Zustand und Verhalten eines Piloten repliziert. | |
Ein verteiltes Objekt, das aktiv ist und von einem autonomen Programm gesteuert wird. [Abk. Von ,,Roboter"] | |
Ein verteiltes Objekt, das live von einem Benutzer gesteuert wird. |
Grundstein der Living-Worlds-Strategie zur Szenensynchronisation ist, daß die Quelle jeder Zustandsänderung immer sauber identifiziert wird, und von dort aus alle Änderungsbotschaften über den MUtech an alle anderen Clients weiterleitet. Ein Objekt, das eine Zustandsänderung verursacht, nennt man den pilot; Objekte, die eine Änderung nachvollziehen, bezeichnet man in diesem Zusammenhang als drones.
Piloten und Drohnen |
Das pilot/drone-Paar ist die Basis aller Szenen-Synchronisierung - und auch aller Kommunikation zwischen Clienten. Eine GevU-Szene wird als die Instanzierung einer Objektsammlung auf mehreren Clients verstanden. Die verschiedenen Instanzen jedes Objektes in der Szene synchonisieren sich, in dem die jeweilige Piloten ihre Drohnen mit Hilfe des MUtech auf dem laufenden halten.
Piloten sind also Objekt-Instanzen, die eigenständig Verhalten ausführen und ihren Zustand ändern können. Für jede Zustandsänderung und jede Ausführung eines Verhaltens gibt es immer genau einen Piloten. ,,Pilot sein" ist aber keine permanente Eigenschaft, sondern ein Zustand: Jede Instanz eines verteilten Objekts hat einen Schalter, der angibt, ob diese Instanz zur Zeit als Pilot fungiert. Der Default ist ,,off". Das heißt, die meisten Objekte sind Drohnen, die nur das Verhalten und die Zustandsänderungen, die anderswo gesteuert werden, replizieren. Der Zustand isPilot kann aber auch selbst verteilt sein, das heißt, das Verhalten eines Objekts kann die Möglichkeit einschließen, seinen Zustand von isPilot in isDrone zu ändern.
Das nächstliegende Beispiel für ein Pilot/Drohnen-Paar ist mein Avatar, dessen Drohnen an anderen Clients alle Bewegungen nachmachen, die ich an meinem Client vorgebe. Das Konzept gilt aber gleichermaßen für alle Objekte, deren Verhalten übers Netz weitergegeben wird. Wenn ich eine virtuelle Flasche durchs Online-Zimmer werfe, so daß sie einen anderen Avatar am Kopf trifft und sein In_Ohnmacht_fallen-Skript aktiviert, dann ist die von mir geworfene Flasche auch ein Pilot, der seine Drohnen an allen anderen beteiligten Clients antreibt.
Die Kommunikation zwischen Avataren über Clients hinweg wird ähnlich realisiert. Annas Avatar (dessen Drone auf Bernds und Claras Client-Rechnern zu sehen ist) bittet alle, hineinzutreten. Die Botschaft wird zunächst von Bernds und Claras Drone-Avataren auf Annas Maschine empfangen. Die Drohnen reichen die Einladung an ihre Piloten auf Bernds bzw. Claras Client-Rechnern weiter. Dort entscheiden Bernd und Clara (die Menschen), die Einladung anzunehmen, und schieben mit ihren Mäusen ihre Avatar-Piloten, deren Bewegungen dann auf Annas Maschine von den dortigen Drohnen nachgemacht werden.
Jedes verteilte Objekt kann im Prinzip als Avatar, also als Realzeit-Repräsentation eines Benutzer, dienen. Umgekehrt gibt es keinen Grund, warum man Objekte, die normalerweise als Avatare benutzt werden, nicht auf Automatik umschalten können sollte, damit man sie z.B. in einer Szene als Butler zurücklassen kann. Die Living-Worlds-Spezifikation sieht ein besonderes Objektattribut is_avatar vor, was soviel wie ,,gegenwärtig unter menschlicher Kontrolle" bedeutet. Ein Objekt mag sich Dank ausgeklügelter Programmierung noch so menschlich verhalten; ist sein is_avatar auf ,,off" gesetzt, dann handelt es sich per Definition nicht um einen Avatar, sondern um ein ,,bot" oder Software-Roboter.
Die Instanz eines Avatars, die sich auf dem Client des Benutzers befindet, ist per Default ein Pilot. Ein Avatar könnte aber ein Nimm_meine_Hand-Verhalten haben, das die Kontrolle über seine Position zeitweilig von seinem Piloten an die lokale Drohne eines anderen Avatars überträgt. Genauso wird eine beliebige Instanz eines Lichtschalters für die Zeitspanne, die nötig ist, um das Licht ein- oder auszuschalten zum Piloten, und wird danach sofort wieder zur Drohne. Dabei ist zu beachten, daß solche Fälle, wie z.B. die Synchronisation zwischen Instanzen, die alle zugleich Pilot sein wollen, nicht trivial zu lösen sind.
Alternativen in der MUtech-Architektur |
Grundsätzlich gibt es zwei denkbare MUtech-Architekturen: Client-Server und Peer-to-Peer. Die erste Lösung definiert eine kanonische oder Master-Szene, in der alle Objektzustände verwaltet und von der aus alle Zustandsänderungen verteilt werden. Die zweite verzichtet auf eine kanonische Szenendarstellung und definiert lediglich ein Protokoll, womit jeder Telnehmer seine Zustandsänderungen an allen anderen kommunizieren kann.
Die VRMLC-WG haben sich aber dazu verpflichtet, möglichst keine architektonischen Entscheidungen vorzuschreiben. Keine der beiden Architekturprinzipien erweist sich in ihrer puren Form als tragfähig. Sobald die Anzahl der Beteiligten einer Szene ein paar Dutzend übersteigt, wird entweder der Server zum Flaschenhals oder das Netz wird durch die Synchronisierungsbotschaften überfordert. So wird ein zentrales Thema in jedem GevU-Design die Performance-Optimierung: Welche Information soll wem wie oft verteilt werden? Welche Kombination von Server- und Peer-to-peer-Lösungen ist für verschiedene Zwecke in verschiedenen Umständen am besten geeignet, um die angeforderten Antwortzeiten zu erzielen?
Um z.B. eine Szene für Echtzeitspiele zu entwickeln, braucht man einen MUtech, der extrem kurze Antwortzeiten garantieren kann. Dagegen wird es z.B. für ein Einkaufszentrum wichtiger sein, daß der MUtech Electronic-Cash-Funktionen besitzt. Man kann sogar daran denken, die Funktionalität einer Szene zu ändern, indem man den MUtech austauscht (um im Beispiel zu bleiben, z.B. den Electronic-Cash-fähigen gegen einen Doom-artigen MUtech, um nach der Arbeitszeit einen virtuellen Überfall im Einkaufszentrum zu inszenieren ...).
Zonen: Skalierbarkeit und Struktur |
Die Diskussion über alternative MUtech-Qualitäten - und das Beispiel von Bernds Brettspiel - legen die Idee nahe, daß an verschiedenen Orten innerhalb einer GevU u.U. verschiedene MUtech aktiv sein können oder sogar müssten. Andererseits wirft die simple Tatsache, daß es bereits mehrere unabhängig voneinander entstandene GevU gibt, sofort den Wunsch nach entsprechenden Navigationsmitteln auf, womit man von einer zur anderen reisen könnte. Zumindest brauchen wir Begriffe, mit denen wir über die Skalierbarkeit von VRML-Konstrukten reden können und mit denen ihre Grobstruktur kontrolliert werden kann. Die LW-WG schlägt vor:
Tabelle 15.2
Living-Worlds-Konzepte - Szenenstruktur
Eine oder mehrere Szenen, die technisch und konzeptuell verbunden sind. | |
Eine räumlich begrenzte Menge von VRML-Objekten, durch die man sich kontinuierlich (ohne Sprünge) bewegen kann. | |
Ein zusammenhängender Teile einer Szene; technisch: ein Container für verteilte Objekte. |
Die Begriffsbildung World > Scene > Zone legt eine Hierarchie in drei Ebenen fest. Sie unterscheidet die Vereinigung von separaten Szenen zu einer thematisch, aber eben nicht physisch integrierten Welt (z.B. eine virtuelle Großstadt, die aus diversen Stadtviertel besteht, die je viele Gebäude enthalten, die wiederum jeweils - mindestens - eine Szene darstellen) von der Unterteilung von Szenen in Zonen mit evtl. sehr unterschiedlichen Eigenschaften (z.B. ein Wohnzimmer und das Schachbrett, das auf dem Tisch steht).
Die Zone ist auch als der Wirkungsbereich einer MUtech konzipiert. Objekte in einer Szene werden daran als ,,verteilt" erkannt, daß sie einem Zone-Knoten zugeordnet sind, die wiederum von einer MUtech verwaltet wird. Eine Zone ist eine räumlich zusammenhängende, aber nicht notwendigerweise feste Region einer Szene. Zonen können benutzt werden, um Objekte für ein gemeinsamen Verhalten, z.B. auf einem Spielbrett, zu gruppieren. ,,Welt" ist dagegen kein Terminus technicus, sondern eine Konvention: trotz des VRML-Kürzel .wrl wäre das Wort world besser aufbewahrt, um eine Szenensammlung zu bezeichnen, damit einem die Unsinnigkeit erspart wird, jeden einzelnen Teil einer Level-of-Detail-Serie als eigene Welt bezeichnen zu müssen.
Natürliche Komplexität |
Szenarien wie der Abend bei Anna machen deutlich, daß die GevU-Thematik nicht nur in sich komplex ist, sondern auch von einer grundsätzlichen Unordentlichkeit gekennzeichnet ist. Es gibt nicht einmal theoretisch einen Satz von Axiomen oder Algorithmen, mittels derer man diese prinzipielle Unordnung in schlichten formalen Ablaufschemata einfangen könnte. GevU-Systeme sind chaotisch - die Auswirkungen kleiner Unregelmäßigkeiten sind prinzipiell nicht vorhersehbar und folglich nur bedingt kontrollierbar. Solche Systeme müssen mit vielen Mechanismen versehen werden, mit denen man iterativ einen Szenenentwurf verfeinern und adaptiv den Szenenbetrieb steuern kann. Solche Mechanismen stiften softwaretechnische Komplexität - aber nur so kann man die inhärente Komplexität dieser Systeme in den Griff bekommen.
Hier sei nur ein Beispiel von natürlicher Komplexität angeführt, stellvertretend für viele andere, in dem es sich vor allem um Performanz und Persistenz dreht. Das Thema hier ist die Optimierung des für die Szenensynchronisation notwendigen Netzverkehrs. Das Beispiel zeigt, wie unterschiedlich der Informationsbedarf verschiedener Szenenobjekte sein kann.
Man stelle sich eine Szene vor, in der einige Entertainer auf der Bühne darstellen, während im Publikum ein Roboter Programmhefte verkauft. Das Publikum soll sehen können, was sich auf der Bühne abspielt - folglich muß nicht nur das Verhalten der Performer, sondern auch der Farbwechsel der Bühnenbeleuchtung an alle Publikum-Clients verteilt werden. Es ist aber unnötig (und wahrscheinlich auch unmöglich), jedes einzelnes Publikumsmitglied jedem anderen sichtbar zu machen. Andererseits will man schon ein gewisses Publikumsgefühl aufkommen lassen - deshalb soll jeder im Publikum die Aktionen seiner nächsten Nachbaren mitbekommen. Der Rest des Publikums wird mit einem generischen Bild und einem Hintergrundgeräusch suggeriert. Der Programmverkäufer ist ein Ausnahmefall; ihn muß man von überall sehen können, er selbst muß aber nur diejenigen sehen, von denen er direkt angesprochen wird. Das verkaufte Programmheft muß nür für seinen jeweiligen Käufer visualisiert werden. Der Verkaufsroboter ist ein permanenter Bestandteil der Szene, seine Programmhefte werden aber von ihren Käufern nach der Veranstaltung mitgenommen.
Wenn man nicht eine Unzahl verschiedener Objekttypen für die Szene verwalten will, so muß der Standardobjekttyp mit etlichen Feldern versehen werden, wodurch mindestens die folgenden Varianten gekennzeichnet werden können:
Tabelle 15.3
Aspekte der Szenenverwaltung
|
Update
Neighbors |
Receive Updates |
isAvatar |
Persistent |
Schauspieler: für alle und sich gegenseitig sichtbar. |
false |
true |
true |
false |
Bühnenbeleuchtung: für alle sichtbar, selbst blind. |
false |
false |
false |
true |
Publikum: sieht die Bühne, die Nachbarn, den Verkäufer. |
true |
true |
true |
false |
Programmheft: sieht nur der Käufer; selbst blind. |
true |
false |
false |
(either) |
Verkäufer-Roboter: reagiert auf Anruf; bleibt Teil der Szene. |
true |
true |
false |
true |
Allmählich wird es klar, weshalb die ersten VRMLer damals die GevU-Thematik vor sich geschoben haben - und bis jetzt haben wir nur einige Komplexitäten betrachtet, die in der Natur der Aufgabe stecken. Die Implementierung solcher Strukturen in VRML97 stellt, wie wir gleich sehen werden, nichttriviale Probleme.