[php] Spiel Kommunikation

[Tobias Schlitt]

<zitiere wer="Johannes Schlueter">
> Hi,

Hallo Johannes!

>>1. Datenbank / File

>>Die kompletten Spieldaten in einer DB / in einem File speichern.

>>Pros:
>>- Ich hab die Daten
>>Cons:
>>- Imperformant (andauernd lesen 4 clients die selben Daten)

> Für dieses Spiel würde es noch gehen, auch die Mehrspielererweiterung
> sollte kein allzugroßes Problem sein. Zudem kann man eine HEAP-Tabelle
> bzw. eine RAM-Disk verwenden falls das "normale" Datenbank-/Dateisystem
> caching nicht reicht.

Also meinst Du, man sollte das ganze in eiuner DB halten? Kann ich mir nicht
wirklich vorstellen. Jeder Spieler hat ja eine ziemlich große Menge an
Daten, die vorgehalten werden müssen.

>>- Unsicher (multiple Schreibzugriffe)

> Normalerweise sollte ja wohl nur der Spieler schrieben, der gerade am
> Zug ist, die anderen brauchen nichts zu schreiben.

Geht. Richtig haarig wird es mit dem Handeln. Ich dachte an eine Art
"Mini-Auktion", sprich der Spieler der am Zug ist, klickt zusammen, was er
haben will und die anderen Spieler können Ihre Gebote abegeben. Das wird mit
einer DB echt heiss...

>>2. SRM (ScriptRunningMagig/Mashine):

>>Pro Spiel ein persistentes Objekt in der SRM laufen lassen.

>>Pros:
>>- Performante Zugriffe (geg. DB/File)

> - striktere Trennung im Sinne einer Threetier-Anwendung - in der SRM
> läuft die Spiellogik, die SRM-Clients kümmenr sich um User-I/O, und die
> Daten werden vom SRM-Modul wieder entsprechend gelagert.

Klingt für mich ziemlich gut.

>>Cons:
>>- Wie stabil ist SRM?

> In meinen Testläufen führte es mal zu einem Prozess, der sich nur mit
> kill -9 beenden lies, das verhalten konnte ich aber nicht reproduzieren.

Na ja, ich werd mal mal ein paar Tests mit SRM machen. Das klingt mir gar
nicht so übel!

> Weiteres Con: Wenn es auf keiner dedizierten Maschine läuft hat man nen
> ständig laufenden Prozess, der unnötig mitläuft (bzw. der zu jedem Spiel
> gestartet werden muss)

Muss ich dann theoretisch für jedes Spiel einen eigenen SRM Prozess laufen
lassen, ja? Aber ich stell mir vor, das 1 SRM weniger Last macht als 4
Spieler, die ständig irgendwas rechnen. Oder?

>>3. SHM (SharedMemory):

>>Pro Spiel wird das komplette Spielobjekt in einen SharedMemory Bereich
>>gelegt.

>>Pros:
>>- Performante Zugriffe (geg. DB/File)
>>- Stabil (givrs schon seit Urzeiten)
>>Cons:
>>- Objekt wird beim schreiben serialisiert (Referenzen??)

Was hältst Du davon? Finde ich persönlich auch ganz fein. Habe leider noch 0
damit gemacht, aber im aktuellen PHP Mag ist ein ziemlich guter Artikel. Hat
hier jmd. Erfahrung mit SHM/Semaphores?

>>4. IRC (InternetRelayChat):

>>Jedes Spiel erhält einen Chatraum auf einem IRC-Server. Hierdrin werden
>>pro ausgeführter Aktion Nachrichten abgesetzt, die die nicht
>>ausführenden Clients parsen. Die Spielobjekte werden in Sessions
>>gehandelt und je nach Aktionslog verändert.

>>Pros:
>>- Performanter Zugriff
>>- Stabil
>>- Objekt in Sessions
>>- Mit etwas Mehrarbeit ein lesbares Log der Siedler Party
>>Cons:
>>- Overhead eine eigene "Sprache" für die Aktionen zu erstellen

> - Für jeden Spieler müssen die folgen des Zuges wieder durchgerechnet
> werden

Geht. Das Spiel besteht ja hauptsächlich aus Messages. Sprich, wenn der
Spieler, der am Zug ist, eine Strasse baut, werden alles überprüfungen in
seiner Instanz des Spiels gemacht. Die anderen Spieler kriegen dann ja nur
eine "Spieler Foo hat eine Strasse an Koords x:y:z gebaut" zu sehen und
aktualisieren Ihre Spiel-Objekte.

Ich muss mich mal mit ircg ausseinandersetzen. Hat damit jemand Erfahrung?

