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.

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.

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…

Beispiel: JavaScript Templateparser

Ich stehe immer noch zu OOP und auch JavaScript untersützt OOP hochgradig, allerdings in einer für PHPler ungewohnten Form: mit Prototypes, ohne Klassen. Überhaupt ist in JavaScript alles ein Objekt oder – noch besser – eine Funktion! Ich habe hier keine Zeit eine JavaScript Einführung zu geben, ich bitte daher um selbständige Fortbildung um diesen Artikel verstehen zu können.

AJAX Requests sind asynchron, laufen also immer mit Callbacks. Ich verwende jQuery als JS-Framework.

$.get(url, function(data) {
    // callback code
});

Wenn ich nun mehrere Requests brauche, weil ich – im Falle des Templateparsers – Template, Sprache und Daten brauche, dann gibt das eine häßliche Verschachtelung:

$.get(tplurl, function(tpl) { // hole Template
    $.get(lngurl, function(lng) { // hole Sprache
        $.get(url, function(data) { // hole Daten
            $.bindTo(tpl, data, lng, '#content'); // parse das Template mit den Daten und der Sprache nach #content
        });
    });
});

Und das ist noch vereinfacht… Dabei hätte ich viel lieber, wobei die Templates und die Sprache gecacht werden sollen:

$.get(url, function(data) {
    $tpl(tplID).bindTo(data, lngID, '#content');
});

Nun.. wie bekommen wir das Callback weg?

Analyse des Problems:

Wir wollen anstatt eines Callbacks eine Verkettung per Punktschreibweise (Objektmethodenaufrufe), das bedeutet die Befehle die auf das Templateobjekt ausgeführt werden, werden höchstwahrscheinlich AJAX Requests beinhalten, auch wenn der Cache verwendet werden kann, müssen wir innerhalb mit Callbacks arbeiten, aber wir können sie nach außen hin verstecken, solange dem Coder gewahr ist, dass der bindTo-Aufruf auch asynchron ist. Für den Fall, dass man doch weiter abhängigen Code hat, führt kein Weg an weiteren Callbacks vorbei.

$tpl(tplID, callback).bindTo(data, params{lang,callback…})

Trotzdem wird das Aussehen komprimiert und etwas lese- und schreibfreundlicher.

Nun, wie ist das im Inneren gelöst?

Wir definieren zuerst eine Funktion get() (private), die das Template auftreibt, sei es aus dem Cache oder per Request. In beiden Fällen führt sie (oder der zugehörige Request) das interne Callback aus, sofern es gesetzt ist.

Das Objekt besitzt nun die public Methode bindTo, welche zuerst das interne Callback definiert (mit dem echten internen bindTo Code) und dann get() aufruft. Dazu kommen noch die beiden äußeren Callbacks von $tpl und bindTo, die wie das interne Callback am Ende von get() aufgerufen werden, sofern sie definiert sind.

Folge: Beim Aufruf von $tpl(tplID) passiert noch nichts besonderes, außer das ein Objekt zu Rückgabe gebildet wird. Der Aufruf von bindTo() auf dem Objekt stößt nun den Request an, welcher danach das echte bindTo ausführt!

So. Das wollte ich loswerden , vielleicht hilft es ja irgendwem oder animiert Leute JavaScript zu lernen…

Bei echtem Verwendungsinteresse des Codes einfach Mail an mich.

Vorerst muss ich darauf hinweisen, dass ich kein Profi bin und hier meine subjektive Meinung vertrete. Dies wird also kein Eintrag wie aus dem Lehrbuch, ich versuche nur etwas auf meine Weise klar zu machen.

Einleitung der GoF: Favorisiere Zusammensetzung vor Vererbung (“Favor object composition over class inheritance”)

Vererbung sollte für jeden, der schon mal ein paar Klassen geschrieben hat, klar sein; Stichwort dazu ist (in PHP) “extends”. Zusammensetzung ist schon ein wenig schwieriger. Ich bin mir nicht mal sicher, ob das auch wirklich die perfekte Übersetzung für Composition ist. Die wichtigste Rolle spielt hier der Dekorierer.

Hier nun ein bischen PHP-Code, hoffentlich schon selbsterklärend:

interface Etwas
{
    public function tuWas();
}
class EtwasImplementation implements Etwas
{
    public function tuWas()
    {
        return 'Etwas tut was.';
    }
}
class AnderesEtwas implements Etwas
{
    public function tuWas()
    {
        return 'Dieses Etwas tut was Anderes, evtl. Ähnliches auf andere Weise.';
    }
}
class EtwasDekorierer implements Etwas
{
    protected $_Etwas;
    public function __construct(Etwas $Etwas)
    {
        $this->_Etwas = $Etwas;
    }
    public function tuWas()
    {
        return $this->_Etwas->tuWas().' Und der Dekorierer verarbeitet das noch weiter, kann jedes Etwas erweitern.';
    }
}

Wie man sieht ist der EtwasDekorierer selbst ein Etwas, kann auch jeder Zeit die Stelle eines Etwas einnehmen, wie als würde er davon abstammen (Vererbung). Der klare Vorteil gegenüber der Vererbung ist nun, dass der EtwasDekorierer sowohl die EtwasImplementation als auch AnderesEtwas erweitern kann. Das, was erweitert wird, wird dadurch austauschbar. Mehrere Dekorierer lassen sich übrigens hervorragend verschachteln.

