oneback

Moin moin ihr Schurken.

Geplant ist ein Browsergame.
Software: CouchDB, PostgreSQL, Memcached, PHP 5.3 - FASTCGI + APC
Frontend: HTML 5 + Javascript

Bisherige Plattformen habe ich objektorientiert und als MVC umgesetzt.
Fraglich ist, ob das auch für Games die beste Möglichkeit ist.
Ich denke schon.

Viel mehr noch bereiten mir andere Sachen sorgen.
Es gibt Charaktere, Charaktere haben Skills, Charaktere haben Gegenstände welche die Skills beeinflussen und eigene Eigenschaften haben. Und natürlich verschiedene Umgebungseigenschaften.
Charaktere können natürlich Leveln und insgesamt wird es sicher einige größere Algorhythmen geben.

(An dieser Stelle möchte ich nicht hören, PHP sei zu langsam für Games, die Diskussion können wir uns sparen)

Absoluter Overkill wäre hier für jedes Level, jeden Charakter, jeden Gegenstand usw eine eigene Klasse anzulegen. Das wäre weder performant noch leicht zu warten und erweitern.
Eine Möglichkeit wäre hier zum Beispiel die Dinge in XML-Dateien auszulagern.
XML ist easy und einfach da!
Geladen werden diese Daten eh nur einmal und sind dann in Memcache.
Aber mal Caching Beiseite, wichtig ist eine rapide Spieleentwicklung und natürlich soll das Datenmodel einigermaßen elegant sein.

Für die Levels hatte ich auch schon eine Idee.
Hier könnte man es wirklich in einer Methode machen und per Switch abfragen was passieren soll:
switch ($level){
case 1:
$XP=0;
$level=1;
$skills=10;
$defense=0;
break;
case 2;
$XP *= 2
$level=2
$skills+=round($skills/2+($skills/10));
$defense=4;
break;
}

Ich bin mir aber unsicher.
Wie würdet ihr das Ganze angehen?
Kennt ihr gute Blogs und habt ihr Erfahrungswerte?

Beste Grüße,
Oneback

Mister Ad

Trainmaster

Du willst nicht ernsthaft für alle Levels ein Switch-Case-Konstrukt verwenden? Ich stelle mir gerade vor, wie das bei 100 Levels aussieht. Außerdem ist dein Beispiel meiner Meinung nach nicht richtig. Das Level wird in aller Regel auf Basis der XP bestimmt, demnach switch($xp).

Für jeden Charakter, Gegenstand, Level etc. eine eigene Klasse zu erstellen ist nicht Sinn und Zweck von OOP. Überlege dir bspw. eine Basis-Gegenstandsklase. Dort sind alle möglichen Eigenschaften und Methoden für einen Gegenstand notiert. Die konkrete Konfiguration eines Gegenstandes, sprich welche Eigenschaften verfügbar sind, welche Werte etc. speicherst du in der Datenbank ab. Dasselbe Prinzip würde ich bei Charakteren und Skills anwenden. Du musst dir halt stets überlegen, wie du am geschicktesten eine Basis-Klasse erstellen kannst und gegebenenfalls du Vererberung deine Basis-Klassen spezifizierst. Dies könnte ich mir bei der Charakter-Klasse vorstellen.

Bzgl. des Levels würde ich mir zunächst Gedanken über die Level-Berechnung machen, sprich lineares oder exponentielles Wachstum. Meiner Erfahrung nach tendieren Spiele zu einer leicht exponentiellen Wachstumsrate. Zusätzlich definierst du mit einer Level-Klasse alle möglichen Ereignisse, welche beim Leveln eintreten können. Die konkreten Werte etc. legst du in der Datenbank ab und führst bei jedem Leveln eine Überprüfung durch. Jenachdem ob in der Datenbank etwas hinterlegt ist, werden die jeweiligen Aktionen ausgeführt oder eben nicht. Damit bleibst du sehr flexibel.

tr0y

Ich würde Actions wie Stufenanstiege, Skillverbesserungen ect. pp garnicht erst ins Script packen das nen Client aufruft, sondern per php einen Deamon bauen der die Datenbank- und Spiel-Logik bereitstellt. Das Clientscript die Darstellungs- und Interaktions-Logik. Wenn man will könnten diese Scripts auch lokal den Deamon per sockets joinen, was aber wiederum die realisierung einer server-internen Client-To-Deamon Architektur voraussetzt, die die sockets kontrolliert.

