Lobby-Modus Anregungen

Also nach dem wir jetzt längere Zeit über den Lobby-Modus gefachsimpelt haben sind wir zu folgendem Ergebnis gekommen:

so wie er jetzt implementiert werden soll ist das nicht ganz sinnvoll. Folgende Gründe:

Aufforderungen mit einer passivität des clients ist nicht gut zu implementieren da man dann alle paar Sekunden jeden client abfragen muss(Große Netzlast)

Eine Spielaufforderung kann nicht abgelehnt werden?!

In Lobbys gibt es normalerweiße eine chat.. (welcher sehr praktisch wäre) (dazu müsste der client aber aktiv senden dürfen)

Lobby-Modus ist mit einem bestimmten Spieltyp verbunden d.h. Lobby-Reversi kann nicht TicTacToe spielen ... schade

Darum wäre besser:

Lobby ist ein eigener Regeltyp.
Die komplette Lobby steht dann vor dem eigentlichen Spiel!
In der Lobby(also mit Lobbyregeln) ist der client dann auch aktiv!

Das würde heißen: man verbindet sich mit einem Lobbyclient zu einem Server mit Lobbyregeln und landet in der Lobby des Servers. Bei Spielaufforderung wird dann geprüft ob der client mit Reversiregeln/TicTacToeregeln gegen denn Herausforderer spielen will. Zusätzlich kann man dann noch mit den anderen clients chaten...

Insgesamt bedeutet das ein eigenes Lobby-Interface!(Sinnvoll da momentan wenn man mit Tournamentregeln spielt die entsprechenden Lobby-Funktionen garnicht genutzt werden( eventl. leer sind))

btw: wir haben grad das neue Interface eingebunden und der neue Server kann diese Regeln noch nicht (also testen ist momentan nicht drin) ...

Dafür - also eigene Abfrage s. unten

Wenn ich mir dann 00 Hans Müller aussuche dann will der womöglich aber Backgammon spielen und ich aber Reversi..

Wenn dann doch eher andersrum, also erst Spieltyp wählen und dann die Leut dazu.. und solang man keinen Spieltyp gewählt hat bekommt man auch keine Lobby-Information ab.

Von der Idee den Client aktiv werden zu lassen bin ich nicht soo begeistert, das liegt wohl aber eher daran dass man das schon immer hätte verwenden können (getName, getRules etc), und das jetzt ein paar Wochen vor Torschluss das doch recht schöne (und zugegebenermaßen simple ) Konzept des RPC gründlich kaputtmachen würde.

Und nochwas: Wie wäre es wenn man nach einer Spielpartner-Auswahl-Funktion dem Auserwählten eine Anfrage a la boolean DoYouWantToPlayWith(String player) schickt?

Ich wär auch für eine Realisierung, so wie Marianne sie vorgeschlagen hat, zum einen weil das RPC Konzept damit natürlich beibehalten wird und zweitens weil die Lobby einfach dem Client die Option gibt noch zu wählen gegen wen er Antreten will und mehr nicht.
Stell mir das nicht als Chat Messager vor, dafür gibst andere Tools, sondern du loggst dich ein, weil du gegen Andere Reversi spielen willst oder eben TicTacToe. Vom Konzept her ist das eher so wie eine Arena und du kannst jemand beliebigen zum Match herausfordern.
Ob die Lobby Regeln schon gehen hab ich nicht getestet, aber zumindest mit RULES_REVERSI_TOURNAMENT kann ganz normal getestet werden (also eben die KI ).

Kommt eben drauf an wie man es gerne haette. Ich persoenlich finde es nicht toll die Lobby an einen bestimmten Spieltyp zu knuepfen... nehmen wir an ich will TicTacToe spielen aber niemand ist in der TicTacToeLobby dann moechte ich vielleicht doch was anderes spielen...

ist halt nur eine Frage der Anzeige bzw später auch eine der Implementation... Ich fände es halt recht schoen wenn alle die überhaupt etwas spielen wollten in der Lobby angezeigt werden wuerden...

Ist natürlich schwerer zu implementieren aber wer in seinem Projekt eine sauber MFC trennung hat fuer denn ist diese art der Lobby kein problem...(der sollte dann mit einem LobbyClient alle spiele spielen koennen...)

