[php] Spiel Kommunikation

[Johannes Schlueter]

Hi,

> >> 1. Datenbank / File
>
> >> Die kompletten Spieldaten in einer DB / in einem File speichern.
>
> > 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.

Ich wollte bloß noch ein paar pros/cons sammeln aber wirklich als Lösung 
würde ich es nur in der rundenbasierten Variante in betracht ziehen ;-)

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

Darüber hatte ich mir noch keine Gedanken gemacht - wobei das auch ncit 
so "heiß" ist, einer stellt sein Angebot rein, jeder kann ein Gebot 
abgeben - sind drei Zugriffe parallel (wobei ich bezweifel, dass alle 3 
Mitspieler ihr Angebot gleich schnell zusammenklicken) und dann kommt 
wieder ein Schreibzugriff (welches Gebot erhält den Zuschlag oder es 
werden alle abgewiesen...)

> >> 2. SRM (ScriptRunningMagig/Mashine):

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

Ein SRM sollte reichen wobei ich nicht weiß wie stabil der noch läuft 
wenn der von zwei Spielen (8 Usern) ständig (parallel) befragt wird ;-)
Um mehrere Spiele parallel zu betreiben müsste man dann entweder eine 
"Banana" laufen lassen, die zwischen den "Spielobjekten" immer hinund 
hersschaltet (wie auch immer man das im Detail macht) oder mehrere 
"Bannanas" die immer das gleiche sind, bloß anders heißen - das müsste 
sich z.B. durch Extending lösen lassen.
Wäre aber in jedem Fall mal mein primärer Kandidat :-)

> >> 3. SHM (SharedMemory):
>
>  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?

Kann ich nicht viel zu sagen - habe es nur einmal mit einkompiliert und 
die Funktionen ausgetestet ;-)
Das angesprochene Problem mit den Referenzen ist dabei aber kritisch - 
sowie eventuelle konkurrierende Zugriffe (Handeln, Chat, ...)

> >> 4. IRC (InternetRelayChat):
>
> > - Für jeden Spieler mmü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.

Spieler X hat eine 4 gewürfelt - dann müssen alle Spieler die 
Kartenvorräte aktulisieren (wer ist an einem Feld mit der 4?) Und lauter 
so Zeug - aber bei vier Spieler sicher kein Problem - wenn aber 100 
Spiele parallel auf einem Server laufen sollen wird's eng ;-)

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

War mir, als ich es mir ageschaut hatte, zu teuer (war für eine Sache 
von der ich eigentlich nichts außer Erfhrung gehabt hätte und jetzt 
komplett anders gemacht habe...)

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

Ist aber auch gleich die Lösung gegen abstürzende PCs und 
zusammenbrechende Internetverbindungen (ich hasse die 
24h-Telekom[T-Online]-Zwangstrennung) ;-)

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

Eher an die SRM-Variante. Ein (in PHP) geschriebener Server, der sich um 
die komplette Spiellogik kümmert und über Unix Domain Sockets/TCP/.... 
auf Anfragen der Clients liefert. Clients in diesem Kontext sind 
ebenfalls PHP-Programme, die als Webserver SAPI laufen und die die 
Ergebnisse des SiedlerDaemon in HTML wandelt und die Benutzereingaben an 
selbigen zurückschickt - wie gesagt so wie das SRM-Modell, bloß dass der 
Server eben auch eine eigene Entwicklung ist ;-)

> >> Wie würdet Ihr das Updaten der Clients realisieren? Auch hierzu
> >> meine ersten Ideen:
>
> > 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:
>
>
>  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?

Das Status-Frame könnte auhc als kleines Chatfenster misbraucht werden - 
bei mir ist es selten dass ich stumm vor mich hin siedel ;-)

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

Bei Flash habe ich mit der MX Version letztes etwas herumexperimentiert 
und es ist schon ganz cool. Man kann recht einfach XML Nachrichten 
hin-und-her schicken und dann die verschiedenen Objekte (Linien, Felder, 
....) manipulieren ohne dass es Reloadeffekte oder sowas gibt. Da hat 
sich seit Version wirklich viel getan. Ich selber habe mit Flash aber 
nichts produktives gemacht - da sind meine graphischen Skills halt doch 
viel zu schlecht für ;-) Aber wenn Du jemanden findest, der sich mit 
Flash auskennt und Dich auf die Serverseite konzentrieren kannst (oder 
selber in Flash einsteigst) würde ich persönlich die Variante vorziehen 
auch wenn ich Flash für eine normale Website i.dR. als das falsche 
Werkzeug betrachte - wo es Sinn machen kann sollte man es imho genauer 
evaluieren.
Ohne es vorliegen zu haben: Das PHP Mag Titelthema "Flash, PHP und XML" 
scheint da recht nah dran zu sein - den Artikel kannst Du ja mal 
durchblättern....

[Von der Liste nhemen]
>  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.

Sicher und die obigen Dinge können ja auch für alles mögliche 
interessant sein (Angefangen beim einfach Chat bis zur komplexen 
PHP-basierten Maschinensteuerung *g*)  Aber dann die Details der 
Implementierung müssen dann hier nichtmehr hin (und erst die PSe von mir 
unten) ;-)

johannes

P.S. geht es um die Standard-Variante, eine eigene Variante oder darf 
ich auf "Städte und Ritter" hoffen? ;-)

P.P.S. Die Umlaute in Zitaten sind bei mir falsch angekommen, die von 
Dir geschriebenen aber korrekt - liegt das am, von mir gerade 
getesteten, Mozilla Thunderbird oder irgendwo anders?

P.P.P.S. Habe gerade gesehen, dass es jetzt umgestaltes Siedler-MAterial 
gibt - gefällt mir ja nicht so wie die sclhichten alten... 
http://195.212.44.26/siedler/catan-server.nsf/97fee97d35d06c57412569d70032db2d/8b159e938c8caa4ec1256cc500595ec4?OpenDocument