Ich hatte vor längerer Zeit mal ein Projekt betreut das einen Support-Chat via IRC realsiert hat, die ganz ähnlich gearbeitet haben. Der IRC-Deamon war ein PHP-CLI-Script das permanent auf dem Server lief. Die Client-Scripts die ebenfalls auf dem Server liefen betraten den IRC-Server per socket. IRC-Services die man Modular starten konnte, ebenfalls. Das IRC-Protokoll allerdings wäre - denke ich - da es ein Relay-Prinzip verfolgt, der Falsche Weg für einen Game-Deamon.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

oneback

Wenn ich Stufenanstiege und Skillverbesserungen als CLI implementiere dann habe ich wahrscheinlich mehr Rechenaufwand.
Denn ich muss ständig alle checken. Wenn der User aber nichts macht, bzw sich nichts getan hat, dann ist dieser Check praktisch umsonst.
Okay, sowas könnte man ja performant per Memcache klären. Bei einer Änderung wird dann ein Wert in die DB geschrieben, der Daemon checkt dann ob dieser vorhanden ist und führt ggf ne Überprüfung durch.

@Troy ich glaube aber dein Prinzip nicht _genau_ verstanden zu haben, könntest du das bitte noch einmal besser erläutern?

@Trainmaster, nein das war nur ein erster Gedanke, natürlich ist das später Schwachsinn.
Du hast Recht, die Dinger bekommen schon ihr Objekt. Es muss nur möglichst elegant gelöst sein was bei den Actions passieren kann.
ich bin da noch sehr "vorsichtig". Level-Berechnung sollte exponentiell sein, denke ich auch.


Ich dachte bezüglich des Frontends auch schon an WebGL, bin da aber noch etwas unschlüssig auf Grund fehlender Kompatibilitäten.

tr0y

Stell dir mein vorgeschlagenes System als MySQL-Server vor. Die Verwaltung der Daten selbst übernimmt der mysql-deamon, dein client ( php -> mysql* ) erzeugt nur requests in form von querys und bekommt eine antwort.

Würde dein Spieler nun seine seite aufrufen, würde das loginhandling von diesem deamon gehandhabt werden und anhand der session wüsste der deamon wo die daten und der avatar von deinem spieler steht, welche stufe er hat und was für eine klasse er bspw. ist.

Will der spieler nun mit etwas interagieren, bspw. einem Item in seinem Inventory, frag das clientscript den deamon ob er das darf, führt diese Aktion für den client aus und sendet dem clientscript entsprechende anweisungen wie die darstellen zu ändern ist. das client-script leitet das weiter an den browser ( bspw. via Ajax-Reply )

Was ein Deamon ist weißt du ?

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

dr.e.

Das du dir denn darüber mal Gedanken gemacht? Die letzten beiden Datenmodelle, bei denen ich in die Diskussion mit eingebunden waren ausgedruckt nur noch auf einem A1-Papier unterzubringen.

Sofern du noch keine Überlegungen dazu angestellt hast, solltest du das nachholen. Gerade bei einem BG ist das Datenmodell das zentrale Element.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

oneback

@troy Na klar weiß ich was ein Daemon ist. Verstehe jetzt auch was du meinst.

@dre Genau deshalb diese Diskussion hier. Gedanken darüber gemacht habe ich mir, ich hätte aber gerne Erfahrungswerte und Vorschläge dazu.

oneback

Es macht wahrscheinlich Sinn es über Comet laufen zu lassen um Requests zu sparen.

dr.e.

Du erwartest aber nicht ernsthaft, dass ich dir nun einen Vorschlag zu deinem Datenmodell hinpinsel? Wenn doch, solltest du dich fragen, ob es wirklich eine gute Idee ist, ein BG selbst zu schreiben.

Erfahrungswerte: komplex, erfordert viel Erfahrung und Feingefühl für Datenmodellierung, dauert mehrere Wochen.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dark Guardian

Was das Problem mit Gegenstand beeinflusst Skill, Skill beeinflusst Charakterwerte etc. bietet sich das Decorator Pattern an.

__________________
"Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst".