Kategorie: Building

Festungen Gors, Teil I: die Black Shark Piraten

Wie neulich angekündigt nun ein Post, der mal eine typische Festung einer Gruppe mit erhöhtem Schutzbedürfnis genauer unter die Lupe nimmt. Zunächst aber einmal ein Bild als positives Beispiel, das zeigt, wie man es machen könnte, eine Stadtmauer, bei der eben nicht „form follows function“ gilt und diesem Credo alles untergeordnet ist, sondern die Funktion höchstens die zweite Priorität gewesen ist.

Ladies and Gentlemen, and here we proudly present: die Stadtmauer von Lydius (Klick darauf zeigt es wie immer in voller Grösse). Gut gemacht!

Die Stadtmauer von Lydius

Nach diesem positiven Beispiel nun also die besagte Festung. Kurz zu den Sharks: es handelt sich bei ihnen um eine der beständigen Piratengruppierungen, sie waren bereits auf dem allerersten Lydius unter Spitte noch direkte Nachbarn der Stadt, wohnten später bis zu dem Untergang der Sim auf der schönen Sim Moorland und wohnen nun auf einer Viertelsim (Fullprim), es gibt sie also grob geschätzt mindestens (mit kurzer Unterbrechung) zwei Jahre. Auf den Bildern ist, soweit nicht anders gekennzeichnet, oben der Norden.

Lageplan der Sim

Schauen wir uns zunächst einmal eine Karte an, denn nicht ist besser um sich einen Überblick zur Orientierung zu verschaffen als eine solche. Oben in der gelben Umrandung ist der Landepunkt für alle Gruppen. Es gibt im Osten der Sim noch eine weitere, aber normalerweise nehmen alle Angreifer direkt diesen. Es handelt sich dabei, wie so oft, um ein Schiff. Unten links im Südwesten der Sim rot eingezeichnet ist das Lager der Sharks. Der direkte Weg zum Lager ist in dieser Karte pink eingezeichnet und führt dabei nach 2/3 des Weges über eine schmale Brücke, die schwarz gekennzeichnet ist. Hinter der roten Umrandung direkt befinden sich die Befestigungsanlagen des Lagers, die Form erinnert entfernt an eine Bastionsmauer.

Sobald man etwa die Hälfte des Weges vom Schiff zum Lager hinter sich gebracht hat – also noch lange vor der Brücke – kann man bereits vom Lager der Piraten aus unter Beschuss genommen werden. Wichtig ist auch, dass die südlicheren Teile der Mauer einen Wassergraben haben, so dass die direkte Angriffsfläche vor dem Lager recht klein gehalten ist. Umgekehrt haben natürlich die Verteidiger die gesamte Mauer zur Verfügung und können von dort bequem alles unter Beschuss nehmen. Im Norden des Lagers der Shark ist übrigens ein Pantherlager, von dem aus man aber nicht wirklich angreifen kann, im Westen und Süden die Simgrenze, so dass man es normal nur von der Ostseite aus angreifen kann.

Die Simgestaltung folgt der alten Maxime der möglichst langen Weggestaltung für den Angreifer und Schaffung künstlicher Nadelöhre, durch die er gehen muss, um angreifen zu können. So eine Brücke ist einfach praktisch, auf der alle Gegner wie Perlen an einer Kette aufgereiht hinüber müssen, es kommt meist zu einem Stau und so kann man sie viel einfacher da unter Beschuss nehmen. Dabei wird das Terrain für mögliche Angriffe minimiert während die Verteidiger gleichzeitig auf möglichst maximaler Fläche  agieren können. Berge dürfen auf der Sim nicht bestiegen werden, sie gelten als nicht passierbar.

Nun ist so ein Lageplan eine Sache, man darf nicht vergessen dass es sich bei Second Life um eine dreidimensionale Angelegenheit handelt, bei der man auch mit dem Terrain viel arbeiten kann. Mit einer Karte alleine kann man die Leistung des Baus nicht entsprechend genug würdigen, sondern da müssen weitere Betrachtungen her. Daher nun weitere Bilder zur Betrachtung. „Festungen Gors, Teil I: die Black Shark Piraten“ weiterlesen

Erhöhtes Schutzbedürfnis

Es gibt sie irgendwie immer noch: Gruppen, die aufgrund ihrer Spielweise meinen ein erhöhtes Schutzbedürfnis zu haben und entsprechend verteidigungstechnisch optimiert ihre Sims oder Lager auf Sims mit anderen Gruppen bauen, damit sie einen möglichst großen Heimvorteil haben. Diese Lager oder gleich ganzen Sims sind dann in Prim und ins Terrain gegossene Konstrukte, die eigentlich zwei Botschaften aussenden, nämlich erstens „Wir wollen möglichst oft gewinnen!“ sowie „Bleib lieber weg!“ Man muss sich dann nicht wirklich weiter wundern, wenn viele friedliche Besucher solche Lager eher meiden, da sie oft anhand des Baustils vermuten, dass es dort mit dem Rollenspiel an sich doch eher mau bestellt sein könnte.

