• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Go-Statistik Programm

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
Hallo Leute,

ich habe vor einiger Zeit das Spiel Go für mich entdeckt.
Leider bin ich wohl noch nicht all zu gut in diesem Spiel. Daher würde ich ganz gerne ein kleines Programm mit euch entwickeln, in dem man ein Go-Spiel eintragen kann und das von Zug zu Zug die "vermutlichen" Teritorien / Punkte anzeigt. Vielleicht dazu auch noch einen Graph mit sowas wie einem Verlauf, wie sich die Teritorien usw. über den Spielverlauf verändert haben.
Hat da jemand Lust mitzumachen? Alleine ist mir das vermutlich zu aufwändig und ich würde die Lust daran verlieren. Zudem habe ich nicht die Zeit, das komplett umzusetzen.
Aber vielleicht ist ja jemand anderes ebenfalls daran interessiert und möchte das mit mir angehen?

Die Sprache ist mir dabei relativ egal, da allerdings relativ viel berechnet werden muss, würde ich vielleicht JavaScript ausschließen, da dort einfach die Performance zu gering sein würde. (oder nicht?)

Hey,
verlinke doch das Github-Projekt im Startpost.
Ggf. auch (dann für später) eine Art Versionsnotiz im Startpost, also: "TODO: ... DONE: ..." usw., dann ist das ganze besser überschaubar.

Github: GoStatistics

Spiellogik:
Done:
  • Coordinate Klasse erstellt. Sie beinhaltet die x und y Koordinaten. Sie stellt einen eigenen Datentypen dar.
  • Group Klasse erstellt. Sie enthält eine Sammlung von Coordinate-Objekten, die zu einer Gruppe zusammengefasst werden.
  • Turn Klasse Grundgerüst erstellt
  • Board Klasse erstellt. Sie stellt die Dimensionen des Spielfeldes bereit und hält gelegte Gruppen und Züge. Zudem bietet es eine Möglichkeit Nachbarn der Coordinate / Gruppe zu bestimmen.
Todo:
  • Coordinate Klasse um Funktion erweitern, die die eigenen Nachbarn ermitteln kann. Nachbarn sind nur horizontale oder vertikale Nachbarn.
    • Möglicherweise sollte die Coordinate Klasse statisch die Grenzen des Spielfeldes kennen, damit nur valide Nachbarn ermittelt werden.
  • Group::getNeighbours() ist derzeit noch nicht implementiert.
    • Möglicherweise sollte die Group Klasse statisch die Grenzen des Spielfeldes kennen, damit nur valide Nachbarn ermittelt werden. Die getNeighbours Funktion kann derzeit noch Coordinaten außerhalb des Spielfeldes zurückgeben.
  • Die Funktion Group::add() benötigt ggf. noch eine Überprüfung, ob die hinzugefügte Coordinate überhaupt der Gruppe zuzuordnen ist. Möglicherweise über eine eigene Funktion, die überprüft, ob die Koordinate an einem Nachbarfeld der bisherigen Member liegt. (Coordinate-Nachbarn bestimmen und prüfen, ob mindestens einer davon ein bisheriger Member ist...)
  • Datentyp von Group::m_members überprüfen. Gibt es einen sinnvolleren Datentypen als einen Vector für dessen Aufgabe?
  • Die Klasse Group könnte eine Funktion "merge(Group)" bekommen, um einfacher zwei Gruppen miteinander zu verbinden.
  • Turn::isValid() muss noch implementiert werden. Wann ist ein Zug valide? Diese Funktion wurde durch die folgende ersetzt.
    • Funktion Board::isValid(Turn) implementieren. Dabei ist nicht nur zu überprüfen, ob der Zug von dem richtigen Spieler ausgeführt wird (Color) sondern auch, ob das zu besetzende Feld frei ist sowie besetzt werden darf (Atari einen Zug zuvor ... oder die Zielgruppe sich selbst entfernen würde (Zielgruppe kann in diesem Fall auch der neu zu setzende Stein sein))
  • Board::applyTurn(Turn) muss noch implementiert werden. Der übergebene Zug muss ein Element zu den entsprechenden Gruppen zuordnen, ggf Gruppen zusammenführen und den Zug dem Verlauf (m_turnHistory) zuordnen Das meiste hiervon wurde bereits getan. Es wird noch folgendes benötigt:
    • Überprüfung, ob man sinnvoller auf die Gruppen zugreifen kann. Derzeit wird ein Vector<Group*> zwischengespeichert und entsprechend später überflüssige Gruppen gelöscht.
    • Es wird noch eine Implementierung benötigt, die umzingelten Gruppen zu entfernt. (Ganz unten in applyTurn(Turn) )
      • Es muss noch eine Regel für Atari hinzugefügt werden, bei denen auf ein vorherigen entfernten Stein in einem Atari nicht gesetzt werden darf, falls dadurch der letzte Gegnerstein gefangen wird. Falls mehr als der letzte Gegnerstein gefangen wird, darf der Stein gesetzt werden (da damit das Atari aufgelöst wird).
  • Überprüfen, ob für die ein oder andere oben genannte Aufgabe ein verschieben von manchen Variablen/Attributen notwendig ist.
  • Die Operatoren von Group könnten fehlerhaft sein. Kann da jemand einmal rübergucken?
  • Hinzufügen von isNeighbour() Funktionen
  • Überprüfen, ob isValid(Group) um die Funktion, zu überprüfen, ob alle Member miteinander verbunden sind, hinzugefügt werden sollte. (Die Funktion isValid(Group) hat nun auch eine Überprüfung, ob die Mitglieder der Gruppe miteinander verbunden sind)
  • Funktionen oder Funktionsblöcke, die in Board::applyTurn(Turn) und Board::isValid(Turn) mehr oder minder gleich sind in entsprechende Funktionen auslagern.
  • Board::getGroups() mit default-Parametern ausstatten und vereinfachen. Dopplung von Code vermeiden.



