Re: [pygame] Capabilities of Pygame

[Christopher Night <cosmologicon@xxxxxxxxx>]

On Thu, Jan 12, 2012 at 9:04 PM, Ryan Strunk <ryan.strunk@xxxxxxxxx> wrote:

> If you're working on a game that you could conceivably write by yourself or with a small team, python will probably be up for the job.

That’s good to know. With as much as critics of Python harp on the speed, I was worried that resulting software was going to crawl along at a snail’s pace. Are there any situations that come to mind where Python wouldn’t work?

It's a little complicated. If you write everything in pure python only using the pygame library, then yes I can easily think of some examples where it wouldn't work at all, or not have good performance. However, some (maybe all?) of these can be solved by finding another library written specifically for that purpose to help you. And, as Sean Wolfe said, there are people working on speeding up python, and don't forget that computers are getting faster all the time. So it might not even be the case in a few years. Given that, if I were making a game that relied heavily one of the following things, I would reconsider python:

• 3D - I've only used pyopengl and, I admit, it's kind of slow. When I ported a pyopengl game I wrote into C++, I got something like a 10x speedup. pyglet might perform better.
• Huge numbers of sprites, like in the thousands or tens of thousands.
  
• Collision detection and physics between more than ~100 objects. There are certainly libraries for this, but I'm not sure how they perform compared to their C++ counterparts.
  
• Pixel-level manipulation of images, although this has gotten much better with the surfarray module.
  
• Running on a mobile device.
• Running in a browser.
  

This has some similarities with Silver's list, which is also good.

-Christopher