Ich persönlich bin der Meinung, dass man dem vermeintlichen Schutzbedürfnis längst nicht alles unterordnen darf. Sicher, wenn man Mauern baut, will man die auch nutzen, aber möglicherweise sein Terrain gleich so zu gestalten, dass man viele Vorteile und der Angreifer viele Nachteile hat, ist und bleibt einfach unfair. Es spricht nichts dagegen, eine einigermaßen sichere Verteidigungslinie aufzuziehen, aber da man ja immer noch mit den angreifenden Gruppen miteinander spielen will, gehört zu einem fairen Miteinander und damit Baustil meiner Meinung nach unbedingt dazu, dass man bewusst Lücken in der Anlage mit einbaut, so dass ein Angreifer auch eine faire Chance hat, sollte er sich nicht zu dumm anstellen, mal zu gewinnen. Eine zu perfekte Verteidigung nämlich wie manche Gruppen sie haben hat kein Angreifer gerne und mit ständigen Gewinnern wegen einer solchen spielt am Ende keiner auf Dauer gerne, man beginnt sie dann oft irgendwann zu meiden und das ist oft der Anfang vom Ende einer Gruppe. Hier sollte eigentlich im Sinne der Fairness und des Miteinanders gelten: Mut zur Lücke und Mut zur Unvollkommenheit!

Ein gutes Beispiel, dass es auch anders geht, ist für mich zum einen das alte Scagnar, in dem es keinerlei Mauern noch Wälle gab, sondern nur ein paar offene Holzpalisaden und das ist es gewesen. Sicher, der Weg vom Hafen bis zum Runenberg war zwar lang, aber es gab eine durchaus faire Chance da auch mal zu gewinnen, sofern man der massiven Kampfkraft der Feuerbringer gewachsen war. Ein weiteres Beispiel war der alte Axtfjord, der auf 1/2-Sim auch sehr offen ohne irgendwelche großen Verteidigungswälle angelegt war, auch dieser sah sehr schön aus und es bestand dennoch auch für Angreifer eine gute Chance, da mal zu gewinnen.

Vielleicht nehme ich mal in ein oder zwei späteren Posts genau solche Festungen nach allen Regeln der Kunst auseinander, irgendwie juckt es mich gerade stark in den Fingern das zu tun.

Wollt ihr bessere Meshkleidung? Stimmt für Jira SH-2374!

Meshes machen sich langsam in Second Life breit. Ein großes Problem dabei bei Avataren ist, dass man den Shape des eigenen Avatars bisher ans Mesh anpassen muss – und nicht umgekehrt. Technisch kommt das daher, weil die Meshes am Bone des Avatarskeletts getragen werden und sich um die Beschaffenheit des Shapes überhaupt nicht kümmern. Dadurch bewegen sich die Meshes zwar bei jeder Bewegung des Avatars super mit, es hat aber zur Folge, dass die Kleidungsdesigner wenn sie Mesh einsetzen verschiedene Größen ausliefern müssen. Der Kunde wiederum muss dann die Größe wählen, die seinem Avatar am ehesten passt und entweder seinen Shape leicht anpassen oder mit Alphalayern arbeiten.

Nun ist es aber so, dass für viele der eigene Shape ja ein wesentlicher Bestandteil der virtuellen Identität ist, etwas, was man nicht wirklich ändern will. Entsprechend gehen bei Meshkleidung daher auch die Reaktionen auseinander. Wer darüber mehr lesen will, der wird bei Rowan Derryths Post mit vielen Bildern fündig, in dem sie die Probleme detailliert schildert.

Designer Maxwell Graf hat nun daher im Bugtracker JIRA einen Verbesserungvorschlag bei den Lindens eingereicht, dass sich am Avatar getragene Meshes in Zukunft automagisch dem Shape anpassen sollen. Dies läuft unter der Bezeichnung SH-2374 „Request for parametric rigged mesh deformer“ im JIRA und ist eine sinnvolle Sache, wenn ihr auch der Meinung sein solltet, dass Linden Lab das unbedingt verbessern sollte, dann loggt euch da bitte ein und unterstützt den Vorschlag, indem ihr dafür stimmt. Bis das implementiert worden ist, wird es vermutlich für viele ein Unding sein, Meshkleidung zu kaufen.

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.