Here’s my contribution its the first thing I’ve programmed so I doubt it will be completed in time for the Jam, for now this is me since progress will be slow if any.
Apologies everything is messy including the Git…
“The Zoo Had to close Gary the snail had to go get drunk guide Gary to the pub.”
This game is a bit of an obsession for me. I thought about it a lot when I was working on HR. Mostly because you created a rather complicated situation having single lines for the walls.
I think one could potentially use Arduboy2Base::collide but defining all the rectangles would be time consuming by hand and a real pain to add new stages.
So I think Arduboy2Base::getPixel could be used to scan the edges of the rectangle created by the snail graphic(plus a one pixel border). Then restrict the movement in the directions one finds a set pixel. It is likely not the most efficient means of doing the detection, but I think it should work.
So basically if the user presses up, the program will loop the width of the sprite via x axis and check if the pixel +1 of the sprite’s y position is active. then it would increment the y value if this returns false
I was thinking of keeping track of if up is blocked and just ignoring the up input. Maybe have a bool for up, down, left and right and setting or clearing them after drawing the maze, but before checking input. I don’t remember if input was being checked before or after drawing, but drawing at least the maze first would be necessary to use this method.
I also think special care would need to be taken checking the corner pixels to make sure movement isn’t restricted in a direction that it shouldn’t be.
He can check point vs line collide while he is redrawing the lines of the maze and discard invalid new player movements because intersections. It wont be extremely clean but you can do some tricks over that, for example skip lines in where the x1 and x2 are too far away from the player new x position.
Basically an easy implementation is to replace the current drawLine( with isValid = drawLine( ... , newx, newy)
Rather than keeping track of the walls, it may be better to define the lines that make up the path that the snail can follow. This way you just have to keep the snail centred on one of the lines.
The maze is then rendered by drawing the walls a fixed distance from the lines (the path lines aren’t drawn). Most walls would end up being rendered twice, due to there being a path line on either side of the wall, but that shouldn’t be a problem. You could draw the maze once and then move the snail by only erasing and drawing itself.
The discussion here leaves me a lot to ponder hopefully once I’ve learnt some more I can revisit and get this to 12 levels. It kinda progressed beyond my capabilities faster than anticipated.
Make a sprite >>background>> make it move>>make a destination>>blink some LED’s>>add some music>>menu and knowing on day one I’ll hit a wall trying to hit walls.
Good work!
In my experience, the only way to learn programming is having no fear of going beyond your capabilities. Thinks that looks difficult or even impossible now becomes trivial after a few hours of hard work. (Sometimes thinks that seems easy turns into a pain when coding )
Take it easy, explore different approachs, learn a bit from all of techniques and finally choose the one you feel more confortable or works better for your game.
Mainly making use of Arduboy2’s justPressed (while still keeping the screen flicker effect), changing hit to a bool and getting rid of a few ugly build warnings.