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.

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!

Anfang Dezember habe ich das Forum neu aufgesetzt, weil ich dachte, dass wir kein PHPBBplus mit User-Sternzeichen brauchen^^. [Phlegmas Registrierungsdatum: 7.12.2007]

Danach kam noch die Version 0.4(a) raus, die Chlorel Anfang 2008 für sein XNova verwendet hat. Ich habe noch vor Jahrende den Downloadbereich gesperrt, weil 0.4a schon damals schlecht war und es nur so Bugmeldungen hagelte.

In der nachfolgenden Zeit habe ich das Release der Version 0.5 immer weiter verschoben und sehr viel dazu gelernt.

Anfang des Sommers gab es mal intern eine Version 0.4++, die irgendwie geleakt ist. Später habe ich dann “meine” 0.5 an Sascha übergeben, der sie immernoch vertreibt, wenn auch mit wenig Andrang.

Zur Feier des Jahres habe ich eine Reihe von Themen für den Blog vorbereitet, die meine jüngsten Erkenntnisse dokumentieren und die Blogleser teilhaben lassen. Erwartet nicht zuviel, aber freuen dürft ihr euch drauf! ;D

Ich möchte das nun einmal analysieren. Dazu versuche ich mich in die Lage eines der “Kiddies” zu versetzen, die den Großteil der vermeintlichen Spieladmins darstellen.
Danach werde ich versuchen dem Problem auf den Grund zu gehen!

Motivation:
[ Der folgende fiktive Monolog eines "Kiddies" ist wohl irgendwas zwischen Durchschnitt und WorstCase ]

Boah, OGame is voll lahm und Abzocke! Ich will das selba machen! …googlegoogle… cool XNova… Download.. hmmpf was brauch ich da… uhm Webspace.. Funpic.. [nun folgt höchst beschwerliche Arbeit: den Webspace dazu bringen was das Kiddie will] *Dateien draufklatsch* .. so, jez was?.. /install/install.php aufrufen.. das Tutorial is aber echt kompliziert…

Endlich! hach is das cool, jez such ich mir ein paar Leutz und stell den Speed auf 20x [mal 2500]. Hm warum kommt den niemand… ach ich muss Werbung machen! *Forum such*, *nicht die Regeln les*, *vollspamm*, nächstes Forum…

[ Dies ist übrigens das Nervigste am ganzen Problem, die einmalpostenden Spammer, ohne sie würde wahrscheinlich kaum jemand von den aus dem Boden sprießenden XNovas gestört. ]

Oh nein, wo is meine 3kk RIP Flotte??! WTF! Ich muss gleich mal zu dem Forum rennen wo ich das her hab, die sind bestimmt Schuld! … Achso ja, das is verbuggt? .. und es gibt noch keine neue Version? WANN KOMMT DIE NEUE VERSION? WARUM HABT IHR DEN TERMIN VERSCHOBEN? … Ja tut mir Leid, dass ich nicht die Suchfunktion benutzt hab … *dummguck* .. Nein ich kann doch kein PHP, das macht ihr schon… WANN KOMMT DIE NEUE VERSION?

[ Das nervt wirklich fürchterlich, weil es einfach verdammt schwer ist, sowas zu schätzen, daher sollte man es eher gleich lassen. Die Wörter "vielleicht" oder "ungefähr" werden sowieso grundsätzlich überlesen, wenn es um etwas geht, das einem Weihnachtsgeschenk gleicht. ]

*3 mal am Tag ins Forum schau, erste verkrüppelte PHP Gehversuche mach, extrem spamme*

[ Nun, das ist immerhin mal ein guter Ansatz, aber es nervt immer noch fürchterlich wegen des Spammens, zumal man für ein Browsergame doch mehr Erfahrung im Programmieren braucht, als man auf den ersten Blick so denkt.. ]

Zurück zur Problematik:
Ich habe schon gehört wie sich Leute darüber aufgeregt haben, dass XNova das ganze Genre der Weltraumspiele ruiniere und es allgemein dem Ruf der Browsergames schade.

