I made a snake game on a weekend awhile ago and this is the result. Some parts of the code may make you laugh or make you cry but they are all in there anyways.
Computer Science Canada Yes, it's another snake game... |
| Author: | keyboardwalker [ Fri Jul 05, 2013 4:22 pm ] |
| Post subject: | Yes, it's another snake game... |
I made a snake game on a weekend awhile ago and this is the result. Some parts of the code may make you laugh or make you cry but they are all in there anyways. |
|
| Author: | Raknarg [ Fri Jul 05, 2013 4:53 pm ] |
| Post subject: | RE:Yes, it\'s another snake game... |
Pretty good, though I don't understand why it took you over a thousand lines to write. Also, there's an issue when you turn sound on. Try playing with it on. |
|
| Author: | keyboardwalker [ Fri Jul 05, 2013 7:36 pm ] |
| Post subject: | Re: Yes, it's another snake game... |
If you look through the code you'll notice why it's so large. Just looking at the Draw_Scales procedure you'll find out how it got so large. Most of the code is also just sloppy with tons of unnecessary spacing. I thought I had removed the sound because when I made this I didn't know how to use Turing's "amazing" processes. I added sound as a separate process now, which I'd think would fix the issue to some degree. |
|
| Author: | Insectoid [ Fri Jul 05, 2013 8:25 pm ] |
| Post subject: | RE:Yes, it\'s another snake game... |
This looks really good, though it can be made more efficient. For example, in the procedure move_snake, there is no need to move every single body part, since there is no visual benefit. You can simply move the last part to the head's position, and move the head forward one in the direction of movement. The complexity of this algorithm then becomes O(1) instead of O(n). Currently, the longer the snake is, the longer the move_snake procedure takes to execute. With this change, the move_snake procedure requires the same amount of time no matter how long the snake is. Your code in general can be massively simplified by restructuring the program to operate on grid coordinates rather than screen coordinates. All of your calculations currently involve BOXSIZE and BOXSPACING, which clutters up your code and makes things like collision much more complicated than necessary. If you deal only with the grid, collision checks involve no more than looking at the spots around the head for anything in the way. You only need to worry about the box size and spacing when drawing the snake and food. |
|
| Author: | Raknarg [ Fri Jul 05, 2013 8:30 pm ] |
| Post subject: | RE:Yes, it\'s another snake game... |
ah yes, I didn't notice that. To rephrase, generally what you do is have a coordinate system that keeps tack of everything. Lets say you had boxes that were 10 pixels wide. To draw the object, you mwould just say Draw.FillBox (x * 10, y * 10, x * 10 + 10, y * 10 + 10, black). This makes keeping track of everything and doing comparisons and whatnot way easier. |
|