Grafische Oberfläche:
Todo:
  • All

Statistiken:
Todo:
  • All
 
Zuletzt bearbeitet:

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Ich lerne ja gerade über ein Fernstudium C++, soweit ich im Bilde bin, kannst du ja C++. Da könnte ich dir vielleicht auch etwas unter die Arme greifen.
Wäre eine Idee.

Allerdings weiß ich durch das Fernstudium nicht, wie viel Zeit ich neben der Arbeit habe, da wirklich aktiv mit zu wirken, eben weil ich auch Deadlines habe die ich einhalten muß um mich in den Stoff einzuarbeiten.

Ich sehe aber schon nen Vorteil darin, in der Sprache selbst mal etwas zu schreiben, auch wenn dies nicht unbedingt gleich hoch qualitativer Code wäre den ich (ohne die richtige Ahnung in der Sprache) produzieren würde.

Aber grundsätzlich wäre das interessant. Über die Details müsste man sich aber noch einmal austauschen. :)
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #3
C++ kann ich soweit ausreichend gut.
Lediglich grafische Oberflächen, die bei sowas schon ganz schön wären, sind absolut nicht meine Stärke - wenn nicht sogar mein persönlicher Horror.
Da müsste ich selber auch mal schauen, was man da so nutzen kann und so weiter.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
C++ wäre jetzt nur eine Idee - aber das lerne ich gerade, daher wäre das für mich interessant.

Müsste man mal abstecken was du dir vorgestellt hast und mit welchen Frameworks das zu realisieren wäre, was eine GUI angeht ;)
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
Daher würde ich ganz gerne ein kleines Programm mit euch entwickeln

Wie klein kann das denn sein, bei einem so komplexen Spiel wie GO?

Vielleicht habe ich noch nicht verstanden, auf was sich das Programm beschränken soll.

Mal zum Vergleich (open source):

gnugo
pachi
fuego

Bei Pachi arbeiten die für eine hohe Spielstärke mit einem Cluster aus 64 Rechnern mit je 20 Kernen. :T
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #6
Wie klein kann das denn sein, bei einem so komplexen Spiel wie GO?

Ich habe mich vielleicht ein wenig falsch ausgedrückt.
Ich möchte eine grafische Oberfläche mit dem Spielfeld und entsprechenden Steinen.
Ich möchte auf dem Spielfeld die Steine setzen können oder alternativ die Züge in Kurzschreibform eingeben lassen. Anhand dessen soll das Spielfeld dann mit den Spielsteinen besetzt werden und dann mit einem Overlay die Territorien abgeschätzt werden (und resultierende Punkte). Dabei muss es nicht 100% korrekt sein - das kann man dann ja vielleicht immer weiter verfeinern.
Zudem hätte ich dann gerne ein Diagram, wie sich die Punkteverhältnisse im Verlauf des Spiels verändert haben.
Das Programm soll selber nicht spielen. Es soll lediglich anmalen und etwas Statistik rauspusten.

Die von dir zitierten Programme sind ja alles eigene KI-Spieler. Das ist mir zu aufwändig und geht auch vollkommen an meinem Spielvermögen vorbei - dafür bin ich nicht gut genug in dem Spiel :D
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #7
Grundsätzlich sollte man sich auch frühzeitig Gedanken über die Datenstruktur machen.

Erstes Brainstorming:
Spielstein:
  • Farbe (weiß/schwarz)
  • Position (x und y) auf dem Spielbrett
  • Nachbarfelder vielleicht
Gruppe:
  • Liste von Spielsteinen
  • Freiheiten der Gruppe (leere Nachbarfelder)
  • Status, lebend oder tot - ermittelt durch die Anzahl der Freiheiten
Spielbrett:
  • selbsterklärend, denke ich

Das wäre ja erstmal grundlegend zu dem Spiel. Dann müsste man das vielleicht noch etwas sinnvoller abstrahieren, damit man auch einen Spielverlauf gut abbilden kann ohne einen riesigen Overhead an Daten zu produzieren.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Ich muss ganz ehrlich sagen, ich hab mich noch nie mit "Go" intensiv beschäftigt, wäre dann wohl angebracht ;)
Ob deine Datenstruktur so "ideal" wäre, kann ich daher nicht sagen.

