Pygame 2.0

An alternative, but much more disappointing explanation for this is that Pygame saw almost no development from '09 until about a year ago: https://github.com/pygame/pygame/graphs/contributors

That's cool, what kind of mapping and rendering are you doing with it?

I built a game engine and some games on top of Python, way back in the day when I was still learning programming.

Pygame on its own really gives you none of the features that a proper game engine needs, such as support for animated sprites, a map loader, a camera system (in Pygame, everything is in screen coordinates, and you can't zoom in or out), a real physics engine, a particle system, tweening, and so on. And unfortunately, back then, because it was still running on top of SDL1, it used a software renderer, which made it very painful to implement these features as well. Features that require whole-screen updates, such as smoothly zooming in on a tilemap, were just impossible to implement in a way that would still give you 60fps. This may have improved with the switch to SDL2, but the fact that you have to handroll a lot of things has not.

I consider Pygame to be a good toy for beginners: it has relatively little complexity, while at the same time still feeling like an actual API and in principle gives you a foundation that really cool and fun things can be built on (unlike turtle or other things that are only toys). But if you're not looking to play, you're looking to make a game, it's obviously a wrong choice.

It's a friendly wrapper to SDL. The people saying "but it's not a serious engine" are letting the point of it fly over their head. If what you want is some raw control over I/O it's a fine choice, provided you aren't going for a compute-intensive main loop. I know of a few folks who shipped pygame stuff in the 2000's - that was an era when software rendering was still defacto the right choice for high compatibility, and of the options for speeding up development, a dynamic typed language offered some compelling advantages. If your game didn't scroll the screen, or targeted low res and 256 colors, or you mixed it with pyOpenGL, it was hardly the end of the world. The first comment in that Quora thread is from a student, who unsurprisingly has blamed the tool.

Emphasis on "pygame is slow" mostly comes down to "Python* is slow", and that, too, has an asterisk in that you can hybridize to add Cython or a C module. It will never be as fast as a good native code implementation, but when using all available tools to extend performance, you could easily accomplish just about anything from 90's-era gaming.

I've done a fair amount with Pygame. It's great for learning the fundamentals of 2D graphics and little toy games, it works well for writing simple programs to do things with image data, and I imagine you could use it to pretty easily get an OpenGL window to draw into.

I would not recommend using Pygame to develop a serious game project. All of Pygame's provided functions use software rendering, so you won't be able to take advantage of the graphics card. More seriously, Pygame includes essentially none of the features that come out of the box in a modern game engine, so you have to do things like write the event loop yourself and find your own solutions to physics and animation and figuring out which UI element is currently under the mouse cursor. Great for learning how that stuff works, not great for getting a high-quality game shippable.

I wanted to counter some of the child comments who say that it's a bit of a child engine with some real world results. After all, people are making great games today with Pico-8 or on a Game Boy, surely there must be some great indie Pygame games. Now, these aren't AAA developers, but it seems to have as much capability as something like Love2D does.

Sure enough, there's quite a few = https://itch.io/games/made-with-pygame

(Side note, when I first searched for the 'pygame' tag on Itch, I got nothing. It didn't even suggest it as a tag, wouldn't let me search for it. However Googling "games made with pygame" provided the Itch tag as the first result, not sure why that was)

I am working at a company that is tracking vehicles using GNSS antennas. When designing the vehicle dynamics model for the Kalman Filters, I found it useful to have a graphical representation (including error ellipses, velocity vectors etc). Turns out that pygame was a great fit for that type of visualization.

Fast forward to two days ago, when I was idly watching George Hotz design a monocular visual SLAM prototype in 11h. Much to my surprise, one of the first things he fires up is pygame for visualization [1]!

[1] https://youtu.be/7Hlb8YX2-W8?t=701

Yup! I've worked a bit with pyGame to build a robot interfaced with a PS3 joystick. By far the easiest library I've used for interfacing Python scripts with a joystick.

I can't speak to PyGame2, but PyGame circa 2010 was definitely super slow compared to, say, Java and SDL. For some kinds of games it was fine, and it was good for prototyping and if you were just getting in to game dev.

From my limited experience with Pygame, I found that it struggles[1][2] with sprite rotations. I am assuming that this was happening due it being using software rendering instead of the GPU which might have changed now with Pygame 2.0.

[1] https://github.com/ducaale/nyan/blob/feature/lines/examples/...

[2] https://youtu.be/OfaZavigYUw

I don't know specifically about pygame, but since it uses SDL, and SDL can run in browsers using emscripten, I wouldn't be surprised.

Indeed! I despised them initially thinking typing made code unreadable. But I've grown used to it and I only use type hints when necessary. I use Pydantic when I need more than just "hints" and when validating config file schemas.

Made this in a few days (it is a tetris which starts shaking, rotating, inverting and solarizing the area as you pass levels)

https://github.com/nurettin/tedriz

I don't know if pygame is really easy or if I got pretty good at coding in python. Probably the former.

It supports multiple monitors and has better OpenGL support now.

I highly doubt it's possible to do Android stuff with toys, I'm still curious to learn otherwise.

I have no idea, but to me the opposite of good commercial games is the point here. What is not to love about a title such as mediocre tetris: https://www.pygame.org/project/5421/7844

This is cheating, but renpy is based on pygame. So tons of visual novels are technically made in pygame, the most popular is probably Doki Doki Literature Club.

This comes to mind: https://store.steampowered.com/app/951360

I have heard that "Unity of Command", the WW2 themed wargame was built in pygame.

Impressive (http://impressive.sourceforge.net) is a PDF slideshow viewer based on Pygame.

We used it (first directly, and then via PsychPy) for running vision experiments.

You need to be a little careful about timing, but otherwise it's not bad....

A pygame volunteer here.

Wish lists are fun. True, integration is important. We should do more. Luckily some of yours already came true!

:)

For image sharing, there's a surfarray, and sndarray modules for integration with numpy. pygame.image.frombuffer/tobuffer to going to and from buffers. PIL(low), opencv, and other python image and audio libraries can be used pretty easily this way. There's articles, books and videos on how to integrate with most other libraries. Since python 3.3 or so there's been a much better buffer interface at the C and python API levels which many python libraries are using for integration. There's currently a gap in typing around this, but there's some progress.

If you don't like the 11MB download for numpy, we have a builtin pixel array module that can do a lot of the same stuff for images. There's also some built in Vector math objects (modeled closely on the GLSL ones).

The pixel array stuff is usually a hit in class settings because doing visual affects is very easy to write. As you say, computers are fast enough. Better (although more advanced) is probably the shadertoy website :)

Mu Editor, has built in support for pygame/pygame zero. It even comes with a pygame+arduino example. There's tutorials about for teaching it with microbits (and other little devices).

CircuitPython comes with some built in game libraries. This is probably better to use than pygame. It's best place to look probably for python on micros if you're into crafting games on very small devices. pygame comes preinstalled with raspberry pi, so that's also an option considering some of them can be found for $5 (or for free if you go hunting around dusty drawers).

We have some Python Mode for Processing users. There's a big community of video artists using pygame, and pygame comes built into some of the most popular video synths in recent years.

Python Mode for Processing does a lot of cool things right, and is definitely better than pygame for what it does. It would be great if some of the integration work done in this direction would continue. It's one of the most compact and readable ways to go. pygame zero follows this style a little bit, but being able to reuse code and concepts from both communities is even better.

Are you serious? At least opencv is odd ...