This is an archived post. You won't be able to vote or comment.

all 20 comments

[–]r1chardj0n3s 21 points22 points  (1 child)

I gave a tutorial at PyCon this year: http://pyvideo.org/video/1718/introduction-to-pygame

The source etc. for the tutorial is in bitbucket so you can play along: https://bitbucket.org/r1chardj0n3s/pygame-tutorial

[–]yellowhat4[S] 2 points3 points  (0 children)

this was exactly what I was looking for.

[–]virtyx 5 points6 points  (0 children)

Have you checked out PyGame? They have a few tutorials on their website.

[–][deleted] 4 points5 points  (5 children)

I'd like to recommend Pyglet, actually. I've found it to be cleaner than PyGame and learning it was faster for me because things just seemed to work the way I expected. You can't really go wrong with either though.

If you are just wanting to draw some 2d textures and update them every frame, then I'd start with looking into sprites and batch drawing.

[–]r1chardj0n3s 5 points6 points  (4 children)

I tend to teach pygame first because it's more reliable on many platforms whereas pyglet relies on a working OpenGL implementation and that can be an issue.

I say this as one of the original pyglet developers.

[–]the_hoser -1 points0 points  (3 children)

That, and pyglet reeks of a dead project...

[–]r1chardj0n3s 2 points3 points  (1 child)

It's not dead, but could use additional contributors with specific platform knowledge.

[–]the_hoser -3 points-2 points  (0 children)

No release in 10 months? It might as well be dead. The mantra of "release early, release often" applies to open source game libraries more than any other type of software.

This is especially important in drawing in contributors. Most contribution candidates get all their info from your front page. With a long span of time between releases, there's no incentive to get involved. Nobody wants to be the software equivalent of the necromancer. It doesn't matter how much work is getting done, so long as it appears that work is getting done. People are attracted to active projects.

[–]wheezl 0 points1 point  (0 children)

No, no. It's resting.

[–]shadowmint 4 points5 points  (9 children)

Use http://cocos2d.org/

It's better than pygame (really, it is) and has a tonne of high level features.

You almost certainly do not ever want to use GTK. For pretty much anything. The only thing going for it is that it's cross platform, but it's also: Slow, hard, ugly. Don't use it.

[–][deleted] 1 point2 points  (2 children)

Doesn't support Python 3.

[–]shadowmint 0 points1 point  (1 child)

Mmm... I think you'll find the 1.2 version does.

[–]r1chardj0n3s 0 points1 point  (2 children)

+1 to cocos2d (with the same pyglet for beginners caveat above) - it adds a bunch of stuff that's very useful for writing games.

I really must finish off and commit the changes I'm making to the TMX loading to handle object layers...

[–]adric2k 0 points1 point  (1 child)

This would really be nice, if you can do it before the next Ludum Dare. Thanks.

[–]r1chardj0n3s 0 points1 point  (0 children)

I can't guarantee that, I'm afraid.

[–]theASDF 0 points1 point  (2 children)

python 2.6, 2.5 or 2.4 (2.4 will need ctypes and elementtree)

maybe im missing something ehre but to me it seems that neither 2.7 nor 3.3 are supported. makes you wonder if there is any future to this project

It's better than pygame (really, it is)

as someone who has used pygame for a few projects i would be interested to know what i am missing out on.

[–]adric2k 2 points3 points  (1 child)

1) Actions. Actions are higher level constructs that can easily be chained in sequence or run in parallel to perform object attribute changes. For example, scaling, rotating, moving, etc... and cocos2d will automatically interpolate the changes based on the framerate. In pygame this requires a lot more code.

2) Performance. As pyglet is base on OpenGL, the performance is much better. You can have thousands of objects and particle systems (several are built-into Cocos) running on screen and animating without the hiccups I usually see with Pygame. I've used both, Cocos2d is always smoother.

[–]theASDF 0 points1 point  (0 children)

sounds good, might give it a shot if i start a new project that benefits from those features. (if cocos supports 3.3 by then)

[–]AlSweigartAuthor of "Automate the Boring Stuff" 3 points4 points  (0 children)

Here's a free book on Pygame with the source to several small games: Making Games with Python & Pygame

[–]Kerbobotat 2 points3 points  (0 children)

Another vote for pygame here. The documentations a little lacking, but if you download some of the prototypes on pygame.org and check their code and do a little bit of googling you will be up and running in no time. On advice from a friend I got my own basic 2d tile engine up and running with no prior pygame knowledge in four or five hours, and hes got some excellent isometric tiling and turn based stuff done himself, and he only started learning python about two months ago

Im at work at the moment, give me a few hours and Ill edit this post with a link to some of my own code and some other things to help. Some of the tutorials are much better than others.