Lobby-Modus Anregungen

Ja genau. Wie man sie implementiert ist ziemlich egal, ich denke es ist einfach schöner als ein String[] zurückzugeben. Außerdem kann man in der Klasse gleich schön die Parameter in den richtigen Formaten speichern.. z.B. PieceColor

Genau. Der Server ist auf eine Regelart festgelegt (für eine Lebenszeit). Wer mehr will, muss parallel mehrere Server (auf unterschiedlichen Ports) starten.

Gib Beispiele, dann kann ich mit der Aussage auch etwas anfangen.

Basti hat Folgendes geschrieben:

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

Der Aufwand lohnt tatsächlich nur wegen ACTION_PLAY. Strings direkt zusammenzubasteln ist immer etwas hässlich. Um das zu vermeiden, kann man genauso statische Methoden verwenden. Aber: Da Methoden in Java nur einzelne Werte zurückgeben können, wird man den Rückgabewert so oder so in die Instanz einer neuen Klasse stecken. Klassen haben immer den Vorteil, dass man alles zu einem "Thema" an einem klar definierten Ort findet. Also hier (z.B.): In der abstrakten Oberklasse gibt es einerseits eine statische Factory-Methode "parseProtocolString", die LobbyAction(-Unterklassen) zurückgibt. Andererseits ist eine abstrakte Methode "toProtocolString()" definiert, die Unterklassen wie LobbyActionPlay implementieren müssen.

Weiterer Gesichtspunkt: Wie schlage ich alles relevante zu einem Thema nach? Wenn es ACTION_PLAY nicht gäbe, könnte der Rückgabewert per Enum implementiert werden. So kann man immerhin mit Eclipse zur Klasse LobbyAction springen und sich dann noch alle Unterklassen anzeigen lassen.

Nunja wir haben seit Anbeginn eine Spielart admin (die als Spielbrett und Spielzüge realisiert ist) die innerhalb des "alten" Playerinterface-Protokolls eine CHAP-SHA512-authentifizierte Administration erlaubt. Das alles ging über den einen Standard-Port und den Standard-Ablauf den jeder andere Spieler auch durchlaufen hat. Jetzt muß man irgendwie mehrere (evtl über einen Server-Manager verknüpfte) Instanzen erzeugen, zudem muß man die Ports "raten"/berechnen.

Verstehe noch nicht ganz. Wer wird administriert? Der Server? Was macht diese Administration? Ist das Überwachung im Sinne des PST-Monitors? Oder wird auch gesteuert? Was?

Vielleicht wäre es machbar, dass man getRules() wieder aufnimmt, und "Lobby" anfordert.
Nun fragt der Server nacheinander alle seiner Spielarten nacheinaner mit setRulesKind() ab und merkt sich welche Spiele ein Spieler spielen würde. Bei der LobbyAction play wird die Spielart mitgeliefert. (Der Server checkt das dann nochmal). Der Server packt die Spielart dann nochmal in die Mitteilung an den anderen Spieler.

Der ganze abstrahierte Code für n-viele parallele Spielarten wäre dann nicht ganz verloren.

BTW automatisches serverseitiges Umbenennen ist sehr uungeschickt, da der Client seinen neuen/eingetragenen Namen in diesem Fall nicht mehr kennt, und somit auf bllöd versucht ein Spiel gegen sich selbst anzuzetteln.

Ja der Server, also Load-Begrenzung, Turniere erzeugen/starten/löschen, normal runterfahren/anhalten, Netzwerkports hinzufügen/entfernen, Nutzungstatistiken/Turnierverläufe.

OK, der Knackpunkt ist für Euch das parallele Spielen von mehreren Spielarten und/oder -modi. Sonstige Admin-Mechanismen würde ich als getrenntes Thema sehen; zumindest habe ich dafür ein komplett separates Protokoll. Dann könnt ihr aber doch folgendes machen: Ihr macht eine erweiterte Version des Servers und des Spielers mit folgender Variation:

• Server: Schickt alles, was er kann an den Spieler (also mehrere setRuleKind). Wenn dem Spieler nichts davon gefällt, wird der Spieler disconnected.
• Spieler: Gaukelt dem Nutzer vor, dass es auf dem Server mehrere "Räume" gibt: Einen für Reversi, einen für TTT etc. Vor Server-Kontakt muss sich der Nutzer auf einen Raum festlegen, wenn es den nicht gibt, dann macht der Server ein Disconnect, weil der Spieler mit nichts zufrieden ist und der Spieler kann dem Nutzer einen leeren Raum vorgaukeln. Raum wechseln bedeutet, disconnect, neuen Raum wählen, wieder beim Server anmelden.

