Nach guten JavaScript-Prinzipien arbeitend, möchte ich natürlich nicht den globalen Namespace verschmutzen. Ich führe nur zwei Globals ein: Game und Phlame. Phlame ist das Framework, das ich baue. Grundlegende Abstraktionen werden dorthin ausgelagert. Bisher ist es nur eine Vorgabe für das MVC-Pattern, welche Klassen in Zukunft dorthin ausgelagert werden, habe ich noch nicht festgelegt. Wahrscheinlich wird dort auch die grundlegende Kommunikation mit dem/n Server/n abgelegt.

Ordnerstruktur:

/cfg Konfigurationsordner, ermöglich einfache Modifikationen am Spiel
/lib Library
    /Phlame Dateien des Phlame-Frameworks
    jquery.js
    ...
/style Aussehen des Spiels: Bilder, Cascading-Style-Sheets
/lang Sprachdateien
    /de
/src Source des Spiels
    /clientside
        /views
        ...
    /serverside
        ...
    ...
/spec jspec Tests
index.html Startseite
game.html Spielintern
admin.html Adminintern (externer Login)

Dateistruktur (Beispiel einer View):

(function() { // module pattern

//import
var $ = jQuery;
var View = Phlame.views.View;

//class or object declaration
function SolarsystemView(args) {
    View.apply(this); // inheritance
    var privateVar;

    this.priviledgedMethod = function() {
         // do something with privateVar
    };
}
//prototype inheritance
SolarsystemView.prototype = new View();
SolarsystemView.prototype.commonMethod = function() {
    // "this" available, but no privateVar(s)
};

//export
Game.views.Solarsystem = SolarsystemView;

})(); // end closure (module pattern)

Wie zusehen, verwende ich keinen Sugar für Klassendeklaration und Vererbung, weil ich finde, dassdiese Schreibweise nicht viel umständlicher ist und man so näher an der Natur von JavaScript arbeitet. Den einzigen Sugar, den ich mir leiste sind ECMA-262-3 Funktionen Object.prototype.create() und Function.prototype.bind().

Nachdem ich mich jetzt während des Sommers mit Objektorientierung, Softwarearchitektur und Entwurfsmustern beschäftigt hatte, suchte ich auch in JavaScript nach Mustern und Best Practice, und  nun möchte ich diese Erfahrungen auf meinem Blog teilen.

Vorab sollte erwähnt werden, dass JavaScript in mehreren Aspekten eine besondere Sprache ist. Es wird nicht umsonst geschmäht aufgrund unerklärlichen Verhaltens. Man sehe sich nur mal wtfjs an! Dennoch ist JavaScript auch sehr mächtig als objektorientierte Sprache. Closures und Prototypen sind recht unbekannt in der sehr von Java geprägten objektorientierten Welt. Die Umgewöhnung kann schwer fallen, auch ich hatte da meine Probleme. Zum Glück gibt es zum Beispiel Videos von Douglas Crockford auf YUI Theater, die einem helfen einen Einstieg zu finden.

Ich möchte nun hier zwei Funktionen vorstellen, die es auch in die neue ECMAScript Spezifikation geschafft haben: Function.prototype.bind und Object.create. Beide lassen sich mit einigen Tricks auch auf dem momentan verbreiteten JavaScript verwenden, bei Frameworks gehören sie zum Grundrepertoire.

Viel kann ich noch nicht zu prototypenbasierter Programmierung sagen, da ich selbst noch nicht ganz auf den Trichter gekommen bin, trotzdem habe ich schon Anwendungen gefunden und ziehe Nutzen in meinem sonst noch recht klassenbasierten Stil.

Object.create

if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

Diese schöne Funktion erzeugt ein Objekt auf Basis eines anderen Objekts, welches zum Prototypen wird. Vorsichtig muss man sein, wenn man lokale/private Variablen im Prototypen verwendet, da sich die beiden Objekte diese teilen. Der Prototyp sollte also ein neues Objekt sein, dass sonst nicht genutzt wird, oder die vermeintlichen Methoden müssen neu initialisiert werden, wie ich es in vorigem Blogeintrag mit dem aufrufen eines Konstruktors mache.

Ich möchte das Beispiel auch nochmal aufgreifen, wobei ich mittlerweile nochmal refaktorisiert habe.

Resource.prototype.create = function(newAmount) {
    var newResource = Object.create(this);
    Resource.call(newResource, newAmount, this.getType());
    return newResource;
};

