Log In  


Endless Underground Snake 2.5.D

Cart #endless_snake_2_5_d_v2-0 | 2020-04-18 | Code ▽ | Embed ▽ | No License
6

Endless Underground Snake is online!

I've made some great changes to the game, including endless gameplay with hundreds of different, procedurally generated levels, an ability to dig underground, a tutorial intro screen as well as a mini-map. For future updates I plan to fill those rooms with new creatures and paths.

If you want to skip the intro screen hit Y/Z
I hope you enjoy!

Updates:


April 2020 Update: Fixes
- minor fixes concerning collision detection
- pause 1 second after collision
- Input reworked and GUI implemented

March 2020 Update: Snake goes underground
- endless gameplay
- hundreds of possible levels
- procedural level design
- ability to go underground
- changed doors/ spider AI
- added a mini-map

Jan 2020 Update: implemented help arrows

Nov 2019 Update: implemented reset function

Concept

Endless Snake is a mix of skill-, memory- and puzzle-game concepts taking place in a dungeon.
The gameplay goes on infinitely and there are hundreds of different, procedurally generated levels.

Controls

  • You control the snake with the arrow keys.
    The button pressed/ next move to be done will show up in the lower right corner
  • By pressing X / V you can show the mini-map.
  • By pressing Y / Z / C you can dig up/down.
    Tunnel commands show up und the lower left corner

The map is a square of 3x3 rooms
Follow the arrows in their order to reach the end

Goals

  • Kill all spiders to open the last door and collect their eggs to get extra points.
  • Plan your way as you might need to come back to a room again.
  • Spiders produce eggs over time, more eggs more bonus-points.
  • Eggs are also needed to dig underground. Let the spiders live for a while to produce more eggs.
  • The longer your snake the higher your score will be.

Previews/ Level-Walkthrough

Check me out on insta: https://www.instagram.com/yesyoorgames/
Video of older versions are also posted there. :)

Have fun!

6


This is pretty nice! Happy coding \o/


Thanks! Same to you! :)


Good but instead of jerking back from hitting a wall, suggest player start overe where they first entered this particular room.

As it is you can get yourself trapped just once and this will use up all your lives.


This is really tricky! Thanks for the interesting game - I think I'll have some fun learning strategies for this.


@dw817
yes! you are absolutely right and I planned to add a feature where you can give up a life to jump back to the last door used :)
An other idea I had is to implement a skill with a cool down, which enables you to tunnel yourself. Unfortunately this second idea came to me quite late and is kind of difficult to implement in the design I use now. I am planning an android version with higher resolution, bigger maps, map elements like bridges, tunnels and such skills as mentioned above in the future. But it will need to wait since I am currently working on a 2d top down game with rpg elements.

@packbat
yes I know if you don't know the path it is really a hard try and error strategy with good memorization needed. If you feel like it is getting to hard check out my instagram acc (yesyoorgames), I posted a walkthrough video of that lvl there ;)

Also without those skills mentioned above the order to visit the rooms is pretty much fixed for this first level. In a future version I hope that a different level design and features as tunneling will be able to fix this.

Thank you all for checking it out and your feedback! I really appreciate
it ! :)

edit:

@packbat
@dw817
reset function is implemented now ;)


If you plan to write a version for Android, @Yesyoor, you will have to leave Pico-8 behind. Unfortunately Pico-8 does not run on the Android nor is there a program to convert a cart to APK (native Android and cellphone executable).

The main reason I'm in PICO-8 is simplicity. Sometimes I can really get bogged down by coding in a more complex language.

Pico-8 is refreshingly simple to program in.


@dw817
Yes true, but I was developing android apps before I came to pico 8. I am currently working on a 2D top down game using libgdx. I would use libgdx again to realize it on Android and all other platforms. But as you said it, pico-8 is perfect for checking out ideas and building prototypes in a very short time (and pretty environment too!)


@packbat
@dw817
@FrelonK

Any wished/ ideas for future updates? :)


This is such a superb twist on Snake that makes the concept immediately more interesting and appealing. :) My only issue with it is the controls! I just can't get the timing right on turning and digging; I very often overshoot and hit something even when it seems like I should have plenty of time to turn. Because of that I find it quite a difficult game to play.

I think the issue might be that sometimes, when the snake head is on the tile directly in front of an obstacle, you can't transition to another state (eg. tunneling, turning) before you hit it? I don't think it's reaction speed - I think sometimes, the input simply doesn't succeed.


@hawthorn
Hey thanks for checking out my game! I really appreciate the feedback and it helps to improve it!
There were indeed multiple bugs concerning the input, thanks a lot for pointing this out, I think I finally made it to track this behaviour down.

I made some changes to it, and it should be much easier to control now! :) I added a pause timer, reworked the collision and input detection and added graphical representations of the next commands. So If you die, the snake pauses for one second. The first 1/6th of that second input is ignored ( to leave time to release the last key). Then new input gets registered. I hope the graphic representation at the bottom will be helpful here. You don't need to look at it directly, I think it is already helpful to see if input was registered - even if just in the corner of the eye.