Das geht aber mit dem momentanen PlayerInterface, wenn man den Client darauf einstellt, dass setRules auch mehrmals aufgerufen werden kann. Das kann ich als Kommentar noch in die Spec schreiben. EDIT: Denkbar ist auch ein boolean "lastInvocation" als zweites Argument, das von den meisten Spielern ignoriert wird, das ihr aber zum anzeigen des leeren Raumes verwenden könnt.

Genau. Deshalb findet die von mir vorgeschlagene Methode auch rein Client-seitig statt, eher von der Marke "netter Hack".

Genau. Aber unser Admin-Spiel passt perfekt in diese Umgebung, daher ist es kein getrenntes Thema!

Genau so ist es momentan implementiert, desshalb waren wir über das Statement, dass der Server jetzt durch "ein setRuleKind()." so drastisch beschnitten werden sollte so schokiert.

Das mit den Räumen (Punkt 2) hatten wir vor.. ich verstehe aber den Grund nicht warum das der offizielle Server nicht auch so macht..(?)

Ganz abgesehen davon: was hat es für einen Sinn einen Server zu schreiben, der seine Dienste exklusiv anbietet? Das wäre ja wie ein Webserver der ENTWEDER http ODER ftp unterstützt.. und dazwischen müsste ich immer den Webmaster bitten den Server neu zu starten..

Zwickt es mit dem letzten Vorschlag sonst noch irgendwo?

Momentan ist mein Ziel, die zwei Modi jeden für sich möglichst gut zu verstehen und für möglichst einfache Server zu sorgen. Später zusammenstecken kann ich immer noch. Ich verstehe aber, wenn das jemand gleich machen will. Momentan habe ich nur den Bedarf, entweder Reversi oder TicTacToe und entweder Turnier oder Lobby zu spielen. Dieser Wunsch kann sich ändern, wenn ich einsetze, was ich programmiert habe, aber deshalb ist es ja *Soft*ware im Sinne von Flexibleware.

Eine flexible Codebasis hilft mir aber auch beim getrennten Programmieren (also wenn ich noch nicht einen Alleskönner-Server machen will), denn dann kann man beide Server aus sehr viel ähnlichen Bausteinen zusammenstecken. Und wenn man seine Codebasis in Ordnung hat, dann schockiert einen relativ wenig, wenn der Kunde heute hü (getrennte Server) und morgen hott (ein Alleskönner) sagt.

Bei den Lösungen, die ich kenne, sind httpd (der HTTP-Dämon) und ftpd unterschiedliche Programme, die auf unterschiedlichen Ports (gleichzeitig) laufen. Beide greifen auf eine Vielzahl ähnlicher Bibliotheken zu (zweimal kommt ja z.B. TCP/IP zum Zug). Genau so sind meine Prototypen momentan designt.

Oja, genau darum geht es uns.. wir vermischen die Spiele ja nicht irgendwie

Ja gut, dann hoff ich ist für uns alles klar..

Kann es vielleicht sein das:

boolean setRuleKind(String ruleKind)

total unsinnig ist!?

Normalerweise will ich als Client wissen welche Protokolle/Codierungen/Spiele der Server unterstützt.
Was soll ich denn jetzt als Manueller-Spieler zurückgeben?
1. das Spiel ich spielen kann?
2. das Spiel ich spielen will?

Wie soll das aussehen?
1. den Client jedes Mal fragen ob er dieses Spiel spielen will/kann?
2. den Client gleich am Anfang fragen was er spielen will und dann automatisiert auf die Anfrage reagieren?

Beides macht für mich irgendwie keinen Sinn...

Und was soll dann der Server machen?
Unser LoginServer hat einfach den Spieler gefragt (getRules) was er spielen will und ihn dann in die jeweilige Lobby geschmissen. Und jetzt?

Für jede Spielart einen LoginServer(auf verschiedenen Ports) und eine Lobby für jede Spielart?

Find ich jetzt nicht soooo sinnvoll...

Was war denn so verkehrt an der getRules???
Wenn doch setRuleKind das selbe macht!?

Naja, der Client kann jetzt so gebaut sein, dass er bei mehrfachen Fragen sein Spiel auch mal ändert.. also zumindest bin ich jetzt nicht so begeistert, das Ganze das jetzt doch mal fix sein sollte wieder zurückzuändern..

Weil alle paar Tage das Playerinterface um-zu-implementieren find ich grad nicht soo lustig..

Marianne Busch hat Folgendes geschrieben:

Weil alle paar Tage das Playerinterface um-zu-implementieren find ich grad nicht soo lustig..

Hey, kann ich doch nix dafür, es hieß ja:

Heut ist Mittwoch!

Aber noch was anderes:

    /**
     * Signature:
     * <blockquote>
     * Play(PieceColor ownColor, String opponentName, [long computationTimeout, boolean forceTimeout])
     * </blockquote>
     * Comments:
     * <ul>
     * <li> If ownColor is <code>null</code>, it means that the choice of color
     * should be randomized by the server.
     * <li> We add the network latency to the computationTimeout! How the server determines
     * that latency is unspecified.
     * </ul>
     */
    public static final String [inlinecode]ACTION_PLAY[/inlinecode] = "!play";

Wie soll das denn jetzt genau aussehen?
1. Auf welche Serveranfrage? getLobbyAction()?
2. Was hat Play(PieceColor ownColor, String opponentName, [long computationTimeout, boolean forceTimeout]) genau mit ACTION_PLAY zu tun?

Das Action_Play hat halt Parameter.. sozusagen mehrelementige Rückgabewerte

(die Action Strings sind Antworten auf getLobbyAction)

Auf die Idee bin ich auch gekommen, nur steht des eben nett genau da!?
Und es steht eben "Play(PieceC..." und nix von ACTION_PLAY oder "!play" oder...
(irgendwie geht mir schon wieder die UML-Protokoll-Definition ab, die es angeblich gibt, zumindest hat es das ja am Anfang des Semesters geheißen... )

AYBABTU hat Folgendes geschrieben:

Auf die Idee bin ich auch gekommen, nur steht des eben nett genau da!? Und es steht eben "Play(PieceC..." und nix von ACTION_PLAY oder "!play" oder... (irgendwie geht mir schon wieder die UML-Protokoll-Definition ab, die es angeblich gibt, zumindest hat es das ja am Anfang des Semesters geheißen... )

ACTION_PLAY ist doch Play.. und das ist gemeint

Die Frage ist, wer hat die Kontrolle: Server oder Client? Da jeder (naturgemäß) etwas anderes in der Protokollspezifikation sieht, normiere ich garade folgendes: Der Server entscheidet sich für einen festen Modus und der Client kann über setRuleKind() erfahren, wie diese Entscheidung ausgefallen ist und entsprechend darauf reagieren. Leute, die an dem alten getRules() hängen, können quasi ein getRules mit einer Menge an Rückgabewerten (nicht nur einem) programmieren, indem der Server über alle momentan bekannten Variationen iteriert und jedesmal den Client fragt, ob er Lust hat, so zu spielen. Der Client muss sich aber am Anfang einer Socket-Verbindung verbindlich für die gesamte Verbindung festlegen.

Bei dieser wie bei sehr vielen Designentscheidungen steckt sehr viel persönlicher Geschmack drin, deshalb kann man oft die Entscheidungen anderer Leute nicht verstehen (weil sie einfach dem eigenen Geschmack widersprechen). Da muss man immer aufpassen, dass es nicht in einen Diskussionsstil abdriftet, der ähnlich ist wie bei: "Was ist besser? Buddhismus oder Christentum? SPD oder CDU? Emacs oder Vi?".

Das momentane PlayerInterface bleibt, nur ein Kommentar wird ergänzen, dass man setRuleKind() auch mehrmals aufrufen kann.

Genau.

Das sind die bisher verwendeten RPC-Regeln in der umgekehrten Richtung (diesmal vom Client zum Server).

Ähm, wer frägt jetzt wen, nochmal!?

Ich hätte halt gern was gehört wie:
es muß nicht:

Play(PieceColor ownColor, ...

sondern:

!play(PieceColor ownColor, ...

heißen, oder so..

Ansonsten weiß ich nämlich nicht genau was ACTION_PLAY usw. soll...

Play(PieceColor ownColor, ...

!play(PieceColor ownColor, ...

ja exakt.

Play(PieceColor ownColor, ...

!play(PieceColor ownColor, ...

Signatur ist

Play(PieceColor ownColor, String opponentName, [long computationTimeout, boolean forceTimeout])

Zurückgeschickt wird (bei import static PlayerInterface.*)

ACTION_PLAY+SEP+ownColor.toProtocolString()+SEP+opponentName+SEP+Long.toString(computationTimeout)+SEP+Boolean.toString(forceTimeout)

Der Server macht quasi den Methoden-Aufruf, der Client erfährt dadurch, an welche Regeln sich der Server hält. Das "erfahren" im obigen Zitat ist also passiv gemeint.