Schlagwort: Programming

Die rabiate Phoenix-Fanbase und noch ein paar Statements von Henri Beauchamp zum Thema Serverside Baking

Am 17. Dezember 2012 verkündete das Phoenix-Team das Ende der Entwicklung des beliebten Phoenix-Viewers. Die Gründe dafür sind unter anderem, dass man nicht mehr weiterhin zwei unterschiedliche Codebasen pflegen will und 2013 neue Features wie Serverside Baking erscheinen werden, die ohnehin die Kompatibilität mit der 1er-Viewercodebasis brechen werden.

Festzuhalten dabei ist: man kann seinen Phoenix noch weiterhin benutzen, die Entwicklung aber wurde Ende 2012 eingestellt. Eine lange überfällige Ankündigung, bei der man förmlich die Freude des Teams, endlich diesen Zombie losgeworden zu sein, spüren könnte. Die Reaktionen auf den Post sind zweigeteilt: die einen haben absolut kein Problem damit, und sich beim Phoenix-Team für all die Arbeit bedankt, sie nutzen in Zukunft nun entweder eben Firestorm, Singularity oder den Cool Viewer. Andere aber tun so, als sei dies der Untergang des Abendlandes und überziehen das Team mit überbordender Häme und Flames.

Diese Flamer haben dabei offensichtlich nicht verstanden, was Opensource ausmacht. Opensource heißt, du kannst den Code nehmen und damit im Rahmen der Lizenz machen, was du willst. Es heißt aber nicht, dass nun die Entwickler eines Projekts unentgeltlich nach der Pfeife ihrer Benutzer tanzen müssen und machen müssen, was die wollen. Wenn die Entwickler keine Lust mehr haben, etwas weiter zu entwickeln, dann ist das eben so und fertig. Dann kann man entweder selber die Initiative ergreifen und da weitermachen, oder lebt damit und lässt es eben sein. Punkt, aus, fertig!

Alles in allem sind aber die anhaltenden Flames der Phoenixfanbase mit bisher 178 Kommentare im Blogpost oben dermaßen überzogen, dass sich die Entwicklerin Tonya Souther zu dem Kommentar „Go ahead, fork Phoenix!“ hinreißen ließ. Souther beschreibt die Codebasis des Phoenix-Viewers als hoffnungslos veraltet, dass es schon massiver Arbeit bedürfe, alleine das Meshrendering auf den Level von 3.4 zu bringen – es basiere noch auf Viewer 2.8.

I’m not kidding when I say it’s an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.

Ich übertreibe nicht, wenn ich sage, dass es [Phoenix] eine unwartbare Masse an Hacks ist, die von Spucke, Kaugummi, Tesafilm und losen Drähten zusammengehalten wird.

Das Zitat lässt dann schon tief blicken, und weil die Fanbase so rabiat weiterhin auf Phoenix pocht, soll sie doch den Mist einfach übernehmen, warten und fertig. Der Rest könne ja mit Singularity oder dem Cool Viewer glücklich werden.

Kurz: Undank ist wohl der Welten Lohn und manche Hohlpfosten fordern da von Freiwilligen eine Arbeitsleistung ein, auf die sie kein Recht haben das einzufordern. Klar, dass da einem schon mal die Galle überlaufen kann.

Übrigens schwebt über all diesen Probleme Henri Beauchamp, denn der bastelt ja nach wie vor an seinem eigenen Viewer, dem Cool Viewer, alleine. Diesen entwickelt er vor allem für sich selbst und wenn jemand Gefallen daran hat, bitte, kann er ihn gerne nutzen. Beauchamp gibt an, über 35 Jahre Programmiererfahrung zu verfügen und dementsprechend kein unbeschriebenes Blatt zu sein.

Gut, Beauchamp hatte mal wieder Langeweile, und daher kann die aktuellste Version vom Cool Viewer bereits Server Side Baking. Ein Feature, das der Phoenix-Viewer nie mehr bekommen wird, es sei denn jemand macht einen Fork und nennt den dann anders. Der Cool Viewer ist damit der erste TPV, der dieses Feature offiziell unterstützt.

Übrigens gibt’s zu dem Thema auch noch eine launige Mail von Beauchamp in der Entwicklerliste an Oz Linden, die es in sich hat. Beauchamp wirft Linden Lab in Sachen Opensource schlichtweg Vollversagen vor, anders kann man es nicht nennen. So schreibt er dies:

