pygame is
Simple DirectMedia Layer is
Site Swing

PicoSnake - 3.0.0 - 320B

Ian Mallett (geometrian)



The ever-increasing (decreasing?) progression of smaller snakes.


Physically as small as I can get it without impairing usability significantly (you already can't move the mouse too much). Again, the major part of the (ever-smaller) code comes from, it's been more than a year; here's reminding people of the fun of hyper-obfuscating code to make it smaller! My major contribution here is using "from pygame import*" instead of "import pygame as p". [EDIT: I see now tgfcoder suggested that a while ago, so I guess this is just a compilation of everything else!] Here's hoping someone can outdo (er, underdo) this--and do try, please!
from pygame import*;q=display;T=16;f=q.set_mode([256]*2).fill;l=[];d=a=x=1
while not(x&528or x in l):
 while a&528or a in l:a=a*9%512
 l=l[a!=x:]+[x];f(0);[f(99,(o%T*T,o/32*T,T,T))for o in l+[a]];q.flip();time.wait(99);D=d
 for e in event.get(2):
  if-n-D and 0


Home Page:


click to view original size


PicoSnake - 4.0.0 - 304B - Feb 15, 2010
PicoSnake - 3.0.0 - 320B - Aug 30, 2009
PicoSnake - 2.0.0 - Aug 1, 2008
PicoSnake - 1.0.0 - 390B - Jul 30, 2008 account Comments

If you wish to leave a comment with your account, please sign in first.

April 30, 2010 3:16pm - josmiley / Luke spywoker - nickname: (mutualaccount)
April 30, 2010 3:12pm - josmiley / Luke spywoker - nickname: (mutualaccount)
[f(99,(o%T*T,o/32*T,T,T))for o in l+[a]]
[f(-1,(o%T*T,o/32*T,T,T))for o in l+[a]]
for better visibility
March 12, 2010 7:33pm - ffao - nickname: (ffao)
I don't think the D variable can be completely eliminated -- the reason it is there is because if you press two directional keys at the same time (one back on yourself, one a valid turn), and the valid turn gets processed first, then you can hit yourself. I could accept removing it if the bug were fairly infrequent, as this program does have a history of bug tolerance unlike mine (event.get(), anyone?)

As a side note, geometrian, can you tell what the line while not x&528 does? It's magic, isn't it? :)
March 10, 2010 6:44pm - James - nickname: (monkjr)
at the end of line 4 ";D=d" can be deleted (you don't use it anywhere else than on line 7 so I did "if n+d:d=n" (added tgfcoder's thing) for 297 (the game still runs the same + you can't go back on your-self).

but you could do "if-n-d&0<5:d=n" on line 7 like you have for 302

March 9, 2010 8:02pm - ffao - nickname: (ffao)
About time someone beat me and PicoSnake lived up to its name :)
Go go!
February 18, 2010 4:26pm - Jordan Trudgett - nickname: (tgfcoder)
You can also change line 2 to

while x&528==0:

to bring it to 299. :)
February 18, 2010 4:19pm - Jordan Trudgett - nickname: (tgfcoder)
Yes actually that line of code is broken. It's supposed to stop you going back onto yourself, but it should be:

if n+D:d=n

which will make sure your direction isn't the opposite of the last frame's direction. :) This gets you to exactly 300 bytes.
February 17, 2010 9:59am - Jordan Trudgett - nickname: (tgfcoder)
292 bytes, and its exactly the same from what I can tell. :D
February 17, 2010 9:56am - Jordan Trudgett - nickname: (tgfcoder)
but its not game-breaking really.

