onli blogging

Die Import- und Exportfunktion arbeiteten einwandfrei in meinen Tests mit kleinen Beispieldaten, scheiterten aber an der Größe der Datenbanktabellen bei Dirk und YellowLed. Bei Dirk klappte der Export, aber der Import starb mit einem Timeout, bei Yellowled riss der Export die Speichergrenze von 64 MB. Mit der Hilfe der beiden konnte ich beide Fehler - zumindest auf meinem Testsystem - beheben, und ich werde hier beschreiben wie.

Export

Der Export scheiterte an der Speichergrenze, also musste der Speicherbedarf reduziert werden. Es passiert eigentlich nichts anderes, als das mit einem Select die ganze Datenbank abgefragt und diese Daten mittels fputcsv in eine Datei geschrieben werden. Um also den Speicherbedarf zu reduzieren, wird das nun nur noch in Blöcken von 10.000 Zeilen gemacht:

while ($amount > ($start = $runs * 10000)) {
    $sql = "SELECT 
           token, ham, spam, type  
        FROM
           spamblock_bayes
        LIMIT $start, 10000";
    $database = serendipity_db_query($sql);
    
    foreach ($database as $fields) {
        fputcsv($fp, $fields);
    }
    $runs++;
}

Ich bin mir bei Limit immer etwas unsicher, aber da es von sqlite ebenfalls unterstützt wird und in meinem Test so der Export auch bei einer Grenze von 16 MB durchlief, dürfte das eine akzeptable Lösung sein.

Import

Der Import war kniffliger, hier griff ich massiv auf Hilfe von Dirk zurück. Zuerst einmal das bisherige Datenbankschema:

| token (varchar) | ham (int) |spam (int) | type (varchar) |

Er stellte fest, dass Duplikate in der Datenbank waren - zumindest in seiner MySQL-Datenbank. Denn bei ihr ist "hallo" und "Hallo" identisch, in PHP (und sqlite) jedoch nicht, wodurch doppelte Datensätze angelegt wurden. Ein Key, der das verhindert hätte, war nicht vorhanden. Diesen jedoch nun auf token und type zu legen erschien sinnvoll, weil das an sich eine eindeutige Kombination ist und beim Import abgefragt wurde:

$sql = "SELECT 
            token 
        FROM 
            spamblock_bayes
        WHERE 
             token = '$token' AND type = '$type'";

$tester = serendipity_db_query($sql);

if (empty($tester[0])) {
    $sql = "INSERT INTO 
            spamblock_bayes 
                (token, ham, spam, type)
        VALUES('$token', $ham, $spam, '$type')";
} else {
    $sql = "UPDATE spamblock_bayes
        SET 
            ham = ham + $ham,
            spam = spam + $spam
        WHERE token = '$token' AND type = '$type'";
}

Da Duplikate in der Datenbank waren, konnte da kein Key und damit kein Index drübergelegt werden, der die SELECT-Abfrage mit dem WHERE token = '$token' AND type = '$type'"; massiv beschleunigt. Also mussten diese entfernt und danach der Key darübergelegt werden.

Duplikate entfernen

Dirk schlug folgendes Vorgehen vor, das ich allerdings nicht nutzen konnte:

ALTER TABLE serendipity_spamblock_bayes ADD id INT UNSIGNED NOT NULL AUTO_INCREMENT, ADD PRIMARY KEY (id);

select a.id, a.token, a.type from serendipity_spamblock_bayes as a, serendipity_spamblock_bayes as b where a.token=b.token and a.type=b.type and a.id <> b.id;

Das funktionierte auch und hätte die Duplikate geliefert. Aber an der folgenden Stelle scheiterte ich:

Anschliessend summiert man die gleichen Datensätze zusammen: "select sum(ham),sum(spam) where id in (1,2,3,4)" oder gleich als neuer Datensatz "insert into tabelle (token,type,spam,ham) values (wert1,wert2,select sum(ham),sum(spam) where id in (1,2,3,4))" und anschliessend "delete from tabelle where id in (1,2,3,4)".