I’d rather not judge „Oz, the man“ because it is hard to tell whether his actions are the only result of his own decisions and doings, or are the materialization of LL’s policy towards OpenSource and, if we can judge from the resulting actions their policy would clearly be: „take benefit of all the advantages OpenSource can bring to us (i.e. free coding and debugging horsepower provided by volunteering developers), and dismiss all the duties OpenSource cooperation involves in return (such as providing clean diffs for changed we made behind closed doors(*) before releasing them, but also providing an *open* list of known bugs to developers)“.

Kurz und gut: Linden Lab würde gerne die Vorteile der Community wie kostenlosen Code und Debugging abgreifen, dafür im Gegenzug aber nicht mal die grundlegendsten Selbstverständlichkeiten an die Community, wie eine offene Liste der bekannten Bugs, zurückliefern. Eine Klage, die nun überhaupt nicht neu ist, sondern genau so schon Nicholaz Beresford vor fast fünf Jahren formulierte. Linden Lab bleibt also sich und seiner Linie treu. Das Hauptproblem von Linden Lab sei, dass sie hinter verschlossenen Türen monatelang neues Zeug entwickeln würden und dann – BUMM! – ist es auf einmal eben da. Das sei nicht die Art und Weise, wie Opensource funktioniere, und vor allem käme da Linden Lab seinen Pflichten nicht wirklich nach…

Daran angehängt ist eine Email von Beauchamp an Oz Linden vom Juli 2012, in dem sich Henri lange und breit darüber auslässt, wieso er die Art der Implementierung – basierend auf dem „Current Outfit Folder“ für eine denkbar schlechte Idee hält.

Und jetzt, wo die ersten Testimplementierungen da sind und das Feature offenkundig so bockt wie Beauchamp voraussagte, zeigt Beauchamp denen mit Freuden den Stinkefinger und sagt dazu: „Ich habe es euch doch gleich gesagt!“ – Tja, und er hat damit sogar noch Recht, aber Linden Lab wollte ja nicht hören…

Die Programmiersprache Lua

Viele Spiele kommen ja heutzutage nicht mehr ohne eine irgendwie geartete Programmiersprache aus, in denen gewisse Sachen geskriptet sind und die ggf. zur Entwicklung von Erweiterungen zur Verfügung gestellt wird.

Ein bekannter Vertreter war früher beispielsweise S.C.U.M.M. von Lucas Arts, in dem viele von deren berühmten Adventures (wie Monkey Island, Day of the Tentacle und weitere) programmiert worden sind. Heutzutage aber ist der bekannteste Vertreter dieser Art eindeutig Lua.

Wo kommt es her?
Lua ist ursprünglich eine Entwicklung einer katholischen Universität aus Rio de Janeiro in Brasilien. Die Entwickler beschreiben Lua als schnelle, leichtgewichtige, mächtige und einbettbare Skriptsprache. Es ist sehr einfach möglich, Lua in beliebige Spiele als Skriptsprache einzubetten und dann zu benutzen. Der gepackte Download hat gerade einmal 182 Kilobyte und Lua selber ist in nur 20.000 Zeilen C-Code implementiert. Damit ist die Codebasis klein und überschaubar, also auch sehr gut wartungsfähig.

Was bedeutet der Name? Ist das eine Abkürzung?
Nein, Lua ist einfach nur portugiesisch für Mond. Das ist alles.

Was kostet das?
Nichts. Lua wird unter der wohlbekannten MIT-Lizenz zur Verfügung gestellt, die grob gesagt „Mach damit, was dir beliebt, Hauptsache du nennst irgendwo unseren Namen“ als Bedingung hat. Daher ist Lua sehr weit verbreitet.

Wo gibt es Dokumentationen zu Lua?
Zu allererst in Englisch auf der Seite des Projekts, daneben aber auch auf Deutsch wie beispielsweise hier ein Einsteigerkurs und noch eine Referenz.

Welche Spiele nutzen denn nun Lua?
Die Liste ist lang, bekannte Spiele sind unter anderem Die Siedler: das Erbe der Könige, Monkey Island ab Version drei, World of Warcraft, Angry Birds, Baldur’s Gate, Civilization V, Sim City 4, Mafia II und viele andere.

Warum sollte man sich mit Lua beschäftigen?
Ganz einfach: wer schon immer mal wissen wollte, wie eine Spielmechanik geskriptet worden ist oder für Spiele wie World of Warcraft, bei denen die Erweiterungen komplett in Lua geschrieben sind, vielleicht selbst Add-Ons schreiben will oder diese zumindest verstehen, der kommt um Kenntnisse in Lua nicht herum.

