Hallo Besucher, der Thread wurde 4,2k mal aufgerufen und enthält 26 Antworten

letzter Beitrag von Hamrath am

Neues Spiel: Maze Of Death

    Moin,


    für den aktuellen Ludum Dare*-Wettbewerb habe ich auch dieses Mal wieder ein C64-Spiel geschrieben. Das vorgegebene Thema ist "Sacrifices must be made" (auf deutsch: "Opfer müssen gebracht werden"). In meinem Spiel "Maze of Death" muss man ein Labyrinth erforschen und zum Ausgang finden.


    Das Problem ist: Es ist stockdunkel und die Wände sind tödlich. Berührt man eine Wand, verliert man ein Leben (von 3) und wird am Startpunkt des Labyrinth wiedererweckt. Glücklicherweise bekommt man das Leben zurück, wenn man sich zu seinem Sterbeort begibt. Die einzige, sonstige Hilfe ist, dass man vor jedem Schritt gesagt bekommt, ob 1, 2, 3 oder 4 Wege frei sind (kleiner Tipp: ein Weg ist immer frei, nämlich der, aus dem man kommt).


    Die Idee würde ich als eine Mischung aus Minesweeper, Simon Says und einem Labyrinthspiel bezeichnen. Die Level werden immer zufällig generiert.


    "Maze of Death" wurde komplett in BASIC V2 geschrieben und dann mit AustroSpeed compiliert.


    Gespielt wird mit Joystick in Port 2.


    Die bisherigen Rückmeldungen sind recht positiv. Und was sagt Ihr?


    Titelbild
    forum64.de/wcf/index.php?attachment/164260/


    Ingame-Screenshot


    Download: mazeofdeath.d64


    * Ludum Dare ist ein vierteljährlicher Spieleprogrammierwettbewerb, bei dem man innerhalb von 48 Stunden zu einem vorgegebenen Thema ein Spiel programmiert.

    So, ab jetzt wird es spannend. Die Rückmeldungen der letzten 24 Stunden sind durchweg positiv. Höchstens, dass Maze of Death etwas eintönig und zu lang ist, wird bemängelt. Ideen für Verbesserungen habe ich bereits. Vielleicht versuche ich mich demnächst mal daran, das Spiel auf Assembler zu porten und dann neue Ideen einzubauen.


    Inzwischen habe ich sogar genug Punkte, um in die finale Wertung aufgenommen zu werden. Das war mir mit meinem letzten Ludum Dare-Spiel für den C64 noch nicht gelungen. Also, mal schauen, wo ich am Ende lande. 8)


    Den offiziellen Link zum Competition-Beitrag findet ihr übrigens hier.

    Nettes Spiel. Gut finde ich ja, daß man sein verlorenes Leben wiederbekommt, wenn man zu Sterbepunkt geht. Grafisch halt sehr oldschool. Gefällt mir dennoch. Eine größere Figur (16x16 Pixel) und passenden Mauern wäre noch edler. ;) Das Spiel hat aber potential.


    Kannst du mir den BASIC Code mal zusenden. Ich kann ja mal eine Commodore Plus/4 (oder C16?) Portierung machen.

    Zitat von RKSoft

    Eine größere Figur (16x16 Pixel) und passenden Mauern wäre noch edler.

    Oh, das ist eine tolle Idee! Damit wäre auch gleich die Größe des Labyrinths verkleinert und der Spielspaß erhöht.


    Zitat von RKSoft

    Kannst du mir den BASIC Code mal zusenden. Ich kann ja mal eine Commodore Plus/4 (oder C16?) Portierung machen.

    Gerne. :) Den Code findest du auf der ldjam-Seite (im zweiten Post des Threads).

    Code
    1. 100 ex=0
    2. 101 if peek(l-1)<>102thenex=ex+1
    3. 102 if peek(l+1)<>102thenex=ex+1
    4. 103 if peek(l-40)<>102thenex=ex+1
    5. 104 if peek(l+40)<>102thenex=ex+1

    kannst du auch

    Code
    1. 100 ex=ex-(peek(l+1)<>102orpeek(l-1)<>102orpeek(l-40)<>102orpeek(l+40)<>102)

    machen. Das gleiche funktioniert hier nochmal:

    Code
    1. 150 d=peek(56320)
    2. 151 ifd=123thendd=l-1
    3. 152 ifd=119thendd=l+1
    4. 153 ifd=126thendd=l-40
    5. 154 ifd=125thendd=l+40

    zu

    Code
    1. 150 d=peek(56320):dd=l+((d=123)or-(d=119)or40*(d=126)or40*-(d=125))

    Und bei solchen Dingen kannst du noch viel mehr Zeit einsparen:

    Code
    1. 157 ifd=127thengoto100


    machst du zu


    Code
    1. 157 on-(d=127)goto100

    Wenn du in eine Hauptspielschleife mit GOTO irgendwo tiefer ins Programm springst, verlangsamt sich die Laufzeit noch viel mehr. Wenn du mit GOTO arbeiten musst, packt den Teil, zu welchem das GOTO springt, soweit wie möglich an den Anfang des Programms. ;)


    Ich hoffe, die Optimierungen funktionieren soweit.


    Nachtrag:
    Wenn möglich, immer nur einen Buchstaben als Variable nutzen, keine 2 oder mehr. Auch der Blödsinn mit a% oder cc% ist, nach meiner Erfahrung, dünnpfiff. Das Programm wird dadurch nicht wirklich schneller; auch wenn es einigen gern meinen. Ich hab das bei meinen 2 letzten Spielen auch immer wieder versucht und hab feststellen müssen, daß es eben nicht schneller wird; leider.


    2.Nachtrag:
    So funktioniert bei mir das Spiel einwandfrei und schneller als vorher. Wenn du noch die Sprünge zur Anzeige entfernst, rennt es.

    Ah, danke. Das ist hilfreich. Ich hab auch andere Sachen inzwischen optimiert. Hab fast alle Hilfs-GOSUBs entfernt. Gerade die Cursor-Positionierung hab ich einfach direkt in den Code geschrieben, ohne Sprünge. Ohne deine Tipps hab ich inzwischen schon 10 Zeilen eingespart.


    Ich hab bspw. die Farb-POKEs bei der Generierung entfernt. Ob der Hintergrund braun oder weiß ist, muss ich erst während des Spiels festlegen. Ich hatte auch mal probiert, das Labyrinth erst im Speicher zu generieren. Ggf. ist der Ansatz auch nicht die schlechteste Idee. Jetzt POKE ich das komplette Labyrinth ja direkt in den ScreenRAM, was auch Zeitverschwendung ist. Eigentlich muss ich die Position einer Mauer erst anzeigen, wenn der Spieler dagegen läuft.


    Hauptsächlich brauch ich das Kompilieren aber für die Erstellung des Labyrinths. Das ist halt wesentlich fixer dann. Aber ggf. kann man auch das optimieren.


    Alles in allem denke ich aber, dass ich daraus mein erstes größeres Assembler-Programm mache. Das Spiel ist relativ simpel und für div. Ideen, die ich zur Verbesserung habe, wäre das wohl der bessere Weg.

    Zitat von RKSoft
    Code
    1. 100 ex=ex-(peek(l+1)<>102orpeek(l-1)<>102orpeek(l-40)<>102orpeek(l+40)<>102)

    Ja, kann man so machen. Führt aber, wie man hier sieht, zu völlig unleserlichem und unverständlichem Code.
    Zumal hilfreiche Kommentare ja auch wieder Zeit brauchen und aus diesen Grund entfallen müssen.


    Da sind ja gut kommentierte Assemblerprogramme besser zu lesen (und viel viel schneller).


    Was spricht gegen die moderne Methode: Leserlich programmieren und compilieren?

    Zitat von Bytebreaker

    Wenn man den sportlichen Ehrgeiz hat, natives Basic ohne Compiler auf spielbare Geschwindigkeit zu trimmen.

    Als eigene Disziplin: Ok. Wie gesagt, kann man so machen. Muss man aber nicht.


    Aber wenn ich lese, dass Hamrath schon anfängt, seine Gosubs zu entfernen und damit beginnt, sein Programm in Spagetticode zu verwandeln... :nixwiss:


    Ausserdem ist das hier definitiv kein Basic mehr:

    Code
    1. 157 on-(d=127)goto100

    Das ist Codeverschleierung. :D

    Zitat von detlef

    Aber wenn ich lese, dass Hamrath schon anfängt, seine Gosubs zu entfernen und damit beginnt, sein Programm in Spagetticode zu verwandeln...

    Es waren insgesamt 6 GOSUBs auf 2 Hilfsfunktionen (Cursor setzen und Zeile löschen) bei insgesamt knapp 150 Zeilen Code. Das ist schon okay, denk ich. ;)


    Aber Ihr habt schon recht. Man muss es mit der Optimierung auch nicht übertreiben, wenn der Geschwindigkeitsvorteil marginal ist. Der Flaschenhals ist ja definitiv nicht die Eingaberoutine oder die Anzahl der möglichen Wege. Ich fand die Vorschläge von RKSoft trotzdem interessant. Ob sie mir wirklich nützlich sind, steht auf einem anderen Blatt.

    Zitat von RKSoft

    Auch der Blödsinn mit a% oder cc% ist, nach meiner Erfahrung, dünnpfiff. Das Programm wird dadurch nicht wirklich schneller; auch wenn es einigen gern meinen.

    Meint das wirklich jemand? Die Wahrheit ist: Das Programm wird langsamer (jedenfalls im BASIC des C64). Das liegt daran, dass alle arithmetischen und logischen Operationen nur für float Variablen vorhanden sind, es muss also für jede Aktion konvertiert werden. Allerdings: Wenn man einen Compiler verwendet sieht das schon wieder anders aus, der kann aus der Verwendung von integer Variablen "besseren" Code generieren.


    Zitat von detlef

    Was spricht gegen die moderne Methode: Leserlich programmieren und compilieren?

    Das ist nicht unbedingt die Herangehensweise in BASIC, dann kann man gleich was anderes (C, Assembler) nehmen -- was ich auch immer bevorzugen würde.


    Zitat von detlef

    Ausserdem ist das hier definitiv kein Basic mehr:

    Code
    1. 157 on-(d=127)goto100

    Das ist Codeverschleierung. :D

    Doch, GENAU das ist (optimiertes) BASIC auf dem C64 ;) Und ein schönes Beispiel dafür, dass "guter" BASIC-Code schlicht unlesbar ist. Da frage ich mich immer wieder, wieso sich Leute BASIC wirklich antun.

    Zitat von Hamrath

    Man muss ja nicht so programmieren. :P Und es gibt sicherlich genug Gründe, um BASIC zu nutzen. Für mich wären das bspw. alle nicht zeitrelevanten Programmabläufe.

    Für mich höchstens "nostalgischer Spaß" ;) Warum? Wenn es nicht zeitkritisch ist, will man in der Regel etwas anderes erreichen: übersichtlichen, modularen, gut wartbaren Code. Auf dem C64 würde sich sicher z.B. C anbieten. Oder diverse Umsetzungen von Pascal. Geht das auch in BASIC? Eher nicht so .... ;)

    Kurz nochmal Offtopic:
    Mit BASIC hab ich, wie viele andere auch, auf einem 8 Bit Heimcomputer angefangen zu programmieren. Heute reizt es mich einfach, alles an Geschwindigkeit aus einem Interpreter rauszuholen. Wenn ich Spiele mit Parallax-Scrolling, vielen Gegnern und Features machen will, nutz ich andere Sprachen. Assembler kann ich nicht und hab auch keine Zeit/Geduld mehr, es zu lernen. Das einzige, woran ich mich irgendwann mal ranwagen werde ist C für die Heimcomputer.


    Topic:
    Mir gefällt dein Spiel auch ohne die Optimierungen. Auch die Idee find ich klasse. Mir fallen da wieder so einige neue Sachen ein, was man machen könnte; auch in BASIC. :D

    Zitat von RKSoft

    Mit BASIC hab ich, wie viele andere auch, auf einem 8 Bit Heimcomputer angefangen zu programmieren. Heute reizt es mich einfach, alles an Geschwindigkeit aus einem Interpreter rauszuholen.

    Was durchaus eine "valide" Motivation ist, genauso wie es andere reizt, in Assembler "alles" aus der CPU und dem Grafikchip zu holen ;) Gemeinsam haben die Resultate vermutlich eine eher schlechte Lesbarkeit, ich behaupte mal in entsprechend trickreichem BASIC ist es noch schlimmer :)

    Zitat von RKSoft

    Assembler kann ich nicht und hab auch keine Zeit/Geduld mehr, es zu lernen. Das einzige, woran ich mich irgendwann mal ranwagen werde ist C für die Heimcomputer.

    Wenn du das wirklich mal machst ist die Wahrscheinlichkeit gar nicht so gering, am Ende doch bei Assembler zu landen -- gerade auf dem C64 ist man mit C nämlich schon sehr nahe dran. Irgendwo habe ich mal gehört, C sei eigentlich auch nur ein "portierbarer Assembler". Ist erstaunlich nahe an der Wahrheit ;)

    Zitat von RKSoft

    Mir gefällt dein Spiel auch ohne die Optimierungen. Auch die Idee find ich klasse. Mir fallen da wieder so einige neue Sachen ein, was man machen könnte; auch in BASIC. :D

    Ich hab's noch gar nicht ausprobiert X/ allerdings finde ich auch, dass die Idee sich zumindest richtig gut anhört: Sehr simpel und trotzdem kommt es mir gar nicht bekannt vor, so muss das sein. Werde es bestimmt noch antesten :)


    Was das BASIC angeht, es ist was ganz anderes, wenn man vorhat, das Resultat zu kompilieren. Irgendwelche kryptischen Optimierungen für den Interpreter könnten sich da am Ende sogar als schädlich herausstellen. So wie ich das sehe ist dieses Spiel hier unter extremem Zeitdruck entstanden, dann ist es für jemanden, der im C64 BASIC "fit" ist, sicher nicht der schlechteste Ansatz, damit loszulegen und das zu kompilieren -- um überhaupt fertig zu werden ;) (was ich übrigens, ganz egal in welcher Sprache, doch recht beeindruckend finde!)


    Würde man das ohne die Deadline so planen wäre ein Compiler für eine andere Sprache aber wahrscheinlich die bessere Wahl.