Hier noch ein kleines, etwas konkreteres Beispiel:

class Logger # soll Methodenaufrufe des dekorierten Objekts loggen.
{
    protected $_Object;
    public function __construct($Object) #ggf prüfen ob es ein Objekt eines bestimmten Typs ist (per Typehint)
    {
        $this->_Object = $Object;
    }
    public function __call($method, $args);
    {
         printf('Methode %s eines Objekts der Klasse %s wurde aufgerufen \n', $method, get_class($this->_Object));
         # Hier kann man natürlich je nach Bedarf etwas Anderes einbauen... (e.g. In Datei schreiben etc.etc..)
         return call_user_func_array(array($this->_Object, $method), $args);
    }
}

Der Nachteil am Dekorierer ist, dass man alles delegieren, also weiterleiten, muss. Besonders wenn der Dekorierer nur einen Teil der Methoden verändern soll ist das nervig alle Methoden an das dekorierte Objekt weiterzuleiten. PHP5s __call() kann da praktisch sein, obwohl dann zu überdenken ist, ob der Dekorierer nicht unnötig ist, gerade in PHP, wo OOP weniger performant ist.

Insgesamt wird mit dem Dekorierer eine weniger feste Bindung zwischen den Objekten gelegt, dadurch wird das Design flexibler.

Python lässt sich, im Gegensatz zu PHP, welche eine pure Websprache ist, für jegliche Anwendung verwenden. PHP wird sehr gerne für Websiten verwendet, der Code ist schnell geschrieben, besondere Strukturen würden zwar nicht schaden, sind aber nicht von Nöten, weshalb kaum einer sich wirklich Mühe gibt. Dementsprechend ist auch der Ruf sehr schlecht. Es gibt viel zu viel Spaghetticode, allein UGamela war ein Beweis.

Ich persöhnlich habe mich sehr mit OOP und Designpatterns angefreundet und überzeugt ein gut strukturiertes stabiles Spielgerüst zu bauen. Es ist eindeutig ein Anreiz einmal OpenSource-Code mit Qualität aufzubauen, es wird viel zu viel geklagt wenn man sich mal umhört. Auch da geht der Abscheu zu PHP mit einher. Wenn man in höheren Kreisen erzählt man schreibe ein Browsergame in PHP wird man komisch angesehn. Zu Recht, denn PHP scheint denkbar ungeeignet:

Ein Browsergame ist mit nichts im Web wirklich vergleichbar und trotzdem versucht man es in einer Scriptsprache zu schreiben, die denkbar ungeeignet ist, schon allein aufgrund Performance. Um den Überblick im Spiel halten zu können (Wartbarkeit) und auch mal kurz neue Features einzufügen oder zu testen (Erweiterbarkeit & Flexibilität) muss der Code gut strukturiert sein, sonst wird das nach kürzester Zeit chaotisch, wenn er es nicht sowieso schon war.

Noch ein paar weitere Dinge die ich für das Spiel brauche:

1. Eine einfache Sprache, denn das Spiel soll möglichst von jedem erweitert werden können
2. Verfügbarkeit auf Webservern, evtl. Webspaces und wenig Installationsaufwand
3. Wahrscheinlich ein CMS oder Framework, das mir Funktionen zur Userverwaltung abnimmt

1) Bieten PHP und Python beide, mir scheint Python sogar noch einfacher durch das Wegfallen der Klammern und die automatische Einrückung.

2) Hier schlägt PHP eindeutig Python, es ist quasi überall verfügbar, Standard.

3) In PHP sowie auch Python vorhanden, den PHP Frameworks wird aber allen keine besonders gute Performance zugesprochen.

Allgemeines Fazit:

PHP muss nicht so schlecht sein, wie alle sagen. Mit PHP lassen sich auch größere Projekte verwirklichen, aber dafür gedacht ist es weniger. Für kleine Sites ohne größeren serverseitigen Rechenaufwand ist es gut geeignet und auch überschaubar. Mit PHPs OOP lässt sich etwas anfangen, aber die Vorzüge echter objekt orientierter Sprachen bietet es nicht. Am Ruf darf man sich dann nicht stören.

Python sollte verwendet werden wenn OOP von belang ist, damit hebt es sich am stärksten von PHP ab. Wenn auf eurem Webspace Python verfügbar ist, dann kann ich nur dazu animieren das einmal auszuprobieren!

Mein Fazit:

Python ist denkbar besser geeignet, vor allem weil ich mir soviel Struktur wünsche. Ich freue micht jetzt schon auf den sauberen Code, habe die Semikolons und Klammern satt. Ein einfacher (billig) Webspace ist sowieso denkbar ungeeignet für ein Browsergame. PostgreSQL wird hervorragend passen, das unterstützt sogar innerhalb Python Aufrufe (Ersatz für die MySQL Procedures). In wieweit ich ein Framework wie Zope, Django oder Pylons zur Hand nehme steht noch nicht fest.

Ich möchte hiermit alle UGamela Interessierten dazu auffordern einmal in Python hineinzuschnuppern, der Aufwand könnte sich lohnen!