Ist Lua neben Spielen noch weiter verbreitet?
Kaum.  Es gibt Ausnahmen wie beispielsweise Prosody, ein komplett in Lua geschriebener Jabberserver, aber die Liste dieser Programme ist dann doch sehr überschaubar.

Pathfinding-Bugs

Linden Lab wusste sicher, dass mit der Einführung von Pathfinding einiges an Arbeiten auf sie zukommt, da Teile der Physik massiv geändert worden sind.

Interessant ist es dabei wenn man mal einen Blick ins JIRA-System wirft, was sich so bisher dort an bekannten Bugs versammelt hat. Ich gehe davon aus, dass diese Fehler zügig bereinigt werden, denn manche davon sind richtig unschön. Man sieht auch daran vor allem, dass trotz dem längeren Test auf den Magnum RC-Regionen damit längst nicht alle möglichen Fehlerquellen entdeckt worden sind, sonst wäre das JIRA nicht voll davon.

In der Kategorie Showstopper (also die höchste Stufe, so etwas wie ein GAU, weil damit eine extrem wichtige Funktion nicht mehr funktioniert) befindet sich das Ticket PATHBUG-181. Die Funktion llVolumeDetect() ist fehlerhaft gemeldet. Dies betrifft vor allem Vehikel, wenn die auf ein Prim mit dieser Funktion prallen (typischerweise der Start/Zielstreifen einer Renstrecke), dann ist das Prim entweder auf einmal lange genug nicht mehr Phantom und schleudert so das Vehikel zufällig in eine andere Richtung oder aber während einer Kollission auf einmal nicht Phantom und lässt das Vehikel gar nicht mehr passieren. Damit sind Rennen momentan schwer bis unmöglich, die Besitzer von Rennstrecken schäumen vor Wut und lassen in den Kommentaren ihren Gefühlen freien Lauf. Ich bin mir sicher, der Fehler wird schnellstmöglich behoben sein. Kurioserweise tritt der Fehler umso wahrscheinlicher auf je größer das Prim mit dem Skript ist.

Dazu kommen teilweise fehlerhafte Berechnungen des Land Impacts und ein Haufen weiterer Fehler, die gerade noch kategorisiert werden.

Ich denke mal, in so zwei bis drei Wochen dürften die gröbsten Bugs allesamt beseitigt sein und dann wird man langsam, aber sicher anfangen können damit richtig zu arbeiten.

All work and no play makes Jack a dull boy

Linden Lab hat seine diesjährige Lagbekämpfungsintiative unter dem Namen Projekt Shining veröffentlicht. Das Hauptziel soll es sein, die Geschwindigkeit des Aufbaus von Avataren und Sims zu erhöhen.

Das Projekt gliedert sich dabei in drei Teilprojekte namens Projekt Sunshine, Objekt Caching und HTTP-Bibliothek. Als Begleitmaßnahme wird Linden Lab gleichzeitig die Anzahl der Rechenzentrenstandorte von drei auf zwei reduzieren und nach Angaben von Rod Humble in diesem Jahr noch die höchste Investition der Firmengeschichte in neue Hardware tätigen.

Projekt Sunshine
Projekt Sunshine ist das Teilprojekt, welches das korrekte Rendern von Avataren deutlich beschleunigen soll. Bisher läuft das Spielchen so: damit ein Avatar nicht als Wolke erscheint, holt sich zunächst der Viewer vom Benutzer alle angezogenen Texturen des Avatars, es werden einige simple Bildbearbeitungsalgorithmen darüber laufen gelassen – stellen wir uns das einfach wie verschiedene Ebenen in Photoshop vor, die man übereinander legt und exportiert – und das Ergebnis wird dann an den Simulator hochgeladen. Diese im Fachjargon Baked Texture genannte Datei wird dann an alle weiteren Benutzer in der Nähe gesendet.

Im Prinzip eine einfache Sache, aber man sieht, wo es zu Problemen kommen kann: zunächst einmal muss der Client des Avatars einiges an Texturen runterladen, das dauert, dann muss er die Textur berechnen, als JPEG2000 kodieren und wieder hoch laden. Da gibt es genügend Punkte, wo es zu Problemen kommen kann und wenn der Upload nicht richtig funktioniert, sieht der Rest einen möglicherweise grau oder gar nicht.

