Type-In BASIC Programs

[RT-55J]

Ran into this today:

GOBLINS.BAS - 1D roguelike for the C64 (61 lines)

Poasting here to remind myself to do something with it (play it? port it? make something like it?).

[RT-55J]

okay i played GOBLINS.BAS:



i was too lazy to type in the program myself, so i just dragged-n-dropped the .d64 disk image on the game's itch page into the emulator

it's not much of a game, but it's interesting. the screen is slow to redraw when you move. level generation has no logic (fully random). you just move back and forth collecting loot and keys, and moving goblins and doors out of the way until there's nothing else to do. still it's neat.

there is no "win condition", i guess this is technically "non-game."

i could see a kid interested in this back in the day modifying this code to add all sorts of interesting stuff (maybe i could be taht kid...)

[RT-55J]

Thoughts:

Maybe I could port this to the SMS. Once in CVBasic, once in Z80, and then once in C.

Maybe I could turn this into an actual game with decisions and a goal.

Maybe I could make my own type-in game.

[neen]

rt needs to make a sega master system game 

[RT-55J]

[RT-55J]

there's a couple one-off errors with the collision, but otherwise this works! 

[neen]

nice nice. what's next?

[RT-55J]

gonna squash the bug and refactor the code until it's how i like it.

might add a mechanic or two to make the game actually interesting.

[RT-55J]

Okay. I figured out the bug.

The original code had the viewport rendering and player input handling as part of one big loop. I refactored things so the rendering and input logic were in separate functions.

Code Select Expand

mainLoop:
    gosub drawViewport
    wait ' Avoid stupidly rapid movement
    wait
    wait
    wait
    wait
    gosub playerInput
goto mainLoop
However, it looked like the player was travelling two squares every time I pressed left or right, but that clearly wasn't happening because the player wasn't phasing through anything. Still, sometimes the player would appear to interact with goblins and doors at a distance.

Using a debugger showed that sometimes the position was getting incremented/decremented twice in a frame, but the onscreen position would only sometimes match the position listed in memory. It didn't make any sense to me.

After looking through the code some more, I finally found the error.

The drawViewport and playerInput functions were contiguous in my source code. I forgot to put a Return at the end of drawViewport, meaning that execution fell through to playerInput. Thus, each frame the game would  process the player's input, redraw the playfield, and then process the player's input again without redrawing anything. The CVBasic compiler failed to warn me of this fall-through because I forgot to mark drawViewport as a "Procedure."

very silly language