The sentiment seems to be that it's not suitable for more than small toy games -- which in itself would still be interesting. I mean, it's clear that professional AAA studios are not the core target group.
But has anyone here on HN additional hands-on experience that would support or reject the above assessment?
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.
Pygame is great if you want to enjoy the process of low-level game programming but also want to abstract away the lowest levels. If your goal is to build a product (rather than enjoy a process) picking up a game engine is probably going to yield faster results.
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.
Are you sure you're not talking about an older version of Pygame regarding the software rendering? I haven't used it but the very first bullet point in the list of changes of this release says:
> Support for Metal, Direct 3d, Vulkan, OpenGL 3.0+ in various profiles (core, compatibility, debug, robust, etc), OpenGL ES, and other modern hardware accelerated video APIs across many platforms.
There's an important caveat: We provide an API for the SDL2 render system, and some functionality for up-scaling pixel art games on the GPU, but existing pygame 1.x games won't magically become faster by running on PyGame 2.0. They will be a little faster, because we have new, optimised blitting and drawing routines. To make use of GPU-based rendering, you will need to use the new APIs.
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.
(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)
Having used both Love2D and Pygame, Love2D is far and away more capable than Pygame used to be, because it can actually use GPU acceleration, and because Lua's features (like coroutines) make for a far more expressive way to write games.
Which isn't to say that people can't use Pygame to good effect, but that you're working uphill with it a lot more.
Looking at other comments here, though, it sounds like newer versions of pygame stepped up significantly in terms of what can be done. Kudos!
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]!
I used pygame for a reinforcement learning course assignment: I built a gridworld simulator where you can input a text file with the origin, goal and obstacles, and watch as an agent learns a policy using Q-learning. It's based on a visualization used in a Berkeley RL bootcamp: https://miro.medium.com/max/992/1*FnCKMEFZC9QRnxLWT3lSCA.png
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.
That was more or less Python's fault, rather than PyGame, which uses SDL also. I remember getting a huge speedup for one game with import psyco; psyco.full(). It's going to continue being true that Python + whatever is going to be slower than almost any other lang + whatever, even with more GPU support. But still, lots of games (even shippable ones) are possible, and lots of non-game applications. I'm still in love with the pygame/SDL1 way of doing 2D graphics, it was just so straightforward, and working with their interfaces and abstractions (pygame.sprite was nice) rather than SDL directly was always more pleasant too.
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.
The sentiment seems to be that it's not suitable for more than small toy games -- which in itself would still be interesting. I mean, it's clear that professional AAA studios are not the core target group.
But has anyone here on HN additional hands-on experience that would support or reject the above assessment?