Schlagwörter: second life

Blogs als RP-Verhinderungsmaschinen

Bei mir ist heute das Blog „ganzweisserschwan“ aus der Blogroll rausgeflogen. Nicht, weil es nicht mehr gepflegt werden würde und es damit keine aktuellen Inhalte mehr gibt, im Gegenteil, sondern gerade wegen der aktuellen Inhalte und wegen der Art und Weise der Präsentation! Es gibt gewisse Sachen, auf die ich persönlich nicht weiter verlinken will noch verlinken muss, dieses Blog gehört für mich ab sofort mit dazu.

Der Grund liegt im Posting „Wirtshaussklavin vs. Exotin“, und da dort auch weiterhin in Zukunft ähnliche Kracher auf teilweise derbstem Gossenniveau zu erwarten sind, in dem Rollenspieler aufs übelste beleidigt und samt Namen an den Pranger gestellt werden, weigere ich mich, noch weiterhin nach dort zu verlinken und somit für zusätzliche Awareness betreffs dieses Blogs zu sorgen.

Das Blog ist für mich ab sofort Geschichte und wird hier nach diesem Post von mir hier nicht mehr erwähnt werden.

WTF: die Latexburka!

Geneigter Leser, diese wundervolle Geschmacksverirrung kann zum Schleuderpreis von 850 L$ DIR gehören!

Da spaziere ich gut gelaunt über eine Clubsim, auf einmal packt mich da das kalte Entsetzen, denn was müssen da meine entzündeten Augen sehen? Eine schlampig aussehend gearbeitete Burka aus Latex, erhältlich in Schwarz und Rot! Dieses Juwel des handwerklichen Nähens mit der viel zu heißen Nadel kann für nur lumpige 850 Lindendollar dir gehören, ja genau, DIR!

Also Leute, kauft es und rennt damit herum, dass die Schwarte kracht, denn eine Demo gibt es leider nicht, aber dieses wunderschön gearbeitete Foto alleine ist doch sicherlich für uns alle mehr als Anreiz genug, das haben zu wollen! Vielleicht kann man es ja noch für Rollenspiele zweckentfremden, aber – besser nicht!

Meshupload mit Drittviewern

Meshes sind ja nun langsam dabei, sich im Grid auszubreiten und werden mehr und mehr Standard werden, einfach weil sie massive Vorteile haben, auch wenn sie sicherlich noch mit einigen Problemchen behaftet sind. Wer mit veralteten Viewern wie Phoenix sich Meshes am Avatar anschaut, der sieht beispielsweise statt einer Hose nur einen Mann ohne Unterleib mit einer komischen Kugel. Aber ich bin mir sicher, da der Druck nun vorhanden ist, wird eine Vielzahl an Benutzern sehr schnell Viewer bei sich installieren wollen, die Meshes darstellen können.

Bisher gibt es folgende Viewer, die Meshes darstellen können:

Weiterhin wird die nächste Version des Firestorm-Viewers Mesh offiziell unterstützen, dazu kommt noch bereits angekündigt der Singularity Viewer. Alles in allem sieht es gar nicht so schlecht aus, die Vielfalt des Viewerzoos wird erhalten bleiben und läuft Mesh in einem der 1.xer-Viewer erstmal gut genug, werden sicherlich auch andere bereitwillig den Code bei sich einbauen und übernehmen.

Nun ist die Darstellung von Mesh eine Sache, das Uploaden von Meshes aber leider eine andere. Wer selber Meshes erstellen will, der ist auf den Viewer der Lindens oder Kirstens Viewer angewiesen. Alle anderen Viewer können zwar Mesh bisher darstellen, aber noch nicht wirklich erstellen.

