[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