Mit dieser Methode ist es möglich Objekte der selben Resource anhand einer vorliegenden zu erstellen. Theoretisch könnte ich diese Methode auch clone() nennen, da ich aber gleichzeitig das neue Objekt initialisiere, behalte ich den namen der Basisfunktion – create(). clone() lässt sich damit aber recht leicht verwirklichen, man muss nur die Eigenschaften vom alten Objekt übergeben.

Resource.prototype.clone = function() {
    return this.create(this.getAmount());
}

Schön, jetzt habe ich ein paar tolle neue Möglichkeiten Objekte zu erzeugen, was soll das nun?
Unter den Entwurfsmustern gibt es eine Untermenge: Creational Patterns, Muster zur Konstruktion. Einige Muster, die sich mit verschiedenen Möglichkeiten der Konstruktion von Objekten beschäftigen. Alle vermeiden die Konstruktion mittels “new <Klassenname>”, weil dies (unter anderem) zu statisch ist.
Wenn ich ein Objekt mit einer create() Methode übergebe, dann übergebe ich gleichzeitig die Möglichkeit ein neues Objekt des selben Typs zu erstellen, ohne mich explizit an den Typ zu binden. Die Konstruktion ist dynamisch. Aus diesem Grund kann ich auch leicht Vererbung anwenden ohne danach meinen ganzen Code nach “new <Elternklassenname>” durchsuchen zu müssen.

Function.prototype.bind

if (typeof Function.prototype.bind !== "function") {
    Function.prototype.bind = function(context) {
        if (arguments.length < 2 && typeof arguments[0] === "undefined") {
            return this;
        }
        var method = this, args = Array.prototype.slice.call(arguments, 1);
        return function() {
            var a = merge(args, arguments);
            return method.apply(context, a);
        };
    };
}

Den Code dieser Funktion habe ich mir aus dem Prototype Framework geholt und von Abhängigkeiten befreit. Jede Funktion und insbesondere Methode ist ab jetzt mit der Funktionalität ausgerüstet, unabhängig von ihrem Objekt gemacht zu werden.
Schonmal das probiert?

var func = someObject.someMethod;
func();

Das geht schwer in die Hose wenn someMethod “this” verwendet, “this” is dann nämlich “window” – eine der Freuden an JavaScript.
Stattdessen verwendet man besser:

var func = someObject.someMethod.bind();

Theoretisch kann man auch bereits Parameter mitgeben.
Diese Funktion findet häufig Verwendung, wenn man bei AJAX oder Effekten Callbacks übergibt und spart jedes Mal manuelles Umwickeln mit einer anonymen Funktion.

Die Tiefe von Patterns habe ich mit diesem Artikel wohl nicht erreicht, aber ich hoffe er ist trotzdem einigen Leuten hilfreich. Die vorgestellten Funktionen würde man wohl als Sugar (“Zucker”) bezeichnen.

Gleichzeitig handelt es sich um das Muster Wertobjekt (ValueObject), welches unveränderlich ist.

Vorweg muss noch gesagt werden, dass alle Attribute als Konvention protected gelten, public wird nicht benötigt und private lässt sich über Closures realisieren. Einfache Attribute tragen zudem den Anfangsbuchstaben ihres Typs (z.B. s für String).

Objekte der Klasse stellen eine Menge eines Rohstoffs dar.

/**
 * Represents an amount of a resource
 * @param {number} amount
 * @param {string} type
 */
function Resource(amount, type) {
    var nAmount = amount;
    var sType = type;

    if (amount < 0) {
        throw new IllegalArgumentException("amount has to be positive");
    }

    /**
     * @method Resource
     * @return {number} amount of the resource
     */
    this.getAmount = function() {
        return nAmount;
    };

    /**
     * @method Resource
     * @return {string} resource type
     */
    this.getType = function() {
        return sType;
    };
}

