The game could actually run twice as fast as it currently does, but then there isn't enough time to make much strategic decisions, so I decided this speed was better.
Thanks, those are both good ideas to save some bytes!
The reason I can't make the level look the same every time, is that the random numbers are used both for placing platforms and treasures, so even if you seed the PRNG the same every time, it will start to diverge when you pick up a different treasure. This could be solved with a second PRNG, but that's a bit of code, and you'd have to be mindful of the speed. Another idea would of course be to store level data instead of randomizing it, but that's truly not suitable for a one-screen comp. A third idea would be to use the program code itself as a sort of (bad) PRNG to generate the level...
I was actually considering using a ROT-1 cipher instead, but I decided my reason for obfuscating the words was just to hide them so someone who browses the code doesn't see any words by mistake, *and* I wanted to make it easy to modify the words for anyone downloading the game. Maybe someone wants to make their own set of puzzles with a certain theme.
I wanted the player to feel a bit stressed, and I did't want the game to go on forever. I found that the time bonus had to decrease over time, but then I found that at a certain point, it gets crazy hard to keep playing, so I would end up with just about the same score every time. I started decreasing the time bonus much slower at that point, and that really helped. Then a friend suggested a countdown sound when you only have a few seconds left, and I think that added to the experience as well.
I would actually have wanted the level layout to be the same every time, so the player can learn an optimal path, but I couldn't figure out how to do that with the limited code size. Same thing with the sometimes jerky movement - this happens when a new platform must be (randomly) placed, and it ends up in a position overlapping with an existing platform, or too close to one, so the game has to randomize a new position and check again. Without the code size constraint, I think this could be fixed.
Yeah, when I was almost done, I had to change the name prompt from "Name player #1" etc, to just "Name", which gets confusing, but writing a game in just a screenful of code is all about compromising, right?
A nice game. I personally felt the speed was unbearbly low, but I figured out I could just lower the value of S in line 4 to make it faster. Basic is nice in that way!
The horse animation is really cool, and the sounds add to the experience.
I don't know what the numbers mean, and I wish the program would handle bets too, but I understand it would be hard to fit it in, considering the comp requirement on code size.
Nice ship and enemy graphics, and the haunting/stressful sound! I would have liked it to be faster, as I felt I could just have played forever without losing (well at least until I'm too tired). Maybe there's room for selectable speed?
This is very impressive! Also, I think it's a little bit too hard. I reached level 90+ many times, but then fell down to 75-85 before going up to 90+ again. The ghost is helpful but unpredictable. A few times I managed to complete a level thnks to the ghost. After an hour or so, I gave up. Nevertheless, it's a really cool game idea, nice sound and graphics, and it's just crazy that you fit it on one screen of Basic!
Extremely cool, and just mesmerizing to watch! I wish it would randomize a few pixels near the starting point when it starts, so it could go generate a lot of different patterns.
Note: When using Ozmoo on C64: If you save the game using one Ozmoo build, and try to restore that save using a different Ozmoo build, you can expect it to either work perfectly OR crash the game - it depends on the code size of the two builds. The more features you enable, which weren't enabled in the original build, the less likely it gets that you can restore an old game save.
