Im letzten Artikel habe ich bereits über erste Erfahrungen mit NodeJS gesprochen: http://ugamela-blog.pheelgood.net/2011/04/29/nodejs/

Hier soll nun, ähnlich wie letztes Mal, ein Vergleich von Programmiersprachen stattfinden, wieder hinsichtlich der Entstehung eines Browsergames. Dies ist kein allgemeiner Vergleich und teils eine subjektive Meinung.

Des weiteren geht es um die Erschaffung eines OpenSource-Browsergames. Mit der Architektur stellt sich auch die Frage der richtigen Programmiersprache, die für diesen Fall am besten geeignet ist.

Die Platform ist für den Client – den Spieler – sein Browser, somit eine Website oder gar WebApplication. Hier steht nur eine Sprache zur Wahl: JavaScript. (Ich hasse Flash).

JavaScript wird mittlerweile von entwickelten Engines optimiert und sogar teils compiliert, auch größere Konstrukte sind im Browser möglich, es kann Rechenlast (Server->Client) ausgelagert werden.

Serverseitig ist die Auswahl größer. Letztlich lässt sich in fast jeder Sprache ein Server schreiben. Die meistverwendetsten sind wohl PHP, Java, Ruby, Python und Perl.

Java bleibt hier außen vor, und über Ruby (zu langsam) und Perl (zu häßlich) möchte ich nicht schreiben.

Entstehung:

JavaScript, PHP und Python hatten verschiedene Entstehungsbedingungen und Intentionen, sind daher auch für verschiedene Aufgaben geeigneter.

• PHP: Hypertext-Preprocessor. Als Templatesprache gedacht und dann für Webprogrammierung ausgeweitet.
• Python: Für besonders gute Lesbarkeit entwickelt. Allzwecksprache.
• JavaScript: Mehr Möglichkeiten zur Benutzerinteraktion auf Websites, HTML und CSS sind nicht turingvollständig. Komplizierte Entwicklung.

Zuletzt ist JavaScript stark beeinflusst durch den Browserkrieg. PHP ist etabliert, Python ist einfach schön.

Stil:

Prozedural, funktional, objektorientiert – das können alle drei, wobei prozedurale Programmierung in Python wohl Missbrauch wäre und PHP objektorientierte und funktionale Aspekte vor nicht allzu langer Zeit gelernt hat. JavaScript kommt mit einem minimalen Wortschatz aus und ist zudem klassenlos, kann aber Klassen ohne viel Aufwand nachbilden. Für mich ist ordentliche Objektorientierung wichtig. Der Prototypenbasierte Ansatz bei JavaScript gefällt mir.

Bedingungen:

Bei einem Browsergame ist eine Menge Kommunikation von Programmen erfordlich (Client-Server), besonders wenn es ein verteiltes System werden soll. Wobei jeder Server zumindest 100-1000 Spieler gleichzeitig aushalten sollte.

Platform:

PHP wird meist über (FastCGI) an einen Apachen oder anderen Webserver angebunden, der für jede Anfrage einen neuen Thread aufgemacht, der die Anfrage dann verarbeitet. Ein Thread hat jeweils einen eigenen Adressraum, teil sich keinen Arbeitsspeicher mit den anderen Threads. Für 100-1000 simultane Spieler braucht man dann halt einen leistungsstärkeren und teureren Server. Gleichzeitig konkurieren die Threads die ganze Zeit um die Datenbank.

NodeJS unterscheidet sich deutlich in der Architektur, welche aus dem Browser abstammt. Es gibt zwar die Möglichkeit Arbeit in Threads auszulagern, die sollte aber normalerweise nicht notwendig sein. Die Verarbeitung von Requests erfolgt ereignisgesteuert, Timeouts und Events werden von einer Schleife ausgeführt, die die ganze Zeit läuft (ein einziger Prozess). Abfragen mit verknüpfter Wartezeit (Datenbank, Dateisystem) werden asynchron ausgeführt. Während gewartet wird, widmet sich der Prozess eventuell bereits der nächsten HTTP-Anfrage.

Auch kommt hier eine Möglichkeit hinzu, die mir bei PHP gar nicht in den Sinn kam: Alle Requests teilen sich einen Adressraum und können auf den selben Arbeitsspeicher bzw. die selben Objekte im Code zugreifen. Deadlocks sind relativ unproblematisch, weil eh nur eine Anfrage zur Zeit verarbeitet wird. Natürlich gibt es Bibliotheken die auch für PHP Objekte im RAM cachen können, doch insgesamt gestaltet es sich deutlich einfacher in NodeJS. Das Array einfach eine Scope-Ebene drüber deklariert, und schon können alle darauf zugreifen. Ich plane die Datenbank komplett im RAM zu halten und alle paar Sekunden eine Schreiboperation an eine simple Datenbank zu schicken, die die Objekte versioniert (so kann dann im Falle eines Absturzes das Spiel wiederhergestellt werden).

Python ist auch in der Lage Objekte über den Applicationscope zu teilen.

Verbreitung:

Deutlich für PHP und Python spricht ihr Alter und ihre Verbreitung. Doch NodeJS ist gut dabei bald in die selbe Liga aufzusteigen. Gerade auch mit dem Cloud-Hype wird NodeJS immer beliebter. Ein kleiner Server mit NodeJS ist in der Amazon Cloud schnell installiert, aufrüsten gestaltet sich deutlich einfacher als auf einem normalen Server.

Frameworks:

Frameworks bilden sich für NodeJS erst langsam, da ist bei PHP und Python schon deutlich mehr Auswahl und Umfang enthalten. Mit Frameworks lässt sich natürlich Arbeit sparen, andererseits bläht es das System aber auch unnötig auf. Wieso ein großes Framework verwenden, wenn man denn doch nur einen kleinen Teil der Funktionalität braucht.

Fazit:

Es gibt keinen eindeutigen Sieger. Für mich selbst hat PHP allgemein verloren, weil ich an seine Grenzen gestoßen bin. Mit Python lässt sich in diesem Fall auch arbeiten, aber dann müssen Server- und Clientseite separat implementiert werden. NodeJS unterscheidet sich vor allem in der Herangehensweise und grundsätzlich in der asynchronen Architektur, da ist erstmal umdenken angesagt, wenn man vorher nur synchron programmiert hat.

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”. Komposition ist schon ein wenig schwieriger. 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.

PHP und Python unterscheiden sich stark, daher wird dieser Vergleich vor allem auf die Verwendbarkeit für ein Browsergame abzielen.

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!

Es gibt in PHP zwei Typen von Objektreferenzen, auch wenn es keine Dokumentation dazu gibt (Wer eine findet bitte sagen..!).

Im Handbuch steht nur: Objekte werden immer als Referenz übergeben

Das stimmt natürlich, nur ist es nicht ganz so einfach. Das Problem fällt allerdings erst auf, wenn man Objekte kontrolliert zerstören will.

$obj = NULL; # (1)

Sollte ein Objekt zerstören, wie unset(). Doch was wenn man vorher

$obj2 = $obj;

gemacht hat? Plötzlich zerstört der erste Befehl (1) nichtmehr, er setzt nur die erste Variable auf NULL. Nun das selbe ein bischen verändert:

$obj2 = &$obj; # & für Referenz sollte eigentlich nicht nötig sein

(1) Führt nun dazu, dass beide Variablen NULL sind. Huch?

Diese Referenzen heißen entweder hard/soft oder echt/unecht, wie auch immer.

Die letzten Tage bin ich aber endlich darauf gekommen, wofür man diese Interfaces in PHP verwenden kann.

Zuerst einmal: Was ist so ein Interface?

Interfaces sind Klassen, die bestimmte Funktionen vorbestimmen. Die Funktionen bilden dann eine Schnittstelle, also eine bestimmte Möglichkeit von anderen Objekten angesprochen zu werden. Im Gegensatz zu anderen Klassen werden Schnittstellen implementiert (“implements”). Dadurch kann eine Klasse mehrere Schnittstellen haben, aber nur von einer einzigen normalen Klasse abstammen.

Man muss also nur die Schnittstelle kennen, um die Klasse verwenden zu können, die sie implementiert. Anders gesagt, man kann die Klasse so verwenden wie man die Schnittstelle als Klasse verwenden würde.

Sehr konkrete Beispiele liefert PHP selbst mit einigen Schnittstellen:

ArrayAcces: Die Objekte einer Klasse lassen sich wie Arrays ansprechen.
Iterator: Die Eigentschaften einer Objekts lassen sich iterieren, also auf eine bestimmte Weise durchlaufen.

Interfaces lassen sich aber auch noch weit abstrakter verwenden:

Ich schreibe ein Interface Datenbankverbindung, das ich aus praktischen Gründen dokumentiere. Ich weise nochmal darauf hin, dass dieses Interfaces keinen Programmcode enthält, es gibt nur Struktur vor.

Danach schreibe ich einen Dekorierer für meine mysqli Klasse und achte derweil auch etwas darauf, wie PDO aufgebaut ist, denn wahrscheinlich wird das eine weitere mögliche Datenbankverbindung (->Interfacename…) mysqli wird etwas zurechtgebogen und erweitert.

Resultat: Ich kann verschiedene Datenbankklassen nach ein paar Anpassungen verwenden. Ich benutze mysqli, weil es anscheinend die schnellste ist, was MySQL angeht. Letztlich verwende ich Typehints auf “Datanbankverbindung” und Autovervollständigung für das Interface, welches ich dokumentiert (phpDoc, Zend Studio) habe.

Ich hoffe, ich habe es etwas anschaulicher erklärt, als es das Handbuch tut. Ich erinnere nocheinmal daran, dass dies keineswegs einfach ist und ich selbst lange gebraucht habe es zu verstehen.

Ich habe mich sofort für OOP begeistern können, als ich es kennenlernte, auch wenn mir das nicht leichter fällt als prozedural (das ist der andere PHP Stil den quasi alle praktizieren) zu programmieren.

Yeah, PHP OOP ist supertoll, das muss ich ab jetzt umbedingt immer verwenden!
→ Nein! Man muss eindeutig abwiegen, ob man etwas OO programmiert, den bei PHP geht dabei Performance verloren, denn das kompliieren dauert länger.

Zum Preis von einem bischen Performance bekommt man dafür:

• Übersichtlichkeit / Lesbarkeit
• Darstellung von abstrakten und realen Dingen
• Erweiterbarkeit
• Wiederverwendbarkeit
• Kapselung
• und somit Effizienz

Und diese Liste ist noch lang nicht vollständig.

Das hat mich letztlich überzeugt. Ich bin dabei das Herzstück (“Phlame Engine”) für UGamela in OOP zu schreiben. Dabei werde ich zum Beispiel Planeten und Flotten in Models abbilden. Das Ergebnis gibt den Moddern, die hoffentlich angespornt sind und viele Ideen haben, einfache Möglichkeiten mit den Daten umzugehen, wahrscheinlich ohne selbst Ahnung von MySQL oder Sessions zu haben.

Ihr könnt ich somit schon auf die PHP OOP Pfeilchen “->” freuen xD