Woher kommt das? Nun, ein Mesh ist ja zuerst einmal ein sichtbares 3D-Polygonnetz. Damit es aber in SL auch vernünftig einsetzbar ist, gehört dazu auch eine entsprechende, unsichtbare Hülle für die Physik, schließlich will man ein Haus zwar betreten können, aber nicht durch die Wände hindurchlaufen. Die Physik-Hülle nun kann man entweder im Tool seiner Wahl mehr oder minder selber generieren oder den Viewer die Arbeit übernehmen lassen. Dazu hat Linden Lab eine neue Programmbibliothek mit dem schönen Namen llconvexdecomposition erschaffen, die nichts anderes als ein sog. Wrapper um die Havok-Library ist. Havok selber ist aber kein Opensource, sondern kostet richtig Geld. Für Linden Lab ist das kein Problem, da sie ja Havok einsetzen, für Linden Lab funktioniert diese Bibliothek, aber da man zum Bauen von llconvexdecomposition Havok braucht, funktioniert sie für die Mehrheit der externen Entwickler eben nicht. llconvexdecomposition selber ist Open Source, aber da es nichts anderes als eine Zwischenschicht zu Havok ist, braucht man für einen alternativen Viewer eigentlich auch dann Havok, damit da Meshupload funktioniert.

Nun hat Linden Lab, damit externe Viewer auch Meshs irgendwann mal uploaden können, eine Bibliothek namens llconvexdecompositionstub im Programm. Diese enthält dieselben Funktionen wie llconvexdecomposition, aber ein Stub ist nur ein Platzhalter. Sprich, die Funktionsaufrufe laufen alle erfolgreich ab, aber diese Bibliothek leistet gar keine Arbeit. Der einzige Sinn und Zweck ist es, den Programmierern das Interface an die Hand geben zu können, mit dem sie dann selber einen Ersatz für Havok bauen können. Ob das kommt oder nicht, wird die Zeit zeigen. Es kann ja sein, dass die größeren Viewerhersteller wie Phoenix einfach Havok lizenzieren und dann auch entsprechend verteilen. Wenn man nämlich einen eigenen Ersatz für Havok da baut ist die Frage, wie gut oder schlecht die Ergebnisse im Vergleich zum Lindenviewer beim Upload sein werden.

Solange das aber noch Zukunftsmusik ist, solange funktioniert der Meshupload nur mit dem Lindenviewer wirklich zuverlässig. Wer Meshes erstellen will, der ist nur mit diesem wirklich auf der sicheren Seite.

Über gutes Gamedesign

Ich habe in den letzten paar Wochen recht intensiv das nun frei verfügbare Team Fortress 2 von Valve gespielt. TF2 ist ein teambasiertes Onlinespiel, in dem immer zwei Teams gegeneinander antreten und eine Aufgabe lösen müssen, sei es das Erobern von Kontrollpunkten, eine Fracht von A nach B zu bringen oder Capture the Flag. Wichtig bei solchen Spielen ist immer, damit sie nicht zu langweilig werden, eine gut ausbalancierte Spielbalance.

Bei TF2 selber gibt es grob zuerst einmal drei Klassen: Angriff, Verteidigung und Unterstützungsklasse. Dem Angriff gehört der schnelle Scout, der raketenwerfende Soldier und der Feuerteufel Pyro an, der Verteidigung der bombenwerfende Demoman, Sentry-Guns bauende Engineer und der Damage-Dealer-Tank Heavy mit seinen Megawummen an, den Support stellen der alles heilende Medic mit seiner Medigun, der Sniper mit seinem Scharfschützengewehr sowie als Sonderrolle der Spion, der sich als Gegner tarnen kann und hinter den feindlichen Linie ordentlich für Verwirrung sorgen kann.