Ich hatte ein Array voller Duplikate, geordnet nach id oder type oder token. Bei denen hätte ich nun - zumindest verstand ich das so - einzeln heraussuchen müssen, welche zusammengehören, und diese dann wie beschreiben zusammenfügen müssen. Da schon das Select in Dirks Tabelle 5 Minuten dauerte, erschien mir das als nicht in akzeptabler Rechenzeit durchführbar, überhaupt verknotete sich an der Stelle mein Gehirn. Normalerweise hätte ich hier nachgehakt (ergänze mich doch einfach hier, wenn ich einen einfachen Lösungsweg schlichtweg nicht sah), aber ich stolperte nebenbei über eine alternative Lösung (die er ebenfalls erwähnt hatte), die direkt funktionierte.

Diese Lösung lautet: Nutzung einer temporären Tabelle und von ON DUPLICATE KEY UPDATE. Beim Update auf die neue Version des Plugin wird eine temporäre Tabelle angelegt, die bereits den Primary Key auf token und type hat. In diese werden der bisherige Dateninhalt inserted. Dabei werden die Konflikte auftreten, doch dank ON DUPLIKATE KEY kann MySQL darauf reagieren:

INSERT INTO 
    spamblock_bayes_temp 
        (token, ham, spam, type) 
    SELECT 
        orig.token, orig.ham, orig.spam, orig.type 
    FROM 
        spamblock_bayes as orig 
ON DUPLICATE KEY UPDATE 
    ham = spamblock_bayes_temp.ham + VALUES(ham), 
    spam = spamblock_bayes_temp.spam + VALUES(spam);

Danach wird die originale Tabelle gedroppt, mit dem Key neu erstellt und die alten Daten da hineingesetzt.
Bei sqlite oder anderen Datenbanken wird stattdessen wie oben gezeigt mit einem Tester gearbeitet.

Der Import selbst

Das Vorgehen beim Import selbst wurde äquivalent angepasst. Statt da wie oben gezeigt mit einem Select einen Tester zu holen und je nach dem zu inserten oder upzudaten, wird dort ebenfalls erstmal inserted und bei einem Konflikt mit einem ON DUPLICATE KEY UPDATE reagiert. Das löste bei mir das Problem, das das Importieren der 22000 Zeilen langen CSV-Datei aus Dirks Blog der Import länger als 10 Minuten dauerte. Das geht auf meinem Testsystem nun in 30 Sekunden.

Ich war jedoch ehrgeizig und schaute mir an, wie das ganze mit sqlite gehen könnte. Denn dort gibt es kein ON DUPLICATE KEY UPDATE. Aber es gibt ein INSERT OR IGNORE. Damit kann man ein Insert durchführen, wobei ein Fehler einfach ignoriert wird. Das Vorgehen ist dort also, erst immer zu inserten mit Wert 0 für spam und ham und direkt danach mit einem Update den Wert zu setzen. Ich war etwas stolz, so eine schöne Lösung gefunden zu haben, stieß den Import an - und wartete, wartete, wartete...
Als nach einer halben Stunde das immer noch nicht fertig war suchte ich nach Performance-Tipps für sqlite. Dabei stieß ich auf den Hinweis, man solle unbedingt Transaktions nutzen, selbst wenn man nur eine Datenbank liest - das Plugin schreibt, sollte sie also auf jeden Fall nutzen. MySQL scheint das von selbst ordentlich zu machen, sqlite (sqlite 2, warum auch immer nicht automatisch von PHP unter Ubuntu 10.04 das installierte sqlite 3 genutzt wird) nicht. Also ein

serendipity_db_begin_transaction();

vor den Code und ein

serendipity_db_end_transaction(true);

dahinter, und schon lief der Import in 40 Sekunden.

Vielleicht sind das keine Spitzenzeiten und es geht noch mehr, aber es sind Verbesserungen um (mehr als) 1500%. Daher ist das Update nun hochgeladen, um Export und Import überhaupt erstmal zu ermöglichen. Wie immer gilt: Sollten Probleme auftauchen, bitte melden.

Download: serendipity_event_spamblock_bayes-0.3.9.1.tar.gz

YellowLed hat explizit danach gefragt und auch Dirk hatte so etwas in groß mal vorgeschlagen, daher liefert das neue Update für das Spamblock-Bayes-Plugin eine Import- und eine Exportfunktion nach. Mit diesen kann der gesamte Inhalt der Datenbank in eine CSV-Datei gespeichert und wieder in einen Blog geladen werden.

So etwas könnte man auch direkt über einen Datenbank-Dump machen, aber der Weg über die CSV-Datei vereinfacht das natürlich. Außerdem funktioniert das etwas anders: Die CSV-Datei wird mit dem bestehenden Datenbankinhalt kombiniert.
In der Datenbank stehen die Einträge in folgender Form:

|token| |ham| |spam| |type|
casino    2    100    body

Das Beispielwort casino kam - im Textteil - 2x in validen Kommentaren und 100x in Spamkommentaren vor. Beinhaltet nun eine andere Datenbank und damit die von dort importierte CSV-Datei diese Zeile

casino 100 100 body

Dann wird das zusammengemischt, also

casino 102 200 body

Klingt und ist einfach, ist aber auch wichtig zu wissen, dass über die Importfunktion die Datenbank eben nicht einfach überschrieben wird.

Download: serendipity_event_spamblock_bayes-0.3.9.tar.gz oder über Spartacus.

Seven Kingdoms war mein erstes richtiges PC-Spiel. Gut, das allererste war wahrscheinlich Sokoban an irgendeinem fremden Rechner, aber Seven Kingdoms war das erste, was ich wirklich am heimischen Rechner für lange Zeit spielte. Ich habe ewig gebraucht, um die Steuerung zu durchblicken, und auch einige Spielkonzepte wurden mir erst später klar, aber ich fand es schon damals toll und finde es immer noch großartig.

Dieses Spiel ist inzwischen unter der GPL freigegeben und für Linux portiert worden. Ich habe es unter Ubuntu 10.04 mit dem nouveau-Treiber getestet, läuft problemlos (auch unter Windows XP läuft es stabil). Es gibt sogar ein .deb: 7kaa_2.14.1-i386.deb.

Vorher die Abhängigkeiten libsdl1.2debian-all und libopenal1 installieren, dann das .deb. Nun nur noch das Spiel starten per

cd /var/games/7kaa
./7kaa

7kfans scheint die Anlaufstation für weitere Informationen zu sein.

Politiker von Union und SPD wollen die Möglichkeiten zur Überwachung der Telekommunikation verbessern: Sie plädieren für die Vorratsdatenspeicherung. Das Bundesverfassungsgericht hatte die bisherige Regelung zur Vorratsdatenspeicherung im März gekippt. Seither dürfen Telefon- und Internetdaten nicht mehr ohne Grund sechs Monate lang gespeichert werden. Die Union drängt auf eine baldige Neuregelung,...

So wird wenigstens klar, was der ganze Unsinn der herbeigeredeten Bedrohung soll: Speicherung der gesamten Kommunikation plus Vollzugriff der Nachrichtendienste. Nein, das verhindert natürlich null Terroranschläge - aber es sichert die Macht einer Politikerkaste, die sich immer weiter gegen das Volk stellt.
Diese offene Einrichtung einer Vollüberwachung (die VDS in jetziger Form ist nur der Anfang) zugunsten der Staatssicherheitsdienste bestätigt letzteres nochmal.

Zumindest fast 100 Tage: Am 13.02.2011 wird in Dresden wieder der jährliche Naziaufmarsch stattfinden, der das letzte Mal erfolgreich blockiert wurde. Damals war ich dabei, diesmal kann ich das noch nicht sicher sagen.

Wäre bestimmt wieder eine gute Sache.

Martin hat bereits eine Erklärung zu den Unterschieden zwischen X und Wayland verfasst und dabei auch erklärt, was das schlussendlich bedeutet. Im Grunde gelungen, fand ich mich danach doch nach weiteren Erklärungen suchen. Ich fasse hier zusammen, was - soweit ich es verstanden habe, das hier ist nicht mein Gebiet - nun der Unterschied zwischen X und Wayland ist. Dafür stelle ich beide Modelle gegenüber und freue mich über Korrekturen.

Auf der Waylandseite findet sich eine gute Erklärung der Architektur, mit Diagrammen, die ich hierfür mal übernehme.

XServer jetzt

Das ist im Grunde nicht zu kompliziert. Das Diagramm zeigt, wie auf ein Input-Event (z.B. ein Mausklick) reagiert wird. Der XServer wird von evdev benachrichtigt, danach benachrichtigt der XServer die Clients (also die registrierten Programme, die das Event betrifft, also z.B. das Fenster, auf das geklickt wurde), um dann - und das ist der zusätzliche Schritt um den es geht! - den Compositor zu benachrichtigen, damit über ihn die Oberfläche neu gezeichnet wird, der dann nochmal unnötigerweise den XServer benachrichtigt.

