#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
Benutzeravatar
snafu
User
Beiträge: 5247
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon snafu » Dienstag 14. Februar 2017, 20:02

BlackJack hat geschrieben:@snafu: Was neueres als Python 3.3 bekomme ich hier nicht installiert.

Naja, das ist ja schonmal was. Gut möglich, dass das Spiel auch unter Python 3.3 laufen wird oder dass nur geringe Anpassungen nötig sind. Über die könnte man sich, sofern sie tatsächlich auftreten, bestimmt noch einigen. :)
shcol (Repo | Doc | PyPi)
BlackJack

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon BlackJack » Dienstag 14. Februar 2017, 20:04

@Pygoscelis papua: Die meisten Einsteiger werden wahrscheinlich Python 3 verwenden, so insgesamt würde ich mich diese Aussage nicht trauen zu machen.

Und doch, Python >3.3 selber zu kompilieren ist bei mir schwer. Ich habe ja den Punkt beschrieben ab dem ich aufgegeben habe. Eine Abhängigkeit die ich mir nicht selbst kompilieren möchte, wäre beispielsweise OpenSSL. Da habe ich eine ”alte” Version, aber mit den entsprechenden Sicherheitsupdates, aber Python lässt sich dagegen nicht kompilieren. Für Tkinter müsste ich Tk neu kompilieren und dem war dann mein X-Server zu alt. Wenn ich den Rattenschwanz anschaue der da dran hängt beim neu kompilieren, immer in der Hoffnung das dadurch am System und den Anwendungen irgendwas nicht mehr läuft, könnte ich mir auch die Zeit nehmen das System komplett neu aufzusetzen. Das hat aber sein EOL noch nicht erreicht und ist näher an den Rechnern für die ich ernsthaft programmiere, also will ich da jetzt noch keine Zeit drauf verwenden.

Selbst mit der 3.3 hätte ich dann ja immer noch ein Problem mit Qt wenn das 5 sein sollte. Qt5 zu kompilieren würde mir nämlich auch zu viel Aufwand sein. :-)

Na egal, ich bin ja auch nicht die Zielgruppe für das Projekt.

Zu den Klassen: Wenn das die Logik ist, dann brauchen `Crossroad`-Exemplare keine Position in der GUI.
Benutzeravatar
snafu
User
Beiträge: 5247
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon snafu » Dienstag 14. Februar 2017, 20:19

Wegen dem Qt 4/5 Thema habe ich mir noch keine Gedanken gemacht. Ich fänd's schön, wenn du dabei wärst, BlackJack. Ich für meinen Teil könnte mich auch gut mit Qt 4 anfreunden, weil ich mir nicht vorstellen kann, dass Qt 5 etwas mitbringt, das wir unbedingt benötigen.

Ansonsten haben wir ja viel GUI und Spiellogik in der Planung drin. Das müsste normalerweise alles auch von Python 3.3 unterstützt werden. Es klang bei dir erst so, als wolltest du zwingend bei Python 2.7 bleiben. Da sind die Unterschiede ja nun doch etwas größer. Dass du dein System lieber stabil halten möchtest anstatt den "heißesten Scheiss" drauf zu haben, ist dein gutes Recht und das kann ich auch nachvollziehen - gerade bei Linux.

Ich finde, dass wir uns an den exakten Versionen unserer Abhängigkeiten in der jetzigen Projektphase noch nicht aufhängen sollten. Es ist gut, dies mal besprochen zu haben, aber ich denke schon, dass sich hier ein Kompromiss finden lässt. Wie gesagt: Wenn der kleinste gemeinsame Nenner zumindest Python 3 ist, kann ich gut damit leben. Sofern man irgendwann das fertige Projekt überarbeiten möchte (z.B. das Spiel als mobile App), könnte man ja wieder neu über die geforderten Versionen nachdenken, da Qt 5 in dem Punkt deutliche Stärken gegenüber seinem Vorgänger hat. Soweit meine Meinung zu dem Thema...
shcol (Repo | Doc | PyPi)
Pygoscelis papua
User
Beiträge: 206
Registriert: Freitag 13. März 2015, 18:36

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Pygoscelis papua » Dienstag 14. Februar 2017, 21:02

