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.
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 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.
Here's some awesome libraries and frameworks that work with or are built on top of pygame.
pygame_gui - gui elements for pygame.
pymunk - 2d physics library. Lots of examples, very well maintained.
Thorpy - a GUI library for pygame.
pyscroll - Scrolling maps. Fast scrolling images easy.
pyTMX - Reads Tiled Map Editors TMX maps. Can use a Map editor easily.
spritesheetlib - loading sprite sheets.
animation - Tasks and tweening using pygame groups. No framework needed to smoothly move sprites or execute things over time.
pyknic - collection of useful tools (tweening, animation, context, timing, fonts, spritesystem, skeleton, ...) for games.
pytmxloader - Map loader for tmx files
pygame-text - Greatly simplifies drawing text with the pygame.font module.
Wasabi2d - cutting edge python game framework.
pgzero - game framework built on top of pygame. Intended for education.
moderngl - Modern OpenGL bindings for python. pygame-menu - A menu for pygame, simple, lightweight and easy to use.
> 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.
https://mdco2.mini.debconf.org/ https://wiki.debian.org/DebianEvents/internet/2020/MiniDebCo...
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)
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!
- Unity - 25,954 tags
- GameMaker - 6141 tags
- Godot - 4192 tags
- RPGMaker - 3979 tags
- Unreal Engine - 3915 tags
- Pico-8 - 2446 tags
- LÖVE - 1581 tags
- PyGame - 226 tags
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 never got to open-sourcing it though
[1] https://github.com/ducaale/nyan/blob/feature/lines/examples/...
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?