[php] Spiel Kommunikation

[Johannes Schlueter]

Hi,

Tobias Schlitt wrote:

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

>- Unsicher (multiple Schreibzugriffe)
>  
>
Normalerweise sollte ja wohl nur der Spieler schrieben, der gerade am 
Zug ist, die anderen brauchen nichts zu schreiben.

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

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

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)

>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??)
>
>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

>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 :-)
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)

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

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

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

johannes