UGamela Blog

Without a better title to relate, my first english blogpost:

My last action concerning UGamela has been cloning Microsofts redis for Windows repository. I’m quite happy that I found prebuilt libraries in there, I really don’t want to install Visual Studio just to compile this database. Still, I’m glad MS is supporting this! The production will probably run on a linux machine, that’s the ideal hosting for redis.

So it is decided: redis will be database foundation. A simple key-value store which works in memory and can be dumped to harddisk.

Also I’m working with Backbone at my work as webdeveloper (still as a student, but yeah, I’ve got a job as javascript developer!) and I will probably use it in UGamela as a framework. Also, Twitter Bootstrap helps me -not being a designer- making a nice interface.

Then I got this insane idea to have a full fledged developer admin front-end with CodeMirror, but that might be just my wish to have a better javascript development environment. Still, it would be nice to code the game in the game^^ – a game content creator, which will need imba security, because it probably won’t work without evil eval().

I’m not sure if I should spend time on it, it might speed up the rest of the development.

Ich habe schonmal einen ähnlichen Artikel geschrieben, der allerdings mittlerweile veraltet ist und die meisten Seitenaufrufe meines Blogs produziert. http://ugamela-blog.pheelgood.net/2009/01/25/vergleich-php-vs-python-browsergame

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.

Nachdem ich letztes Semester nicht dazu kam mich viel mit meinem Browsergameprojekt zu beschäftigen, wahrscheinlich vor allem wegen des Praxis-Software-Projekts der Uni, beschäftige ich mich zur Zeit nebenher wieder damit, wobei ich momentan auch noch das neue Semester ordne. Wie kompliziert ein Studiengang im Aufbau sein kann!

http://nodejs.org
Ich habe mich ein wenig eingerichtet. Da ich Windows-Nutzer bin, stellte sich das als nicht unkompliziert heraus, da NodeJS Windows nicht wirklich unterstützt. Die Installation unter Cygwin ist zur Zeit nicht zu empfehlen. Wobei da Besserung seitens der NodeJS Entwickler versprochen ist.
Es gibt einige Vorträge, die ich mir angesehen habe. Auf meinem Laptop habe ich Dualboot, kann daher auf Ubuntu ausweichen zur Entwicklung. Die Installation erweist sich dort mit ein wenig Konsole-Kenntnissen als nicht so schwierig. Auf meinem Hauptrechner ist das komplizierter, weil ich nicht das Betriebsystem zum Programmieren wechseln will. Die Installation auf Cygwin hatte ich vor ein paar Monaten erfolglos probiert. Ich kann Ubuntu aber in einer Virtual-Machine betreiben. VMWare bietet einen Unity-Modus, in dem die Oberflächen zusammengeführt werden. So kann ich ein Ubuntu Terminal unter Windows7 offen haben, fein. Ich kann einen Ordner auf dem Host(Windows) freigeben und auf dem Gast (Ubuntu) mounten, so kann die Entwicklungsumgebung auf dem Host laufen lassen.

v8 lässt sich direkt über den Chrome Browser debuggen, da bin ich noch gespannt wie die Anbindung funktioniert.
Langsam bilden sich kleine Frameworks unter NodeJS, interessant finde ich vor allem express. Teils lese ich im Quellcode von interessanten Projekten um den Aufbau und die Nutzung der NodeJS-API zu verstehen. Die asynchronen Aufrufe sind mir noch ungewohnt.

Allgemein bietet JavaScript sprachliche Aspekte die man nicht aus Java und nur wenig aus PHP kennt. So werden manche Probleme über Currying gelöst, in JavaScript sind Funktionen First-Class.

Was mir sehr gefällt, ist dass sich auch komplexe Aufgaben in wenigen Zeilen lösen lassen. So sieht man wie der NodeJS Entwickler während(!) eines Vortrags in 20 Zeilen einen simplen Netzwerk Chat schreibt.

Ich versuche den funktionalen Aspekt den JavaScript bietet (für Simplizität) und die gelernte Objektorientierung (für Erweiterbarkeit) zu verbinden. Derweil höre ich dieses Semester einige passende weiterführende Vorlesungen.

Leider bin ich mir noch nicht sicher wieviel Zeit ich dieses Semester diesem Projekt widmen kann, hoffe allerdings viel, das letzte Jahr lag irgendwie nur alles Brach.