Dem Abhilfe verschaffen soll eine neue Instanz an Servern, deren einzige Aufgabe es werden wird, die Baked Textures zu berechnen und den Simulatoren zur Verfügung zu stellen. Damit wird diese Aufgabe von den Clients hin zu Servern im Rechenzentrum von Linden Lab verlagert. Das Ergebnis wird eine spürbare Beschleunigung des Rezzens von Avatartexturen sein und wenn Linden Lab es richtig implementiert, dann werden auch graue Avatare endlich der Vergangenheit angehören.

Verbesserter Objekt-Cache
Der lokale Cache des Viewers soll persistenter und performanter werden, das Ziel ist eine massive Erhöhung der Hitrate. Auch soll die Kommunikation vom Viewer beim Aufbau einer Szene mit der Sim optimiert werden.

Das ist eine Maßnahme, die schon lange überfällig ist, denn die schlechte Performance des Viewercaches ist ja geradezu legendär. Außerdem spart das Linden Lab mitunter auch bares Geld, wenn es massiv zu weniger Kommunikation kommen sollte.

Bessere HTTP-Bibliothek
Die HTTP-Bibliothek auf den Simulatoren soll durch eine deutlich besser funktionierende Variante ausgetauscht werden. Man darf gespannt sein, wie sich das auswirken wird, Linden Lab wird wohl kaum veröffentlichen, was sie da genau nehmen und bisher genommen hatten.

Wer damit nichts anfangen kann: HTTP ist ein Transportprotokoll des Internets, das zur Übertragung von Daten – meistens Webseiten – genutzt wird. Festgelegt wurde HTTP/1.0 in RFC 1945 und HTTP/1.1 in RFC 2616. Eine HTTP-Bibliothek stellt nichts anderes als für Programme aller Art die Transportfunktionen bereit, so dass man sie nicht selber erst implementieren muss. Nachdem HTTP ein alter Hut ist, gibt es heutzutage eine Vielzahl an zur Verfügung stehenden Bibliotheken genau für diesen Zweck.

Eine bekannte Bibliothek dieser Gattung, die neben HTTP noch andere Protokolle beherrscht, ist cURL. Diese wird auch standardmäßig im Second Life Viewer zur Kommunikation mit dem Simulator verwendet. Eine Auflistung mit weiteren Bibliotheken für HTTP-Transport findet sich denn hier.

Gamification – ein Weg auch für den offiziellen Second Life Viewer?

Nirans Viewer macht es mit dem Release 1.36 gerade vor: es ist ein Errungenschaftssystem (Englisch: Achievements) eingebaut, wie man es von moderneren Spielen und MMORPGs kennt. Wie das aussieht, kann man bei Maddy ausführlich bewundern, daher erspare ich mir hier einfach die Screenshots davon.

Zudem ist der Viewer inzwischen offiziell in der TPVD drin, herzlichen Glückwunsch!

Nun ist es ja so, dass nach Rod Humble Linden Lab im Moment genau darauf setzt, was Niran vormacht, nämlich Gamification. Achievementsysteme sind irgendwie das neue Buzzword in der Branche, und werden in Zukunft häufiger vorkommen, als man meint. Selbst so dröge Software wie die Compilersuites von Microsoft sollen Achievementsysteme verpasst bekommen, um die Programmierer zu Entdeckungen und besserer Arbeit zu animieren. Muss also was dran sein, und man kann sich das bei Kleinstweich für umme bereits runterladen!

Niran und Microsoft zeigen, was Gamification bedeuten kann. Nachdem Rod Humble in der Spieleindustrie jahrzehntelange Erfahrung hat, weiß er das auch auf dem Effeff. Die Frage ist daher: wie lange dauert es denn noch, bis auch der offizielle Lindenviewer solch ein System spendiert bekommt? Ist so etwas bei Linden Lab überhaupt bereits in Planung? Denn wenn Linden Lab es ernst mit der Gamification ist, dann wird sich das zu alleerst im Viewer zeigen müssen, wo denn auch sonst!

Linden Lab könnte es sich sogar einfach machen und einfach Nirans Änderungen bei sich für umsonst einbauen, the joy of open source eben! Ob sie das aber machen oder nicht – wir werden sehen. Jedenfalls erwarte ich früher oder später solch ein System auch im offiziellen Lindenviewer, alles andere widerspricht dem neuen Credo der Firma.