Beim Compositor wird anders als bei X eine Textur statt einer pixmap erstellt. Hier entstehen ggf. die Effekte, wie man sie durch Compiz kennt, und dabei wird die Grafikkarte genutzt. Ein Compositor muss nicht selbst ein Fenstermanager sein - Compiz und Metacity sind beides, xcompmgr ist nur ein Compositor. Daher kann letzterer auch mit normalen Fenstermanagern wie Fluxbox oder IceWM kombiniert werden, wobei inzwischen wohl eher diese Nicht-Compositoren als Fenstermanager die Ausnahme sind.
Metacity und Compiz sind die Fenstermanager und Compositoren, die von Ubuntu genutzt werden, Metacity für keine und einfache Effekte, Compiz wenn man die erweiterten aktiviert (zumindest war das so, ich hoffe, hier hat mich nicht die Enwicklung überholt).

Wayland dann

Wayland ersetzt den XServer bzw - wichtiger - vielmehr das zugehörige Protokoll (Wayland ist kein echter XServer, auch wenn das bei Golem so steht!) und ist gleichzeitig selbst ein Compositor. Das input-Event geht zum Wayland-Compositor, zu den Clients, von denen zurück zum Wayland-Compositor. Das spart den Schritt, nach der Kommunikation zwischen Clients und Server nochmal den Compositor zwischenzuschalten.

Das muss so zwar nicht sein - aber es wäre denkbar, dass tatsächlich eine Art WaylandServer Standard wird, der dann von den Compositoren genutzt wird - oder dass die dessen Compositor ersetzen. Nach dieser Option sieht es derzeit aus, also dass der Compositor des WaylandServers von z.B. Compiz ausgetauscht wird (Danke, Martin). Wichtig wird es demnach sein, zwischen dem Protokoll Wayland und der Software Wayland (was ich hier mit dem unzutreffenden Begriff WaylandServer versucht habe) zu unterscheiden.
Denkbar ist nämlich auch, zumindest so wie die Architektur momentan erklärt wird, dass es den großen zentralen Server für alle Clients so nicht mehr geben wird - immerhin könnte auch Firefox (so das Beispiel des Compiz-Entwicklers) zum Compositor werden und sich selbst zeichnen. Das wäre eine fundamentale Abkehr vom zentralen Client-Server-Modell, wie wir es derzeit haben.

Also, der Unterschied zwischen heute und morgen wäre: Ersetzung der Software XServer und des Protokolls X Window System (=X11) durch das Protokoll Wayland, wobei bei Wayland der Compositor sein eigener Server ist (wie das dann praktisch aussieht wird sich zeigen).

XServer dann

Interessant ist noch die Frage, wie der Umstieg zustande kommt. Wahrscheinlich wird lange dieses Bild bestimmend sein, und das wäre wohl eher schade:

Der XServer, der Wayland-Events bekommt statt direkt Input-Events, würde all die Anwendungen verwalten, die noch X- statt Wayland-Clients sind.

Mir ist allerdings nicht ganz klar, was alles umgeschrieben werden müsste, um dieses Szenario zu vermeiden. Sicher alle Fenstermanager, alle Toolkits (wie GTK); aber auch Anwendungen können derzeit direkt XLib benutzen. Ich habe das z.B. mal bei einem Musikplayer getan, um damit global Tastenkombinationen abzufangen und ihn so zu steuern. Wie aufwändig der Umstieg für die Linuxwelt als Ganzes wäre hinge demnach davon ab, wie verbreitet solche Verhaltensweisen sind und wie gut und einfach die Möglichkeiten, diese Wayland-kompatibel zu ersetzen.

Ein wunderbares Beispiel für misslungene Kommunikation und absurde Pläne findet sich derzeit bei Jagged Alliance 2 - Reloaded (via). Angekündigt war:

Mit Jagged Alliance 2 - Reloaded erscheint im nächsten Jahr der mehrfach preisgekrönte Klassiker in neuem Gewand. ... Jagged Alliance 2 - Reloaded greift das bewährte Spielprinzip auf und verbessert es dort, wo es notwendig erscheint. Dabei wird es aber an der beliebten Kombination aus rundenbasiertem Strategiespiel mit Rollenspiel-Elementen festhalten.

Also sollte es ein echtes Remake werden, mit besserer Grafik und Komfortfunktion. Man beachte auch das wunderbare "wo es notwendig erscheint", mit dem schön vermieden wird zu behaupten, dass Verbesserungen am Kultspiel notwendig seien.
Im zur Webseite gehörenden Forum stellte man den Fans dann diese Frage:

We would love to receive your suggestions and ideas for a modern, turn-based combat system.

What do you think a modern version of such a combat system should look like? What is wrong with the existing JA2 combat system, what annoys you about it and what must be retained without fail?

Auffällig ist die Fragerichtung, denn sie enthält zwei. Zum einen wird konkret nach Vorschlägen für rundenbasierte Kämpfe gefragt, also: "Wie kann man das bestehende System kleinschrittig verbessern?". Dann aber wird negativ gefragt, "was ist falsch", "was nervt". Da hätte man durchaus misstrauisch werden können, denn so fängt man an, einen Wechsel zu begründen.

Die Fans wurden nicht misstrauisch. Auf 11 Seiten diskutierten sie und fanden auch viele Verbesserungspunkte - Zusatzfunktionen wie um die Ecke gucken, die KI sollte weniger leicht auszutricksen sein, Umstellung auf 100 statt 35 AP und generell die Funktionen der beliebtesten Mods. Wie fast jede Forendiskussion artete auch diese zwischendurch aus in einen erbitterten Kampf, hier um die Vorzüge des bestehenden IGOYOUGO (also echter rundenbasiertheit) und IPLANYOUPLANWEGO (gemeinsam planen, ausführen und dann wird geguckt, was passiert) - da das erste System klar überlegen ist und das zweite das Spielgefühl komplett verändern würde und praktisch kaum durchzuführen ist wurde die Diskussion aber eindeutig entschieden. Alles in allem eine sehr konstruktive Diskussion, aus der man als Entwickler viel ziehen könnte.

Die ganze Zeit über beteiligte sich keiner der Entwickler. Um dann schließlich dies zu schreiben:

..., we will simply make a few changes to the existing JA2 combat system. We are calling the new combat system the “Plan & Go” system. It is based more on real time, and represents a departure from the original combat system in Jagged Alliance 2.
... we have omitted the “Fog of War” ...
... removes the turn-based structure. ...
And I can tell you that we had a lot of discussions here especially on the combat sysetm as we know that it's the "secret cow" of the game. (Anm.: kursive Hervorhebungen von mir)

Ein Schlag ins Gesicht der Diskutanten vorher. Keine ihrer Ideen wurde aufgegriffen, wichtig war nur die interne Diskussion, die vorherige Ankündigung was mit dem Lieblingsspiel dieser Leute gemacht wird wird gebrochen und statt des originalen Systems wird ein (vll besser verkaufbares) Mainstreamsystem eingefügt. Das bricht natürlich mit allem, was erwartet war.

Das größte Problem ist nicht das neue System selbst, sondern die Art wie es eingeführt wird - entgegen den vorherigen Versprechungen und ohne sich an der selbst angestossenen Diskussion zu beteiligen. Es wäre ehrlich gewesen, die scheinbar bestehenden Vorbehalten gegen das System zu benennen und direkt nach ihnen zu fragen, aber dazu war man seitens bitComposer wohl nicht in der Lage. Stattdessen ändert man - "einfach so" auch noch, in eigenen Worten, "simply"! - das Kernelement des Spiels. Außerdem wird klar kommuniziert, dass die Entscheidung gelaufen ist - der "Fog of War" ist entfernt statt wird entfernt werden, die Diskussion zwischen "uns" war hitzig (aber ist vorbei) und generell statt in dem Text sehr oft "we have" - wie um klarzumachen, dass bitComposer entscheidet, nicht die Fans. Pure Provokation.

Lustig sind auch die Begründungen für den Wechsel, denn sie müssen eine weitere Beleidigung für die Fans darstellen:

To ensure that ... the remake is as attractive as possible to players who know the Jagged Alliance series and to those who have yet to play it, ...
In addition, the world looks much more animated and lively as the hostile forces patrol in the meticulously detailed 3D backdrops. ...
The real-time elements in the “Plan & Go” system also add new and exciting features such as “Timing” for example. ...
The new system also allows us to incorporate new AI functions such as cutting off and flanking enemies, that only work when actions are carried out simultaneously and not one after the other.

