Hallo Besucher, der Thread wurde 14k mal aufgerufen und enthält 58 Antworten

letzter Beitrag von Hexworx am

Kartenspiele

    @ RKSoft


    Ok, wenn Du im Boot bleibst bleibe ich auch. 2 Spieler dann.
    Ich behaupte aber weiterhin, gescheite KI und akzeptable KI Geschwindigkeit in der von Bugjam gewünschten Form gibt es mit V2 Basic nicht.


    Machen wir Matatu als Programmierübung. Aber etwas Besseres als die Android App wird das Spiel dann nicht. Ich werde den Code wieder veröffentlichen, evtl. macht ja wer anders die KI und ich liefere das Regelgerüst und den 2P-Modus.

    OK, erstmal 2 Spieler, dass die Regeln stehen. Hast wohl recht, das geht nicht in BASIC - kompilieren bringt ja noch was Speed, aber das genuegt wohl nicht. Andererseits muss er ja nicht gleich spielen wie ein Weltmeister - aber er sollte zumindest so klug sein, wenn er z.B. einen J eund einen K auf der Hand hat, erst den J und darauf dann den K zu legen, anstatt den K, nur weil der mehr Punkte zaehlt. Das ist fuer mich jetzt nicht wirklich "Intelligenz" (im Sinne von Spieltaktik), sondern ganz grundlegende Spiellogik...

    Zitat von bugjam

    Also ich dachte an so ganz einfache Bedingungen, wie IF Gegner_nur_noch_1_Karte_auf_der_Hand_und_hat_sich_Farbe_gewuenscht THEN versuche_Farbe zu_wechseln_auch_wenn_man_bekennen_koennte. :-)

    Irgendwie aus dem Zusammenhang gerissen oder? Wie kommst du plötzlich darauf? Egal, wie siehts hier eigentlich aus?

    Hehe, ja, hast eh recht - ich dachte nur, ich erlaeutere mal die "Intelligenz" etwas naeher - das klingt so komplex, ist aber an sich erstmal recht simpel, wenn man nur die groebsten Fehler vermeiden will, die die "KI" von der App macht. Das ist mir neulich so eingefallen, wahrschinlich als ich auf dem Haeusl sass und Matatu auf dem Handy gezockt habe. ;-)

    Ich habe mir schon ein Konzeptpapier gemacht. Ich arbeite zuerst an der reinen Spielmechanik. Visualisiert wird mit Zahlencodes (H5 für Herz5 usw. in primitivster Formatierung.


    Wenn die Spielmechanik sitzt kommen Char-Grafiken dazu (Rahmen mit Symbolen für Karten, etc). Wobei ich hoffe, dass RKSoft diese Char-Grafiken verändern wird. Er macht das einfach so gut. :-)


    Es müssen dann auch visuelle Lösungen gefunden werden wenn man viele Karten auf der Hand hat, d.h. eine Möglichkeit zu blättern. Das kommt aber erst wenn die Spiellogik sitzt.


    Ich setze das Spiel nicht auf dem Plus/4, sondern gleich am C128 um. Basic 3.5/7.0 nimmt sich da nicht viel. Ich kann aber den "Play" Befehl für das Abspielen primitiver Soundeffekte nutzen ohne den SID näher zu kennen.


    Das Listing wird es für RKSoft sowieso als Textdatei geben.


    Aktuell in der Pipeline habe ich:


    • Matatu in Basic (evtl. dieses Jahr noch - Spielmechanik-WIP-Versionen kann ich ja hier rein posten falls Bugjam das Verhalten testen möchte und Ratschläge geben
    • C64 Intro in ASM mit SID-Musik und mehreren Bildschirmmodi per IRQ (die nächsten 12 Monate)
    • Bitmap-Effekte in Basic am Schneider CPC - das CPC Basic ist halt so überlegen geil, dass man ohne Hardwarekenntnisse Bitmaps manipulieren kann. Es gibt einen Befehl "test", der mir sagt, an welcher BS-Koordinate welche Pixelfarbe gesetzt ist. "testr" ermöglicht eine Pixelabfrage relativ zum aktuellen Koordinatenursprung. So euphorisch der C128 einen macht - für Amateurcoder legt der CPC immer noch ne Schippe drauf. Für Profis ist es egal. Da wird es in jedem Fall Assembler und das gibt an jedem Computer Knoten im Hirn. Da zählt dann nur noch die Hardware, und da punktet der C64 und der C128 vor allem mit Sprites.

    Das klingt doch schonmal sehr gut! Ja, ich werde WIP-Versionen gerne testen. C128 ist auch eine interessante Plattform - da wuerde sich vielleicht der 80-Zeichen-Modus anbieten; wird dann natuerlich etwas komplizierter auf den C64 runterzuporten.
    Und fuer das Intro koenntest Du ja die _naechste_ Ausgabe von dieser Compo anpeilen: http://csdb.dk/event/?id=2526 :-)

    Kleines Update :


    Habe jetzt am c128 die Grundlage geschaffen. Karten mischen und ausgeben funktioniert.


    Erstmal alles text basiert mit 2 Spieler Modus. Dann kommt ki dazu bzw was man in basic als ki halt machen kann.


    Läuft erstmal die engine, kann man die Visualisierung umstellen auf char Grafik mit Karten.


    @ bugjam :


    Ich bin kein Profi coder und vieles was du dir vielleicht einfach vorstellst ist es gar nicht. Allein das verdammte mischen von 52 Karten mit 4 blättern zu je 13 Karten musste ich erstmal hinkriege ohne dass der c128 ewig rechnet sondern halbwegs zackig. Ich mach das gern und weil ich zugesagt habe aber bitte kein Wunder erwarten. Lieber freundlich überrascht sein wenn es am Ende spielbar ist.


    Quellcode kommt hier rein sobald text Version im 2 Spieler Modus fertig. Die text version wird nur das nötigste enthalten, der Fokus geht auf die Logik. Wenn die sitzt geht es ans malen.

    Bytebreaker: Das stimmt wohl, als Nicht-Coder habe ich oft eher naive Vorstellungen davon, was "einfach" und was "schwierig" zu implementieren ist. :-) Keine Sorge, ich finde es super, dass Du Dich ueberhaupt des Projekts angenommen hast, von daher freue ich mich auf jeden Fall auf jedes (Zwischen-) Ergebnis. Ein bisschen Speed kann man sicher auch noch durch Kompilieren rausholen; und wenn es spezifische Fragen gibt, wird Dir hier im Forum ja bestimmt auch geholfen. Das war eh so meine Idee - ein win-win: ein nettes kleines neues Spiel fuer mich und die Community, und eine Lernerfahrung fuer einen Coder.
    Von daher all thumbs up!

    Zitat von Bytebreaker

    Ich bin kein Profi coder und vieles was du dir vielleicht einfach vorstellst ist es gar nicht. Allein das verdammte mischen von 52 Karten mit 4 blättern zu je 13 Karten musste ich erstmal hinkriege ohne dass der c128 ewig rechnet sondern halbwegs zackig.

    Zum Thema "zufällig mischen" verbrechen Programmieranfänger mitunter die maximal umständlichsten Algorithmen, daher hier die Standardlösung: :P


    Bitte nicht als Kritik missverstehen...


    (ach ja, ich war jetzt zu faul, um nachzusehen, welches Argument für RND() in diesem Fall das "Beste" ist)

    Zitat von Mac Bacon

    Zum Thema "zufällig mischen" verbrechen Programmieranfänger mitunter die maximal umständlichsten Algorithmen, daher hier die Standardlösung: :P

    Ähm, nein...


    Zitat
    Code
    1. for i = 0 to ma:rem iterate over all positions
    2. j = int(rnd(0) * ma):rem select a random partner

    Siehe hier: "Similarly, always selecting j from the entire range of valid array indices on every iteration also produces a result which is biased"

    Zitat von Unseen

    Siehe hier: "Similarly, always selecting j from the entire range of valid array indices on every iteration also produces a result which is biased"

    Zitat

    As a concrete example of this bias, observe the distribution of possible outcomes of shuffling a three-element array [1, 2, 3]. There are 6 possible permutations of this array (3! = 6), but the algorithm produces 27 possible shuffles (3³ = 27). In this case, [1, 2, 3], [3, 1, 2], and [3, 2, 1] each result from 4 of the 27 shuffles, while each of the remaining 3 permutations occurs in 5 of the 27 shuffles.

    ...sobald man es weiß, ist es ganz logisch...
    Danke für die Korrektur!

    Ok, hier jetzt die hoffentlich korrekte Version:

    Code
    1. rem shuffle:
    2. for i = ma to 1 step -1:rem iterate over positions (stop early because index 0 could only be swapped with itself anyway)
    3. j = int(rnd(0) * (i + 1)):rem select a random partner
    4. t = s(j):s(j) = s(i):s(i) = t:rem triangle swap
    5. next

    Hab gerade noch gesehen, dass mein erstes Programm sogar noch einen weiteren Fehler hatte, denn eigentlich wollte ich das RND-Ergebnis mit (ma + 1) multiplizieren.


    Endurion: Durch den Test auf belegte/freie Slots landest Du automatisch in der quadratischen Komplexitätsklasse, zumindest habe ich Deine Beschreibung jetzt so verstanden.

    Bin auf eine erste Beta gespannt! :)

    Danke für die Shuffle-Tips. Knapp und elegant wie man es von Euch kennt. :-)


    Ich habe mir etwas eigenes ausgedacht, das vielleicht etwas eigenwillig ist, aber funktioniert, nicht zu lang dauert und einen begrenzten Satz Karten jedes Mal nach etwas umstellt was wie Zufall aussieht.


    Ich sehe es auch kommen dass natürlich bessere Vorschläge kommen was die Programmarchitektur/Konzeption angeht. Davon will ich gerne lernen. Trotzdem möchte ich zunächst versuchen, mit eigenen Denkansätzen in akzeptabler Spielgeschwindigkeit ans Ziel zu kommen. Wenn das scheitert, dann nehme ich die Alternativen. Und beim nächsten Kartenspiel sowieso das Eleganteste was ich damn kenne.


    Ich habe es zum Beispiel mit Mikes Punktsetzalgorithmus auf Bitmaps so gemaht. Ich hatte einen eigenen, der hat auch funktioniert aber ich kenne keinen der so schnell ist wie Mike's. Also ist das meine Referenz. Trotzdem finde ich es wichtig, selbst zu erfinden und nicht nur zu übernehmen, auch wenn die eigenen Sachen nicht auf Anhieb so effizient sind.


    Anbei mein Shuffle-Code, er ist in VICE C128 einfügbar und ausführbar.


    Ich mache jetzt weiter mit dem Regelwerk und der Hauptschleife für den 2-Spieler-Modus. Ihr seht schon ich werde Strings auswerten und Teile davon in Zahlen umwandeln um damit zu rechnen.

    Lese interessiert mit, Bytebreaker :) .


    Was mir aufgefallen ist:


    Zeile 130: Der Zwischenschritt über N$ ist überflüssig/kost nur Zeit.



    Ohne jetzt groß im Spiel zu stecken, würde ich den Kartensatz wohl nur einmal als Strings speichern und die Spieler-Karten nur als Werte händeln. Es sei denn, es gibt einen guten Grund dagegen.