Spiel in Arbeit: 8192

  • Spiel in Arbeit: 8192

    Ich wollte auch endlich mal ein simples C64 Spiel schreiben, also habe ich mir vorgenommen, das Handy- und Browser-Game "2048" für den C64 umzusetzen. Dabei gleich auch eine kleine Umbennennung: 8192. Wenn man gut ist schafft man das, und C64-Gamer sind wohl gut :)

    Inzwischen ist ein erster Zustand erreicht, der eine "public alpha" rechtfertigt, also wer mag bitte testen (disk-image hängt an).

    Noch offene Punkte:
    • Laden und speichern plus Highscore-Liste
    • Sauberes beenden (zurück zu BASIC)
    • Sound! (Musik, Effekte)
    Den Quellcode gibt's hier.
    Dateien
    • 8192.d64

      (174,85 kB, 17 mal heruntergeladen, zuletzt: )
  • Nur nicht entmutigen lasse, wenn man feststellt, dass es schon etwas ähnliches gibt, wie das was man macht.
    Wenn Du erst mal die Basis gelegt hast, kannst Du Dich von dem anderen Spiel leicht weg-differenzieren.
    Es gib eigentlich in jedem Spiel etwas das man selber anders gemacht hätte. - HIer hast Du die Möglichkeit :)
    CIA and Co have reached the C64 - see the proof in the Hack Attack Trailer
  • z.B. das man mit einem mit 1024 gefülltem Bereich anfängt - hatte ich auch überlegt bei mir.
    Denn bis kurz vor 2048 ist es doch recht einfach zu kommen, da jedesmal durchzumüssen
    dauert halt jedesmal. Oder leicht andere Regeln - ich hab z.B. 'nen 2. Regelsatz als Option, wo
    man mehrere, gleiche beim Zuganfang vereinen kann für höhere Punkte.
    Also 2-2-2 -> 8 oder 8-8-8 -> 32

    das hilft wieder, schneller zu 2048 zu kommen. Aber danach nicht wirklich. Was ich so auch wollte,
    um das Anfangsspiel zu verkürzen..

    Zaadi hat da völlig recht - es gibt immer was, das man selbst gern hätte.

    Oh, und permanente Hiscoretabellen..
  • RetroJeck schrieb:

    z.B. das man mit einem mit 1024 gefülltem Bereich anfängt - hatte ich auch überlegt bei mir.
    Denn bis kurz vor 2048 ist es doch recht einfach zu kommen, da jedesmal durchzumüssen
    dauert halt jedesmal.
    Das sehe ich sehr skeptisch: Der spätere Erfolg hängt stark davon ab, dass man in dieser "langweiligen" Phase gut organisiert vorgeht :)

    RetroJeck schrieb:

    Oder leicht andere Regeln - ich hab z.B. 'nen 2. Regelsatz als Option, wo
    man mehrere, gleiche beim Zuganfang vereinen kann für höhere Punkte.
    Also 2-2-2 -> 8 oder 8-8-8 -> 32
    Das allerdings klingt interessant. Verletzt aber die grundlegende "Steine addieren" Regel. Mal drüber nachdenken ;)

    RetroJeck schrieb:

    Oh, und permanente Hiscoretabellen..
    Ist definitiv auf meiner TODO-Liste ;) Dazu muss ich aber erst noch einen IRQ loader und saver einbauen. Die Musik (ebenfalls TODO) soll ja weiter laufen ;)
  • zrs1 schrieb:

    Ruckelfreies flüssiges spielen hab ich schon, aber das kann C=2048 laut wiki ja auch.
    Das bezieht sich bei unserem C-2048 wahrscheinlich darauf, dass wir als einzige bis dato C64-Umsetzung des Games eine Art Softscrolling für die Tiles realisiert haben – sie springen also nicht im 4er-Raster, sondern bewegen sich verhältnismäßig weich über den Screen – und das halt flüssig und smooth. Das war ALeX und mir wichtig, weil man dann (gerade als Anfänger) besser sieht, was mit den Tiles passiert. Was wahrscheinlich kaum jemand bemerkt, ist, dass wir selbst für dieses grafisch eher simpel erscheinenden Game einen Sprite-Multiplexer im Einsatz haben. Wir nutzen den Hires-Char-Mode und da kann man ja bekanntlich nur eine einheitliche Hintergrundfarbe für den Screen und dazu eine freie Farbe je Char für den Vordergrund wählen (oder optisch umgekehrt, wenn man "negative" Darstellung wählt). Wir wollten aber, wie im Original, farbige Tiles und farbige Ziffern – und so liegen hinter allen Tiles 16 bunte Sprites, die durch die Char-Zahlen durchscheinen. Das nur als Ergänzung zum Wiki-Eintrag (in dem nebenbei auch noch Screenshots der RGCD-Compo-Version gezeigt werden werden und nicht die aktuellen aus der Modul-Release-Version). Nicht, dass meine Ausführungen falsch verstanden werden: Die hier gezeigte Umsetzung gefällt mir auch gut!
  • Retrofan schrieb:

    Das bezieht sich bei unserem C-2048 wahrscheinlich darauf, dass wir als einzige bis dato C64-Umsetzung des Games eine Art Softscrolling für die Tiles realisiert haben
    Achsoo ... habe noch nicht reingeschaut, mache ich irgendwann heute :) Das klingt natürlich sehr aufwändig! Auf so eine Idee wäre ich nie gekommen, habe damit experimentiert, jeden "step" auf dem Board für 2 Frames anzuzeigen und fand das schon irgendwie unnötig langsam. Gewohnt bin ich die Android-Version, die läuft auch eher zackig ab :) Aber klar, für Anfänger ist das sicher super und wie gesagt, einiges an Aufwand zu implementieren.

    Sprites verwende ich bisher auch gar nicht, hatte ich eigentlich auch nicht vor und daher den Screen bei $fc00 :) Ich mach dann einfach mal so weiter wie ich es sowieso vorhatte, das Spiel wird sicher eine "simplere" Umsetzung, aber je nach Geschmack hat es vielleicht am Ende den ein oder anderen "Vorteil" :)
  • Habe über dieses Thema ein wenig nachgedacht und einen "Kompromiss" eingebaut: Gezeichnet wird nur noch jedes zweite Frame und neue Steine "poppen" auf, ähnlich wie in der Android-Version. Das könnte man sicher noch verschönern indem man doch jedes Frame zeichnet (entsprechende Zwischenschritte), was aber ein wenig schwierig wird -- das Zeichnen soll im Border-Bereich abgeschlossen werden. Mal sehen.

    Jetzt interessiert mich nur mal: Findet ihr das so überhaupt besser? Kann man einigermaßen gut nachvollziehen, wie sich das Board bewegt? Und würde sich die Mühe lohnen, Zwischenschritte zu implementieren (draw in jedem Frame)?
    Dateien
    • 8192.prg

      (1,96 kB, 12 mal heruntergeladen, zuletzt: )
  • Man kann fast im ganzen Frame zeichnen, wenn man dabei "hinter" dem Elektronenstrahl bleibt. Ansonsten bleibt noch die Option die VIC-Bänke umzuschalten und verdeckt zu zeichnen (double buffering).
    In a moment all went screaming wild until the darkness killed the light..
  • Draco schrieb:

    Man kann fast im ganzen Frame zeichnen, wenn man dabei "hinter" dem Elektronenstrahl bleibt. Ansonsten bleibt noch die Option die VIC-Bänke umzuschalten und verdeckt zu zeichnen (double buffering).
    Ist natürlich beides absolut logisch ;) Würde aber eine frühe Entwurfsentscheidung* über den Haufen werfen und damit größere Änderungen nach sich ziehen, daher versuche ich es zuerst einmal zu vermeiden :)

    * "Zeichnen im IRQ der mit Beginn des Rahmens ausgelöst wird, außerhalb des IRQ wird die eigentliche Spiellogik abgearbeitet"