Aber auch um eine GUI zu realisieren, weil ich denke das wäre der wichtigste Part, auf welches Framework/Bibliothek würdest du dich verständigen wollen?
Die Frage kommt daher, du brauchst einmal eine Visualisierung des Spielfelds, du brauchst einen Zeichenfläche oder ähnliches um valide Züge bzw. die Züge darzustellen, die du nachzeichnen lassen willst. Und du brauchst etwas, was mit einem Charting Bibliothek für Statistiken zusammenarbeitet bzw. visualisieren kann.

Und ist die Frage, soll bei den Charts irgendwas interaktiv sein?

Nimm es mir nicht krumm, aber die Datenstruktur ist ein Teil, aber lässt sich vielleicht doch mehr oder weniger ohne weiteres realisieren, egal was man oben auf setzt, oder nicht? :)
Oder hab ich nen Denkfehler, das du erst einmal die "Logik" haben willst - aber ohne zu überlegen wie sich so etwas "effizient" darstellen lässt?
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Die Frage kommt daher, du brauchst einmal eine Visualisierung des Spielfelds, du brauchst einen Zeichenfläche oder ähnliches um valide Züge bzw. die Züge darzustellen, die du nachzeichnen lassen willst. Und du brauchst etwas, was mit einem Charting Bibliothek für Statistiken zusammenarbeitet bzw. visualisieren kann.
Nimm es mir nicht krumm, aber die Datenstruktur ist ein Teil, aber lässt sich vielleicht doch mehr oder weniger ohne weiteres realisieren, egal was man oben auf setzt, oder nicht?
Oder hab ich nen Denkfehler, das du erst einmal die "Logik" haben willst - aber ohne zu überlegen wie sich so etwas "effizient" darstellen lässt?
Abhängigkeiten zeigen immer in Richtung der Domain, in diesem Fall das Spiel Go.
Es ist klug und sinnvoll, zuerst die Domain zu definieren und den Rest darauf aufzubauen. Am Anfang denkt man immer: Das ist ja alles ganz einfach.. bis man es konkret angeht :D.
Die Statistiken sind ja auch unabhängig von der Visualisierung, da ist es vllt direkt einleuchtender. Du überlegst dir ja nicht ob du jetzt Balkendiagramme oder Torten haben willst, sondern definierst erstmal, welche Statistiken du konkret erheben willst und DANN überlegst du dir, wie du diese gut darstellen kannst.

Spielbrett:

selbsterklärend, denke ich
Ist das so? Hat nicht ein Spielbrett Spielfelder, welche Nachbarfelder haben, im Gegensatz zu Spielsteinen, welche zu genau einem Spielfeld gehören und selber keine Nachbarfelder haben?
Und gibt es überhaupt Spielsteine an sich oder vielleicht nur Spielsteingruppen mit einem einzelnen Element oder mehreren Elementen?
:P

--- [2017-08-12 10:37 CEST] Automatisch zusammengeführter Beitrag ---

Man hätte dann die relativ simple Aufteilung:

Spielbrett:
* hat 0..n Gruppen
* hat maximale Dimension
* hat aktuelle Farbe (schwarz oder weiß)
Methoden:
lege(Koordinate)
führeZusammen(2..n Gruppen)
entferneGruppe(Gruppe)
gründeGruppe(1..n Koordinaten)

Gruppen:
* hat 1..n Koordinaten
* hat Farbe (schwarz oder weiß)
Methoden:
bool istNachbarVon(Koordinate)
neuesMitglied(Koordinate)

Koordinaten:
* hat x-Koordinate
* hat y-Koordinate


Spielzug:
[src=cpp]Spielbrett.lege(Koordinate(x,y)):
teste ob Koordinate auf Spielbrett liegt;
für jede Gruppe g:
wenn g.istNachbarVon((x,y)):
wenn g.farbe == aktuelle Farbe:
freunde+= g;
wenn g.farbe != aktuelle farbe:
feinde +=g;
wenn freunde leer:
Spielbrett.gründeGruppe((x,y))
wenn genau ein Freund:
freund.neuesMitglied((x,y))
wenn mehrere Freunde:
führeZusammen(freunde, (x,y))
wenn feinde nicht leer:
[...]
[/src]

Wenn man wissen will, ob eine Gruppe gefangen ist:

[src=cpp]für jedes Element e der Gruppe:
für jede Gruppe g: // ToDo: Use BoundingBoxes to avoid iterating over all groups
wenn nicht g.istNachbarVon(e) return nicht gefangen;[/src]
Das würde ja reichen, weil sobald neben einem Stein nichts liegt ist die Gruppe nicht gefangen.

Mehr kann ich nicht abbilden, da ich die Regeln von Go nicht kenne :D
 
Zuletzt bearbeitet:

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Mehr kann ich nicht abbilden, da ich die Regeln von Go nicht kenne :D

Guten Morgen, die Aussage disqualifiziert deine Methoden eigentlich schon wieder, weil wenn man die Regeln nicht herausgearbeitet hat, kann man auch nicht mit diesen arbeiten. :p