Eine der wichtigen Grundregeln des Gamedesigns, die hier gut umgesetzt wurde, ist, dass keine Klasse alleine zu übermächtig sein darf, sondern man nur wirklich im Team gewinnen kann. Das bedeutet, jede Klasse für sich hat schon mal eine unterschiedliche Ausstattung an Gesundheit. Dabei gilt die Faustregel, je schneller sich die Klasse fortbewegen kann, desto weniger Gesundheit, je mehr Gesundheit, desto langsamer die Klasse in ihrer Bewegung. Ähnliches gilt dabei für die Waffen: Waffen brauchen Munition, sie feuern nicht selber unendlich, sondern es braucht dazu ab und an auch Nachladezeiten und die Magazingrößen variieren. All das sorgt für ein recht ausgeglichenes Spiel, wobei auch darauf geachtet wurde, dass Klassen mit Fernwirkung im Nahkampf eher schlecht sind und umgekehrt Klassen wie der Heavy, die im Nahkampf auftrumpfen, durch ihre langsame Geschwindigkeit und breite Streuung der Gatling-Guns in der Ferne keine Wirkung erzielen können. Auch gilt, das Waffen mit Fernwirkung im Nahkampf kaum sinnvoll sind und umgekehrt.

Gutes Gamedesign ist dabei ein stetiger Prozess, einerseits sollen die Klassen natürlich ihre Eigenheiten behalten, andererseits darf keine Klasse alleine zu übermächtig werden und auch keine Waffe. Wenn zum Beispiel eine Waffe mehr Schaden erzielt als die Standardwaffe, dann bekommt sie bei Valve auch einige Mali verpasst, wie kleiner Magazingröße, geringerer Splashradius und ähnliches, damit sich das immer die Waage hält. So kann der Sniper zum Beispiel aus der Ferne mit einem Kopfschuss seines Gewehrs einen Mann direkt töten, allerdings dauert es zehn Sekunden bis das Gewehr seine Höchsteffizienz erlangt und man sieht am anderen Ende einen Laserpunkt wandern, auf den man achten kann – ist also gewarnt. Nimmt der Sniper dagegen seinen Huntsman, einen Bogen, wird er beweglicher, aber wenn er damit zielt, bewegt er sich auch kaum noch.

Es gibt also klar voneinander unterscheidbare Rollen, wobei es aufs Teamplay ankommt, um zu gewinnen und je nach Einsatzort auch verschiedene Waffen.

Betrachtet man sich dagegen mal das Gorean Meter mit seinen Waffen, dann werden starke Unterschiede klar. Wichtig ist dabei, dass das GM für Second Life als praktikabel und erprobt anzusehen ist, aber es folgt dem obersten Prinzip der Lagvermeidung. Daher kümmert es sich nicht wirklich um gutes Gamedesign.

Das beginnt natürlich mit der Dominanz der Bögen über die Nahkampfwaffen – ein Unding. Dazu kommt, das wer einen Bogen spannt, auch langsamer gehen sollte und nur einen begrenzten Vorrat ein Pfeilen mit sich herumtragen dürfte. Solche Systeme gab es schon, wie von Andera Shermer damals der realistic Bow, auf breiter Front durchsetzen konnten sie sich nie. Die Nahkampfwaffen wiederum erlauben zwar eine gewisse Differenzierung, wer Zweihandwaffen führt schlägt langsamer zu aber hat eine größere Reichweite, nur wirklich durchgreifend ist die auch nicht. Ebenso fehlen Rollen, ein Krieger nunmal wird mehr Schlagkraft und Gesundheit haben als ein normaler Schreiberling oder eine freie Frau.

Kurz und gut, Kampf mit GM ist zwar an und für sich ganz nett, aber wirklich richtig toll ist er auch nicht. Er stellt das bestmöglich machbare in SL dar, komplexere Systeme wie das Metalife Meter oder GLM haben sich auf breiter Front nie richtig durchgesetzt, aber in Sachen Gamedesign ist man andersorts viel weiter.

Meshes und das Viewer-Ökosystem