/**
 * Addition of two resources produces a new resource with the sum amount
 * the new object uses the old one as prototype
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.plus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    var newRes = Object.create(this); // create a new object based on the current one
    // execute the Resource constructor on it
    Resource.call(newRes, this.getAmount() + resource.getAmount(), this.getType());
    return newRes;
};

/**
 * Subtraction of two resources produces a new resource with a smaller amount
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.minus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    if (this.getAmount() < resource.getAmount()) {
        throw new IllegalArgumentException("can't substract a higher amount");
    }
    var newRes = Object.create(this);
    Resource.call(newRes, this.getAmount() - resource.getAmount(), this.getType());
    return newRes;
};

Interessant ist vor allem die Stelle, an der dynamisch neue Objekte der selben Klasse zurückgegeben werden (plus() und minus()), ich möchte Resource noch erweitern können und evtl. für die verschiedenen Rohstoffsorten eigene Klassen ableiten, daher sollten diese Methoden dann nicht nach einer mathematischen Operation auf die Klasse Resource zurückschrumpfen. In PHP kann man “new” einfach einen String übergeben, in Java muss man einen Umweg über eine Factory oder Reflection machen.

In JavaScript bietet es sich an, das momentane Objekt als Prototyp für das neue zu verwenden und dieses durch den Resource Konstruktor zu initialisieren.

Ich weiß noch nicht, ob mir dieses Pattern noch öfter begegnen wird, aber vor allem bei Wertobjekten (ValueObject), die mit Vererbung erweiterbar bleiben sollen ist dies praktisch. Allgemein wenn man ein neues Objekt des selben Typs wie das momentane zurückgeben möchte.

Jetzt kann ich eine Kindklasse ResourceContainer schreiben, die noch Funktionalität für Gewicht und Volumen des Rohstoffs bereitstellt (z.B zum Beladen von Schiffen):

/**
 * stores resources, adds weight and volume to a resource object
 * @inherits Resource
 * @param {Object} amount
 * @param {Object} type
 */
function ResourceContainer(amount, type) {
    Resource.call(this, amount, type); // inherit priviledged Resource methods
}
ResourceContainer.prototype = Object.create(Resource.prototype); // inherit nonpriviledged Resource methods

Resource.DESITY.metal = 7.85;
Resource.WEIGHT.metal = 1000;

/**
 * @return {number} weight of the resoure amount
 */
ResourceContainer.prototype.getWeight = function() {
    return this.getAmount() * Resource.WEIGHT[this.getType()];
};

/**
 * @return {number} volume of the resource amount
 */
ResourceContainer.prototype.getVolume = function() {
    return this.getAmount() * Resource.DENSITY[this.getType()];
};

Ich beginne langsam die Prototypennatur von JavaScript zu verwenden, bin aber immer noch sehr von Klassen von PHP und Java geprägt.

Zuerst suche ich eine geeignetes Test-Framework, am besten BDD getrieben. Für JavaScript wimmelt es nur so von solchen Frameworks: Screw.Unit, jsspec, jspec, inspec etcetc. PHP bietet genau eines: PHPSpec, dessen Projekt vor über einem Jahr eingeschlafen ist. So bleibt nur noch PHPUnit, welches nicht wirklich BDD zulässt.

Okay, also mache ich mich daran meine IDE einzurichten und ein paar Klassen anzulegen. Netbeans stellt sich aber als sehr schwachbrüstig heraus, was Refaktorisieren in PHP angeht. Die Java Aufgaben für die Uni habe ich mit Eclipse gelöst, daher ist das mein nächster Anlaufpunkt. Naja, Eclipse ist auch nicht viel besser, aber moment, da gab es doch Zend Studio für Eclipse, das mich früher schon mehrfach enttäuscht hat, als es nach Version 5.5 mit Eclipse vereint wurde. Mittlerweile ist es allerdings in Version 7.1 und bittet seine Nutzer doch von 5.5 umzusteigen. Gut, denke ich mir, vielleicht ist es wirklich besser geworden.

Fehlanzeige, Zend geht seit Version 6.0 den Bach runter, die neue Version untstützt nichteinmal Drag and Drop von Text im Editor, ohne das kann ich einfach nicht arbeiten. Wieder runtergeschmissen (das dritte Mal, ich glaub nicht, dass ich das so schnell wieder versuche).

Nun steh ich da, mit dickem Hals auf PHP. Je mehr ich darüber nachdenke finde ich nur Nachteile, weil ich an PHP festhalten will, um irgendwann einmal eine Referenz zu haben und das Spiel auf jeden Webspace klatschen zu können. Nun, das muss nicht sein, wieso all diese Schwierigkeiten in Kauf nehmen, nur um dann einen Haufen Kinder am Hals zu haben die mit der Objektorientierung nicht klar kommen.

Wenn ich mich jetzt gegen PHP entscheide stehen mir plötzlich alle Möglichkeiten offen: Python, Java, … Aber ich weiß etwas besseres:

JavaScript serverseitig! Damit muss ich auch nicht mehr Code duplizieren wenn ich reiche Funktionalität im Browser haben will, weil ich die gleichen Scripte, die auf dem Server laufen, auch im Browser laufen lassen kann (gut, mit ein paar Feinheiten), trotzdem ist das viel besser, als den Code in PHP und JS duplizieren zu müssen.

Nun habe ich die Wahl, JavaScript serverseitig ist mittlerweile mit einigen verschiedenen Grundsystem möglich. Aptana Jaxer bietet sich an, da ich die IDE bereits für JavaScript nutze. CouchDB wäre mal ein interessanter Ansatz.

Insgesamt wird das ganze um einiges Noob-feindlicher, was aber sowieso schon zur Debatte stand.

Weitere Infos kommen, sobald ich mich entschieden habe.

Edit: Ich habe den Artikel eine Woche zurückgehalten, um nicht irgendwelche voreiligen Entscheidungen in den Raum zu stellen.

Seitdem wurde ich weiter enttäuscht: Mein Favorit Aptana Jaxer scheint nicht mehr wirklich gepflegt zu werden – in der IDE lässt es sicht nicht mehr installieren, auf der Aptana-Seite ist es verschwunden und auf jaxer.org sind bereits einige Links tot. Schade, das Projekt sah vielversprechend aus.

Alternativen gibt es zum Glück genug, bisher sieht Myna am vielversprechendsten aus. Ich habe die Entscheidung allerdings ein wenig verschoben und schreibe vorerst die Clientseite und verlagere danach Elemente nachträglich auf den Server.

Insgesamt beabsichtige ich einen sehr fließenden Ablauf im Browser zu erreichen. Die Ajaxabfragen werden dann im Hintergrund ausgeführt, nach Möglichkeit unabhängig von der momentanen Aktion des Users, damit es nicht zu Wartezeiten kommt.

Lebt UGamela noch? Fragen sich viele. UGamela wird noch sehr lange leben, denn viel zu viele Browsergameprojekte haben den UGamela Source als Basis verwendet. Selbst OpenSource wird ein Zweig von UGamela weiterentwickelt: XNova. Gut, ob das wirklich Entwicklung ist, darüber könnte man sich jetzt streiten…

Für mich, und damit das ganze german UGamela Projekt, war das Jahr von meinem Abitur, Ferien und meinem Studienbeginn bestimmt. Code wurde nicht viel geschrieben, dafür habe ich mich auf professionelles Niveau, was Objektorientierung angeht,  gebildet und einen guten Stil in JavaScript gelernt. Mittlerweile kenne ich auch noch andere Sprachen und weiß Vorteile von PHP und JS zu schätzen. Ich habe auch einige Techniken gelernt was allgemein Softwareentwicklung angeht und hoffe, dass ich in der Lage sein werde ein Opensourceprojekt zu leiten.

Mit einem Release rechne ich trotzdem nicht vor einem Jahr.

Alles weitere weiterhin auf diesem Blog!

Soviel zu meinem Studium, freizeitlich beschäftige ich mich weiter mit UGamela bzw. der Phlame Engine. Nach “Entwurfsmuster” habe ich “Patterns of Enterprise Application Architecture” begonnen zu lesen und einige Muster wieder erkannt, auf die ich auch schon gekommen war. So handelt sich meine Idee um einen Mapper für DomainModels (das was ich ursprünglich Phlame genannt hatte, mangels eines beschreibenden Namens [siehe Entwurf Nr.3]), das ganze kann man dann auch “Unit of Work” nennen. Diagramme dazu kommen irgendwann demnächst, spätestens zum Release für die Dokumentation.

Dazwischen habe ich viel in einer Wiki gelesen und allgemein viel über Softwareentwicklung und Entwurfsmuster gelernt. Zudem habe ich ein wenig in der Abteilung in der Bibliothek gestöbert und einige Bücher überflogen. Nun lese ich gerade ein Buch über Testgetriebene Entwicklung und versuche mir diese Strategie anzueignen, wie auch schon im letzten Post beschrieben.

Wie geht es nun mit dem Code voran? Ich habe gerade Relationen zwischen DomainModels implementiert und werde nun einige Tests durchführen bevor ich mich weiter dem JavaScript-Front-Backend widmen kann um dann endlich Spielinhalt schreiben zu können.