Also wegen der "Domain", beziehst du dich damit auf die "Anforderungen" bzw. "Gegebenheiten" ? Irgendwie fehlt mir da eine Begrifflichkeit. Falls du das mal genauer darlegen möchtest, als kurzen Exkurs. (Was ich hervorragend finden würde! :))

Also, mein Einwand kommt daher, es steht und fällt ja vieles damit, was wirklich umsetzbar erscheint. Daher auch die Frage, mit welchen Werkzeugen oder Erweiterungen ließe sich etwas grafisch aufbereiten oder was vereinfacht einem die Aufgabenstellung oder hilft dabei, die Regeln oder Daten leichter abbilden zu können?
Im Grunde hab ich selbst nichts dagegen das Rad neu zu erfinden, aber ist die Frage ob das überhaupt ohne tiefgründige Vorkenntnisse in einem Bereich oder der/einer Sprache möglich ist. Eine 2d/GUI Engine zu schreiben wäre für die Problemstellung wohl overkill, auch wenns vielleicht für den Anwendungsfall super sein könnte weil man dann ja noch viel detaillierter eingreifen kann.

Auf der anderen Seite, wenn man mal die Visualisierung rauslässt bzw. "offen" lässt, weil das ein ganz anderes "Problem" darstellt - wäre es ja schon korrekt daran zu arbeiten, wie die Spiellogik und Regeln programmiert werden können. Wäre wohl egal ob in 2d, 3d, als ASCII in ner Konsole... oder was auch immer, Hauptsache die Logik steht.

Jaja, da hab ich gestern wohl auch zu "einfach" gedacht. :rolleyes:
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
Ich habe ja nichts gegen eine gepflegte aber belanglose Plauderei über das Thema Programmierung.
Aber es ist doch schon klar, daß hier nie etwas produktives zu Stande kommen wird, oder?
Ebensowenig, wie beim NGB Paßwortmanager

Da sagt einer. Eh, last mal ein Auto bauen.
Dann läßt sich einer über Benzin, Diesel oder Elektro aus.
Einer schreibt über die Farbe.
Einer über Gummimischungen in Reifen.
Einer über Off-Road oder Sportwagen
Dann gibt es noch eine Diskussion von 2 "Fachleuten", ob Benz oder BMW die besseren Autos baut.

Könnte man jetzt noch weiterführen
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Guten Morgen, die Aussage disqualifiziert deine Methoden eigentlich schon wieder, weil wenn man die Regeln nicht herausgearbeitet hat, kann man auch nicht mit diesen arbeiten.
Stimmt schon so generell, aber offenbar kann man einen schwarzen oder weißen Spielstein setzen (müsste man noch checken, was alles ein valider Zug ist) und offenbar ist 'Freiheit' Teil des Konzeptes bei Go, Wikipedia scheint mir das zu verifizieren, dass ich das korrekt verstanden habe:
Eine Freiheit einer Kette ist ein leerer Schnittpunkt, der zu einem Stein der Kette über eine Linie benachbart ist.
Das sind die beiden Konzepte, die ich abgebildet habe.

Also, mein Einwand kommt daher, es steht und fällt ja vieles damit, was wirklich umsetzbar erscheint. Daher auch die Frage, mit welchen Werkzeugen oder Erweiterungen ließe sich etwas grafisch aufbereiten oder was vereinfacht einem die Aufgabenstellung oder hilft dabei, die Regeln oder Daten leichter abbilden zu können?
Im Grunde hab ich selbst nichts dagegen das Rad neu zu erfinden, aber ist die Frage ob das überhaupt ohne tiefgründige Vorkenntnisse in einem Bereich oder der/einer Sprache möglich ist. Eine 2d/GUI Engine zu schreiben wäre für die Problemstellung wohl overkill, auch wenns vielleicht für den Anwendungsfall super sein könnte weil man dann ja noch viel detaillierter eingreifen kann.

Auf der anderen Seite, wenn man mal die Visualisierung rauslässt bzw. "offen" lässt, weil das ein ganz anderes "Problem" darstellt - wäre es ja schon korrekt daran zu arbeiten, wie die Spiellogik und Regeln programmiert werden können. Wäre wohl egal ob in 2d, 3d, als ASCII in ner Konsole... oder was auch immer, Hauptsache die Logik steht.
2D Spielfeld für was rundenbasiertes dürfte eine typische Einstiegssache für jede GUI sein. Das wird nicht das Problem. Kann man vllt noch schauen wo/wie sich das mit den Statistiken gut bauen lässt.

Wäre wohl egal ob in 2d, 3d, als ASCII in ner Konsole... oder was auch immer, Hauptsache die Logik steht.
Ganz genau. Das Frontend kann dann ja auch z.B. einfach html sein. Baust du dir nen table in der entsprechenden Größe und lässt dir von den Domain Klassen den Status jeden Feldes geben (schwarz/weiß/leer). Und packst nen Klick-Handler an jedes Feld, der das ganze dann an Domain weiter reicht mit der Info, an welches Feld geklickt wurde.\
Da sieht man dann auch, dass die Interaktion zwischen den Domainklassen und dem Frontend recht begrenzt sind. Man könnte sich daher auf die Schnittstellen einigen und dann baut einer die GUI/Frontend und jemand anders überlegt sich, wie man die Go-Regeln gut umsetzen kann.

Hier zum Beispiel "classic" C++ und Konsolenoutput: Youtube
Hier ein qt Taschenrechner, wo man sich rauslesen kann, wie die qtgridlayout Klasse funktioniert, falls man nicht eh zuerst in die Doku schauen will: Klick

Ebensowenig, wie beim NGB Paßwortmanager
Das was Roin vorschlägt ist halt um diverse Größenordnungen einfacher als ein Passwortmanager und durchaus realistisch für 'mal so zwischendurch gemeinsam machen'.'


PS.: Domain
Quasi das, was du aus der 'realen Welt' (in diesem Fall) abbilden willst, also das Spiel Go. Aber in dem Sinne, dass du die Konzepte und Regeln abbildest.
Eine KI wäre schon wieder davon getrennt bzw. würde darauf aufsetzen, genau wie eine GUI.
Das ergibt unmittelbar Sinn, denn du kannst ja Go+KI bauen oder Go+GUI oder Go+GUI+KI, die "Go-Klassen" wissen nichts von KI oder GUI, nur die KI und GUI Klassen müssen die Schnittstellen der Go-Klassen kennen.
 
Zuletzt bearbeitet:

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
Weltfrieden ist auch realistischer, als eine intergalaktische Schnellroute.

Wenn die Aufgabe nicht klar festgelegt ist, kommt da nichts bei rum. Da ist viel zu viel "könnte" dabei.

-Brettspiel mit 2 Spielern und 2 Farben.
-Territorien abschätzen
-Verlauf des Punkteverhältnisses im Spielverlauf im Diagramm Darstellen
-Statistiken raushauen

Und dann keinen, der von dem Spiel richtig Ahnung hat.

Muß ja kein Lastenheft sein, aber vielleicht etwas mehr, als das vorhandene?

PS: Ich habe mich gestern mal mit den Grundlagen versucht:
http://playgo.to/iwtg/german/ (interaktiv)
 

BurnerR

Bot #0384479

Registriert
20 Juli 2013
Beiträge
5.504
Wenn für dich ein rundenbasiertes Brettspiel mit x mal y Feldern zu programmieren so schwer ist wie Weltfrieden, dann ist das natürlich so, musst dich dann aber damit abfinden, dass das für den nächsten nichts dramatisches mehr ist.
 

KaPiTN

♪♪♫ wild at heart ♪♫♫♪

Registriert
14 Juli 2013
Beiträge
29.138
Da hast Du die Relation nicht verstanden.

Die Komplexität liegt auch nicht in der Umsetzung des Programms, sondern in der Durchführung eines kooperativen Projektes. Und da sehe ich hier schwarz.

Bei einem Wettbewerb käme da vielleicht noch etwas raus, vielleicht sogar mehrere Lösungen. Aber bei so etwas kommt wahrscheinlich nicht einmal eine Zeile Code raus.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
@BurnerR: Danke für die Begriffserklärung :T

@KaPiTN: Dein Go-Link ist auch sehr hilfreich, ich hab mal eben die ersten 10 "Kapitel" davon gelesen und angespielt. Finde die Grundregeln gar nicht so schwer. :)
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #17
@BurnerR:
Danke für den Beitrag. Stimmt. Meine grundlegende Datenstruktur war vielleicht noch nicht die beste. Das war ein Schnellschuß als ich ein wenig müde war :D

Wenn die Aufgabe nicht klar festgelegt ist, kommt da nichts bei rum. Da ist viel zu viel "könnte" dabei.

-Brettspiel mit 2 Spielern und 2 Farben.
-Territorien abschätzen
-Verlauf des Punkteverhältnisses im Spielverlauf im Diagramm Darstellen
-Statistiken raushauen
Da hast du die Anforderungen.
Da ich in allen gängigen Sprachen mindestens Grundkenntnisse habe, wollte ich diese erstmal offen lassen, damit die Schnittmenge von Leuten, die Bock darauf haben und Leuten, die die passende Sprache können sich maximiert.

Und dann keinen, der von dem Spiel richtig Ahnung hat.
Ich habe bisher leider noch nie so ein kooperatives Projekt gestartet, welches über das Internet organisiert wurde, sondern nur mit Freunden, die direkt neben mir saßen. Das ist nunmal etwas anderes. Und Go spielen kann ich - nur leider nicht so richtig gut. Aber alle Regeln habe ich verstanden. Die sind auch an sich nicht so kompliziert. Mehr Kopfschmerzen machen mir dann eher die spätere Statistik, wie groß denn eventuelle Einflussgebiete sind. Ich schätze das mit einem "geübten Blick" ab. Worauf ich da genau achte, oder wo ich die Grenzen ziehe ist was ganz anderes. Im Zweifel könnte man da sogar eine "Kriging-Algorithmus" Auswertung machen und den Grenzwert auf 0,5 (0=schwarz, 1=weiß) setzen oder sowas. Da finden sich bestimmt Lösungen.