Die jetzt verfügbaren Meshes sind ja eines der Killerfeatures, die Linden Lab schon lange versprochen hat und nun endlich verfügbar sind. Sie kamen wahrlich nicht über Nacht, es gab lange Zeit eine geschlossene Beta mit ausgewählten Designern und auch mindestens sechs Monate lang eine offene Beta, an der jeder teilnehmen konnte, der wollte. Viele Designer waren da auch fleißig, sammelten im Betagrid reichlich Erfahrungen, so dass sie nun ihre bereits damals erstellten Objekte einfach im Maingrid einführen können, um damit zu arbeiten. Sicherlich ist es zuerst noch eine Sache für die sog. Early Adopters, aber es wird nicht lange dauern, bis sie sich auf breiter Front durchgesetzt haben werden und die kaufbaren Meshes eine ähnliche Qualität erreicht haben werden wie bereits jetzt die Sculpties. Die Vorteile sind einfach zu groß, einfachere Erstellung der Objekte in Blender/Maya/Sketchup/…, dazu wenn man es richtig macht sind sie noch für die Grafikkarte einfacher darzustellen, da man die Anzahl der Polygone hinreichend gut optimieren kann, und und und… kurz, ein Werkzeug nicht nur für Professionelle, aber gerade auch für diese. Die Geschwindigkeit allerdings, mit der sie dann letzten Endes doch kamen, war flotter als erwartet. Rodvik Linden kehrt wohl ganz gut bei Linden Lab und gibt den Leuten die richtigen Arschtritte, damit sie in die Gänge kommen, was kein Nachteil ist.

Nun ist es aber so, dass zur Darstellung der Meshes und damit man in den Genuss derselben kommt, der Viewer diese darstellen können muss und damit fangen dann für die Benutzer die Probleme an. Momentan gibt es genau drei Viewer, die das nämlich können: der Standardviewer von Linden Lab ab Version 3.0, der Snowstorm-Viewer von Linden Lab sowie der aktuelle Kirstens Viewer. Der Rest wird die Meshes zwar von den Daten her auch empfangen können, aber er sieht dann nur Basisprims und nicht die gesamte Pracht. Es wird also durchaus Situationen geben wie „Guck mal, Leo, meine neue, tolle Meshjeans!“ und der guckt und meint: „Was sollen denn da die Pyramiden?“ Das wird kommen.

Meshes treiben also einen Graben in die Viewerwelt, es gibt die Viewer, die sie darstellen können und die Viewer, die es bisher nicht können. Die Viewer, die es können, basieren auf der 2.xer-Codebasis von Linden Lab, weil nur in dieser Linden Lab selber die Meshfunktionalität eingebaut hat. Das bedeutet, dass der Phoenix Viewer, Imprudence, Cool Viewer, Singularity usw. mit Meshes null komma gar nichts anfangen können. Der in der Entwicklung befindliche Phoenix Firestorm soll in einer späteren Version mit Meshes arbeiten können, aber noch sind die entsprechenden Funktionen nicht eingebaut und stehen bisher nicht zur Verfügung. Der Zeitrahmen, den es dauert, bis das soweit ist, wurde von offizieller Seite aus mit „einige Wochen“ bezeichnet. Entgegen bisheriger Befürchtungen wurden die Viewer mit der 1.xer-Codebasis von Linden Lab bisher nicht „abgeschaltet“, aber der Drang sie nun aufzugeben wird bei einigen durch Meshes doch sicher groß.

Damit ist klar, wer Meshes sehen will, der braucht entweder Kirstens Viewer oder den Linden Viewer, daran führt bisher kein Weg dran vorbei. Allerdings gibt es für die Fans der 1.xer-Viewer etwas Hoffnung, denn der Macher vom Cool Viewer – Henri Beauchamp – arbeitet schon nach eigenen Aussagen seit Wochen daran, Meshes auf die alte Viewercodebasis zu portieren, aber das ist eine größere Baustelle und eben dann fertig, wenn es fertig ist. Auch Siana Gearz vom Singularity Viewer schrieb Mitte Juli, dass sie Meshes zur Verfügung haben werden, aber das auch ein wenig dauern würde und sie dafür 120.000 Zeilen Code innerhalb von sechs Monaten umgeschrieben hätten. So oder so, sobald einer dieser Viewer Mesh haben wird, ist es wahrscheinlich, dass die Implementierung auch den Weg in andere 1.xer-Viewer finden wird, bis es aber soweit ist, wird wohl noch einige Zeit vergehen.