und das ganze soll auch nur ein Vorschlag bzw Anregung sein...

was mir viel wichtiger wäre:
entweder keine lobby! (damit mehr zeit für KI!!!) oder in der Lobby die Passivität des Clients aufheben!
Aber diesen workaround das wir alle paar Sekunden abfragen was der client tut nur um rauszubekommen ob er mit jemand anderem spielen will werde ich nicht implementieren da mir das zu unsauber ist!

Gut grundsätzlich sehe ich das ein und fände es ok aber eigentlich bin ich dann eher dafür das man garkeine Lobby macht wozu auch... Dann koennen sich zwei leute die spielen wollen gleich direkt verbinden in der form das einer nen server aufmacht und sich lokal verbindet und der andre halt von seinem rechner aus...

Der zweite wichtig Punkt ist folgender: wenn man schon eine Lobby baut dann aber bitte richtig und gescheit. Vorallem wenn man das Protokoll dafür entwickelt ist dabei darauf zu achten das für später wenn man das Projekt eventuell erweitern will, es erweiterbar bleibt!

Stellen wir uns mal kurz vor wir wollen unsre ganze Arbeit später anderen zu Verfügung stellen: es sollen Leute uebers Internet per Applet in einer Internetseite reversi und tictactoe spielen koennen. Dann brauchen wir eine Lobby mit der das auch geht! Wer will dann schon das ganze Lobbyprotokoll ändern?! Und das nur weil vorher nicht nachgedacht wurde und die Leute engstirnig geblieben sind(sorry aber irgendwie erleb ich das zu oft). Und von der Seite her, bitte jetzt entweder: hier gescheites Protokoll oder Lobby bleiben lassen!

Globetrotter hat Folgendes geschrieben:

Ob die Lobby Regeln schon gehen hab ich nicht getestet, aber zumindest mit RULES_REVERSI_TOURNAMENT kann ganz normal getestet werden (also eben die KI ).