Vielleicht, um das alles ein bisschen konkreter zu machen:
Github oder GitLab?
Überhaupt Git?
Dann würde ich da nämlich ein Projekt anlegen und vielleicht das erste bisschen an absoluter Grundstruktur reinhauen und dann mal sehen, wie wir da weiterkommen.
Aber bei so etwas kommt wahrscheinlich nicht einmal eine Zeile Code raus.
Und genau um das zu vermeiden, möchte ich da wenigstens die Grundlagen schonmal schaffen. Ein Anfang ist besser als keiner.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.561
Also wenn du das Projekt irgendwie planen willst, wäre ich für Github, Gitlab finde ich per se etwas unpraktisch, auch wenn es fast das gleiche wäre...

Allerdings habe ich noch keine Ahnung wie man Forked.... bzw. Code zusammenführt über Konsole bzw. Interface, Forken geht ja über Knopfdruck bei Github, aber dann auch "bearbeiten" und "zusammenführen" der Änderungen? Falls ich mich dann irgendwie daran beteiligen kann, bräuchte ich definitiv dazu eine kleine Hilfe bzw. Kurzanleitung - oder irgendwo wo ich das mal nachlesen kann.

Grundsätzlich ist wohl auch nicht verkehrt sich mit der Datenstruktur zu befassen, das wäre ja bereits eine Grundlage, auf die man andere Sachen (Methoden, Klassen, Funktionen) aufbauen könnte. Wie bzw. ob sich diese dann im Verlauf ändert bzw. erweitert, spielt ja erst einmal keine große Rolle.

Aber ich gebe zu, wenn ich so darüber nachdenke, selbst für Auswertungen des Spielfelds, der Lage von Steinen und den Resultaten, müssen die Grundregeln ja implementiert werden, oder?

Also....
- wann "fängt" ein Spieler die Steine des anderen (wann kommt es zum Atari)
- wie viel Punkte werden gefangen
- ist ein Zug wirklich valide (keinen Stein in einem Atari setzen möglich), auch bei der Eingabe prüfen?
- kann ein Stein, nach einem Atari, innerhalb der freigewordenen Felder gesetzt werden, oder geht das nicht?
- ist das Spiel zu Ende wenn ein Spieler dem anderen X Steine abgefangen hat, weil der andere einfach nicht mehr ziehen/aufholen kann?

Und was vielleicht auch etwas einfacher machen würde, ein Ablaufdiagramm zu erstellen bzw. eine Featureliste...

Also was fällt unter Go-Regeln, welche Fälle gibt es dabei?
Was soll an Userinput möglich sein? Züge eintragen, Steine interaktiv setzen?
Was soll visualisiert werden? Spielfeld, Steinpositionen...
Was sollen die Statistiken darstellen? - Prozentverteilung der Steinverteilung auf dem Brett, Vergleich der Anzahl und Stärke der Ataris? Was müßte dazu aufgezeichnet werden um diese Daten zu bekommen?
Wie wird der Spielverlauf dargestellt bzw. wie lässt sich in diesem navigieren?

Gibt bestimmt noch mehr Punkte, aber das wäre vermutlich alles das, was wohl in das "Leistungsheft" von dem der Kapitn spricht, fließen würde nehme ich an. Und an dem man sich orientieren könnte, wenn man überlegt was wie gemacht werden soll.

Und ich glaube so eine grundlegende "da wollen wir mal hin"-Zielsetzung hilft ungemein.

Aber die kennst zum Großteil wohl nur du @Roin derzeit ;)
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #19
@theSplit:
Mussten das so viele Fragen auf einmal sein? :D
Ich versuche dann mal einige davon zu beantworten...


Also wenn du das Projekt irgendwie planen willst, wäre ich für Github
Einverstanden. Die ersten zwei Klassen sind auch gleich schon online und dann kommt der Link hier hin. Sind wirklich absolute Basics aber ich wollte nicht mit der Tür ins Haus fallen.

Allerdings habe ich noch keine Ahnung wie man Forked.... bzw. Code zusammenführt über Konsole bzw. Interface, Forken geht ja über Knopfdruck bei Github, aber dann auch "bearbeiten" und "zusammenführen" der Änderungen?
Da sollte es doch machbar sein, dass ihr das Projekt runterläd und dann eure Änderungen über einen Pull-Request sendet? So wird in dem Repo auch kein Unfug getrieben (da gibt es ja immer Trolle...) aber auch da brauche ich etwas Hilfe. Ich kann grundsätzlich auf meinem eigenen Repo commiten und vielleicht sogar das mit den Branches verwalten. Aller weitere ist eher neu für mich. Ich arbeite sonst eher wenig mit Git aber ohne wäre ein solches Projekt wohl kaum machbar. Besonders, da wir vermutlich auch unterschiedliche Kenntnisse mitbringen und den Code an der ein oder anderen Stelle bestimmt noch optimieren wollen usw.

Grundsätzlich ist wohl auch nicht verkehrt sich mit der Datenstruktur zu befassen, das wäre ja bereits eine Grundlage, auf die man andere Sachen (Methoden, Klassen, Funktionen) aufbauen könnte. Wie bzw. ob sich diese dann im Verlauf ändert bzw. erweitert, spielt ja erst einmal keine große Rolle.
Ich beginne mit dem Grundgerüst, welches Burner vorgeschlagen hat. Das klingt für mich erstmal ganz sinnig. Ich habe allerdings auch noch eine weitere Klasse hinzugefügt. Undzwar Turn/Spielzug
Diese beinhaltet dann
  • die Farbe
  • das Spielfeld, auf welches gesetzt wird
  • eine Id, um den Spielverlauf darstellen/ermitteln zu können
  • eine Validitätsprüfung vielleicht?

wann "fängt" ein Spieler die Steine des anderen (wann kommt es zum Atari)
Die Spielsteine sind dann gefangen, wenn sie KEINE Freiheiten mehr besitzen. Dies muss man aber vielleicht gar nicht so genau bestimmen. Eine Gruppe kann nämlich als lebendig oder tot gekennzeichnet werden. Eine lebedinge Gruppe hat mindestens 2 Augen - dies sind Freiheiten, die nur von eigenen Steinen umringt sind und somit ein Besetzen dieser Felder durch den Gegner nicht mehr möglich ist, weil der Spielstein sonst direkt entfernt werden würde und somit die Freiheit wieder frei ist.


ist ein Zug wirklich valide (keinen Stein in einem Atari setzen möglich), auch bei der Eingabe prüfen?
Für den Anfang würde ich jeden Zug, der nicht auf einem bereits belegten Feld passiert als valide annehmen. Weitere Eingabeprüfungen würde ich vielleicht erst später nachziehen oder vielleicht über eine Option einstellbar machen. Wir wollen ja erstmal überhaupt ein Programm haben, welches man dann weiterentwickeln kann.

kann ein Stein, nach einem Atari, innerhalb der freigewordenen Felder gesetzt werden, oder geht das nicht?
Jain. Also man kann auf das Spielfeld, auf dem man einen Zug zuvor einen Spielstein verloren hat nicht setzen. Wenn man nachdem der eine Stein gefangen wurde, einen anderen Stein gesetzt hat und dann wieder an der Reihe ist, kann man den Stein wieder setzen. Das ist halt eine Situation, in der die Spieler sich gegenseitig immer wieder einen Stein nehmen können, aber nicht direkt in den aufeinander folgenden Zügen sondern immer mit einem Pufferzug dazwischen.

ist das Spiel zu Ende wenn ein Spieler dem anderen X Steine abgefangen hat, weil der andere einfach nicht mehr ziehen/aufholen kann?
Das Spiel ist beendet, wenn beide Spieler in direkt aufeinander folgenden Zügen gepasst haben. Ansonsten ist das Spiel erst vorbei, wenn ein Spieler, wenn er am Zug ist, keinen validen Zug mehr spielen kann oder einer der beiden Spieler aufgegeben hat.
Für unser Programm würde ich gerne alle diese Möglichkeiten implementieren (lassen) aber auch eine Auswertung eines laufenden Spiels zulassen, sodass nicht zwingend eine Eingabe eines abgeschlossenen Spiels notwendig ist.


Und was vielleicht auch etwas einfacher machen würde, ein Ablaufdiagramm zu erstellen bzw. eine Featureliste...

Also was fällt unter Go-Regeln, welche Fälle gibt es dabei?
  • Spielsteine können auf die Kreuzungen der Linien gesetzt werden (bei uns werden dann wohl dann ganz normal die Spielfelder - ist auch deutlich einfacher zu implementieren...)
  • Spielsteine der gleichen Farbe, welche durch eine Linie verbunden und in direkter Nachbarschaft liegen, sind eine Gruppe und kombinieren ihre Freiheiten und gelten dann als eine Einheit
  • Eine Gruppe gilt als lebend, wenn diese mindestens zwei Augen besitzt
  • Eine Gruppe, die weniger als zwei Augen hat (Achte auf den Spielfeldrand!) gilt als tot und wird beim Spielende vom Spielfeld entfernt.
  • Eine Gruppe, die vollständig von feindlichen Spielsteinen umschlossen ist wird vom Spielfeld entfernt und der Spieler, der diese Gruppe gefangen hat bekommt einen Punkt pro Spielstein zu seinem Endpunktestand gutgeschrieben
  • Der weiße Spieler bekommt zu Spielbeginn 0,5 Punkte gutgeschrieben (Komi), damit der Nachteil des zweiten Steins auf dem Spielfeld ausgeglichen wird.
  • Atari-Regel siehe oben
  • Das Spiel ist beendet wenn ... (siehe oben)
  • Es kann zu Spielbeginn für den Schwarzen Spieler ein "Vorteil" eingestellt werden. Dieser kann bis zu 9 Steine betragen, die auf den großen Punkten auf dem Spielfeld platziert werden...
  • Habe ich etwas vergessen?

