Kartenspiel im Stil von Collectable Card Games

[Nocta]

Hi.
Ich überlege mir gerade, ein Kartenspiel im Stil von Collactable Card Games, also auf Deutsch Sammelkartenspiele zu programmieren.
Das sind so die Kartenspiele, in denen 2 Spieler gegeneinander spielen und Monster "beschwören", Zauberkarten spielen usw. um dem Gegner irgendwie die Lebenspunkte zu zerstören.
Sowas wie Yu-Gi-Oh praktisch
(Nein ich bin kein Yu-Gi-Oh Fan)

Ich hab noch keine wirklich konkreten Vorstellungen davon.
Ich will verschiedene Kartentypen implementieren, Monsterkarten, Zauberkarten, Fusionskarten, ... Vielleicht Items für Monster.
Die Monster sollen dann auch verschiedene Angriffstypen (Feuer, Wasser, Licht, blabla) haben, die gegen verschiedene Verteidigungstypen unterschiedlich stark sind.
Das ganze werde ich durch OOP natürlich von der eigentlichen Spiellogik abgrenzen, so dass man das auch später noch einfach erweitern kann ohne das ganze Programm auf den Kopf stellen zu müssen.

Da ich mir noch nie so ein großes Projekt vorgenommen habe (mein letztes war ein Minesweeper für Konsolen ) wollte ich das Projekt hier mal vorstellen um eventuell Anregungen/Tipps zu bekommen.
Wenn jemand Interesse daran hat, kann er auch gerne mithelfen, aber ich bin auch für einfache Tipps dankbar.
Wo es erfahrungsgemäß Probleme geben könnte, wie ich sie vermeide, oder einfach nur Ideen zum Spiel an sich.
Die Idee ist auch noch kein Stück ausgereift, ich bin mir bei vielen Dingen noch nicht sicher, wie das Spiel werden soll.
Aber da ich das eh alles schön säuberlich trennen will, dürfte es auch kein Problem sein, ohne viel Aufwand alles im Nachhinein noch zu ändern.

[numerix]

Hast du schon eine Vorstellung mit welchem GUI-Toolkit du arbeiten willst?

Welche Ansprüche stellst du an die optische Qualität der Karten und wie willst du diese gestalten: Innerhalb des Programms graphisch erzeugen oder mit einem externen Programm gestalten und als Bilder einbinden?

Sollen (nur) zwei Spieler gegeneinander spielen oder z.B. auch ein Spieler gegen den Computer?

[Nocta]

Hast du schon eine Vorstellung mit welchem GUI-Toolkit du arbeiten willst?

Welche Ansprüche stellst du an die optische Qualität der Karten und wie willst du diese gestalten: Innerhalb des Programms graphisch erzeugen oder mit einem externen Programm gestalten und als Bilder einbinden?

Sollen (nur) zwei Spieler gegeneinander spielen oder z.B. auch ein Spieler gegen den Computer?

Das sind alles Fragen, die ich mir eigentlich erst später stellen wollte.
1. GUI-Toolkit: Erstmal alles auf der Konsole, sollte ja, wenn ich das ganze sauber getrennt habe kein Problem sein, durch jedes beliebige GUI-Toolkit zu ersetzen.
2. Die Karten sollen ja erstmal nur Instanzen von der entsprechenden Karten-Klasse sein, reicht ja auf der Konsole. Ich hab mir dann gedacht, dass ich später eventuell noch ein Modul zum Speichern der Karten schreibe. Zum Beispiel für jede Karte einen Ordner mit einer XML-Datei, welche die Informationen und eine grafik.jpg (oder ein anderes Format) enthält.
Ansrpüche stelle ich aber erstmal gar keine
3. Computergegner waren eigentlich nicht gedacht, ist ja auch irgendwo langweilig und wahrscheinlich wäre das Ergebnis unbefriedigend. Ich hab eher daran gedacht eine Netzwerkfunktion einzubaun.

Also ich hab schon vor, das ganze Ernsthaft anzugehen. Es bringt ja nichts, wenn man so ein Projekt einfach _irgendwie_ in den Editor reintippt und nach 2 Tagen fertig sein will. Funktioniert dann vielleicht sogar, aber viel hat man davon dann ja auch nicht mehr

[numerix]

Die strikte Trennung von Logik und Darstellung ist ganz sicher der richtige Weg.

Ich hatte die GUI angesprochen, weil davon und von deinen Ansprüchen an die graphische Darstellung ggf. abhängt, ob du die Darstellung der Karten vom Programm zeichnen lässt oder als Grafiken einbindest. Offenbar hast du letzteres vor, so dass man die GUI tatsächlich erstmal ganz beiseite lassen kann.

