Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Programming Snake
- Thread starter 5218
- Start date
... or maybe a plan how you would solve the problem?
Designing the program should be done by you; we can help transforming the design to code (although in Pascal, if you're design is entirely correct, it's only a matter of literally translating it).
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
Designing the program should be done by you; we can help transforming the design to code (although in Pascal, if you're design is entirely correct, it's only a matter of literally translating it).
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
lionelhill
Technical User
Snakes are usually controlled by a bloke sitting crosslegged with a flute rather than using pascal. However, if I'm right in assuming that you mean a virtual snake in the game where a wiggly thing moves around on the (often text-based) screen, and dies if it bumps into itself, then there are various possibilities. e.g.
Moving:
control the head as though it were a pacman or any other similar thing.
maintain a list of "occupied squares"
each time the snake moves, add the new square occupied by the head to one end of the list, and delete the last square of the list (which is the end of the tail).
Depending on graphics you probably only need to draw the tail-square (to blank out where the snake has just been), the head square, and possibly the square behind the head if you have different graphics for the head.
Collisions:
either test the screen to see if the head square is now occupied by snake-tail (this can deal with collisions with walls and other snake, too. Test if head square is empty), or (probably slower, depending on graphics again) check through the snake square list to see if the head coordinates are already present.
Moving:
control the head as though it were a pacman or any other similar thing.
maintain a list of "occupied squares"
each time the snake moves, add the new square occupied by the head to one end of the list, and delete the last square of the list (which is the end of the tail).
Depending on graphics you probably only need to draw the tail-square (to blank out where the snake has just been), the head square, and possibly the square behind the head if you have different graphics for the head.
Collisions:
either test the screen to see if the head square is now occupied by snake-tail (this can deal with collisions with walls and other snake, too. Test if head square is empty), or (probably slower, depending on graphics again) check through the snake square list to see if the head coordinates are already present.
I guess you're using *something* loosely based on this:
REPEAT
move snake in chosen direction
UNTIL (snake hits a wall) OR (direction is changed)
Yes?
~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
REPEAT
move snake in chosen direction
UNTIL (snake hits a wall) OR (direction is changed)
Yes?
~*Gwar3k1*~
"To the pressure, everything's just like: an illusion. I'll be losing you before long..."
lionelhill
Technical User
I tend to do
while not snake_dead do.....
begin
(delay, preferably based on screen flyback)
snake moves to snake + snake_increment
if snake_collides then snake_dead := true
if keypressed then snake_increment := appropriate_value
end
(pseudocode!!)
while not snake_dead do.....
begin
(delay, preferably based on screen flyback)
snake moves to snake + snake_increment
if snake_collides then snake_dead := true
if keypressed then snake_increment := appropriate_value
end
(pseudocode!!)
LorenPechtel
Programmer
You can avoid the list of occupied squares if you read back off the screen what's there. I wrote a snake long ago. The initial version had a 10,000 element queue for the snake. At 1024x768 that turned out to be inadequate. How long would it take to collision-test 10,000 elements?! I just dug out my old version. The top entry in the high score table is over 13,000.
Since you've written the program yourself, there's no way of checking wether a score of 13000 is either high or low ;-).
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
Regards,
Bert Vingerhoets
vingerhoetsbert@hotmail.com
Don't worry what people think about you. They're too busy wondering what you think about them.
lionelhill
Technical User
In suggesting the "keep a list" approach I didn't assume 1-pixel length graphic-mode snakes. For a text mode I would keep a list of squares because it's short, or look at the screen, cos that's easy too.
In a high-res graphic mode I personally wouldn't read the screen, because it's often very slow to read screen memory compared to real memory. But I wouldn't keep a list of pixels either. I would keep a list of corners in the snake, because it is unlikely it wiggles more than 20 times anyway. Then you look for collisions by seeing if the head lies on a line between two corners. Update the final corner (i.e. tail end) and first corner (head end) each move, and make a new corner every time the player changes direction.
In a high-res graphic mode I personally wouldn't read the screen, because it's often very slow to read screen memory compared to real memory. But I wouldn't keep a list of pixels either. I would keep a list of corners in the snake, because it is unlikely it wiggles more than 20 times anyway. Then you look for collisions by seeing if the head lies on a line between two corners. Update the final corner (i.e. tail end) and first corner (head end) each move, and make a new corner every time the player changes direction.
LorenPechtel
Programmer
Bertv100:
The scoring in Snake is very simple: It's the length of the snake! 13,000 means there were 13,000 pixels in the snake.
Lionelhill:
Reading the screen, however slow, is still faster than any sort of search based on the snake. Besides, your 20 is way off. It can get folded a *LOT* more than that on a high res screen.
The scoring in Snake is very simple: It's the length of the snake! 13,000 means there were 13,000 pixels in the snake.
Lionelhill:
Reading the screen, however slow, is still faster than any sort of search based on the snake. Besides, your 20 is way off. It can get folded a *LOT* more than that on a high res screen.
lionelhill
Technical User
If your snake is one pixel wide, I agree. Personally I found the text-based version of snake that came with Q-basic very playable, and from a game-play point of view I'd have been inclined to emulate that in prettier graphics. But we're all different (thank goodness!)
- Thread starter
- #13
- Thread starter
- #15
- Status