#pydesw: Programmierung eines Brettspiels

Du hast eine Idee für ein Projekt?

Welches Brettspiel soll programmiert werden?

Umfrage endete am Montag 20. Februar 2017, 16:25

Mühle
6
75%
Dame
2
25%
etwas anderes (bitte im Thread vorschlagen)
0
Keine Stimmen
 
Abstimmungen insgesamt: 8
__deets__
User
Beiträge: 3494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Freitag 27. Oktober 2017, 17:11

Ich habe so etwas noch nicht ein einziges Mal funktionieren sehen.

Bau also lieber deinen eigenen Kram & frag hier nach was die Leute so denken. Und schau dir auf github Pygame Projekte an.
PythonEnte
User
Beiträge: 2
Registriert: Sonntag 8. Oktober 2017, 13:24

Freitag 27. Oktober 2017, 17:36

Schade, ja dann werde ich das so machen.
Benutzeravatar
sls
User
Beiträge: 230
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Tannhauser Gate

Freitag 5. Januar 2018, 19:02

@snafu: das Projekt ist tot, lang lebe das Projekt! Geht da noch irgendwas bei euch?
With great processing power comes great responsibility.
Benutzeravatar
snafu
User
Beiträge: 5536
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Freitag 5. Januar 2018, 19:24

Also von meiner Seite her nichts mehr. Zumindest werde ich hier niemanden mehr animieren. Sollte sich doch noch etwas Konstruktives ergeben (das "wider Erwarten" verkneif ich mir mal), dann steige ich vielleicht später mit ein.
shcol (Repo | Doc | PyPi)
Benutzeravatar
sls
User
Beiträge: 230
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Tannhauser Gate

Montag 8. Januar 2018, 19:08

Das ist schade, ich würde dann wohl eher meine eigene Version bauen. Man kann die Leute ja zu bisherigen Ergebnissen nicht mehr wirklich befragen, vor allem als relativer Anfänger brauche ich bei deinem bisherigen Code schon etwas Zeit um durch zu steigen.

Kann den Frust natürlich verstehen, am Anfang drehen alle durch und wollen in ihrer unbändigen Euphorie Google nachbauen, und nach ein paar Wochen ist dann tote Hose.

Mfg
With great processing power comes great responsibility.
sebastian0202
User
Beiträge: 168
Registriert: Montag 9. Mai 2016, 09:14
Wohnort: Berlin

Donnerstag 11. Januar 2018, 10:38

Hallo,


der letzte Stand ist ja dieser:
https://github.com/python-forum-de/pyde ... e/issues/1
Da ging es um die Abnahme der Modellierung für die Logik.
Dort könnten wir jetzt ansetzen und schauen ob diese soweit passt.
Was wäre dann der nächste logische Schritt, die Umsetzung der Logik in Programmcode?

Ich hätte immer noch interesse an diesem kleinen Projekt.
Benutzeravatar
snafu
User
Beiträge: 5536
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 11. Januar 2018, 11:57

Ich hatte meine Ankündigung gar nicht mehr im Kopf. Vor allem ist meine Motivation gesunken, da wir am Ende nur noch zwei Beteiligte waren. Ich arbeite das Konzept, wie angekündigt, nochmal aus. Das sollte bis zum Wochenende erledigt sein, denke ich.
shcol (Repo | Doc | PyPi)
__deets__
User
Beiträge: 3494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Donnerstag 11. Januar 2018, 12:01

Ich finde diese UML Nummer ja völlig überkandidelt. Das entscheidende ist doch, Logik von GUI zu trennen. Dazu bedarf es meiner Meinung nach stattdessen eher einer Sammlung von Unit Tests, welche den Spielverlauf definieren.

Um das mal zu illustrieren:

Erster Test: Instantziertes Spiel hat Spieler weiß als aktiven Spieler.

Zweiter Test: das Spiel gibt alle möglichen Positionen, die der aktivierspiele besetzen kann, zurück.

Dritter Test: Das tatsächliche Setzen eines Steins verändert den aktiven Spieler.

Vierter Test: die Sequenz Spieler 1 einsetzt, Spieler 2 setzt, liefert nur noch eine Teilmenge der ursprünglich möglichen Züge für Spieler 1 zurück.

Dann ist es natürlich auch noch wichtig, das nicht nur Positionen sondern allgemeiner Zugmöglichkeiten zurück gegeben werden. Beide Arten müssen deskriptiv genug sein, damit die GUI damit etwas anfangen kann. Also alle möglichen Positionen highlighten, oder eine Verschiebung anzeigen.

Am Ende ist das aus meiner Sicht nicht sinnvoll hier über akademisch vorzugehen. Heutzutage setzt sich ja langsam aber sicher die völlig triviale Erkenntnis durch, das Code iterativ entwickelt wird. Und gut getestet sein sollte. schreib also einen Test, schreib die Logik die ihn erfüllt, leg uns das vor, und von vorn.
sebastian0202
User
Beiträge: 168
Registriert: Montag 9. Mai 2016, 09:14
Wohnort: Berlin

Donnerstag 11. Januar 2018, 12:49

Hallo,


UML ist für so ein kleines Projekt vielleicht etwas überzogen, aber andererseits kann man sich daran entlang hangeln.
Es geht ja ums gemeinsame erarbeiten. Bisher haben wir 3 Klassen und wissen ungefähr was sie können sollen. Das kann man auf 3 Schreiber aufteilen.
Wenn wir diesen Code dann haben, können wir die Unit Tests schreiben und die Logik damit testen.
Die GUI kommt zum Schluss.
Oder würdest du die Logik des Spiels aus den Unit Tests ableiten?

4 mögliche Tests hast du ja schon aufgezählt.
Wie ausführlich möchten wir denn testen?
Ist es wirklich nötig zu prüfen, ob wir ein Spiel starten können?
Oder uns das Spiel alle leeren Felder richtig zurückgibt?
Ich finde da keine Abgrenzung für mich :K
Hat das Spiel wirklich 24 Felder? Sind es 2 Spieler? 9 Steine pro Spieler?
Keine Doppelbelegung der Felder? Funktioniert die Erkennung für eine gesetzte Mühle?
Da kann man sich doch doof und dämlich schreiben.

Der beste Unit Test wäre wohl dieser, dass Spiel mit 2 Computer Gegnern zu starten und bis zum Ende durchspielen zu lassen.
__deets__
User
Beiträge: 3494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Donnerstag 11. Januar 2018, 13:02

Dein erster Test ist mein letzter. Denn dann muss schon alles funktionieren, und wenn etwas das nicht tut, dann hakt es wo genau ? Das ist ziemlich sinnlos.

Des Weiteren ist dein Ansatz, erst zu coden und dann tests zu schreiben in meinen Augen fehlgeleitet. TDD ist wertvoll, weil

- du direkt die API die du schaffst, prüfst, und dort Designschwächen auf die Spur kommst.
- dich mit etwas Disziplin zwingst nur das zu schreiben, was du brauchst. YAGNI Lauer überall.
- du mindestens mal für den “happy path” komplette Abdeckung hast. Was mit dem letzen Punkt resoniert:
- niemand schreibt gerne Tests nachdem man denkt, man ist fertig. Und entsprechend schlecht sind die, und man erinnert sich im Zweifel auch gar nicht mehr an alle Randfälle.

Was deine Trennung nach Klassen angeht mit dem Wunsch, die getrennt zu entwickeln, finde ich schon fast rührend naiv. Die drei Klassen die ich gesehen habe sind hoch intim miteinander. Die getrennt entwickeln zu wollen bringt nix, denn da wartet jeder nur auf den anderen. Das frustriert endlos.

Ich sehe stattdessen drei klare Kandidaten:

- Spielobjekt mit einem Interface wie ich es oben skizziert habe. Aktiver Spieler, Zugmöglichkeiten, Zug ausführen, aktuelle Belegung,ggf Dinge wie reset, Invarianten aufrecht erhält gegen Fehlzüge (ist aber IMHO Bonus)
- GUI, die ein solches Objekt kennt, und auch schon mit einer gemockten Variante diverse Darstellungsmodi ausloten kann, ohne echte Logik zu brauchen.
- KI, die basierend auf einem scoring für einen Spieler den besten nächsten Zug wählt. Das ist herausfordernd, und ich bezweifele, das man da schnell was gutes hinbekommt. Darum auch als letztes.
Benutzeravatar
snafu
User
Beiträge: 5536
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 11. Januar 2018, 13:23

Habe zwischenzeitlich noch etwas am UML-Diagramm gebastelt und schonmal einen neuen Issue für die Programmierung erstellt.

Siehe: https://github.com/python-forum-de/pydesw-muehle/issues

Das deckt erstmal grob den Ablauf ab, so wie ich ihn mir rein aus dem Kopf heraus vorstelle. Natürlich ist es bloß eine Orientierung und wird sich bestimmt noch ändern. Ich finde UML gar nicht so schlecht, um einen Überblick für die einzelnen Komponenten zu haben. Darauf kann später womöglich eine "richtige" Dokumentation des Programms basieren.
shcol (Repo | Doc | PyPi)
Benutzeravatar
snafu
User
Beiträge: 5536
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 11. Januar 2018, 13:26

sebastian0202 hat geschrieben:Der beste Unit Test wäre wohl dieser, dass Spiel mit 2 Computer Gegnern zu starten und bis zum Ende durchspielen zu lassen.
Dafür braucht es aber erstmal das komplette Spiel (also mindestens die ausprogramierte Logik), sowie einsatzfähige Computergegner. Soweit sind wir noch lange nicht... ;)
sls hat geschrieben:Das ist schade, ich würde dann wohl eher meine eigene Version bauen. Man kann die Leute ja zu bisherigen Ergebnissen nicht mehr wirklich befragen, vor allem als relativer Anfänger brauche ich bei deinem bisherigen Code schon etwas Zeit um durch zu steigen.
Du kannst dich uns gern anschließen. Die Herausforderung ist halt, wie man Anfänger und diejenigen mit etwas mehr Erfahrung sinnvoll zusammenbringt. Es besteht oft die Gefahr, dass Anfänger sich zurückhalten, weil sie sich nicht trauen oder nicht die nötigen Kenntnisse haben.
shcol (Repo | Doc | PyPi)
Antworten