Also, as far as I can see, "if-n-D&0<5" is always true (correct me if I'm wrong) so chuck the d=n after v=e.key-272;n=((v&2)-1)*[1,32][v<3];

this saves you 12 bytes O:
February 17, 2010 9:50am - Jordan Trudgett - nickname: (tgfcoder)
Ooh, this results in wonky snake.. hehe.
February 17, 2010 9:44am - Jordan Trudgett - nickname: (tgfcoder)
How about changing o*32/T to o/2.
February 15, 2010 11:53am - Ian Mallett - nickname: (geometrian)
Unfortunately, I don't think so. a = (a*9)%512 isn't the same as a = a*(9%512)
February 15, 2010 6:00am - josmiley / Luke spywoker - nickname: (mutualaccount)
on gagne 1 caractere en remplaçant
February 15, 2010 2:27am - Ian Mallett - nickname: (geometrian)
304B--will we break 300???
August 31, 2009 4:05pm - pymike - nickname: (pymike)
If you want syntax highlighting, I believe you can change the pre tag to:

<pre class="python">(code here)</pre>

Nice job, btw. :)
August 30, 2009 3:31pm - Ian Mallett - nickname: (geometrian)
320 bytes...
August 1, 2008 5:03pm - Ian Mallett - nickname: (geometrian)
oh well
August 1, 2008 5:02pm - Ian Mallett - nickname: (geometrian)
August 1, 2008 5:02pm - Ian Mallett - nickname: (geometrian)
Yes, I was wondering about that. Obviously, key inputs will get processed. Nothing else will. I'm thinking this wouldn't be a problem, unless you repeatedly bump the mouse or something. All the <i>relevant<i> data is processed.

Am trying experimental italics here, we'll see how it works out.
August 1, 2008 3:50pm - RB[0] - nickname: (roebros)
Uhoh. You are right, sorry 'bout that. Ian... ;)
August 1, 2008 3:41pm - ffao - nickname: (ffao)
Look at his event.get() calling code:

for e in p.event.get(2):

He kept the 2, but didn't clear the event queue afterwards.
August 1, 2008 3:30pm - RB[0] - nickname: (roebros)
But he is not just grabbing specific events ;) He is grabbing *all* events. Your code grabs only specific events, note the (2) arguments you have ;)

In the end also, you are clearing the event queue the same way he is, just doing it once for the specific events you want (allowing you to use them) and once for the rest.
August 1, 2008 3:00pm - ffao - nickname: (ffao)
About the incomprehensibility, it's because I posted that when the code had those ugly &nbsb; all over it.

About the fairness, well, I guess it's OK.

And about the event queue, check the pygame docs: "If you are only taking specific events from the queue, be aware that the queue could eventually fill up with the events you are not interested." Move the mouse while you play if you don't believe me, the game is going to lock down pretty quickly (the queue will fill with MOUSEMOTION events).
August 1, 2008 2:48pm - RB[0] - nickname: (roebros)
regular event.get clears all events, so they are being cleared every frame, the difference is that ffao is only catching *some* of the events in his code, then destroying the rest...
August 1, 2008 2:43pm - Ian Mallett - nickname: (geometrian)
That and the minus thing are all I really did to it. I also gave you nearly complete credit (plus a link) and didn't say your code was mine at all.

As for incomprehensibility, smaller code expects to be less readable.

Incidentally, I've never had trouble with the event queue; perhaps it's a pygame version thing? I almost always do event checking this way and no one has ever mentioned it...
August 1, 2008 2:14pm - ffao - nickname: (ffao)
I don't think it's really fair that you make minor changes to my code and upload it as a second version of your own -- NanoSnake is open to suggestions, after all (4 people have contributed, if I counted right). But please fix the code, it is incomprehensible right now. Also, you only call p.event.get(2) once -- you need to clear the event queue later, or else it will be eventually (no pun intended) filled with other events.
August 1, 2008 2:00pm - Ian Mallett - nickname: (geometrian)
Version 2.0.0 released!
July 30, 2008 6:26pm - Emanuel Berg - nickname: (metabaron)
Very small indeed but before we can declare you the winner you must fix the thing with the controls, when you go right, you shouldn't be able to go left (and vise versa, the same thing with up/down).
July 30, 2008 3:29pm - Ian Mallett - nickname: (geometrian)
Version 1.0.0 released!

our projects welcomes all python game, art, music, sound, video and multimedia projects. If they use pygame or not.
recent releases
Jul 28, 2014

Jul 22, 2014

Jul 21, 2014

Jul 20, 2014

Jul 19, 2014

Jul 15, 2014

Jul 10, 2014

Jul 9, 2014

Jun 27, 2014

Jun 24, 2014

... more!
for pygame related questions, comments, and suggestions, please see help (lists, irc)