Ziel der Umstellung ist es also, neue Käufer zu gewinnen - klar wollen die viele Kopien verkaufen, aber man braucht den Fans nicht so unter die Nase reiben, dass man ihr Lieblingsspiel verändert und verkauft. Bei einer Umstellung der Zielgruppe fühlen sich die alten Fans immer verraten. Dass die Entfernung der Sichtlinien grafisch besser aussähe und dies damit zu rechtfertigen muss für einen beinharten Strategen so sein, als würde man einem Karatekämpfer Ballet durch den Hinweis schmackhaft machen wollen, dass das Tutu doch so schön aussähe. Das hört sich nach dem Gelaber eines PR-Fritzen an.
Und dann kommt noch die wirklich falsche Behauptung, dass bei dem alten System Timing keine Rolle spiele und dass nur mit dem neuen die KI strategisch flanken könne. Da frage ich mich als Informatiker dann schon, wie man auf so einen Gedanken kommt und was das über die Fähigkeiten der Entwickler aussagt. Natürlich kann eine simple reaktive KI das nicht, aber das hat mit dem System nichts zu tun. Flanken braucht keine Gleichzeitigkeit, sondern Planung.

Damit das deutlich gesagt wurde: Ich bin keiner der absoluten Fans von JA2. Ich mochte das Spiel, ja, aber weder ist es mein Lieblingsspiel noch habe ich mich an der Diskussion beteiligt. Trotzdem sehe ich hierin ein gutes Beispiel, wie man als Entwickler keinesfalls mit den Spielern umgehen darf:

1. Wenn man eine Kultserie kapert und die Beibehaltung ihrer Kernelemente verspicht, hält man sich daran.
2. Sowieso ist das Kapern von Kultserien schwierig und Bedarf größter Sorgfalt. Will man etwas neues machen, ändert man besser den Namen in eine Anlehnung ("The Jagged Edge").
3. Diskussionen mit den Fans starten und dann komplett zu ignorieren geht nicht. Zum einen sollte man sich beteiligen und die Diskussion lenken, wenn man auf etwas bestimmtes hinauswill. Zum anderen sollte man nicht die Anmerkungen der Fans komplett ignorieren. Dann besser gar nicht erst fragen.
4. Nie, wirklich niemals eine solche kritische Entscheidung mit offensichtlich falschen Behauptungen stützen. Aber das gilt wohl immer.

Mir wurde über einen alten "Anarchy Online"-Account ein Betakey für Bloodline Champions zugeschickt. Das ist ein kleines Arenakampfspiel. Der Spieler steuert einen kleinen Champion, der im Team gegen andere Champions spielt. Anders als bei LoL, mit dem es ansonsten nicht nur grafisch durchaus Ähnlichkeiten hat, sind auf den Karten keine Monster und der Champion steigt auch keine Level auf oder trägt Items. Es ist einfach ein Arenakampf zwischen zwei Gruppen.

Es gibt nicht nur das Deathmatch als Spielmodi, sondern auch eine Art "Capture the Flag" und ein "King of the Hill" - wobei ich letzteres mit echten Menschen noch nicht spielen konnte, da keine Spieler den Server jointen. Ein Matchmakingsystem ist auch sofort zugänglich, was allerdings sofort zu bewerteten (gerankten) Spielen führt. Als unerfahrene Spieler waren unsere Gegner jeweils stärker, aber wir nicht immer chancenlos. Das machte also einen guten ersten Eindruck, aber ob es die richtigen Faktoren zur Speilstärkebestimmung nimmt ist noch zu testen. Wir hatten den Eindruck, nach ein paar Testspielen untereinander ungerechtfertigt hoch eingeschätzt zu werden.

Bisher waren die Spiele aber durchaus spaßig. Es ist allerdings ein kleines Spiel, Vollpreis dafür zu verlangen wäre übertrieben. Die Community kann ich nicht einschätzen, wir sind natürlich direkt im ersten Spiel an Leute geraten, die unentwegt beleidigten - dagegen scheinen bisher auch wenige Mechanismen zu existieren. Zwar steigt wie in LoL der Spieler selbst im Level auf, aber ohne vergebbare Meisterschaftspunkte und prominente Meldefunktion wird dadurch der Account scheinbar nicht wichtig genug, um sich zu benehmen.

Die Fähigkeiten der Champions erfordern es nahezu alle, selbst zu zielen, das macht das schnelle Spiel durchaus fordernd und interessant - ob es am Ende etwas Geld wert ist und ob es uns motivieren kann, es weiterzuspielen (bisher habe ich es mit Freunden nur etwas angespielt) bleibt abzuwarten.