Ich habe mich entschieden nach diesem bewährten Schema vorzugehen. Dabei arbeite ich mich gerade in das schreiben solcher Tests ein. Die Schwierigkeit besteht darin, die richtigen Tests zu schreiben. Diese Tests können dann während der Entwicklung immer wieder verwendet werden um den Code zu prüfen. Ich werde dafür Tests mit PHPUnit sowie JSUnit schreiben, denn mittlerweile bin ich mir sicher, dass beide Parts ähnlichgroße Komplexität erreichen werden.

Warum? Weil diese bewährte Strategie mir hilft Fehler früh zu erkennen und spätere Änderungen zu erleichtern. Sobald alle Tests erfolgreich durchlaufen bin ich fertig.

Leider fehlt mir noch die große Vorraussicht alle Tests von vornherein zu schreiben, ich werde Stück für Stück vorgehen müssen. Gleichzeitig überlege ich zuerst ein UML Diagramm anzulegen.

Ein gutes Buch! Ich bereue keineswegs 50€ dafür ausgegeben zu haben. Werde es aber auch nochmal irgendwann auf englisch in die Hände bekommen müssen, wegen des Vokabulars.

Wie der Name schon sagt, handelt es von Entwurfsmustern. Diese Muster beschreiben wie man Objekte in Beziehung setzen kann, Arten von Beziehungen die gut funktionieren. Es hilft bei Problemlösungen und zeigt auf, wie eine Analyse auszusehen hat. Die Beschreibungen laufen über Vor- und Nachteil und detaillierte Beispiele.

Ich bin immer noch sehr dabei diese Art des Programmierens zu lernen, komme einem guten Niveau aber immer näher. Derweil versuche ich noch die Rolle von Prototypen in JavaScript zu verstehen um dann, selbst in JavaScript, Entwurfsmuster anzuwenden.

Leider muss ich zugeben, dass ich in den letzten Wochen nicht wirklich vorwärts gekommen war. Fehlende Motviation und Wissen waren wohl die Gründe. Momentan begreife ich die Objekt-Orientierung in JavaScript, die doch relativ schwierig zu entdecken ist, zumindest war sie das für mich. Wohl einfach aufgrund der größtenteils funktionalen Verwendung von JS. JS OOP programmiert sich zudem ganz anders wie PHP OOP, weil JavaScript vorallem auf Prototypen setzt.

Bei einer Website können mittlerweile client- und serverseitig Skripte aufgerufen werden, der Trend tendiert zur Zeit vor allem zur Clientseite, wobei es immer noch der Server ist, der die wirkliche Validation übernehmen muss. Der Client bleibt manipulierbar und somit unsicher. Auch ich habe mich dem Trend angeschlossen. Dabei setze ich vor allem auf OOP in JS und verlagere so viel wie möglich in den Browser. So wird die Seite bei mir von JavaScript generiert und läd nicht neu. Alles läuft über XHR (XMLHttpRequests – AJAX) und JavaScript. JS bestimmt wie die Seite aussieht, der Server gibt nur noch den Rahmen vor, erlaubt bestimmte Dinge (Zugriffe auf Daten), die Aufbereitung übernimmt der Browser.

Im MVC Modell gesehen verwaltet JavaScript hier die Views und bekommt dafür auch Models zur Verfügung gestellt, wenn auch eingeschränkter als auf PHP-Seite. Die Models stehen trotzdem in einer gewissen Verbindung, auch wenn diese nicht stetig ist, weil ich nicht andauernd unnötige Requests abschicken will, das würde nur zu einer Serverüberlastung führen. Gleichzeitig erzeugt dies einen sehr praktischen clientseitigen Cache, den ich vielleicht von Google Gears unterstützen werde.

Momentan schreibe ich an der Verbindung zwischen Client und Server, die möglichst abstrahiert werden soll (zusammengefasst und einfach verfügbar gemacht) – auch für weitere Entwicklungen.

Für zukünftige Entwickler wird somit auf jeden Fall PHP sowie JS Erfahrung vorrausgesetzt werden. Das schöne an einem Framework ist allerdings, dass man es nicht verstehen muss um es zu benutzen, wenn es gut geschrieben ist und auf kritische Stellen hingewiesen wird. Dafür gibt es zum Glück dann eine Community und Tutorials, die geschrieben werden [uA von mir]. Daher keine Angst, wenn das jetzt alles wie spanisch klang, es wird viele Erklärungen geben.

Ich freue mich schon auf das Verbesserungspotential, das eine Community bietet, wenn man als OpenSource veröffentlicht. Diese Idee treibt mich auch weiterhin an, ich habe aber noch einige schwierige Dinge zu schreiben bevor ich mich überhaupt endlich dem Spielinhalt widmen kann, denn zur Zeit schreibe ich immer noch am Grundgerüst des Spiels, das möglichst variabel und erweiterbar sein soll.