Was soll an Userinput möglich sein? Züge eintragen, Steine interaktiv setzen?
Ich würde vielleicht erstmal damit beginnen, dass über die Konsole die Zielfelder eingegeben werden können. Die Farbe wird ja von dem Programm vorgegeben.
Wenn wir dann soweit sind, können wir auch gerne interaktive Eingaben implementieren.
Dabei wären noch zwei Features, die mir spontan einfallen, möglich:
  • Es gibt eine offizielle Notation von Go-Spielen (ähnlich wie beim Schach, nur einfacher). Diese Liste an Spielzügen könnte man einlesen lassen.
  • Man könnte auch x Spielsteine der gleichen Farbe eingeben und dann die andere Farbe, um nur eine expliziete Stellung analysieren zu lassen. Da wäre dann die Frage, ob man an dieser Stelle auf ein Valides Gleichgewicht prüfen kann... Also, ob die Züge abwechselnd ausgeführt wurden und sowas. Das könnte durchaus sehr kompliziert werden. Es wäre an dieser Stelle auch denkbar nur den Hinweis zu geben, dass keine genaue Prüfung vollzogen wird, da es einfach nicht machbar ist. (Ist es das? Das wäre eine Überlegung nachdem wir das gröbste Implementiert haben.)

Was soll visualisiert werden? Spielfeld, Steinpositionen...

Nachdem wir die Grundregeln und die eigentliche Logik haben, könnte man zum Einen das Spielfeld mit den Spielsteinen darstellen lassen. Zudem wünsche ich mir vielleicht auch eine Anzeige, wie die Einflussgebiete der beiden Spieler sind. Dies könnte man zum Beispiel durch rot/blaue Einfärbung realisieren. Darüber kann man sich gerne noch unterhalten, wie das am sinnigsten zu gestalten wäre. Denkbar wäre auch die Punkte in den einzelnen Gebieten darstellen zu lassen, um das Zählen einfacher zu gestalten.
Was sollen die Statistiken darstellen? - Prozentverteilung der Steinverteilung auf dem Brett, Vergleich der Anzahl und Stärke der Ataris? Was müßte dazu aufgezeichnet werden um diese Daten zu bekommen?
Und dann natürlich noch die Spielstatistik mit den entsprechenden Diagrammen, die dann ebenfalls erst im Zweiten Schritt entwickelt werden können. Da würde ich, wie schon erwähnt, gerne den Verlauf der geschätzten Punkte, vielleicht sowas wie Anzahl der Steine auf dem Spielfeld oder auch Zusammensetzung der Punkte im Spielverlauf darstellen lassen. Eigentlich alles, was man so in einem Go-Spiel mit Zahlen ausdrücken kann.
Um diese Statistiken zu erstellen habe ich vorsorglich erstmal die Klasse "Turn" hinzugefügt. Aus dieser könnte man im Zweifel dann über die restliche Logik alles bestimmen lassen. Vielleicht ist es auch sinnig wichtige Ereignisse, wie das Fangen einer Gruppe oder ähnliches gesondert zu loggen und dann daraus Teile der Statistiken zu ermitteln, um Rechenleistung zu sparen. Das wäre aber ebenfalls erst Optimierung, imo.

Wie wird der Spielverlauf dargestellt bzw. wie lässt sich in diesem navigieren?
Die Spielzüge haben von mir vorsorglich eine Id bekommen. Vielleicht kann man diesen auch noch eine Runden-Nummer zuweisen oder ähnliches.
Dann wäre eine Darstellung der Spielzüge in einer Tabelle mit "Links" möglich. Alternativ auch ein Vor- und Zurück-Button oder entsprechende Befehle auf der Konsole.

Und ich glaube so eine grundlegende "da wollen wir mal hin"-Zielsetzung hilft ungemein.
Viel Text dazu - vielleicht wird das jetzt dadurch dann doch noch etwas klarer...

--- [2017-08-13 14:24 CEST] Automatisch zusammengeführter Beitrag ---

BTW:
Ich habe zwar hier jetzt zwei Klassen (.cpp / .hpp) aber ich kenne mich mit Makefiles leider Null aus und werde da Wochen dran sitzen allein die beiden vernünftig mit einem "make" bauen zu können... Die Klassen wären jetzt Coordinate und Turn. Ich committe gleich und poste einen entsprechenden Link.
 

Brother John

(schein)heilig
Veteran

Registriert
1 Aug. 2013
Beiträge
235
aber ich kenne mich mit Makefiles leider Null aus und werde da Wochen dran sitzen allein die beiden vernünftig mit einem "make" bauen zu können
Schreib Makefiles bitte nicht selber! Für ein nichttriviales Projekt kommst du ohne Buildsystem eh nicht aus. Vermutlich einfachste Lösung: schmeiß CMake drauf. Jede brauchbare IDE sollte dir die nötige Projektstruktur vollautomatisch anlegen.
 
Oben