ok hier ein paar Änderungen:
piece-> hängt von crossing ab
- color
- crossroad_id
- __init__(pos, crossroad_id)

crossing -> hängt von game ab
- neighbours (horizontal/vertical)
- content #(piece/None)
- id

player -> hängt von game ab
- name
- color
- num_pieces_placed
- play(game??? :K )

game
- players
- move_piece(from_crossing, to_crossing) -> Mill -> True/False?
- remove_piece(crossing)
- crossings
- has_won(player) -> True/False
- place_piece(pos) -> Mill? -> True/False?
- turn
- get_removeable_pieces() -> list
- turn_end()
- is_protected(crossroad) -> True/False #mill

Ähnlich verhält es sich mit get_removable_pieces() in der Game-Klasse. Wird das wirklich benötigt? Oder hast du dabei so eine Art visuelle Hilfestellung für den Spieler im Hinterkopf?
Ja ich hatte da so eine Hilfestellung im Hinterkopf :) sollte das dann eher in das Gui?

Wie würde player.play auf das spiel zugreifen? (wird das spiel einfach als parameter übergeben wie angedeutet? )
Bei dem kreuzungs-modell habe ich mir einfach vorgestellt, das es nicht so kompliziert ist. Ich habe mir das ganze eher als Netz gedacht und dann muss man einfach nur den Kreuzungen Nachbarn zuordnen, das klang für mich am einfachsten ...
import this
hidden python features

JAVA = Just Another Vulnerability Announcement :D
BlackJack

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon BlackJack » Dienstag 14. Februar 2017, 21:34

@Pygoscelis papua: Die IDs sind noch drin. Objekte haben ganz automatisch schon selbst eine Identität, man kann Objekte eindeutig voneinander unterscheiden. Zumindest solange man die Vergleichsoperatoren für den Datentyp nicht anders definiert sogar auf ganz triviale Weise, denn dann ist ein Objekt immer nur gleich sich selbst und nicht gleich einem anderem Objekt [1]_, selbst wenn das die gleichen Werte/den gleichen Zustand besitzt. Und wenn man die Vergleiche doch anders definiert, kann man die Identität immer noch in Form einer Zahl mit der `id()`-Funktion ermitteln und ``is`` oder ``is not`` verwenden um zu ermitteln ob es sich bei gleichen Objekten auch tatsächlich um das selbe Objekt handelt. Wenn man das braucht.

.. [1] Stimmt nur solange man nicht einen Datentyp mit pathologischen Implementierungen von den Vergleichsoperationen hat. :-)
Pygoscelis papua
User
Beiträge: 206
Registriert: Freitag 13. März 2015, 18:36

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Pygoscelis papua » Dienstag 14. Februar 2017, 22:07

ok denk dir die id einfach weg. :)
Und zu player.play hat da jemand eine Antwort für mich? Ist einfach game übergeben ok? Sonst müsste man ja verbotener weise global verwenden oder?
import this
hidden python features

JAVA = Just Another Vulnerability Announcement :D
Benutzeravatar
snafu
User
Beiträge: 5247
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon snafu » Mittwoch 15. Februar 2017, 06:08

Ein Spieler könnte bereits bei seiner Erzeugung das Spiel, zu dem er gehört, übergeben bekommen. Die Rückgabe seiner play()-Methode wäre dabei der nächste Spielzug. Was hältst du von diesem Ansatz?
shcol (Repo | Doc | PyPi)
Pygoscelis papua
User
Beiträge: 206
Registriert: Freitag 13. März 2015, 18:36

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Pygoscelis papua » Mittwoch 15. Februar 2017, 08:04

ok das ist doch dann"call bei Referenz" oder?
import this
hidden python features

JAVA = Just Another Vulnerability Announcement :D
BlackJack

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon BlackJack » Mittwoch 15. Februar 2017, 09:03

@Pygoscelis papua: Nein.
Benutzeravatar
Kebap
User
Beiträge: 345
Registriert: Dienstag 15. November 2011, 14:20
Wohnort: Dortmund

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Kebap » Mittwoch 15. Februar 2017, 09:08

Pygoscelis papua hat geschrieben:Wie kann man hier eigentlich einen Anhang anfügen?
Hier ist das Klassendiagramm, es muss aber noch verbessert werden:

...