Nun sind es tatsächlich drei Jahre. Die Zeit vergeht schnell.
Ich habe eben ein bischen recherchiert, mein Forum und Blog wurde mittlerweile in der Googlesuchplatzierung überholt.
Von Polen, die sich keinen Deut um Copyright stören. Evolution Skin, OGame Startseite, …
Miserable deutsche Übersetzung, aber für die Suchmaschine reichts..
Die Franzosen basteln immer noch an „XNova-NG“, wobei da anscheinend auch nichts passiert ist das letzte halbe Jahr. Wie für das Genre üblich, werden Releasedates immer weiter hinaus geschoben.
Die deutschen XNova Kiddies haben sich auch nicht verändert, vielleicht mal eine kleine neue Idee, aber keine fähigen Leute die das Spiel anständig neu schreiben.

Ich war und bin das Jahr vor allem mit meinem Studium beschäftigt.
Für german UGamela ist daher dieses Jahr auch fast gar nichts passiert, was aber nicht bedeutet, dass ich nicht weiter an meinen Ideen gearbeitet habe. Es kristallisiert sich immer mehr heraus.

Mittlerweile steht zum Beispiel die Platform fest: NodeJS
Ein JavaScript-Server auf der V8 Engine. Das bedeutet kein PHP, dafür sehr viel JavaScript (Das wiederhole ich jetzt auch schon länger).
Das sollte jetzt nicht unerwartet sein, ich habe in vergangenen Artikeln schon öfter über JavaScript geschrieben…

Mehr fällt mir momentan nicht ein, ich wollte mich mal wieder melden.

Patterns – Muster auf Deutsch. Informatiker fassen gerne Probleme in Muster um sie zu katalogisieren. Eine Problemlösung kann so öfter wieder verwendet werden, Fehler werden vermieden. Manchmal stellen sie auch einfach einen Weg dar etwas elegant zu lösen. Besonders in objektorientierter Programmierung sind solche Muster bekannt: Entwurfsmuster.

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.

Weiterlesen „JavaScript OOP: patterns“

Nun, über ein halbes Jahr habe ich mich jetzt mit Softwareentwicklung und Objektorientierung beschäftigt. Immer im Hinterkopf meine Browsergame Idee gehalten und festen Glauben in PHP in Verbindung mit viel JavaScript im Browser gehalten. In diesem Moment, da ich versuche mir alles schön herzurichten um wirklich loszulegen, springen mir die Schwierigkeiten mit PHP nur so entgegen.

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.

Ich kann mir Geburtstage einfach nicht merken. Naja, bei diesem ist eh nicht klar, wann er genau war, jedenfalls im November vor zwei Jahren. (Hab grad nochmal nachgesehn) Interessant, mir kam es so vor, als würde ich schon seit drei Jahren an diesem Projekt arbeiten. Dennoch war dieses Jahr ganz anders wie das letzte.

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!

In letzter Zeit ist so viel passiert, ich weiß gar nicht wo ich anfangen soll. Vielleicht damit, dass ich zwar wusste, dass mit einem Informatikstudium in Karlsruhe ein Haufen Mathe auf mich zukam und damit rechnete, dann aber doch irgendwie unvorbereitet damit konfrontiert wurde. Mathematik an der Universität lässt sich nicht mit Mathe in der Schule vergleichen. Ich belege Höhere Mathematik und Lineare Algebra mit jeweils zwei Vorlesungen in der Woche (=6h), dazu kommt noch jeweils ein Tutorium und die tollen Übungsblätter mit zugehöriger Vorlesung. Dazu noch eine Vorlesung Objektorientiertes Programmieren in Java und Grundbegriffe der Informatik und dann ist meine Woche auch schon gut gefüllt. Wenn man bedenkt, dass ich bereits programmieren kann und GBI eigentlich auch nur Mathe ist, bin ich also die ganze Woche mit Mathe beschäftigt, daran muss man sich erstmal gewöhnen. Keine anderen Fächer in denen man die verbleibenden Gehirnwindungen motivieren kann, kein Wunder, dass man abends relativ fertig nach Hause kommt weil man zwischen den Vorlesungen noch 4h für die wöchentlichen Übungsblätter gearbeitet hat. Die Dinger haben es wirklich in sich. Leider führt da kein Weg dran vorbei, ansonsten wird man nicht zur Prüfung zugelassen.

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.

Testgetriebene Entwicklung.

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.

Design Patterns – das Buch, das weit auch als „das GoF Buch“ bekannt ist, gehört nicht zu den neuesten Büchern zum Thema, ist aber das Bekannteste und Altbewährte. Ich habe es die letzten Wochen das erste Mal gelesen bzw. bin es durchgegangen. Mein Fazit:

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.