Hauptpunkt wäre demnach zunächst die Spiellogik, da müsste man eben mal sammeln, welche Funktionen die Karten so haben sollen, ob du irgendein dir bekanntes Spiel dieser Art mehr oder weniger kopieren willst oder was ganz eigenes machen.

[Nocta]

Ja, die Spiellogik ist der Hauptpunkt.
Erstmal nur der Kern, also das Grundgerüst des ganzen Spiels, das natürlich auch einfach erweiterbar sein soll.
Aber das ist ja auch der Sinn von OOP.
Bis jetzt habe ich keine wirklich innovativen Ideen.
Nur so die Standardideen, die ich mir mal hier und mal da abgeguckt habe.
Vielleicht fallen mir aber auch noch ein paar neue Dinge ein, die es so noch nicht in einem Kartenspiel gibt.

Aber das wichtigste ist ja erstmal, wie ich das ganze strukturiere.
Und ich denke da kann ich von eurem Wissen vielleicht am meisten profitieren.
Ich habe ja verschiedene Kartentypen. Dann würde ich diese also von einer Basis Kartenklasse erben lassen und dann instanzen dieser Klassen erzeugen, wenn ich eine neue Karte erstelle.
Diese Karten hätten dann Eigenschaften.
Zum Beispiel hat eine Zauberkarte einen Effekt (was wohl wieder eine Klasse sein müsste oder so) der beim Spielen der Karte ausgelöst wird.
Oder eine Karte benötigt gewisse Vorraussetzungen. Entweder andere Karten (Fusionskarten) oder vielleicht eine gewisse vorübergestrichene Spieldauer (in Runden) oder sonstirgendwas.
Wie würdet ihr das ganze System implementieren?
Es soll eben flexibel sein.
Ich muss dann ja, wenn das ganze fertig ist auf einfachem Wege Karten erstellen können, verändern, vielleicht neue Spielelemente hinzufügen können, neue Effekte/Zauber usw.
Wenn ich dann die Idee habe: Hmm ... Vielleicht füge ich noch eine Rohstoff-Komponente hinzu, man braucht für gewisse Karten Rohsotffe, welche man mit zum Beispiel einem Steinbruch abbauen kann. Dann will ich dafür nicht alles neu programmieren müssen.
Ich denke ihr versteht was ich meine
Also für ein paar Ratschläge wäre ich dankbar, nicht dass ich das am Ende doch noch alles vergeige.
Irgendwann muss ich ja auch mal lernen brauchbaren Code zu schreiben

[numerix]

Das, was du schreibst, klingt doch schon ganz gut.
Fang doch einfach mal an ...

Vorschläge zur Implementierung zu machen - über das hinaus, was du selbst schon gesagt hast ("Kartenklasse") - finde ich schwierig, weil mir noch zu wenig klar ist, was genau das Spiel am Ende (rein funktionell, nicht hinsichtlich der Darstellung) leisten soll.

Sicher wirst du aber eine Klasse "Spieler" brauchen, der Karten-Instanzen besitzt und ein Punktekonto; außerdem eine Methode "karte_ausspielen" o.ä.

Sinnvoll wäre wohl auch eine übergeordnete Klasse "Spiel" mit einer Liste aller Spieler und einer Liste aller bzw. noch verfügbarer Karten.

Evtl. - aber das hängt dann schon von der Spiellogik ab - auch eine Klasse "Spielfeld". Falls es z.B. eine Art Ziehstapel von Karten gibt o.ä. Evtl. könnte das aber auch in der Klasse "Spiel" selbst verwaltet werden.

[Nocta]

Naja einen Stapel wird's wohl geben.
Dafür benutze ich dann einfach einen Stack, aus dem der Spieler seine Karten zieht. Sollte wohl zu der Spieler-Instanz gehören, weil's ja sein Deck ist.
Eine Spielfeld-Klasse werde ich wahrscheinlich auch erstellen. Zum Beispiel für Slots. Also Karten-Slots in die die Spielkarten gelegt werden können.
Damit man nicht 10 Fallenkarten oder so auf einmal im Spiel haben könnte.
Aber keine Ahnung, ob sowas dann im Endeffekt nötig/sinnvoll sein wird, ich hab mir noch nicht alles in allen Einzelheiten überlegt.
Einfach mal Anfangen wäre vielleicht eine Idee, vielleicht aber auch die Falsche
Es wird ja immer gesagt, man soll seine Projekte vorher gut planen.
Und allzu gut ist's ja bisher nicht geplant.

