Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
10.7
Mal noch ne kleine Schönheitsfrage:
Sollen die ganzen System.outs in die KonsolenSpieler klasse rein oder dürfen auch ein paar in spiele() wie willkommen zu blabla viel spaß, weil im prinzip weiß ja der spieler nicht wieviel er in eine reihe bringen muss.
marc hat doch geschrieben wir könnten auch einen SwingSpieler schreiben, der würde die Konsolenausgaben in NGewinnt.java nicht sehen, von daher wären sie sinnlos!
die einzige ausgabe die ich halt in ngewinnt hab is herzlich willkommen zu n-gewinnt (wobei halt dann das n ersetzt is durch die zahl die bei spiele() übergeben wird, damit der spieler weiß wieviel in die reihe müssen, da ihm ja das nicht übergeben wird, oder man programmierts a weng außen rum.
@Marc: kannst du das interface nicht dahingehend abändern das dem spieler bei starteSpiel als 4. parameter noch die anzahl der in reihe zu bringenden eigenen münzen übergeben wird?
Ich könnte schon, aber ich will nicht wissen wieviele Leute mit einer Änderung unzufrieden sind, da sie schon fertig sind, bzw wieviele die Änderung nicht mitbekommen. Ich sehe, ein dass das gut in die Signatur passen würde, aber code doch bitte drum rum.
alles kloar, d.h. dann implizit: alle system.outs dann auch in den konsolen spieler packen?
Ja. In der Aufgabenstellung steht ja, dass nur dem KonsolenSpieler was per System.out ausgegeben werden soll. Da das NGewinnt-Spiel nicht ohne weiteres erkennen kann, ob es sich um einen Konsolenspieler handelt und NGewinnt sowieso unabhängig von NGewinntSpieler-Implementierungen sein sollte, muss der System.out-code in KonsolenSpieler.java sein.
Bei starteSpiel() wird ein boolean zurückgegeben, wenn der Spieler ein Spiel mit den gegebenen Parametern spielen kann. Mh kann er das nicht immer? Bei negativer breite, hoehe gibts bei mir ne IllegalArgumentException, ansonsten ist das Spiel aber immer spielbar… oder?
Ich finde auch, dass das überflüssig ist. Ich hab das so interpretiert, dass wenn ein Spieler das Spiel spielen kann, der andere aber nicht, der unfähige automatisch verliert und der andere gewinnt.
Das Spiel ist natürlich dann nicht spielbar, wenn n>max(breite, hoehe). In dem Fall wird bei mir einfach null zurückgeben. Die Spieler werden gar nicht erst benachrichtigt, weil es ein in jedem Fall unmögliches Spiel wäre.
Es entspricht meineserachtens gutem Stil, bei Feldgrößen<=0 sowas wie eine IllegalArgumentException zu werfen, aber in der Aufgabenstellung wird von solchen Fällen nichts erwähnt. Daher ist es wohl wurst, wie man damit umgeht.
Sollte eigentlich schon die Spielerklasse die Eingaben des Spielers überprüfen? Also ob die eingegebene Spaltenummer überhaupt im Feld liegt? Oder muss das auch das Spielfeld übernehmen, solche von Anfang an falschen Eingaben abzufangen?
die spiellogik übernimmt das spielfeld, also auch solche falscheingaben.
der spieler muss bloß drüggn.
der boolean rückgabe wert war für irgendwelceh KIs gedacht. z.b. kann ich mir vorstellen das man auf einem Quadratischen feld anders vorgehen muss/sollte als auf einem rechteckigen.
Stichwort: KI - interessante Lektüre: Minimax-Algorithmus
jap 
allerdings habe ich bevor ich mich an sowas mache erstmal ne frage wegen der blöden symbole
Wie sagt ihr eurem spielern, welches symbol sie haben? unter „außenrum coden“ kann ich mir nicht viel vorstellen… und interessant wäre meines Erachtens nach auch, dass man den Spielern sagt, wie groß das N ist?!
Wir könnten ja ausmachen, dass wir in das Spielfeld ne methode „public char getChar(NGewinntSpieler Spieler) {}“ und eine „public int getN() {}“ einbauen.
Der Aufruf wird dann schön im Spieler in trycatch-Blöcke gepackt, und entweder es geht, oder nicht.
Wenn nicht, könnte man noch nen Algorithmus schreiben, der zumindest den Spielstein nach dem ersten Zug erkennt (unterste Zeile, und die Spalte vom Zug, das muss ja mein Stein sein). Allerdings fände ich das recht übertrieben, und wieviele man in einer Reihe braucht, bekommt man so auch nicht raus.
Was mir an der get-Methode nicht gefällt ist, dass es jeder anders machen wird, und dann wieder kein Spieler zu nem Andren Spielfeld passt!
schonmal ne gute Idee! jedoch wird das nicht funktionieren, da du aus XXXSpieler.java keinen Zugriff auf NGewinnt hast, also auf das Objekt, von daher müsstest du es andersherum gestalten, die Spieler müssten dahingehend erweitert werden das sie eine setter methode haben so das ihnen gesagt wird welches N benötigt wird (also public void setN(int n) { this.n = n;}), das mit dem Symbol dagegen ist nicht nötig, da dem Spieler ja bereits in starteSpiel das Symbol übergeben wird!
Stimmt, das mit den Symbolen habe ich ganz übersehn… noch besser.
Hmm, ob nun ne get oder set-Methode ist mir wurst, hauptsache alle die gleiche 
(PS: Kann man nicht aus der xSpieler.java mit NGewinnt.getN() die Variable holen?!)
probiers aus, und erzähl mir dann wie!
stimmt geht nicht
Ok, dann andersrum, ist ja auch wurst.
Also deine
public void setN(int n) { this.n = n;}?
Da wäre ich dabei
€: Hmm, das ist aber auch ekelhaft, da muss man ja erst probieren, die beiden Spieler aus NGewinntSpieler in KonsolenSpieler umzucasten, um dann auf setN() Zugriff zu haben 
?
Man könnte doch einfach das NGewinntSpieler-Interface manipulieren, so dass bei starteSpiel n noch als weiterer Parameter übergeben wird.
Und am Ende gibt man es noch falsch ab