Blizzard stellt für WarCraft3 und andere Spiele ein herrliches Online-Netzwerk zum Spielen bereit, es nennt sich Battle.net. Gepaart mit einem sehr guten Mapeditor ergibt das eine Vielfalt von sogenannten Funmaps, die man online gegen andere menschliche! Spieler spielen kann. Als Browsergamespieler kennt ihr den Reiz gegen menschliche Spieler zu spielen; ich mag sehr gerne Strategie.

DotA ist eine dieser Funmaps, die permanent entwickelt wird. Ich wage zu schätzen, dass weltweit eine Millionen Spieler diese Karte für WarCraft3 TFT aktiv spielen oder bereits aktiv gespielt haben.

Anstatt weiter auf das Spiel selbst einzugehen, möchte ich ein wenig analysieren, was das Spiel so attraktiv macht. Wer sich interessiert sollte mal bei Freunden nach einem WarCraft3+Erweiterung Serial fragen oder sich das Spiel zulegen, zusammen kostet das immer noch 26€ glaube ich. Ein wenig mehr über das Spiel: Wikipedia DotA Allstars. Seit knapp zwei Wochen ist die Karte sogar auf Deutsch verfügbar, wenn auch ein wenig verbuggt. Es wird sich zudem darum bemüht, das Spiel einsteigerfreundlicher zu machen.

Ich sinne auch schon seit Jahren an einer Browsergame-Umsetzung von DotA, aber das ist wahrscheinlich unmöglich. Stattdessen könnte man versuchen sehr gute Aspekte des Spiels wiederzuverwenden. -Keine Angst, ich werde jetzt nicht die Entwicklung von UGamela abbrechen, aber wer weiß, was man alles in ein Weltraumspiel miteinfließen lassen kann, oder ob sich das Spiel nicht doch hervorragend modden lässt…-

Der attraktivste Punkt an DotA ist wohl die permanente Entwicklung und Erweiterung (bereits mind. 7 Jahre) und die einhergehende Vielfalt. Das Spiel umfasst mehr als 95 Helden und eine schiere Fülle von Gegenständen (“Items”). Das Balancing ist fast perfekt und wird immer wieder verbessert. Zum Gewinnen kommt es natürlich auf das persönliche Können jedes Spielers an, doch wichtiger ist noch das Zusammenspiel des Teams. Trotz einer Rollenverteilung ist DotA kein RPG.

Leider ist Teamplay nur sehr begrenzt im Browsergame umzusetzen, doch ständige Weiterentwicklung und Vielfalt sind auf alle Fälle möglich. Ich habe an einen unendlichen Technologiebaum gedacht. Aktive Fähigkeiten von Helden erfordern die Anwesenheit des Spielers und direkte Kommunikation mit dem Server. Bisher laufen Kämpfe im Galaxiebrowsergame eher sehr selbstständig ab, das würde ich gerne behalten, denn für etwas anderes ist das Browser-Server-System ungeeignet. Doch einige Helden und Items in DotA besitzen passive Fähigkeiten, die man in einem ähnlichen Stil übertragen könnte.

Beispiel: Lifeleech (Lebensraub) ist eine Fähigkeit, die einen Prozentsatz des verursachten Schadens als Leben zurückgewinnt. Natürlich müsste man für Raumschiffe einen anderen Namen und eine bessere Beschreibung für diese Fähigkeit finden, aber spannender würde es mit soetwas auf jeden Fall werden. Besonders, wenn sich diese Fähigkeiten auch noch ausbauen oder verschmelzen lassen.

Auch das ist ein wichtiger Aspekt bei DotA: ein Held hat eine begrenzte Anzahl Slots für die Items, kleinere Items lassen sich mit Rezepten zu größeren zusammenbauen. So könnte man die Anzahl der Schiffe im Kampf natürlich senken, indem sie sich effektiv ausbauen lassen. Das macht die Kampfberechnung zwar teils komplexer, aber auch einfacher, weil weniger Schiffe berechnet werden müssen.

Ich hoffe das klang nun alles nicht zu sehr weit hergeholt, aber ich versuche sowieso ein wenig Richtung Fantasy zu gehen. Zum Beispiel mit einer weiteren Rasse und einer anderen Energiesorte (Mana). Spannend wäre es beide Energiesorten gleichzeitig zu nutzen…