Einfaches Schachprogramm - Designproblem (Beziehung Figuren <-> Brett)

[volkard]

walker schrieb:

Naja, die unterschiedlichen Objekte würden sich sehr wohl unterscheiden, und zwar wegen der jeweiligen Liste der Felder, die sie betreten dürfen (sie sind also doch nicht attributlos!)

es ist auf jeden fall komisch, wenn ein objekt sowohl selber weiß, wo es steht, als auch einfach sich nur in diesem wissen von seinen kollegen unterschiedet, obwohl der benuter des objekts (das spielbrett) eh immer weiß, wo es steht und das billig weitersagen könnte.

Oder meinst du ich sollte generell nur _eine_ Liste verwenden, die dann z.B. in der Schachbrett Klasse gespeichert wird und zwar für gerade die Figur, die ziehen wird? Das wär, wenn ich recht überlege, eigentlich ausreichend.

noch weniger. die liste ist weder attribut des steins (ein bauer ist keine figur nach schachterminologie!) noch attribut des bretts. einfach nur kurzlebiger returnwert.

Ich werd mir wohl morgen in der Schule nochmal den Kopf darüber zerbrechen...

ein paar wochen darf es schon noch dauern. mit versuchen natürlich. und ich sage dir, es wird einfach nicht funktionieren, daß du erst planst und dann klappt es. du wirst beim implementieren voll oft sehen, daß ein leicht anderer plan am anfang doch besser am ende wäre. manchmal so erheblich besser, daß man 5 klassen wegwerfen muss und mit der anderung am anfang nochmal aufsetzen. aber mach das. sei da ganz cool nd tu so, als würdest du nicht deine fehler korrigieren, sondern die deines feindes und sei stolz auf jede verbesserung.

was den Spielsteintyp betrifft werd ich es wohl vorerst bei einem enum belassen -- aber wenn es kein enum ist, dann ist es ja wieder eine Klasse, was ja laut deiner ersten Aussage schlecht ist, wenn sie attributlos sind...

enum oder klasse. es gibt wieder aktuelle forschungsergebnisse, die für klasse sprechen. wenn funktionszeiger echt nötig wären, um eine switch-orgie zu vermeiden, dann ist im allgemeinen stattdessen das dispatchen per vtbl noch besser. und genau da kann dann doch wieder die attributlose klasse kommen, die ist normal, um funktionszeigertabellen zu umgehen.

Naja ich hoffe nicht allzu konfus geschrieben dazu haben  :)

konfuser als ich schreibste bestimmt nicht. ich kann deine texte schneller lesen als meine.

Letzte Frage: Warum sollten Entwurfsmuster hinderlich sein?

weil du nicht suchst, WIE du was zu machen hast, sondern WAS du zu machen hast. entwurfsmuster sind IMHO einfach noch zu früh für dich. sie würden deine probleme ganz verwischiwaschien. du würdes auf einmal überlegen, wie du muster einbaust, ohne zu wissen, was rauskommen soll. das erscheint mir fatal hinderlich. ich hab mal ein 4-gewinnt-programm gebaut. so auf meine weise. so lange, bis ich echt keine vereinfachung mehr sah. es war fast nur begriffsbildung. kein akte, der algorithmische oder musterliche hilfe gebrauchen könnte. es war nur eine sehr, sehr lange suche nach den begriffen, die sowohl in der außenwelt klar verständlich als auch im programm mit fast gleicher bedeutung klar verständlich sind. deswegen auch der oben genannte spielleiter. er hatte sich zwei spieler genommen (zeiger auf Spieler), ein brett (Brett) und je abwechslend ie speiler gefragt, welchen zug soie machen sollen (Zug Spieler::getZug(brett const& brett)). und nochj halt nach jedem zug auf unentschieden und gewonnen geprüft. an sich eine triviale sache. und so einfach sollte es bis unten gehen. und ich gebe dir jetzt nicht meinen 4-gewinnt-code, obwohl ich sehr stolz darauf bin. du hast mit deiner programmieraufgabe dir eine aufgabe gestellt, die dich enorm weiterbringen kann und das kostet zwar zeit, wird sich aber vielmals auszahlen, weil du in folgenden aufgaben einfach erfahrung hast. in wichtigen sachen. in entscheidungen, die echt nicht von vorn herein absehbare resultate zeitigen, sodern wo sich fehlentscheidungen erst spät rächen. und diesen gemeinen effekt haste hier fast kostenlos (andere projekte mit so ner gemeinheit kosten immer monatelange arbeit, bevor sich der fehler rächt).