UGamela ist OpenSource. Das bedeutet nunmal, dass man den Source einfach herunterladen kann und dass es umsonst ist. Das Problem an XNova und UGamela war nur bisher, dass der Code einfach nicht gut war. Es ist unmöglich, etwas wirklich Gutes mit Dreckscode als Basis aufzubauen. Das bedeutet, diese Packages waren/sind untauglich zur Weiterentwicklung, wofür OS doch eigentlich gedacht ist. Stattdessen tritt die zweite Verwendungsmöglichkeit, das einfache Erstellen eines eigenen Spiel ohne wirkliche Arbeit, deutlich hervor.

Für den neuen Ansatz gilt also:

1. Guter Basiscode, dazu gehören im zweiten Entwicklungsstadium auch eine enorm gute Organisation und Arbeit sowie Zusammenhalt im Team und mit der Community.

evtl. 2. Noobblocker: Das Spiel darf nicht allzu leicht installierbar sein, einfach um eine zu große Anzahl von Spielen, die von unfähigen Leuten geleitet werden, zu verhindern. Auch ein Filter im Forum wäre möglich, beispielsweise ein kleiner Test beim Registrieren oder wenn man weniger assozial sein möchte, ein abgeschotteter “besserer” Bereich, für den man sich von den anderen abheben oder bewerben muss.

Das lässt sich natürlich umgehen, daher muss alles gut kontrolliert werden und von erfahrenen Leuten mit viel Zeit geführt werden.

Erfahren bin ich nun hoffentlich, aber die Zeit fehlt. Allein werde ich das nicht führen.

Unter diesen neuen Vorraussetzungen hoffe ich, dass das ganze eine gute Entwicklung nehmen wird, auch für die, die bereits XNova verabscheuen. Ein fairer Wettstreit unter den Spielen sowie Zusammenarbeit und Innovation wären dabei meine Wünsche.

Mein Forum scheint ausgestorben und doch wird es täglich von treuen Mitgliedern besucht. In Saschas verbleibendem Forum ist auch nicht viel los. Auf meinem Blog ist dies nun etwas Neues seit Wochen.

Gefällt mir natürlich genauso wenig wie euch! Wir haben schon November und ich bin immernoch nicht sonderlich weiter, so kommt es mir jedenfalls vor. Stattdessen denke ich darüber nach die Sprache zu wechseln (PHP+PgSQL/Python+PgSQL/Java+PgSQL), möchte aber nicht schon wieder aufgeben, was ich bereits geschafft habe.

XNova ist so aktiv wie immer, kann aber die Ruhe um UGamela nicht nutzen um einmal etwas wirklich Gescheites zustande zu bringen. Stattdessen gibt es diverse Kleinkriege zwischen Membern oder Großkriege um Copyrights – wie üblich.

Vor lauter XNova, XNova, XNOVA hört man gar nichts mehr von UGamela; kaum einer weiß überhaupt noch, dass XNova auf UGamela basiert.

Damit muss man leben.  Ich bin über meine Ruhe froh ;D

Das große Problem:

Bei einem Browsergame wie UGamela läuft die Zeit weiter, wenn der User sich abmeldet. Dem Server ist es sowieso egal, ob der User gerade eine Page liest, es kommt immer nur auf die Momente an, zu denen jemand klickt und Daten nachgeladen werden.

Annäherung:
Das Naheliegendste ist es zu denken, dass die Daten immer aktuell gehalten werden, dann wäre ja alles klar. Aber das ist mit einfachen PHP Scripten nicht möglich und wäre auch arg ressourcenverschwenderisch.

Lösungsvorschläge:
Die Erste und wohl beste Methode wäre es, aus komplexeren Problemen, wie den Flotten, Events, kleine Jobs für einen Daemon, zu machen. Daemon bedeutet ein Script, fast eigenständiges Programm, das permanent läuft und Ereignisse dann abarbeitet wenn sie Geschehen. Diese Möglichkeit wäre eindeutig einfacher, wobei man nurnoch auf sehr seltene Überscheidungen achten müsste (zwei Events zum gleichen Zeitpunkt mit überschneidenden betroffenen Objekten), aber selbst das wäre kein Problem, das es ja nur eine Daemon Instanz gibt, also keine Race Conditions.

Ein solcher Daemon müsste tiefer im System sitzen als ein kleiner PHP Script im Apache Server und sollte nach Möglichkeit in einer schnelleren Programmiersprache als PHP geschrieben sein ( C(/#/++), Java ). Daher ist dafür in jedem Fall mehr als ein einfacher Webspace nötig. [OGame hat nach eigenen Angaben ein C oder C++ basiertes Script und extra Server nur für die Kampfberechnung.]

Damit möchte ich mich nicht zufrieden geben. Früher habe ich UGamela gerne mit phpBB verglichen, aber so einfach ist das dann doch nicht. In einem Forum passiert nichts wenn es nicht ein User direkt tut… Trotzdem will ich den Spagat schaffen, dass das Spiel auch auf einem einfachen Webspace läuft.

Hier mein Ansatz:
Eine Berechnung wird erst dann nötig, wenn die Daten benötigt werden, aber dann muss gründlich berechnet werden. Um die Rohstoffe korrekt zu berechnen habe ich MySQL Prozeduren geschrieben, die das erledigen bevor der Apache überhaupt was von den Daten zu Gesicht bekommt. Bei den Flotten will ich auch nur die berechnen, die gerade relevant sind. Aber ich will keinem user Wartezeiten zur Kampfberechnung aufbürden. Der Einzige, der nicht meckert – außer möglicherweise dem Apachen selber – wenn der Script zu lange braucht und selbst auf einem Webspace zur Verfügung steht, ist der Cronjob. Allerdings höchstens alle zwei Minuten. Nun können wir uns ärgern, dass wir dann die Kämpfe nicht zum richtigen Zeitpunkt berechnen lassen können oder wir schieben die Kämpfe in dieses zwei Minuten Raster. Dann findet der Kampf halt nicht sofort statt wenn die Flotte ankommt, sondern “läuft” während einer gewissen Zeit, zum Beispiel könnte man eine Runde alle zwei Minuten ausrechnen, der User könnte dies “live” mitverfolgen und sogar seine Flotte während des Kampfes zurückziehen. Auf jeden Fall ist dies um einiges realistischer als der 10-Sekunden Kampf…

Die meisten anderen Events werden ähnlich wie die Rohstoffberechnung von MySQL Prozeduren abgearbeitet. Nun sorge ich mich langsam nicht mehr um meinen Apachen sondern um meinen MySQL Server… Überlast? .. Ich bin mir da noch nicht sicher, aber ich werde auf jeden Fall mit einem Sessionmanagement aushelfen, teils werden wir gar keine Queries oder Prozeduraufrufe brauchen, hoffe ich.

Ich bitte hier nur die Leute, die wirklich etwas davon verstehen zu posten, ansonsten garantiere ich nicht dafür, dass ich die Kommentare stehen lasse.

Auch wenn dies einige Rechenarbeit ersparen würde, möchte ich das ändern. Zudem finde ich man sollte Geschwindigkeiten etwas variabler machen.

Beispiel Auto: Autos haben einen variablen Benzinverbrauch, und natürlich sind nicht alle gleich schnell. Am sparsamsten sind Autos wenn man mit ihnen nicht zu schnell und auch nicht zu langsam fährt. Vom sich wiederholenden Anfahren in der Stadt ganz zu schweigen.

Nun sagen wir jedes Schiff besitzt eine “beste” Geschwindigkeit und eine maximale Geschwindigkeit. Ich würde sagen wenn das Schiff nicht “beste” Geschwindigkeit fliegt, dann verändert sich der Treibstoffverbrauch mit einem schwachen Exponenten.

Interessant wird noch der Fall des Kampfes, bei dem möglicherweise mitfliegende Tankschiffe zerstört werden. Was macht dann die verbleibende Flotte, die nicht mehr genug Sprit zum heimfliegen hat (Weil dieser nicht schon komplett am Anfang abgezogen wurde…)? Zuerst mal auf die durchschnittlich “beste” (effizienteste) Geschwindigkeit umschalten. Wenn das nicht reicht werden sie wohl irgendwo im Raum ein anfliegbares Gebilde bilden müssen (könnte man theoretisch mit einer Art Planeten- bzw Objekteintrag realisieren).

Die Geschwindikeit wird übrigens wie Angriffs- und Verteidigungswerte nicht mehr variabel an den zugehörigen Ressourcen hängen (Wieso sollten beim Techen gleichzeitig alle Schiffe ausgebaut werden?). Vielmehr kann man dann bei seiner Flotte auf >Aufrüsten< klicken, und muss dafür wieder Ressourcen zahlen. Sogar ein Bauteillager wäre denkbar.

Mich wundert das noch niemand den Fusionskraftwerkbug bemerkt und ernst genommen hat. Er bedingt einige Funktionalitäten auf die ich nicht verzichten möchte:

Gebäude mit starkem “Resourcendrain” (hoher Verbrauch, höher als die Produktion ist) oder eine sehr knappe Ressource die von bestimmten Gebäuden verbraucht wird.

Beispiele:
AMmine/Ultramine: Verbraucht AntiMaterie (das nur sehr wenig bis gar nicht produziert wird) und produziert große Mengen von Energie und als Abfallprodukt Aluminium und Silicium… (gut noch etwas gesponnen sollte aber nur ein Beispiel sein)

Rohstoffwandler: Dieses Gebäude verwandelt Dunkle Masse (die man nur auf Expeditionen findet) langsam in ein Aluminium/Silicium-Gemisch um (Über einen gewissen Zeitraum).

Betanken eines Schiffes: Man lässt eine Extra-Resssorte den Tank herunterzählen (leichter als ein variables Limit einzurichten)  – Energiebetankung/Laden von Batterien?.

Erklärung des Bugs:
Die Ressberechnung basiert auf dem einfachen Prinzip Produktion (Rohstoff durch Zeit) mal Zeit ergibt Rohstoff. Problematisch wird dies allerdings wenn bestimmte Grenzen erreicht werden. Besonders die untere Grenze wird bisher nicht berücksichtigt, weil die Produktion eigentlich immer positiv ist. Wer den Bug beobachten will, der baue einfach mal das Fusionskraftwerk so weit aus wie möglich, stelle seinen Deutextraktor auf Null und das Kraftwerk auf volle Power. Spannend wird es wenn 0 Deuterium oder weniger erreicht wird (MinusDeut?!).

Um dieses doch etwas komplexere Probleme zu lösen hatte ich zuerst eine Klasse in PHP geschrieben, habe mich dann aber von meikel überzeugen lassen, dass es besser wäre das in SQL zu lösen. Nachdem ich irgendwann mein Argument, dass das mit SQL gar nicht möglich wäre aufgeben musste habe ich es in MySQL geschrieben. Dadurch ist der Script weit statischer (versch. Ress-/Energiesorten), doch man kann den Script ja vor dem speichern in der Datenbank durch PHP jagen, welches dann die vierte und fünfte Resssorte hinzufügt, die der Admin gerne hätte…

Als ich das geschafft hatte habe ich mich an einen SQL Eventhandler und eine Bauliste gemacht, die beide fast fertig sind.

Die Bauliste unterstützt eine Wartefunktion, die es dem Spieler erlaubt eine Liste anzulegen ohne vorher auf die Verfügbarkeit von seinen Ressourcen zu achten. Das ist leider noch nicht ganz fertig und bestimmt nicht bugfrei, aber der Ansatz steht.

PHP bekommt hinter dem SQL Core nurnoch die Aufgabe die Daten des Users zu validieren, zb ob er das überhaupt schon bauen darf…

Resultierend aus dieser Umstrukturierung wird es auch möglich sein dem Spieler eine individuelle Schiffgestaltung zu überlassen. Dh. man könnte es beispielsweise ermöglichen bestimmte Waffen einzubauen. Dies ist vorerst allerdings nur Zukunftsmusik, ich kümmere mich vorerst nur um serverinterne Angelegenheiten und um Performance & Erweiterbarkeit. Das Interface könnten danach auch ein paar Helferlein schreiben können, die nichtmal so viel davon verstehen müssten.

Leider ist mir heute bei einem Windoof Absturz mein SQL Ressourcen- und Eventhandlerscript abhanden gekommen, einen Großteil hatte ich mir zum Glück ausgedruckt, aber die Bauliste muss ich wohl neuschreiben, zudem muss ich einiges abtippen. Das kostet mich Zeit und regt mich auf, aber das wird schon.

PS: Morgen werde ich 18