Hello, Guest the thread was called28k times and contains 416 replays

last post from RKSoft at the

Hakuna Matata - it's Matatu Time on C128 and Plus/4

  • Hallo!


    Bugjam bekommt heute ein verfrühtes C128 Nikolaus-Geschenk von mir und natürlich alle, die sich für Basic-Kartenspiele auf 8 Bit Rechnern interessieren. Ich dachte ich mache daraus einen eigenen Thread, der Vorgänger-Thread "Kartenspiele" ist vom Thema her ja nicht direkt Matatu.


    Das Spiel funktioniert wie Mao Mao, nur mit ein paar Sonderregeln:


    As (Wert 15) = Man darf Farbwechsel bestimmen
    Bube / 8 (Wert 11 / Wert 8 )= Man darf nochmal ablegen
    2 (Wert 20) = Der nächste der ziehen muss weil er nicht ablegen kann zieht +2. Das kann sich steigern mit weiteren 2en und das Spiel merkt sich die Strafe bis zu dem Moment wo einer ablegen muss
    Cutter 7 = Bei Spielbeginn liegt irgendeine Karte auf dem Stapel die irgendeine Farbe hat. Diese Farbe ist die Cutter-Farbe (also Herz, Pik, Karo oder Kreuz). Wer nun eine 7 dieser Farbe auf der Hand hat, kann "cutten", wenn das Blatt auf seiner Hand <= 25 Punkte ist.


    Dann wird ausgezählt und wer die wenigsten Punkte hat gewinnt.
    Ansonsten gewinnt der, der seine Karten zuerst los hat.


    Ich habe noch eine Strafe eingebaut, und zwar für den Fall dass der Stapel leer wird weil alle Karten auf die Spieler verteilt sind. Dann wird das Spiel beendet anstatt dass Ziehversuche unterbunden werden. Natürlich könnte man durch Ablegen das Spiel zu beenden versuchen, man hat genug Blätter auf der Hand. Aber wer so blind ist und so viel übersieht, der sollte es von vorne probieren. Matatu ist ein schnelles Spiel, das geht in der Regel zack zack. Man kommt auch in so "Fieberphasen" wo man sagen kann "und jetzt das As, dann den Buben und jetzt hau ich die 7 rein".


    Fehleingaben und Schummelversuche werden abgefangen. Das Spiel spricht auch besser mit einem als die Android-App zu Matatu, d.h. es sagt einem ob es Cut-Versuche gab, wie sie genau ausfielen, lässt die Info stehen anstatt sie sofort auszublenden so dass man sie nicht lesen kann, sagt einem bei wieviel Strafe der Karte 2 wir aktuell sind und sagt einem auch, welche Farbe man nach einem As spielen muss wenn man eine Fehleingabe gemacht hat.


    Für unsere Forum-Coder:


    Noch fehlt eine KI. Erstmal möchte ich das Spiel im 2-Spieler-Modus von Bugjam testen lassen.


    Es fehlt auch eine grafische Petscii-Darstellung. Es gibt ja vorgefertigte Chars die wie gemacht sind für das Abbilden von echten Spielkarten.
    Es stellt sich aber dann die Frage, wie bildet man das ab mit zunehmenden und abnehmenden Karten auf der Hand? Bei mir macht das Abbilden des Spielfelds die Routine 1600. Die muss man ersetzen. Die Eingabe bleibt tastaturbasiert, also "HE11" eingeben um Herz 11 zu spielen.


    Möchte irgendjemand die KI oder die Petscii-Grafik übernehmen und das Programm erweitern? So ganz "dumm" im Sinne von "guck ob Farbe oder Zahl passen und spiel das aus" bekomme ich die KI auch hin. Strategien abbilden scheint mir schwieriger und ich sage mir am Anfang lieber keine KI als eine schlechte oder zu langsame. Wenn keiner mitmacht muss ich überlegen ob ich das Prgramm selber fortsetze/erweitere. Ich warte noch ein bisschen ab ob wir hier gemeinsam etwas tun und dann stelle ich das Spiel auf csdb.


    @ c64 Junior:
    Schau Dir den Quellcode an. Da steht auch einiges drin über das Auswerten von Strings. Ich bin da wenn Du Fragen hast. Heute am C64 wursteln ist sehr ähnlich zu dem, was junge Leute mit Arduinos und Raspberry Pis tun. Es ist das Verstehen der grundlegenden Hardware-Ebene und die ist von der Grundlogik gleich geblieben. Auch in Basic bildet man das ab durch das Setzen und Löschen von Flags und dem Verwalten von Zuständen.


    @ RK Soft:
    Du kannst jetzt schon auf V2 Basic portieren. Im Grunde nur die scnclrs durch print chr$(147) ersetzen, dann ist da noch eine do while loop und ein einziges if then else. Der Rest ist eigentlich V2 Basic obwohl ich mich bemüht habe, es "anders" zu machen für meinen C128. Was auch noch anders zu sein scheint ist die Bildschirmausgabe. Wenn man das C128 Prg am C64 ausführt klappt ja die Textausgabe am Anfang. Die sieht aber anders aus als im Original. Da sind Leerzeilen dazwischen die es beim C128 nicht gibt.

  • Ok, da hat mich die Neugier gepackt, die V2-Version mal anzusehen, zumal die Anpassungen minimal sind.
    Die Notwendigkeit für das DO-LOOP-Konstrukt ist mir jetzt nicht klar, wo das doch mit FOR-NEXT eigentlich besser und effizienter geht. Auch das ELSE in 3030 kann einfach vermieden werden.
    Optimierungsmöglichkeiten im Code selbst gibt es genug, hab aber dahingehend nichts gemacht, weil das Programm ohnehin hinreichend flüssig läuft. :D
    Für V2-BASIC:
    matatu.bas.txt
    matatu.prg

  • @ Jeek


    Du hast es schon richtig erkannt. :D
    Ich bin ziemlich gedrillt V2 Code zu schreiben und die paar wenigen V3.5 / V7 Code-Konstrukte sind bewusst gewollt und konstruiert gewesen damit ich "die neue Welt" meines C128 auch nutze.


    Der Code hat den Status "läuft akzeptabel schnell ohne zu crashen". Von optimiert würde ich auch nicht reden.


    Einen Bug hab ich auch schon gefunden. Die Cut-Prüfung wird immer zugelassen, auch wenn das Blatt gerade nicht passt. Weil Cut-Gelegenheiten so selten vorkommen habe ich das übersehen. Wer konform spielt, dem fällt nichts auf, aber wer die Cut7 spielt sobald er sie auf dem Blatt hat wird sie spielen können, egal ob die Farbe passt.

  • Anbei noch gefixte C64 und C128 Versionen.


    In beiden wurde das Stapelende nicht richtig abgefragt.
    Der Cut7-Bug sollte draußen sein.

  • @ Hexworx


    Danke für den Hinweis. Hab das bei mir eben korrigiert für die spätere Veröffentlichung auf csdb.


    Die Stapel- und Spielerverwaltung findet in einem Array ca$(52,3) statt.


    ca$(52,0) ist ein Hilfsarray, mit dessen Hilfe ein durchmischter Kartensatz von 52 Karten am Ende in ca$(52,3) landet. ca$(52,0) lösche ich pro Forma nach der Initialisierungsphase.


    ca$(52,1) und ca$(52,2) sind die Spielerarrays. Natürlich wird kein Spieler jemals 52 Karten auf der Hand haben. Es geht aber mit 7 Karten pro Spieler los. Die 14 Karten hebe ich von ca$(52,3) ab und fülle die Entnahmestellen mit "0000".


    Das Stack-Array ca$(52,3) sieht also bei Spielbeginn so aus: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 HE12 SP13 usw..
    bis Array-Ende CL07 (alles ausgedacht jetzt bis auf die führenden Nullen, deren Vorgängerwerte jetzt bei den Spielern sind).



    Es gibt 2 Zeiger. Der eine zeigt auf Element 15 direkt nach der letzten Null, also auf HE12. Der zweite zeigt auf das 52. Element, also CL07.


    Ablegen schiebt die aktuelle Spielerkarte auf die linksliegende nächste Null des ersten Zeigers, der dann um 1 verringert wird. Das ist der Stackablage-Zeiger.
    Aufnehmen schiebt die aktuell letzte Stapelkarte zum aktuellen Spieler und der Stackaufnahmezeiger verschiebt sich ebenfalls um 1 nach links.


    So muss ich keine Rotation vornehmen. Allerdings ist Spielschluss, wenn das Stackende erreicht ist, wir also bei Pos. 14 sind. Ich nutze ja keinen Extra-Stack sondern nur das eine Array mit 2 Zeigern.


    Irgendwie bin ich bei dieser Konzeption hängen geblieben. Im Source ist eine eigene Stack-Rotier-Routine die ich so aber nicht brauche, zumal ich die abgelegten Karten nicht wiederverwende.

  • Das mit Ass und co, kannst du das etwas genauer erklären. Peil das irgendwie nicht so ganz.
    Für die BASIC V2 Portierung brauch ich dann ja wohl doch nicht sorgen. ^^


    PS:
    Habs eben mal auf nem +4 getestet und rennt super. Nur mit den Regeln tu ich mir schwer irgendwie. Ich habe eine Runde gegen mich selbst gespielt und gewonnen xD.


    @Code
    Ja, da gibt es einige Optimierungsmöglichkeiten. Wie schon @JeeK schrieb, kann man FOR-NEXT dort besser verwenden. Meine Erfahrungen mit DO-LOOP sind, daß es sehr langsam ist. FOR-NEXT ist auch besser für Portierungen.


    Zu Zeile 3030:
    @JeeK hat dies ja unter BASIC V2 bereits optimiert.


    Zum grafischen Teil:
    Soll ich mich mal damit auseinandersetzen? Bei MauMau gibt es ja 7,8,9,10,Bude,Dame,König,Ass. Wie hast du die definiert? Deine DATA-Zeilen bringen da irgendwie nix her.

  • 64er Version: ?UNDEF'D STATEMENT IN 2052...


    Ich denke auch immer noch, mit Werten statt Strings wäre das alles irgendwie einfacher zu händeln gewesen (und schneller), oder?

  • @ rk soft


    As = wenn ich ein As, also z.b. Eine he15 Spiele, dann darf ich bestimmen welche farbe als nächstes gespielt werden muss, also he, cl, sp und di. Die englischen Abkürzungen für heart (Herz), Clubs (Kreuz), spades (Pik) und diamonds (Karo).


    Bube und 8 spielen bewirkt dass ich zwei mal ablegen darf.


    eine zwei legen heißt, der nächste der nicht bedienen kann zieht zwei Karten statt einer. Antwortet der wieder mit einer 2 sind es 4 usw.


    Cutten heißt das man eine 7 auf der Hand hat mit derselben Farbe wie der ersten Karte auf dem Stapel zu Spielbeginn.


    Wenn man sein Blatt zusammen rechnet, <=25 Punkte hat und die cutter Farbe gerade auf dem Stapel liegt kann man die 7 ausspielen. Es kommt zur Punkte Auszählung auf der Hand und wer weniger hat gewinnt.


    Ich habe die Spielkarten alle als Text strings definiert mit einem farb Teil am Anfang und einem Zahl Teil am Ende. Dabei habe ich für Bube, As, König und zwei nicht text genommen sondern gleich den Wert im zahlen Teil.


    He15 = Herz as
    Cl20 = Kreuz 2
    Di13 = Karo König


    Ich mache das so weil ich ja in der Lage sein muss das Blatt zusammen zu rechnen. Dazu schneide ich die hinteren beiden Ziffern des strings aus, konvertiere sie in Zahlen und rechne damit.
    Den farb Teil hätte ich auch anders organisieren können indem ich gleich die petscii codes für Herz, pik, Kreuz und Karo nehme. Habe ich aber warum auch immer nicht.


    Es wäre toll wenn du den Karten zeichnen Teil machst.

  • @ Hexworx


    Post 4 bitte nehmen.
    Ich zitiere aus der C64 Version:



    Steht doch richtig drin und tut bei mir auch. Jeeks Version in Post 2 enthält den von Dir besagten Fehler ebenfalls nicht. Mein Gefühl sagt mir Du bist kein prg-Herunterlader sondern ein Text-Herunterlader weil Dich eben auch Quellcodes interessieren. Da muss irgendwas bei Copy/Paste verrutscht sein.

  • Leider hat sich bugjam zu dem Thema noch nicht geäußert (ist aber ja auch noch recht frisch).
    Aus meiner Sicht ist Matatu jetzt spielbar.


    Es sind noch Eigenheiten drin die anders sind als bei der Android App, nämlich dass man eine Cutter 7 trotzdem ablegen darf, auch wenn man nicht cutten kann (das Cutten selber wird aber verweigert).


    Außerdem kann man einen Farbwechsel nicht kontern mit einem weiteren Farbwechsel. Das Programm zwingt einen, den Farbwechsel erst zu bedienen bevor man einen eigenen ausspielen kann.


    Bei den Zieh-2-Strafkarten ist das anders. Die summieren sich auf und man kann eine 2 mit einer weiteren beantworten und der erste der nicht ablegen kann zahlt, äh zieht die Zeche.


    Ich würde das so lassen und mich jetzt um eine simple KI kümmern. Dann ist sie halt nicht raffiniert, aber immer noch besser als gegen sich selbst zu spielen denn so viele echte Spielpartner hat man ja nicht. Meine Frau hat sich bei Matatu geziert, dabei hat sie mein Kniffel-Spiel damals noch gut mitgemacht. Also zu Info, ich arbeite jetzt an einer einfachen KI.


    @ RK Soft


    Kommst Du klar? Ist es ok für Dich mit dem bestehenden Code an der Petscii-Visualisierung mit Herzen, Karos, etc. und Kartensilhouetten zu arbeiten? Der Code ist ja mit gerade deshalb unoptimiert, damit er für Dich lesbar ist und mit REMs bestückt. Soll ich noch irgendwas am Spielgerüst tun bevor Du tätig werden kannst oder kannst Du das nehmen und verändern was Du vorfindest?

  • & rk soft du hast gegen dich selbst im zwei Spieler Modus gespielt. Oben wechselt immer Player 1 und Player 2 und jeder sieht sein Blatt.

    Das war eigentlich mit einer Brise ironie versehen. Ich hab das Spiel getestet und halbwegs verstanden. Das ich da natürlich im 2 Spielermodi gegen mich selber spiel und gewinne, sollte klar sein ;)



    Warum so kompliziert, oder denk ich einfach zu kompliziert? ^^


    Karte 2 = 20 <-- 2 Karten ziehen oder gleichwertige ablegen, um den Karte-Nimm-Faktor zu erhöhen (2,4,6,8 usw.) (wäre die Karte 7 bei Mau Mau)
    Karte 3 = 03
    Karte 4 = 04
    Karte 5 = 05
    Karte 6 = 06
    Karte 7 = 07 <-- Cut (vorzeitiges Spielende, wenn diese Karte die gleiche Farbe wie die erste Karte zu Spielbeginn hat + man <=25 Punkte auf der Hand hat)
    Karte 8 = 08 <-- der nächste Spieler setzt eine Runde aus (bewirkt, daß man selber eine weitere Karte ablegen darf)
    Karte 9 = 09
    Karte 10 = 10
    Karte Bube = 11 <-- gleich wie Karte 8
    Karte Dame = 12
    Karte König = 13
    Karte Ass = 15 <-- ich darf eine neue Farbe wählen (wäre wie Bube bei Mau Mau)


    HE = Herz, CL = Kreuz, DI = Karo, SP = Pik


    So korrekt? Dann mach kann ich mich ans visuelle ranmachen.


    Im übrigen hätte ich intern so nicht gehandelt, sondern hätte dort mit "Tiles" gearbeiten; sprich Variablen (ID, Punkte). ;)



    PS.:


    bitte nicht steinigen, bin gesundheitlich ein wenig angekratzt

  • @ Hexworx


    Post 4 bitte nehmen.

    Ich will ja nicht streiten, aber im "matatu64.prg" in Beitrag #4 fehlt nach wie vor Zeile 3000 :alt:;) .

  • Rk soft super dann ändere ich die datas so dass man nicht einen String Wert hat den man zerschneiden muss und die Hälfte davon bei Bedarf in Zahl wandeln sondern immer abwechselnd poke wert für screen ram und direkt rechenbare Zahl im Wechsel. Je zwei Werte bilden eine Karte.


    Ich baue die Verarbeitungslogik entsprechend um.


    Nebenher mache ich noch die simple ki aber auch wenn sie simpel wird, wird es ein paar Tage dauern bis sie fertig ist.