[DarXun]

Habe auch schon Ansätze für's Kartenmischen etc, da ich mich mal an ein "Mau Mau"-Spiel gewagt habe...
Ich hatte auch heute die Idee ein Kartenspiel im Stil von Magic - The Gathering u.Ä. zu machen... ebenfalls mit Python, jedoch im größeren Stil:

Server, Client System.
Doch mein erstes Problem war direkt mal dieses System.
Habe mir mal 'nen Chat gebastelt mit den Sockets usw.
Aber Probleme gibt's dann halt wenn MEHRERE auf den Server connecten sollen... Soweit ich weiß brauch man dazu threading... da steig ich aber noch nicht sooooo durch...

Ich würd' gern mit dir zusammen an diesem Projekt arbeiten.
Brauche jetzt, da ich Ferien habe unbedingt mehr Beschäftigung , da kommt sowas natürlich passend.
Also wäre echt cool wenn wir sowas zusammen machen könnten, aber natürlich nich schlimm, falls du das nicht möchtest.

Im moment lese ich mich zum X.ten mal in threading ein...

~DarX

[numerix]

Habe auch schon Ansätze für's Kartenmischen

Ein großartigen Ansatz braucht man dafür aber nicht:
Alle Kartenobjekte in eine Liste packen, einmal die shuffle()-Funktion aus dem random-Modul drauf anwenden, fertig.

[DarXun]

Sowas gibt's ? Ich komme mir ja so nutzlos vor xP
Naja... okay is ja auch kein Ding... hatte nich viel getan...
Kartenmischen, Kartenhand erstellen etc. also vom programmtechnischen her ist das ja relativ einfach... Probleme hab ich nur bei Netzwerkprogrammierung/ Threading...

Ich würde übrigens direkt mit einem GUI beginnen... Dann hast du anfangs direkt alles so wie du es brauchst... andererseits kannst du natürlich später auch "alles" umschreiben

[Nocta]

@DarXun:
Ich glaube, wir beide haben da wohl unterschiedliche Vorstellungen, was das Programmtechnische angeht. Nimm's mir nicht übel aber ich glaube du hast ein paar grundsätzliche Dinge, die ich hier in dem Projekt anwenden will, nicht verstanden.
1. Will ich die Logik von der GUI trennen, das macht imo das Programm einfacher und macht vorallem später weniger Probleme.
Daher fange ich auch erstmal ohne GUI an, ich wüsste nicht, was ich für Vorteile davon hätte, die GUI direkt zu schreiben.
Umschreiben müssen sollte ich später dann eigentlich auch nichts. Oder nur geringfügig.
2. Wieso ist deine Idee "im größerem Stil"? Meine sollte auch, wenn ich das ganze gut strukturiert habe, problemlos um eine Netzwerkfunktion erweiterbar sein. Das hab ich auch schon als muss-Feature eingeplant.
3. Am Mischen wird's nicht scheitern
Ist wie von numerix gesagt eigentlich überhaupt kein Problem.
4. MauMau ist zwar auch ein Kartenspiel aber davon kannst du im Prinzip nichts in das Projekt mit reinnehmen, weil es eben mehr als "hat auch Karten" nicht gemeinsam hat. Na gut es ist rundenbasiert

Es hat auch schon jemand Interesse bekundigt, der ein wenig mehr weiß, wie ich mir das ganze Vorstelle. Ich weiß zwar nicht, ob derjenige wieder einen Rückzieher macht, da das ganze recht spontan kam, aber wir werden sehn Notfalls schaff ich's (hoffentlich) auch alleine.
Also sei mir nicht böse, aber wenn dann brauche ich jemanden, der mindestens auf dem gleichem Level ist wie ich, weil ich sonst eher noch mehr Probleme habe.
Trotzdem danke für das Angebot.

[Hyperion]

Ich würde übrigens direkt mit einem GUI beginnen... Dann hast du anfangs direkt alles so wie du es brauchst...

Wieso das? Was ist "alles"? Am Anfang steht die Datenstruktur. Damit steht und fällt alles. Wie ich die darstelle ist dabei vollkommen egal - daher kann man sich i.a. auf Konsolenausgaben beschränken. So kommt man schneller voran und kann die GUI dann beginnen, wenn die Logik steht.

Fängst Du sofort mit der GUI an, musst Du idR später daran noch etwas ändern, da sich Sachen ergeben haben, die Du am Anfang noch nicht überblickt hast.

