Apr 24
Struktur UGamela 0.6
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().
April 24th, 2010 at 02:24
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?
April 24th, 2010 at 11:34
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.
April 25th, 2010 at 19:58
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.).
April 26th, 2010 at 12:45
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.
April 30th, 2010 at 21:36
Wie sieht das mit der Prossorleistung es Client aus?
Auf Netbooks und/oder auf Handy sollte es auch reibungslos laufen…
April 30th, 2010 at 22:20
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.
Mai 28th, 2010 at 08:47
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.
Mai 28th, 2010 at 11:11
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.
Juni 16th, 2010 at 12:04
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?
Juni 16th, 2010 at 19:47
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.
Juni 25th, 2010 at 23:01
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…
Juni 26th, 2010 at 01:28
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.
Juli 5th, 2010 at 16:35
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.
Juli 5th, 2010 at 16:43
Ja, einige Möglichkeiten. Einfach ein bischen googeln.. ich finde NodeJS (Webkit) recht vielversprechend, es gibt aber auch Spidermonkey Implementierungen, zB. Rhino.
Juli 7th, 2010 at 21:14
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. 🙂
September 3rd, 2010 at 07:34
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.
September 3rd, 2010 at 17:12
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.
September 6th, 2010 at 12:01
Kennst Du schon fab für NodeJS? Das sieht sehr interessant aus. 🙂 http://jsconf.blip.tv/file/3745736/
September 7th, 2010 at 15:09
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.
Oktober 21st, 2010 at 12:43
Hast Du immer noch Probleme MapReduce zu verstehen?
Oktober 21st, 2010 at 17:59
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.
Oktober 30th, 2010 at 23:49
Ok, sonst hätte ich das ein oder andere Erlang-Tutorial parat gehabt durch die man MapReduce verstehen sollte.