PyGame tips and tricks

blakeohare on 2012/09/01 19:29

I posted a list of tips and tricks that some may find useful for PyGame development (and some are generic enough for other frameworks as well). 

http://www.nerdparadise.com/tech/python/pygame/tipsandtricks/

If you have others you'd like to add to the list, let me know and I'll update it. 

(log in to comment)

Comments

richard on 2012/09/02 00:24:

Added to the sticky, thanks!

Mat on 2012/09/02 16:24:

What does everyone think about the embrace 3.X part? If I develop my game for 3.1+ is it reasonable to expect everyone will be able to play it?

blakeohare on 2012/09/02 17:49:

If you develop just on 3.1, it is unreasonable to expect it to work on 2.x versions. But the converse is also true.

I'm not advocating for everyone to switch over. I would probably get burned at the stake. I mostly meant it from the perspective that you are either developing for both 2.x and 3.x, or primarily developing for 2.x but are simply conscious of the 3.x differences. Since I'd say 90% of PyWeekers are developing on 2.6 or 2.7 it would be unreasonable to develop primarily on 3.1. By all means, if writing code that works identically on both versions becomes burdensome, 3.x compatibility should be the one sacrificed, otherwise you'll get a barrage of DNW's. But if you are successful, it both adds a little future-proofness to your game and also runs a tad faster. 

Usually what I do is develop on 2.6 and do final testing on 3.2 before I submit each feature to source control. 

Mat on 2012/09/02 19:18:

Yeah that's kind of what I did last time, but it's such a hassle to be compatible with both. I'd love to just forget about 2.X forever :(

mauve on 2012/09/02 20:10:

The for loop advice and the music advice contradict each other. The music advice says "You probably won't be able to ensure that every code path leads to the right music playing, so use a slow, dumb method instead". The for loop advice says "Don't use a (slightly) slow method to ensure you can't enter an infinite loop, examine every code path instead".

In practice I think both of those are the wrong way round: you might write a hundred loops, so use "for" to help ensure they all terminate and the game doesn't hang. You write one scene transition system, so ensure that the code paths to invoke the music are all watertight.

richard on 2012/09/02 23:53:

It is perfectly reasonable to use Python 3 in this challenge - pygame fully supports it (and is a little faster), pymunk now supports it, pyglet supports it, and so on. You could even try going the bleeding edge and use Python 3.3, but there hasn't been a final release of that yet so you might be asking a bit too much of the judges. It does have some exciting new features though (like yielding from subgenerators which would be mucho fun for organising AI routines.) Probably best to stick to 3.2 though.

bitcraft on 2012/09/03 21:07:

@Mat, I don't think we should just embrace python 3.  I'm only responding since you asked.

Mat on 2012/09/05 22:34:

Seems python 3 is still controversial :) I'll probably focus on 3.2 and try to make it backwards compatible at the end if I have time...

I disagree with the for loop advice too, it's premature optimisation that you will probably never notice.

mauve on 2012/09/06 19:40:

We're pretty much sold on Python 3, unless Arnav has problems getting the dependencies to work on his Mac.

mauve on 2012/09/07 17:30:

We're now unsold on Python 3, as Arnav hasn't been able to get Pyglet running on Mac under Python 3.

superjoe on 2012/09/07 18:02:

It took me at least 8 hours of banging my head against a wall to get Pyglet running on Mac under Python 2. I'm about ready to simply not support Mac.

richard on 2012/09/07 21:57:

@mauve: do the pyglet devs know of the problems?

Ernie on 2012/09/07 22:09:

I too have problems with installing the new pyglet on my mac. It seems to be related with the port to cocoa. No python3 for me this time :-[

saluk on 2012/09/07 22:12:

Yeah I tried pyglet on python3 on windows, it just doesn't work. print statements aren't even correct.

Ernie on 2012/09/07 22:29:

@saluk yes i fixed those print statements myself, but even then it didn't work. It's alpha, so we can't expect it to work without problems.

mauve on 2012/09/07 23:18:

If the print statements look wrong it is because 2to3 hasn't run correctly. When I toyed with this yesterday, I found the setup.py has some weird codepaths, that may not set the properties right in all situations so that 2to3 is run.

The only thing that worked for me under Python 3 was installing pyglet system-wide with system-wide pip, from a tarballed sdist. My various virtualenv and setup.py experiments resulted in failure.

@richard: I'll encourage him to put some reports in. For my own experiments, I got as far as starting an issue report on Google Code, then decided I didn't know enough about packaging under Python 3 to understand what I should expect: I don't know how 2to3 is invoked or what packaging systems are supported.

richard on 2012/09/08 03:10:

Ok, thanks :-)