[olliander]

Moin.

Vorweg: Ich bin derjenige, der Interesse an einer Mitarbeit bekundet hat, und ich werde keinen Rückzieher machen.

Ich kann Hyperion nur zustimmen. Die Datenstruktur ist das A und O. Wir werden uns die nächsten Tage sicher zusammen setzen und entscheiden, ob wir ein bereits vorhandenes Regelwerk als Grundlage verwenden, oder ein eigenes, evtl. nicht ganz so komplexes Regelwerk auf die Beine stellen. Prinzipiell geht es darum, dass es Charakter- oder eben Monster-Karten gibt, die mit Zauberspruch-, Element-Karten etc. versorgt werden müssen, und die eben die typischen Attribute besitzen (Lebenspunkte, Kraftpunkte etc.)...

Was uns eben noch fehlt, ist ein konkreter Grundstock an Daten, die wir verwenden können, und eben auch die dazu gehörige Logik. Aber das werden wir wie gesagt in nächster Zeit Schritt für Schritt ausarbeiten. Wie das Ganze dann konkret umgesetzt wird, sprich, welche Basis- und Subklassen es geben wird etc., das kann man, wie numerix schon andeutete, momentan sicher nicht absehen.

MfG,
olliander

[DarXun]

Okay... das mit dem trennen hab ich wohl *hust* überlesen...
... Schon klar das MauMau in dem Sinne nichts mit der Art von Kartenspielen zu tun hat, die du meinst.
Achja... das mit dem "im größeren Stil"... Ich dachte du meintest einfach eine Client-to-Client Verbindung und keine größere mit einem Server auf den mehrere Clients zugreifen.
Wenn du es so meintest wie ich... noch besser.
Wie gesagt, ist nicht schlimm...

Viel erfolg, ich werd' das hier auch weiterhin verfolgen

[sma]

ich kenne mich mit derartigen Spielen nicht aus, aber dies wären meine Regeln, die ich brauche, um überhaupt über die Realisierung nachdenken zu können. Damit ist IMHO die erste Herausforderung, ein funktionierendes Spiel zu entwerfen, was noch überhaupt gar nichts mit der Programmierung zu tun hat.

Jeder Spieler hat einen Stapel von Karten, die aus angreifenden und unterstützenden Karten bestehen. Erstere haben einen Angriffs- und einen Verteidigungswert, letzte modifizieren diese. Ein Spieler hat 5 Karten auf der Hand und kann jede Runde eine Karte ausspielen und vor sich ablegen. Danach kann er mit einer oder mehreren angreifenden Karten eine ausgewählte gegnerische Karte angreifen. Dies muss eine angreifende Karte sein, so dies nicht anders für den Angreifer geregelt ist. Für den Angriff und die Verteidigung können verteidigende Karten herangezogen werden.

Beispiel: Mein roter Drache (A5,V5) greift den Steingolem (A4,V6) an, wäre aber ohne die Feuerhöhle (A+2) zu schwach. Der Golem ist jedoch so zäh, dass er die ihn besiegende Kreatur automatisch mit tötet, sodass in dieser Runde beide Spieler beide ihre angreifenden Karten verlieren.

Eine Karte wie den roten Drachen zu repräsentieren, ist simpel. Drei Attribute, Name, A und V, fertig. Unterstützende Karten haben mindestens das Attribut Name. Doch wie will man die Sonderregeln implementieren?

Keine gute Idee ist es IMHO, beim roten Drachen zu implementieren, dass wenn auch eine Feuerhöhle offen liegt, der Angriffswert höher ist. Stattdessen würde ich bei jeder Karte Programmcode hinterlegen, der ihren Effekt implementiert und dann für jeden Schritt in der Runde alle Karten befragen und ihnen die Möglichkeit geben, das ihre zu tun.

Soll der rote Drache angreifen, trägt er (die Standardaktion) zum Angriffswert sein A bei, also 5. Danach werden alle unterstützenden Karten "gebeten", ihren Teil beizutragen. Die Feuerhöhle macht in etwa dies:

Code: Alles auswählen

for a in attackers:
  if 'feuerwesen' in a.properties:
    attack += 2

Will man Unterstützungseffekte wie die Feuerhöhle in einem UI irgendwie anzeigen, muss man wohl anders vorgehen. Dann braucht jede angreifende Karte zwei A und zwei V Werte (Original und Aktuell) und das Ausspielen der unterstützenden Karte erhöht jetzt das aktuelle A um 2 und das Ablegen zieht wieder 2 von dem Wert ab.