Ich hoffe ihr habt noch viele Verbesserungsvorschläge :D


Klar kannst du ein Bild erstellen und hier hochladen, oder du benutzt direkt ein Tool, um Klassendiagramme online zu erstellen/teilen/verbessern, da gibt es sehr viele :mrgreen:
MorgenGrauen: 1 Welt, >12 Gilden, >85 Abenteuer, >1000 Waffen und Rüstungen,
>2500 NPC, >16000 Räume, >170 freiwillige Programmierer, einfach Text, seit 1992.
Benutzeravatar
snafu
User
Beiträge: 5247
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon snafu » Mittwoch 15. Februar 2017, 09:44

Pygoscelis papua hat geschrieben:ok das ist doch dann"call bei Referenz" oder?

Call by Reference ist etwas ganz anderes. Ich dachte es mir so, dass die play()-Methode ein namedtuple liefert mit den Angaben "from" (bzw "from_") und "to". Ein noch nicht gesetzter Stein hätte keine Angabe bzw den Standardwert None für das from-Attribut. Diese Rückgabe könnte vom Aufrufer (also dem Spiel) entsprechend verarbeitet werden. Im Falle eines ungültigen Zuges erfolgt eine Rückmeldung durch das Spiel per Exception, die von der GUI visuell dargestellt wird. Der Spieler ist dann weiterhin an der Reihe und play() müsste erneut aufgerufen werden.
shcol (Repo | Doc | PyPi)
Pygoscelis papua
User
Beiträge: 206
Registriert: Freitag 13. März 2015, 18:36

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Pygoscelis papua » Mittwoch 15. Februar 2017, 14:36

Ich meine wenn man am Anfang dem Spieler das Spiel übergibt,
dann wird ja wohl nicht das Spiel in dem Spieler gespeichert, sondern eher sozusagen ein "Zeiger", da wenn man es verändert (in einer Methode von Spieler), wird das Spiel, dass übergeben wurde ja auch z.B bei einem 2. Spieler geändert, dem das Spiel auch übergeben wurde oder?
Wie wird das Spiel denn sonst angesprochen, als über einen "Zeiger", wenn es nicht im Spieler gespeichert ist?
Das Call ist hier natürlich nicht wirklich angebracht, da es keine Funktion ist ...
@Kebap die Frage was nicht ob sondern wie ... :(
import this
hidden python features

JAVA = Just Another Vulnerability Announcement :D
BlackJack

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon BlackJack » Mittwoch 15. Februar 2017, 14:50

@Pygoscelis papua: Du bewegst Dich da auf der Ebene der Implementierung. Egal welchen Wert Du übergibst oder an ein Attribut bindest, es handelt sich bei Python immer um das selbe Objekt. Python kopiert bei Aufrufen und Zuweisung niemals Objekte/Werte. Das Aufrufmodell kann man als „call by object sharing“ bezeichnen. Namen und Attribute stehen in Python nicht für Speicher(adressen) wo man Werte ”rein tut”. Der Speicher gehört zum Wert/Objekt.
Benutzeravatar
snafu
User
Beiträge: 5247
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon snafu » Mittwoch 15. Februar 2017, 15:49

Die Übergabe des Spiels war eine erste Idee. Eigentlich muss nur das Spielfeld übergeben werden. Als Rückgabe dann wie gesagt ein Spielzug. Hierdurch müsste die play() Methode nichts vom Spiel wissen, sondern nur das Spielfeld mit seiner aktuellen Stellung auslesen können.

Denkbar wäre auch, einen GuiPlayer und einen KIPlayer von der Player Klasse abzuleiten, die als Schnittstelle nur Farbe, Name und die play() Methode haben.
shcol (Repo | Doc | PyPi)
Pygoscelis papua
User
Beiträge: 206
Registriert: Freitag 13. März 2015, 18:36

Re: #pydesw: Programmierung eines Brettspiels

Beitragvon Pygoscelis papua » Mittwoch 15. Februar 2017, 21:34

@snafu: Könntest du das Diagramm vielleicht deinen Vorstellungen entsprechend ändern?
Ich habe jetzt dafür nicht so viel Zeit und außerdem weiß ich nicht wie du dir das genau vorstellst :)
import this
hidden python features

JAVA = Just Another Vulnerability Announcement :D

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder