[php] Spiel Kommunikation

[Tobias Schlitt]

On Sun, 2003-12-07 at 00:33, Johannes Schlueter wrote:
> Hi,

Hallo Johannes!

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

Dann ist ja gut. ;)

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

Na ja, wenn Du eine Transaktionsbaiserte Datenbank da hast, ist es ok.
Bei MySQL 3.x wird das schon schlechter. Besonders mit dem update.
Ausserdem wird das Datenmodell IMHO extrem unübersichtlich.

Also, diese Variante scheidet bei mir aus.

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

Also, die Idee mit dem hin- und herschalten ist irgendwie nicht so
begeisternswert. Von daher eher die Variante 1 Banana / Spiel. Damit
könnte man einiges anstellen. Werde ich auf jeden Fall mal evaluieren.

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

In Sachen Handeln / Chat finde ich IMHO die unten beschriebene IRC
Variante echt gut. Hier hast Du direkt ne echte Queue und brauchst Dir
keine Gedanken mehr über konkurierende Zugriffe zu machen.

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

Na ja, dann muss man die Maschine halt entsprechend Skalieren! ;) Da ich
das Projekt zur Zeit ja rein privat mache, werd ich an den Punkt nicht
all zu schnell kommen.

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

Na ja, die 2er Version ist als Extension verfügbar. Werds mal versuchen
zu kompilieren. Ansonsten nehm ich halt ne Normale IRC Klasse
(PEAR::Net_IRC / PEAR::Net_SmartIRC). 

Die SRM Variante halte ich für zu instabil. Das ist mir zu heukel. Ich
werd mal mit rumspielen, aber ich glaube IRC ist mir angenehmer.

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

Schon richtig, aber nicht realisierbar. Da das Spiel sehr
interkommunikativ ist (Handeln, etc.) ist das irgendwie nicht so
prickelnd. Ausser man setzt die Ticks auf 1 Minute, was aber wieder
einen gehörigen Rechenoverhead erzeugt.

Oder wie hattest Du Dir das vorgestellt?

Das Problem mit getrennten Internet- / IRC-Verbidnungen habe ich bei
anderen Varianten aber immer, das Stimmt. Allerdings sollte ein break
für die anderen, sobald ein "Foo has left the channel" kommt. Das
Problem ganz gut lösen. 

Dann kommt nur noch das Problem auf mich zu, dass ich den aktuellen
Spielstand irgendwie speichern können muss. Am Einfachsten wäre es,
einfach sämtliche Objekte in ein Datenbank-Set / File zu schieben. Da es
nicht auf schnelle Lese- / Schreibzugriffe ankommt scheint mir das die
einfachste und beste Alternative zu sein.

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

Das klingt allerdings auch nicht schlecht. Sollte der Ansatz
funktionieren scheint mir das ideal zu sein. Ausserdem abstrahiert man
damit ganz gut das Frontend, womit auch eine spätere Implementierung in
Flash nicht ausgeschlossen 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 ;-)

Eben. Das war auch meine Idee.

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

Habe ich gestern auch entdeckt. Allerdings noch nicht die Muse gehabt zu
lesen. Muss ich mal tun. Auch wenn mir Flash wirklich wiederstrebt
(graphisch stehe ich genauso da wie Du) kann mir das XML Geraffell ganz
gut weiterhelfen. Wie sagt Sterling immer so schon? "You know, XML is
the solution to all of your problems." ;)

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

Da geb ich Dir wohl recht. Wobei ich gerne noch demnächst ne Art
Blueprint posten würde (Prozessabläufe, UML, etc.) um Eure Meinung
einzuholen.

> johannes

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

Na ja, im Moment ziele ich erstmal auf die Basisversion. Allerdings
möchte ich schon die Architektur so flexibel halten um nachher mit nicht
all zu viel Mehraufwand auch die anderen Variantne zu implementieren.
Kannst Dir die Tage ja mal meinen Blueprint ansehen. Vielleicht hast Du
ja Lust mit zu machen, dann kämen wir schneller auch "Städte und
Ritter". ;)

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

Lag an meinem Webmailsystem vermutlich.

> 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

Die neuen Sachen sind nicht der Hit. Habe jetzt auch ne neue. Ziemlich
unübersichtlich (Siedlungen/Städte unterscheiden, z.B.) aber vom Modell
her echt schön gestalltet. Macht halt das Spielwfeld noch ein wenig
komplexer, als es schon ist.

Grüße! 
Toby

geek by nature, php by choice http://www.schlitt.info