ja mittlerweile... (siehe http://www.die-informatiker.net/viewtopic.php?t=7126)

Also mehr Zeit für die KI würde nicht schaden, da hst du Recht

Allerdings dürfte das bei 99% der normalen DAUs dran scheitern dass sie ihre/n Firewall/Router nicht konfigurieren können/dürfen/mögen. Das ist der usability sicher nicht zuträglich

Und wegen der Lobby vor der Spiel-Abfrage: Ich halte das nach wie vor nicht für gut, denn du schreibst du möchtest euer Projekt erweiterbar halten..
bei 10 implementierten Spielen und sagen wir 300 Clients an einem Server würde es mich übel nerven erstmal ca 30 Namen durchzuklicken, bevor einer endlich mal mein Spiel spielen will..

Anderer Vorschlag:
Server sendet spieleliste, Client sendet liste von Spielen die er bereit ist zu spielen. Client schickt Anfrage (Spielername, Spiel) und der Aufgeforderte entscheidet ob er spielen möchte.

Dafür muss die Lobby-Liste vom Server pro Spieler angeben welche Spiele er bereit ist zu spielen.

Dies ginge alles wunderbar mit RPC

Klingt sehr gut nur eine Frage hab ich da: wie willst du das 'Client schickt Anfrage (Spielername, Spiel)' realisieren ohne das Passiv aufzubrechen? oder hast du gemeint das wir in diesem Fall zum passiv 'good bye' sagen ?

weil im Prinzip muessen wir am Server so oder so einen eigenen Thread erstellen der dann ständig alle Clients abfragt...

oder halt einen oder mehrere Threads am Server die auf Anfragen warten...(Hierdurch wuerde zumindest mal die Netzlast gering gehalten werden... aber dafür ist nix mehr mit Client passiv)

Möglichkeit 1 ist wahnsinig unsauber hier dazu mal ein kleines Beispiel:
Stellen wir uns vor das man in einer Wirtschaft Karten spielen kann! Hierzu kann man sich vom Wirt die Karten fuer ein spiel geben lassen. (Wirt=Server) Möglichkeit ein sieht dann so aus:
Wirt fragt gast1: willst du spielen? gast1: nein
Wirt fragt gast2: willst du spielen? gast2: nein
Wirt fragt gast3: willst du spielen? gast3: nein
das ganze wiederholt er jede sekunde! das ist doch sehr unschön...

Möglichkeit 2 sieht dann übrigends so aus:
gast1 sagt: ich will spielen! Wirt gibt karten(bzw Wirt teilt sich und der einer regelt das Spiel der andre bleibt an seinem posten

Das geht mit RPC wunderbar! Natürlich muss der Server mal nachfragen, aber das ist bei den Regeln und bei dem Namen jetzt ja auch so.

(also an sich hast du völlig Recht wg. Netzlast etc, aber ich finde einfach den Änderungsaufwand etwas hoch, zumal wir das dann schon immer so hätten machen können.. und soo viel Zeit haben wir nun echt nicht mehr dass wir wg den doch eher unwichtigen Lobby-Funktionen die Protokollarchitektur komplett ändern)

Was sagen denn die Offiziellen da dazu? War das RPC blos so ne Überlegung die man auch locker verwerfen kann, oder sollte das fest bleiben?

Weil RPC ist für die Lobby relativ unsinnig aber dafür einfacher fürs Änderungen einbauen.

@Seven: Nein, so war das nicht gemeint.

grundsätzlich kann man mit zwei Methoden (serverseitiges RPC, bisherige Strategie des PlayerInterface) beliebige (Lobby)Protokolle kapseln.

String queryLobby()
void sendLobby(String)

(Wir haben ein "client-aktives" Admin-Spiel, ähnlich einem SMTP/POP3/NNTP Protokoll über computeMove(...) und traceMove(...) realisiert.)

Für das Lobby-Protkoll würde ich vorschlagen:
Den Timeout für das queryLobby() nicht zu klein zu machen, sonst wird der Traffic zu groß, vielleicht 15 Sekunden oder länger)

Clientseitig

RULES // Aufforderung an Server Spieleliste zu senden
OFFER {<RULE>}* // Client aktualisiert seine anfangs leere Liste von Spielarten die er bereit wäre zu spielen
INVITE <PLAYERNAME> <RULE> // Aufforderung an <PLAYERNAME> ein Spiel der Art <RULE> zu spielen
ACCEPT // Aufforderung angenommen
REFUSE // Aufforderung abgelehnt
TALK <PLAYERNAME> <MSG> // Sende <MSG> an <PLAYERNAME>
NOOP // keine Aktion
QUIT // verlassen

Serverseitig

RULES {RULE}* // Liste von angebotenen Spielen
INVITE <PLAYERNAME> <RULE> // man wurde von <PLAYERNAME> aufgefordert <RULE> zu spielen
UPDATE <PLAYERNAME> {<RULE>}* // Spieler <PLAYERNAME> hat eine neue Spiel-"Bereitscafts"-Liste angegeben.
USERS {<PLAYERNAME>}* // Liste der Spieler in der Lobby
JOIN <PLAYERNAME> // neuer Spieler in der Lobby
LEFT <PLAYERNAME> // Spieler ist gegangen
MSG <PLAYERNAME> <MSG> // Spieler <PLAYERNAME> sagt zu dir <MSG>

Das ganze würde dann vom Client aus gesehen so ablaufen ("<" Empfang ">"Senden):

< getRules
> Lobby
< getName
> <NAME>
< queryLobby
> RULES
< sendLobby RULES reversi tictactoe ...
> OK
< queryLobby
> OFFER reversi
< queryLobby
> USERS
< sendLobby USERS a b c
> OK
< sendLobby UPDATE a tictactoe
> OK
< sendLobby UPDATE b reversi
> OK
< sendLobby UPDATE c tictactoe reversi
> OK
< queryLobby
> TALK a servus
< queryLobby
> NOOP
< sendLobby MSG a ah, auch da
> OK
< queryLobby
> INVITE c reversi
< queryLobby
> NOOP
< sendLobby ACCEPT //Klar welcher Spieler und welche Spielart (===letztes INVITE)
> OK
< openGame BLACK c // hier ist die Spielart klar (letztes INVITE)
....
< closeGame c
> OK
< sendLobby LEFT a
> OK
< sendLobby JOIN d
> OK
< sendLobby UPDATE d reversi
> OK
< sendLobby UPDATE c reversi
> OK
< queryLobby
> QUIT

Vielleicht noch ServerMitteilungen

INGAME <PLAYERNAME> // Spieler verläßt die Lobby zum Spielen
INLOBBY <PLAYERNAME> // Spieler hat das Spiel beendet und ist wieder in der Lobby

so far

Nachtrag, wenn der Client gleich "on demand" wiessen will ob sich grad was geändert hat kann er jederzeit NOOP senden und bekommt evtl. updates (Aktualisieren-Funktion bei der Gegnerauswahl)

Wenn man will kann man dann ja serverseitig "fake" Spieler reverso_level0 ... reversi_level10 einfügen die sofern aufgefordert und Server-Rechenleitung vorhanden immer ACCEPT antworten und Serverintern als neue KI-Engines der entsprechenden Stufe erzeugt werden.

BTW. man könnte auch INVTE <PLAYERNAME> <RULES> <TIMEOUT> sagen, wobei 0 der Serverdefault wäre.Der Server sollte das jedoch nochmal checken, da er sich bei Timeout 1Mio Jahre sehr leicht für eine DoS Attacke öffnet ...

Ich sehe noch ein Problem wenn man die Lobby client-aktiv und das Spiel selber client-passiv macht: wann/wie schalte ich um?

Die Passivität kann man recht leicht aufgeben, indem man einfach einen multithread-sicheren Zahlengenerator verwendet und vor jede Anfrage eine neue ((sender, verbindung)-eindeutige) Nummer schreibt und die eintrudelnden (von der Gegenstelle zu markierenden) Antworten daraufhin überprüft. Wäre eine schöne Geschichte sowas mal zu selber zu implementieren, samt aller Probleme (überlauffende Anfrage-Speicher, ausbleibende Antworten ..., falsche IDs) (im nächsten Leben).

Was nein?? was war so nicht gemeint auf was hast du geantwortet???
Ich sag einfach mal: JA

So nun weiter im Text: wenn ich dich richtig verstanden habe sendet der Server alle 15 Sekunden dieses queryLoby und bekommt darauf eine Antwort vom Client was dieser haben will und sendet ihm das entsprechnde!

habe ich das richtig verstanden?? wenn nicht bitte verbesser mich!

ich nehme jetzt mal an das ich es richtig verstanden habe dann ändert das tortzdem nichts an dem was ich sage:

Das ist nur ein Workauround um die Passivität zu umgehen!!!
(Denn ich muss am Server tortzdem alle paar Sekunden jedem Client querryLobby senden und dann auchnoch auf die entsprechende Antwort reagieren!)

Sauberer wäre gleich am Server auf Anfragen des Clients zu reagieren.

wieso umschalten??
Meiner meinung Nach gehört das Lobby zeugs in ein eigenes Protokoll und nicht in das schon vorhandene PlayerInterface-Protokoll hinein.

In einer guten Lösung kann der Server in der Lobby zusätzlich auch Befehle empfangen und verarbeiten kann. Am Client ändert sich(im Lobby-Modus) nur das er jetzt Befehle senden kann und zwar nur wenn er in der Lobby ist.
Ansonsten ändert sich nichts.

ja.

ja.

Und wie weis der Client in welchem Modus er sich jetzt zu befinden hat?
stellen wir uns mal vor, der client sendet eine Chatmitteilung. Zeitgleich senet der Server dem Client ein "openGame ..." um ihm mitzuteilen dass er jetzt spielt.
Dann bekommt der Server auf sein openGame die Chatmitteilung und einen Protokollfehler. Sehr gut!
Willst du eine zweite Netzwerkverbindung dafür aufmachen? dann muß man die einander zuordnen, noch besser!

Ich bin ja auch gegen deglichen unnötigen Datentransfer. Hmm was mit gerade noch einfällt. man müßte in Server und Client jeweils in extra Threads die Netzwerkkommunikation verwalten und die eingehenden Meldungen aufteilen in eine PlayerInterface-Queue und in eine Lobby-Queue. Dann könnte man parallel in der Lobby und im Spiel sein. Dann kann man gleich noch seriennummern vor die Playerinterface-Kommandos packen und gleichzeitig n-Spiele fahren und nebenher chatten. das wäre eine sinnvolle Lösung.
Aber doch etwas viel für noch 4 Wochen und Klausurenzeit.

Einleitung: Mir ist klar, dass der Lobby-Modus nur ein sehr simpler Kompromiss ist. Es wäre natürlich sehr interessant, einen Luxus-Server zu programmieren. Dann bräuchte man Chat-ähnliche Räume, wo in jedem etwas anderes gespielt wird und man auch Textmeldungen austauschen kann. Da aber bis Ende des Semesters nicht mehr arg viel Zeit ist, müssen wir uns mit etwas einfacherem begnügen.

Im folgenden erkläre ich kurz, warum ich welche Kompromisse gewählt habe.

Selbst wenn man das einmal pro Sekunde macht, fliessen nur relativ wenig Daten (verglichen mit vielen anderen Protokollen) und sie fliessen nur, während man in der Lobby ist. Dafür darf man den simplen Kommunikationsmechanismus behalten. Neben kompletter Asynchronizität ist auch denkbar, dass der Client so lange blockiert

Nein. Das ist ein wünschenswertes erweitertes Feature, für eine Basisversion aber nicht so dringend.

Das ist 100% asynchron und von daher zu kompliziert. Standalone Instant Message Clients zu verwenden halte ich für zumutbar.

Nebenbei: Es gibt eine sehr gute Bibliothek für das Jabber-Protokoll (das u.a. von Google Talk verwendet wird). Das wäre ein exzellentes Fundament für einen Edel-Lobby-Modus, da man bei Jabber beliebige eigenen Daten huckepack schicken kann.

Stimmt. Da aber TTT nicht so spannend ist, ist die aktuelle Lösung, der Einfachheit halber, ein akzeptabler Kompromiss.

Seven hat Folgendes geschrieben:

btw: wir haben grad das neue Interface eingebunden und der neue Server kann diese Regeln noch nicht (also testen ist momentan nicht drin) ...

Der Lobby-Wunsch kam von Euch, so dass ich da an einigen Stellen nachbauen muss (GUI, Monitor-Protokoll etc.). Da es für Euch keine kritische Komponente ist, haben momentan noch andere Dinge eine höhere Priorität.

Es gibt einen ganz netten Satz zu diesem Thema: "'Perfect' is the enemy of 'good enough'". Es ist keine Schande, mit einer etwas einfacheren und hässlicheren Version anzufangen, da man dann (anhand der Praxis) schneller und besser versteht, was die wirklichen Probleme sind. Polling ist tatsächlich unschön, aber man muss halt auch immer sehen, wie neue Dinge in die bestehende Infrastruktur passen. Beispiel sind die meisten der aktuellen Web-Anwendungen (Google Calendar, Google Mail etc.), die alle (noch) mit Polling arbeiten (Stichworte: Ajax, Comet etc.).

Die Lobby habe ich auch deshalb eingeführt, da wegen der Aufgabentrennung im Team manche Studierenden nichts mehr zu tun hatten.

Mir ist eingefallen, wie das sehr einfach in das momentane Protokoll eingebaut werden kann ohne Mehraufwand.

boolean startGame(PieceColor farbe, String gegner, long timeout)

Die Methode könnte einfach ein boolean zurückgeben. Durch dieses boolean könnte ein Client Spielaufforderungen akzeptieren und auch ablehnen.

Ich werde es anfangs noch nicht mit reinnehmen. Erstens muss man sich sowieso mit den anderen Spielern (z.B. per IM) absprechen, wer gegen wen spielt. Zweitens wird die GUI etwas komplizierter und man muss sich noch mehr Gedanken über Timeouts machen. Also: Wir machen es erst ohne. Dann warten wir das Feedback im tatsächlichen Einsatz ab und korrigieren wenn nötig.

öhm.. ja wird jetzt dann gar nix geändert am aktuellen PlayerInterface?

Weil wenn das mal feststeht würde ich anfangen das zu implementieren..

Berechtigte Frage! Bis morgen abend ist es final (dann habe ich meine Version fertig und kann mir sicher sein, nichts übersehen zu haben). Vorläufige Liste der Änderungen:

• Man benötigt keine Quit-LobbyAction, wenn man die Semantik des Socket-Schliessens für Lobby- und Turnier-Modus unterschiedlich definiert. EDIT: explizites Quit ist doch schöner.
• Bei der Play-LobbyAction will man sicher noch die eigene Farbe wählen (mit der Option, dass der Server das für einen, zufällig, erledigt).
• getRules() werde ich zu setRules(String) ändern. Damit sagt der Server dem Player, was er für Regeln kennt und der Player gibt ein boolean zurück, ob er das versteht. Dann ist der Server spezialisert auf einen Modus und der Player universell.

Vielen Dank für die Diskussionen , das ist doch sicher ein Teil des Software Engineering Process..

.. Also dann keine Vorschläge mehr machen und implementieren? (Weil auf den Folien, Seite 6 steht: "Bis nächste Woche Donnerstag sind noch Änderungen möglich")

Die zweite "occasion" ist noch irgendwie etwas unklar...
waitingPlayersChanged(...) wird aufgerufen, wenn
1. Ein neuer Spieler ist dazugekommen und alle Clients bekommen nun die neue Spielerliste.
aber was ist
2. "The players change". Heißt das, wenn ein oder mehrere Spieler nicht mehr in der Lobby sind, da diese z.b. spielen, oder das Spiel beendet haben?

Vielen Dank.

Schönen Abend

Vorschläge kamen schon eine Reihe und ich bin etwas früher mit einem Prototyp fertig geworden, als ich dachte. Von daher ist es erstmal fertig.

Genau, sie spielen (damit sind sie auch nicht mehr für eine Anmeldung verfügbar) oder haben die Lobby verlassen.

blubb

Läuft das nicht so ab?

< : server to client

> : client to server

< getLobbyAction
(bzw. als String GET_LOBBY_ACTION)
//mögliche Antworten:
 
> !wait
 
> !quit
 
> !play\t<playerName>

wozu müssen diese Actions (bzw. dann die Strings für diese Actions) in einer eigenen (bzw optional in mehreren) Klassen gespeichert werden?

Wenn man es dem Server schickt, muss man es eh zu String parsen, also im Endeffekt ist es nur eine Wrapperklasse für einen String...

Oder hab ich/wir da etwas überhaupt nicht verstanden?

Vielen Dank....

1. Im PlayerInterface gibt es ja jetzt die Methode
boolean setRuleKind(String ruleKind) die einen boolean-Wert an den Server zurücksendet.
Muss dieser "Rücksendewert" nicht auch als PlayerInterface-Konstante definiert werden, oder soll einfach "true" bzw. false" als String zurückgesendet werden?

2. Wann und wie oft wird denn diese Methode aufgerufen?
(Irgendwie ist der Ablauf noch nicht so ganz klar )

Merci und schönen Tag

Genau. Damit kann man Boolean.parseBoolean() einsetzen.

s@sh hat Folgendes geschrieben:

2. Wann und wie oft wird denn diese Methode aufgerufen? (Irgendwie ist der Ablauf noch nicht so ganz klar )

Der Anfang des Protokolls ist immer einmalig ein getName() und ein setRuleKind(). Es ist nur fest, dass diese beiden Methoden zuerst kommen, aber nicht in welcher Reihenfolge (mein Server macht in der nächsten Version zuerst getName()). Mit setRuleKind() kann man sich z.B. einen manuellen Reversi-Client programmieren, der je nach Server eine Lobby-GUI oder eine Turnier-GUI hat. Für erstere muss man sich überlegen, wie man dem Nutzer die Möglichkeit zum Spiel-Start gibt, für zweitere nicht.

Damit alles klar?

Heisst das also, dass der Server insgesamt nur für eine Spielart aus (R_T, R_L, T_L, T_T) setRuleKind aufruft, und der server damit insgesamt auch immer nur eine einzige Spielart unterstützt? Oder wird über alle Spielarten des Servers der Client mit ca. 4 setRulesKind() aufrufen abgeprüft. Ersteres wäre echt sehr unnutzbar.
Gibt es eine Lobby für alle Lobby-Spielarten oder 2 Lobbys für Reversi und TicTacToe?