Apr 24

Struktur UGamela 0.6

Tag: EntwicklungPhoscur @ 01:20

Das kommende UGamela wird komplett in JavaScript geschrieben, kein PHP und auch kein Python wie ich überlegt hatte. Ein Argument ist einfach durchschlagend: Da man die kommende Version als RIA (Rich Internet Application) bezeichnen kann, ist die ganze Oberfläche in JavaScript gebaut. Um das MVC-Pattern anwenden zu können, werden auch auf Clientseite alle Models implementiert. Anstatt sich nun doppelte Arbeit zu machen und das Spiel doppelt zu implementieren (in JavaScript auf Clientseite und in einer anderen Sprache auf Serverseite), schreibe ich den Code nur einmal und verwende ihn auf beiden Seiten. Natürlich gibt es auch Code, der nur auf einer Seite verwendet wird: clientseitig Views oder serverseitig OR-Mapping (sofern ich mich nicht doch noch zu CouchDB durchringen kann).

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().

22 Kommentare zu “Struktur UGamela 0.6”

  1. y0koert schrieb:

    Interessant. Hab ja schon vieles bei Browsergames gesehn, aber dass alles in Javascript is, das ist mir neu. Bin mal gespannt, wie das ganze laufen wird 😉

    Korrigiere mich bitte, wenn ich falsch liege, aber CouchDB ist doch dokumentbasiert oder? Ist das dann aus Performancsicht nicht schlechter als MySQL und ähnliche?

  2. Phoscur schrieb:

    CouchDB ist mittlerweile eine echte Alternative zu MySQL. Dennoch hängt die Performance stark vom Anwendungsfall und der Optimierung ab. Wenn man sich das mal ansieht, merkt man schnell, dass das ganz anders funktioniert. Ich habe selbst auch noch nicht ganz verstanden wie MapReduce funktioniert.

    Noch was Thema Performance: Wenn ich denn mal so weit bin, dass ich optimieren will (was vorraussetzt, dass ich fast fertig bin und das Spiel nicht schnell genug läuft), dann bietet sich die Möglichkeit eine Ebene tiefer beispielweise in Java im Falle von Rhino zu programmieren. Die Objekte lassen sich dann in JavaScript importieren.

  3. erforderlich schrieb:

    Frage 1: Wie werden die Kämpfe gehandled? Gibt es dafür so etwas wie ein Daemon?
    Frage 2: Da ich keine Ahnung von JavaScript serverseitig habe, würde ich gerne Wissen welche IDE du benutzt und wie (mit welchem Server usw…) man das Ganze zum Laufen bringen würde.
    Frage 3: Wird deine Architektur auch so etwas wie „Plugins/Packages/Erweiterungen/Mods“ unterstützen?

    Schade dass du nun die ganzen „PHP-Kiddies“ ausschließt, das wäre deine einzige Chance gewesen das kommerziell aufzuziehen. Außerdem wird es ohne PHP keine große Community entstehen, die Mods etc. schreibt – außerdem muss diese „Art“ von JavaScript erstmal gelernt und verstanden werden.

    „Um das MVC-Pattern anwenden zu können, werden auch auf Clientseite alle Models implementiert. Anstatt sich nun doppelte Arbeit zu machen und das Spiel doppelt zu implementieren (in JavaScript auf Clientseite und in einer anderen Sprache auf Serverseite), schreibe ich den Code nur einmal und verwende ihn auf beiden Seiten.“
    Meiner Erfahrung nach enthalten die Models die ganze Logik. Ist es nicht etwas sicherheitskritisch oder auch langweilig wenn man in den Quelltext gucken kann um zu sehen was intern passiert (man sieht wie lang etwas braucht um gebaut zu werden oder was man alles erforschen kann etc.).

  4. Phoscur schrieb:

    Zu 2: Vorerst habe ich an Rhino als Serverunterbau gedacht, ich bin allerdings noch nicht soweit, dass es eine feste Abhängigkeit gibt. Nach Möglichkeit möchte ich diese auch vermeiden.
    Als IDE verwende ich Aptana Studio, denn nach langem Suchen habe ich immer noch nichts besseres gefunden.
    1: Es wird wahrscheinlich eine Art Daemon geben, mit Rhino ließe sich dieser auch in Java schreiben.
    3: Ich versuche die Architektur so gut wie möglich nach objektorientierten Prinzipien aufzuziehen, die Erweiterung in jeder Hinsicht unterstützen. So setze ich auch auf Dependency Injection. Zusätzlich gibt es auch noch einige Konfigurationsdateien (in JavaScript), die einfachere Änderungen zulassen.

    Ich habe ja sowieso nach einem Weg gesucht „PHP-Kiddies“ auszuschließen, die Entscheidung für JavaScript fiel aber nicht aufgrund dieser Idee. Wenn sich deshalb eine kleinere Community bildet, ist das schade, aber unumgänglich. Ich werde trotzdem versuchen die Einstiegshürde möglichst zu senken.
    Bei JavaScript kann mir aber keiner erzählen, dass er jetzt „noch eine unnötige“ Sprache lernen muss – JavaScript ist allgegenwärtig im Internet. Es wird Zeit, dass die Standards ein bischen besser werden. Theoretisch sollte es möglich sein, anhand dieses Projektes zu lernen, wie man eine RIA aufbaut.

    Ja, die Models enthalten die ganze Logik und wenn sie auch clientseitig verwendet werden, dann kann man einfach ihren Code lesen. Das kann man aber sowieso, denn das Projekt wird OpenSource. Natürlich werden sich Server- und Clientseite unterscheiden, aber ein Großteil wird doch zumindest ähnlich sein. Dinge wie ein verdeckter Technologiebaum lassen sich trotzdem realisieren, verlangsamen aber das Userinterface, weil auf den Server gewartet werden muss.

  5. Slaver schrieb:

    Wie sieht das mit der Prossorleistung es Client aus?
    Auf Netbooks und/oder auf Handy sollte es auch reibungslos laufen…

  6. Phoscur schrieb:

    Ich erwarte keine Performanceprobleme der GUI aufgrund zu wenig Prozessorleistung, auch nicht auf Handys (die mittlerweile übrigens auch ganz nette Prozessoren haben. Notfalls bleibt immer noch das Optimieren von Engpässen und abstellen von grafischen Spielereien.

  7. Slaver schrieb:

    Zur Struktur der Templates, etc. wollt ich mal was los werden:
    Könnte mal nicht kompleet die ganzen Template und Sprach Dateien mit einem Loader beim Login laden?
    Wenn dann z.b.: Ein Aufruf zur Flottenseite kommt, nach nur noch eine Anfrage an den Server getätigt werden muss, um uns dann mit den „variabeln Variabeln“ (Mir viel grad kein besseres Wort ein) als Antowrt vis JSON/XML da lässt? Ähnlich wie GMail.

  8. Phoscur schrieb:

    So ähnlich ist der Plan. Ich weiß allerdings nicht ob ich wirklich „Templates“ auslagere, denn meist handelt es sich nur um wenige Zeilen in der View. Geparst wird auch nicht mehr so wirklich. Gleichzeitig gibt es das Beobachtermuster, das Aktualisierungen in die Views direkt einbringt.
    JSON ist schon seit längerer Zeit das bevorzugte Kommunikationsmittel zwischen Client und Server, zumindest für mich.

  9. Malocher schrieb:

    Die Idee auf beiden Seiten Javascript einzusetzen finde ich gut. Ich glaube ohnehin das Javascript, welches meines Wissens nach eh schon die am weitesten verbreitetet Programmiersprache auf der ganzen Welt ist, in Zukunft eine noch größere Rolle spielen wird. Es gibt ja auch genug Bestreben die Sprache auf den Desktop zu bringen um damit Desktop-Applicationen zu entwickeln.

    Letztendlich fände ich es zwar besser Scala im Browser zu haben, aber was solls, dazu wird es wohl nie kommen.

    P.S. um nochmal zu klugscheißen -> es heißt solarsystem, nicht „Sunsystem“. ;P

    EDIT – ich glaube ich habe dich noch nie Object literale einsetzen sehen. Hat das einen besonderen Grund?

  10. Phoscur schrieb:

    Die Vista Widgets sind teilweise schon in JavaScript (bzw. JScript) geschrieben, JavaScript wird momentan auch extrem optimiert. Es gibt mehrere Engines die JavaScript sehr performant umsetzen, vor allem auf (mobile) Clients, ist es momentan der beste Weg ein gutes Browsergame zu schreiben.
    Scala im Browser, ich hätte ja nichts dagegen, ich sehe nur nicht wer das durchsetzen soll.. Scala hat ja so schon genug Probleme Fuß zu fassen.
    Danke für den Tipp, ich wusste doch dass irgendwas an dem Wort komisch klang..

    Object literale: Du hast noch nicht viel Code von mir gesehn? Ich verwende sie, wenn sie benötigt werden. „new Object()“ benutze ich jedenfalls nicht.

  11. Slaver schrieb:

    HI, mal eine kurze Frage:

    Wirst du für UGamela eine eigende Template Engine basteln, oder eine schon bereits existierende JS-Template Klasse.
    Kannst du dort mir etwas empfehlen? Momentan habe ich Smarty am laufen was grade für seine Serverperformence bekannt ist…

  12. Phoscur schrieb:

    Bin mir jetzt nicht sicher, hast du das gelesen? http://ugamela-blog.pheelgood.net/2008/12/18/javascript-template-parser/
    Ist natürlich ne Weile her, mittlerweile bin ich mir nicht sicher, ob ich überhaupt Templates brauche. Die Kopplung zwischen Widget bzw. View und HTML Code ist so oder so sehr stark, ich denke ich werde die HTML Struktur einfach im JavaScript erstellen oder direkt als HTML-Seite aufrufen. Du musste sehen, dass das dieser Ansatz in eine ganz andere Richtung wie Smarty geht, wenn du weißt, dass JavaScript für dich sowieso unabdinglich ist, dann ist er allerdings unter vielen Punkten besser.

  13. eman schrieb:

    Hallo,

    gibt es eigentlich für Javasctipt-Server etwas vergleichbares wie XAMPP? Finde die Idee Javascript auch Serverseitig zu nutzen sehr vielversprechend, und würde mich gerne ein wenig damit beschäftigen.

  14. Phoscur schrieb:

    Ja, einige Möglichkeiten. Einfach ein bischen googeln.. ich finde NodeJS (Webkit) recht vielversprechend, es gibt aber auch Spidermonkey Implementierungen, zB. Rhino.

  15. eman schrieb:

    Danke, NodeJS sieht in der Tat recht vielversprechend aus. Leider würde selbst der Entwickler es momentan noch nicht einsetzen soweit ich dies in einem der Videos vom ihm mitbekommen habe. Werde aber weiter ein Auge darauf haben. 🙂

  16. Slaver schrieb:

    Hi Phoscur, vielleicht ist das noch für dich Interressant.
    Schau mal nach mod_v8. Dort wird versucht, Die Javascript Engine V8 aus dem Chrome Browser als Apache Mod zu schreiben.

  17. Phoscur schrieb:

    Danke für den Tipp, denke aber das ich mit NodeJS zufrieden bin (auch V8), ob und wie es mit einem Apachen zusammenarbeiten wird, weiß ich noch nicht. Ich experimentiere mit einem Filmalbum, bin aber gerade im Lernstress für die Uni.

  18. eman schrieb:

    Kennst Du schon fab für NodeJS? Das sieht sehr interessant aus. 🙂 http://jsconf.blip.tv/file/3745736/

  19. Phoscur schrieb:

    Cool auf jeden Fall. Finde die ganzen Klammern aber etwas unleserlich. Methodenname lassen sich gut verwenden um das den Quellcode zu dokumentieren.. das fällt bei fab weg, trotzdem eine spannende Sache.

  20. MapReduce schrieb:

    Hast Du immer noch Probleme MapReduce zu verstehen?

  21. Phoscur schrieb:

    Ne, ich glaub ich hab es halbwegs verstanden, ich muss es nur mal einsetzen.
    Bin vor allem mit Unikram beschäftigt gerade, bleibt keine Zeit für UGamela.

  22. MapReduce schrieb:

    Ok, sonst hätte ich das ein oder andere Erlang-Tutorial parat gehabt durch die man MapReduce verstehen sollte.

Dein Kommentar

Du musst eingelogt sein, um einen Kommentar zu schreiben.