Ich würde also jede Karte als eine Klasse realisieren, die das entsprechende Verhalten an den Tag legt und das vom Spiel dann jeweils aufgerufen wird. Dies muss in so kleinen Schritten und so flexibel passieren, dass die Karte jeden Spielmechanismus durch Sonderregeln überschreiben können, denn darauf kommt es doch bei diesen Spielen an, oder?

Helfen diese Ideen weiter?

Stefan

[Nocta]

Ja, wir haben auch vor, die Trennung zwischen allen Spielelementen so gut wie möglich zu machen.
Dann wär's natürlich nicht sinnvoll, wenn man solche verstärkenden Effekte in die Karten einträgt.
Wir wissen noch gar nicht genau, was für Kartentypen wir alle im Spiel haben wollen.
Solche Verstärker-Karten wie du sie angesprochen hast bestimmt auch.
Aber auch Zauberkarten die dem Gegner zum Beispiel über 5 Runden hinweg Schaden zufügen könnten, wenn er eine bestimmte Aktion durchführt, und so weiter.
Da fände ich es Sinnvoll das ganze in eine Effekte-Liste einzutragen, die jede Runde abgefragt wird und eventuell Effekte, die nicht mehr wirksam sind löscht oder neue einträgt und dann auch ausführt.
Und der Effekt verschwindet dann eben beim Löschen wieder, da er auch nicht mehr abgefragt wird.
Vielleicht auch verschiedene Effekte-Listen, die bei verschiedenen "Events" abgefragt werden.
Zum Beispiel muss ein +2 Angriffs-Effekt ja nur jede Runde abgefragt werden und wenn diese Karte eventuell während der Runde zerstört wird, könnte diese ja einen Destruktor o.Ä aufrufen um ihre Wirkung rückgängig zu machen.
Aber ein Stiehl-Dem-Gegner-X-Lebenspunkte-Beim-Angreifen-Effekt müsste bei jedem Angriff abgefragt werden.

Ich hab mir sogar schon überlegt, dass ein normaler Angriff eigentlich auch ein Effekt ist.
Was für einen Effekt hat ein Angriff? Er verursacht schaden nach vorgegebenen Regeln. Eventuell könnte ein Angriff eines Monsters auch noch eine Paralyse auslösen oder weiß ich was, was ja auf jeden Fall ein Effekt ist. Aber ob des
Also könnte man den Angriff auch als Effekt bzw mehrere Effekte beschreiben.
Aber irgendwie wär's auch sinnlos. Wahrscheinlich reicht's wenn man den Angriff als Angriff sieht und dann zusätzliche Effekte einträgt.
Wird sich zeigen
Das sind auch nur so ein paar verwirrte Gedanken von mir, wir werden heute Abend dann versuchen die Datenstruktur einigermaßen zu klären.
Unser ziel ist halt das ganze möglichst flexibel und unabhängig voneinander zu programmieren.
Im Idealfall müsste man dann bei einer Änderung im Spielsystem (solange sie gewisse Grenzen einhält) nur in dem Teil des Spieles was ändern, der damit in Berührung kommt.

[olliander]

@sma:
Verschiedene Kartenstapel wird es auf jeden Fall geben. Charakterkarten, Energiekarten (o.ä.), Bonuskarten etc...

Für jeden Kartentyp wird es eine aus einer Basisklasse mit dem Namen 'card' (bspw.) abgeleiteten Subklasse geben, also bspw. 'char_card' oder eben 'energy_card' usw. Für die eigentlichen 'Verhaltensweisen' der Karten, die du ansprichst, die ja in die jeweilige Kampfsituation einbezogen werden müssen, habe ich mir eine Art Kampfsystem vorgestellt, welches pro Zug eines Spielers erst sämtliche Attribute der jeweils eingesetzten Karten sammelt (Schaden, evtl. Langzeitauswirkungen (Gift etc.), Heilung etc.), logisch verknüpft und auswertet und dann die Auswirkungen an den Gegner (nach Abfrage, ob evtl. Defensiv-Attribute durch Rüstungen oder Schildzauber vorhanden sind, die einen Angriff abschwächen oder gar zunichte machen) weiterleiten. Man geht also nicht davon aus, welche Art Karte man gerade vor sich hat, sondern lediglich von ihren kampfrelevanten Attributen wie AP, VP etc. Damit wäre diese Verhaltensfrage meines Erachtens nach eleganter gelöst.

MfG,
olliander