If you still want to hear about details and thoughts, see below for an in depth description of the bug and other thoughts.

Details about tunnels

If you want to go UP on a certain spot you have to wait for it to show cracks, like I did here in front of the door, meaning you are moving onto this spot. You will break right through those cracks when you hit C. So they should always be clearly visible when you dig up otherwise you block yourself above ;)
Going down is the same. You will open the tile you are currently on, and once leaving it the tunnel image appears. That tunnel image appears this late because I can't predict what direction you go until that tile is fully stepped on and about to be left. But the input always counts right away, so after finishing this tile, you will be underground already.
As mentioned the directional input will be handled for the next tile (here after the cracks/tunnel -entrance/-exit ) :)
So the next tile you will be of the new direction

If you collide the snake snaps back to the tile it was before (here in front of the door). Now if you don't move quick , it will go straight maintaining its direction and state it had before the collision input- here staying underground again.
With the update above there is more time to decide and it should feel easier to control.

In the new version, you can watch those commands happening at the intro/tutorial screen in slow motion :)

Bug details

I really had a hard time with the input handling and you are right it is confusing sometimes. In an early stage of the game some of my friends even broke the left arrow key when testing it, due to a bug which I solved later on :D

Anyways, as for the snake movement it takes the segments about 30 frames to move from one tile to another ( ~1 second ).
During this time between the tile grid, any tunnel command will result in making this destination tile to an entrance/exit. All directional inputs though will be treated only once you finish the current offset and will influence only the next empty tile you will step on then.

OUTDATED:

Since some of the input events can't be handled during these frames immediately ( like changing directions) I collect them to know where the player wants to move next. I implemented a command pattern for this, meaning all types of input events made are translated into own commands -for example the C key, it can create a tunnel down or tunnel up command based on the status of the snake. Such commands will be generated and stored and sometimes an input event will be ignored and will not create any command, I ll give an example below.

So let's start in the 30th frame. All snake segments arrive and are properly aligned with the grid of the map.
They set their behaviour to searching and save the move they made for others behind to follow.

In the next frame - the 1st frame of the next 30- all segments will check what direction the segment before them made via the moves just stored. Except for the snake head, it will look inside the commands list and take the first one. No one moves during this frame! Now all change their state to walk. Their position is actually also set already, but not visually, and they move there by decreasing an offset. So right after this, still in this frame, they check for collision at their new position.

In the next frame -the 2nd frame of 30 - If no collision occurred , all segments will start moving again ( decreasing the offset). Thats for the basic behaviour now some thoughts and exceptions.

Imagine this:
Someone moves up besides a wall left to him. He accidentally presses the left key once but long enough and due to unlucky timing in a way for this to span across two frames. This will generate two input events, one for every frame where it was pressed. Our player is in a tight situation and made this unfortunate input in the last tiny bit of a second before the snake would have gone on - let's assume he made it between the 30th and the 1st frame.
So the input event of the 30th frame would be stored, the snake finishes its move (offset = 0) and sets it state to search, then it enters the first new frame. The snake is now in searching mode and will consume the direction left event that was stored during the frame before. the player will loose a life and the next segment will turn into the head. here I avoid turning the current (second) input event into a command and ignore it, since the newly transformed head segment will need to catch up to the spot where the head was (right before the wall) and this behaviour was just set already the frame before when it was still a segment and not the head segment. So if I would store the second event as a command, it would result in the snake crashing 1 second (30 frames) later, when the new head will have caught up and would look for the latest command. Thats one example of ignoring input events. Another one would be there was no wall, the snake would turn left and still the next command would be left again, which would be of no use since the snake is going left already. Same appears if you go straight and hit the opposite direction key, so the snake won't turn back on spot.

Cart #yesyoorsnake_2_5_d-2 | 2020-04-16 | Code ▽ | Embed ▽ | No License
6


Version with 50% overlap of the next tile, at collision. Debug only.

In the old version there was a bug when colliding. It would simply ignore the direction you turned to for the next input (due to the filtering I described in the details). This though also prevented you from taking this same direction but switching layers (example tunnel yourself instead of going overground), I must have missed it when implementing the tunnelling feature.

Is it too easy with the snake pausing a second upon hit?
How about that 1/6th of a second after loosing a life. Is it too short? Does sometimes the last input still make it through? Or is it set too long and already ignores the next input you are trying to make (example: you pressed very fast right after getting killed)? In this case the GUI at the bottom would stay empty and the snake would continue the same direction it was going before. Thanks so far already!


1

Hi @Yesyoor

Cool, thank you for looking! I downloaded the new cart and gave it a try but I still find the same issue.

I'm not describing a specific bug with walls, but more generally how the snake handles.

It might help to explain my control expectation with some amazing ASCII illustrations :) Below, I depict the situation of the snake moving right, about to hit its own body.

O = snake segment
o = snake head

....O....
....O....
OOo.O....
....O....
....O....

As the player in this situation, I intend to tunnel underneath my own body and emerge on the other side. To do this, I am waiting for the snake head to be visibly on the tile right next to the body, like this:

....O....
....O....
OOOoO....
....O....
....O....

I press the tunnel button while the snake head is still visibly moving into this tile (meaning that it hasn't visibly hit itself yet). My expectation is that the tile that the snake head is on should immediately become a tunnel opening, with the snake head inside it:

) = tunnel opening

....O....
....O....
OOO)O....
....O....
....O....

Often, even though I am certain I hit the tunnel button before the snake visibly collided with itself, this does not happen. Instead, it's like I didn't press the button at all - the snake just hits itself. Further presses of the tunnel button do not remedy the situation; they do not register. I am, at that point, doomed to keep headbutting my own body until I die, and pressing the tunnel button can't get me out of it.

From a user perspective, it feels to me like the game did not recognize that I pressed the tunnel button in that crucial moment. I have a feeling that what's actually happening is a difference in expectation; I suspect the game has a different idea of where the snake head is than I do.

I would note that the same thing happens if I try to turn the snake instead; again, sometimes it seems like the game just ignores the input.

I admit it's possible that I might simply not be fast enough to play the game - perhaps I just physically can't respond within that very short window of time. I don't think that is the case - I've tried hard to be as fast and as accurate as I can - but it could be that. It does, however, feel more like an input issue to me.

> What do you think for the visual part, is it better to have this overlap?

To be honest, I didn't notice the overlap at first. It happens so quickly that it's hard to tell. I think it is fine - I like the idea that you get some generous leeway with the timing to place a tunnel. However it doesn't seem to make a difference.

Thank you again for trying to fix it - I do think this is a really cool and unique concept for a game and visually, the whole over/under thing is really neat. I just can't control it. ^^


hey @hawthorn
thanks for checking it out right away and the details, ascii symbols are fine I totally understand what you mean. Did you try the version I just posted? There is more time to decide for input and the input is shown. I uploaded it like 20 min ago :D
Yes the one in the post was bugged too, really sorry for that. The new version is on top of this page :)

Thank you again for trying to fix it - I do think this is a really cool and unique concept for a game and visually, the whole over/under thing is really neat. I just can't control it. ^^

Thanks a lot I am really glad to hear that! I will do my best to fix the controls and appreciate all the patience and effort you came up with! I think it is not your fault, but mine having tested it all the time and just knowing the frequency of inputs :D your information is exactly what is needed to have this game make fun to others :) And honestly there is nothing more frustrating than messed up controls, so I am really sorry you are bothering with them.

I think I finally got it:

same here, input events pressing right are ignored due to filtering , because the position is already set and I would go opposite
(back right into myself once having done that step to the left) and thus don t show up in the corner although I press right to move away

Here you'd probably think you could turn away from getting inside again, although the error was made when turning on the next tile inside ( I went up on purpose there to collide the first time).

So what is happening here? It is actually not input being ignored but graphics not synchronised with the actual state.
The snake get inside and arrives on that tile (where I will tunnel later), then the head checked for my UP command , setting the new position and check for collision. I collided the first time. (That was on purpose) The segment behind becomes the head, but following to the spot where the head was before it was processing the new move (even though the move ended up colliding instantly and did not show me graphically on the colliding tile). So the game pauses now for you to make new input. That input as you can see ( right lower corner) does get registered, but only processed once the snake looks into the list again, so only when it arrives the tile inside again.
That's the spot where I decided for the wrong direction before. Now it processes my input which I just made and thought was for the tile before and collides again.

So that's what makes it confusing, you will set your move on the point where you made your decision earlier, but the snake shows the head on the tile before. I ll fix it later, so that the snake first catches up to where it was with twice the speed (inside). Then it will wait and listen for input, to know where to move next, so the graphical information actually matches the input for that tile. :)

Here I caused multiple collisions for testing, but watch when my 3rd heart gets lost, that was by accident, because I didn't release the key of the preceding movement fast enough and my filtering failed somehow. The second triggered right command then causes the collision like in the above gifs, although it shouldn't have passed my filters in this case in the first time. That will probably get fixed when I implement the graphic fix later too. There will be a half second the snake resets and ignores the input (at this moment just 1/6th of a second), and then one second where it pauses on the correct tile to wait for keys, if none occur the snake will go in the direction it is looking at.


@Yesyoor it hurts my head to try to figure out what's going on ^^

The last version I played was yesyoorsnake_2_5_d-2.p8.png... I'm not sure how to check if that is the latest one?

Anyway I played with it a little more and I think I found a bug. If you hold down the tunnel button (instead of pressing it), the snake will start tunnelling repeatedly in and out of the ground by itself for a short while - without consuming any eggs!


@hawthorn, yeah it is due to some pico-8 differences which I found out quite lately. I will recode the game to gain space for additional content and in that manner I will implement a new command behaviour :) but I guess it will take a couple of days to do all of this ;) I will mention you here again once I am done with the basic controls so you can test it at an early stage :)



[Please log in to post a comment]