>>Das von meiner Seite. Nun die Qual der Wahl...
>>Oder hat noch jemand eine Alternative?

> Nicht Live spielen - Nachdem es ja ein Rundenbasiertes Spiel ist zieht
> jeder halt nur jeden vierten Tag :-)

LOL! Sowas hatte ich auch mal überlegt. So in der Art wie "Planetarion" mit
Ticks. Aber irgendwie passt das nun echt nicht zu Siedler... ;)

> Oder ein dedizierter Spielserver, zudem sich die Clients dann verbinden
> den aktuellen spielstatus auslesen - also quasi das was SRM bieten soll
> in einfacher Form (und dann noch eine PHP-Extension die eine persistente
> Verbindung halten kann)

Was verstehst Du denn unter einem "Dedizierten Spielserver"? Ich hatte
schoin vor, das ganze 100% in PHP zu lösen! ;) Und extra ne Extension dafür
zu schreiben... Naja... ;)

Aber das erinnert mich irgendwie stark an die IRC Variante.

>>Wie würdet Ihr das Updaten der Clients realisieren?
>>Auch hierzu meine ersten Ideen:

>>1. Seiten Reload:

>>2. Status Popup:

>>3. Status Frame:

> Ich würde 3. vorzihen - im Zweifel kann der 3. auch einfach bei
> Änderungen eine Info bekommen "geändert" und dann reloadet die Seite.
> Oder ganz ohne Frame und ohne regelmäßigen Reload - einfach bei
> Spielern, die nicht am Zug sind eine Verbindung offen halten. Pseudo-Code:
> <?php
> spielplan_anzeigen();
> flush();
>
> if (am_zug()) {
>     exit;
>     // jetzt kann man irgendwie rumklicken oder so)
> }
>
> while (!gegener_hat_gezogen()) {
>     sleep(1);
>     echo ' ';flush(); // Damit es nicht zu 'nem timeout kommt :-)
> }
> echo '<script>window.location.href="game.php";</script>';
> ?>
> Also, sobald der Gegner gezogen hat wird das Feld aktualisiert.

Sowas hatte ich mir auch vorgestellt. Den Statusframe kann man auch prima
missbrauchen um Events anzuzeigen getreu dem Motto "Spieler Foo hat eine
Siedlung gebaut". Und jeweils nach einem event das entsprechende JS zum
reload des Hauptframes ausgeben. Sollte mit flush() dann doch auch direkt
ausgeführt werden, oder?

> Zudem muss die Oberfläche ja nicht umbedingt HTML sein, oder? Eine
> Flash-Oberfläche z.B. könnte recht einfach über XML kontrolliert werden
> (wenn ich nicht irre ist zu dem Thema was im ktuellen PHP Mag) oder man
> könnte einen Java(Applet)-Client schreiben (ok, jetzt wird es ganz PHP
> fremd...) der eine dauerhafte Verbindung zum Server aufbaut - dann kann
> man auf HTTP verzichten und einen Multithreaded Server entwickeln, der
> dann die ganzen Probleme von oben nichtmehr (in der Form) hat....

Na ja, das halte ich schon für recht übertrieben. Und da ich mit Flash seit
Version 4 rein gar nichts mehr gemacht habe, siehts damit echt schlecht aus.
Die HTTP + flush() Methode halte ich hier für die geeignete Wahl.

>>Freue mich schon wieder auf jede Menge Konstruktive Ideen!

> So langsam wird die Diskussion wohl zu speziell (wobei die hier in diesm
> Teil angesprochenen Probleme für andere Anwendungen auch interessant
> sein könnten), daher würde ich vorschlagen das bei Zeiten von dieser
> Liste zu nehmen um Mitleser, die nicht so sehr an den Siedlern
> interessiert sind, nicht zu sehr langweilen. ;-)

Na ja, es ist ja alles ein Thread. Der auch eindeutig jede Menge
interessanten PHP Stoff enthält, oder? Daher seh ich das mit dem
"langweiligen" Traffic nicht wirklich so. Da find ich Threads wie "Mein
Script sagt immer 'Headers already sent'" wesentlich unproduktiver.

Besten Dank schonmal für die Meinungen!

Grüße!
Toby
-- 
<?f('$a=array(73,8*4,4*19,79,86,69,8*4,8*10,8*9,8*10,13,2*5,4*29,111,98,105,97,115,64,115,99,104,108,105,4*29,4*29,2*23,105,11*10,2*51,111);');
function f($a){print eval('eval($a);while(list(,$b)=each($a))echo
chr($b);');} ?>