.png)
Alright, here's my first foray into an actual game.
Updates in v0.2:
-
Spiffy new title screen, makes start of game and game over states more pleasant
-
Significantly better control handling using a button input queuing system
-
Sound improvements, including Crash sound volume reduced
-
Brief start of game animation to help gently draw player attention to the snake before it begins to rocket across the screen
- Win condition is less seizure inducing (though still too hard for me to reach legitimately so that I cannot easily confirm it even works right. Are there tool-assisted-speedrun uh.. tools for PICO-8 by any chance? 😅)
Nice start but the control handling for u-turns is atrocious, especially when going down. Crucial key presses are dropped all the time when trying a 1 tile U-turn. It gets slightly better if you purposefully stagger the two key presses, but even if both directions are pressed in the correct order, the timing has to be exactly 1 key press per snake movement or key presses get dropped leading to a quick game over.
@RealShadowCaster Yep, I concur.
I'm working on the next version presently, which will include a title screen (also more helpful as a game over screen) and in the next version I have finally perfected the input handling using a button queue. 😊
If you play for a bit and avoid sharp turns, you can get quite long, but invariably the apple disappears. I looked at the code and I think it happens because you replace head tile with a 0 before spawning the new apple, and if the drawn spawn place is where the head was, it gets replaced by a snake segment.
spawning the fruit before clearing the head seem to fix the problem, but I haven't tried to see if winning works
if tile==0x11 then --eat an apple lengthtarget+=1 spawnfruit() mset(head.x,head.y,0) sfx(1) end |
@RealShadowCaster
I did that though, below is the code as it should be in the version I just published:
if tile==0x11 then --eat an apple spawnfruit() mset(head.x,head.y,0) lengthtarget+=1 sfx(1) end |
And when I click on "code" below the cart in this thread it shows the snippet just as I've pasted it above as well.
I wonder if you're working from an older version somehow, or if some other difference like where the lengthtarget increment line goes makes a difference for some reason? 🤔
Controls are much better but still not perfect : when trying to move in a zig zag pattern to get used to the timing for future tight situations, I fail much more when zig-zagging up or down than left or right like in the screen shot.
I tried it on other pico-8 snake games and don't get much difference between horizontal and vertical zig-zags so it's related to the control handling.
Also, late game, I keep losing by crashing into my own tail. In most snake games, you can move towards the last tile of the snake without dying. You can easily check it : at length 4, you can't stay alive in a 2 by 2 square. Still haven't won this one. Would like to have one of the buttons be a speed time 2, for example, as getting to late sizes takes forever.
Thank you for the feedback, @RealShadowCaster. For the tail issue I think I know a fix, and for the wiggle issue I'll try to investigate some other snake games for inspiration as to what's going on there.
But you haven't noticed any further issues of missing fruit since the Nov 17 release right? 🤔 It'll be nice to know if/when that bug is finally put to bed. 😋
No more missing apple bugs so far, but I haven't tested end of game potential bugs yet.
I have a suspicion why the zig zag problem might be :
to do a zig zag on a digital pad, you alternate diagonal presses while aiming for an angle slightly shifted towards the direction you want to be registered first. If the angle it too near from 45 degrees, both direction presses will be registered as happening on the same frame, especially with _update() that will bundle together all presses that happened during the 1/30th of a second. (if CPU is below 50% at 30FPS, using _update60 might be enough to fix the problem)
When that happens, I suspect you handle horizontal presses first, followed by vertical presses. When zig zagging horizontally, this means the horizontal movement is dropped as a going back movement, and only the vertical movement will be treated. Ideally, you should move where possible and buffer the other direction. Beware that if you press Up too strong on the pad, you'll get up, left and right registered on the same frame. You will want that case to be treated as up, not as a U turn.
[Please log in to post a comment]