[phlox81]

Ich denke Grundproblem ist, das das "Schachbrett" weis, wo die Figur steht,
die Figur weiss wie sie ziehen kann, das Schachbrett weis aber als einziges
ob sie da überhaupt hin ziehen kann. So kann die Figur nicht wissen,
ob das Feld besetzt ist oder nicht.

[Jockelx]

volkard schrieb:

Ich wollte ursprünglich eine "Chessboard" Klasse erstellen, die aus einem 8x8 Array der Klasse "Field" besteht, welche wiederum einen Zeiger auf die dort stehende Figur (falls sich dort überhaupt eine befindet) beinhaltet.

8x8-Array des enums spielstein reicht eigentlich.

Da möchte ich widersprechen. Vielleicht willst du deinem Programm
ja doch irgendwann eine KI verpassen und dann brauchst eine
Bewertung der Positionen.
(Mittendrin steht man besser, als am Rand, usw...)

Jockel

[Jester]

Dieses Wissen und die dazugehörigen Daten kann man dann aber bequem in der Klasse KiSpieler unterbringen.

[Jockelx]

Da sehe ich keinen Vorteil. Insbesondere da man ja noch mehr
Informationen auf das Spielfeld legen kann, z.B. 'Visible' bei
12x12 - Brettern. Das aufteilen des Bretts in viele 12x12 (oder 8x8)
Arrays macht meiner Meinung nach keinen Sinn und verwirrt nur.

Jockel

[volkard]

Jockelx schrieb:

Da sehe ich keinen Vorteil. Insbesondere da man ja noch mehr
Informationen auf das Spielfeld legen kann, z.B. 'Visible' bei
12x12 - Brettern. Das aufteilen des Bretts in viele 12x12 (oder 8x8)
Arrays macht meiner Meinung nach keinen Sinn und verwirrt nur.
Jockel

wer spricht von vielen arrays?

[Jockelx]

volkard schrieb:

wer spricht von vielen arrays?

Ein Volkard und ein Jester

Vielleicht hab ich euch auch missverstanden, aber dein Vorschlag
war doch ein enum-Array mit enum {BAUER, TURM,..} oder sowas zu
nehmen. Meiner Ansicht nach gehören aber in ein Schachfeld
mehrere Informationen, weshalb eine Feldklasse vorteilhaft ist.

Jockel

[Jester]

Jo, genau ein Array sollte es geben mit 12x12 Größe. Und da sollte drinstehen können was auf dem Feld ist (Bauer, Läufer, etc. oder auch Leer/blockiert), also ein enum.

Welche Informationen möchtest Du denn noch im Feld unterbringen?

[Jockelx]

Wie gesagt, beispielsweise wie 'wertvoll' die Position ist.

[MisterZ]

Jockelx schrieb:

Wie gesagt, beispielsweise wie 'wertvoll' die Position ist.

Er will ja keine KI schreiben, hier ist nur relevant, welche Figur sich wo befindet.

[Gast]

Jockelx schrieb:

Wie gesagt, beispielsweise wie 'wertvoll' die Position ist.

Das ist ne KI-Sache. Ein TryToControlCenterAiPlayer kann andere Prioritäten setzen, als ein AttackFromSidesAiPlayer oder ein menschlicher Spieler. Und dem Feld geht das schon gleich gar nichts an, wie irgendein Spieler irgendwas bewertet, IMHO.

[Jockelx]

Langsam komme ich mir veräppelt vor!

Ja, natürlich ist das eine KI-Sache, hab ich ja auch gesagt, dass
eine spätere Änderung auf KI dann umständlich wäre.
Bei der Schachprogrammierung hat jedes Feld im Mittelspiel eine
(zunächst) konstante Wertigkeit, d.h. dass nicht nur wieviel schlage ich/
wieviel verliere ich, sondern auch wo stehe ich anschliessend bewertet
wird. Daher brauch man ein 8x8-int-Array, wo die Wertigkeiten drinstehen
und das wären dann schonmal 2 Arrays. Wenn ich noch etwas überlege,
fallen mir sicher noch weitere ein.

Jockel

[Jester]

Jo, diese Wertigkeit gehört aber vom Konzept her trotzdem in die KI und nicht in das Spielfeld.