Game Programming With Python
If you have an existing game and want to add a scripting engine to make it more flexible, Python is also a very good choice. But you'll have to learn about IntegratingPythonWithOtherLanguages.
Read Humongous Python for a case study.
PyWeek is a bi-annual programming challenge that produces several great games.
There's also some books that specifically cover game programming in Python:
- "Game Programming with Python is about building games using Python. It deals with general concepts of game development and specifics that apply when using Python for game development. Some of the general topics include simulations, game architectures, graphics, networking, and user interfaces."
- "The author set out to write a book like the one he used to teach himself programming at age 12. ... This book has been successfully used by homeschooling families and public school teachers." The library and example code supplied with the book is also available for download.
I tried porting Escape of the Unicorn to Python/PySDL, but the game dropped from 30 fps to 6 fps.
After a lot of profiling and unrolling screen draw code, I was able to reach 8 frames a second.
If you look at PyGame and PySDL games, you'll notice that they aren't action or arcade games.
I have only heard of few efforts that succeeded in embedding Python in C++, and I have forgotten them. For the most part, people (including Humongous, as described in the case study described) extend Python with C++. If you are going to mix Python and C++, I think it is best to extend Python- that is the intended direction. I consider this a failing of Python.
If you want to embed a scripting system because you already have a huge system, embed something like Guile. I think it is an inferior solution, but that it will result in a lot less heartbreak.
I suspect I'll try to rewrite Escape of the Unicorn as a C++/Python mixture some day, and pay careful attention to how I cut the C++/Python lines. I think only a few things need to be given to C++, such as display loops, animation management, and collision detection.
-- LionKimbro 2002-07-19 10:45:57
Not every type of game will work well with python. Although I must disagree that none of the games written in pygame are action or arcade games. Pygame can do extremely well in these environments. My first game, SolarWolf, is an action arcade game. It runs locked and limited at 40 frames per second with its 800x600 graphics, with generally over 50 animated objects on the screen. It uses time-scaling to control animations on slower machines, and has been rated very playable by people on less than 200mhz pentiums.
The general performance problems people have with pygame are related to using the SDL library. Without special tweaking, games usually run on SDL with no hardware acceleration. This can take a noticeable speed hit on games with fullscreen scrolling graphics. Generally, speeding up the python code will have minimal performance games, but optimizing what is drawn will have significant impact.
Still, I concede that there are types of games that just won't be suited towards python. But the situation is far more hopeful than the experiences of 'Escape of the Unicorn'.
-- Pete 'ShredWheat' Shinners
I work for a publicly held MMP game publishing company. I can't provided too many details because most of the interesting stuff is company confidential. However, I can testify that we are using Python to develop both the client and the server architectures. To be fair, the core graphics engine and high performance stuff is written in C++, but the game code is in Python. It goes something like this:
Client: The executable is the Python interpreter, and it loads C++ extension modules for 3D rendering, collision, UI, movement, and such. Game code is written in Python. The main rendering loop is in C++, however, which is a critical point for performance. In development we get around 50 FPS with a high-poly scene, and up to several hundred FPS rendering a single large triangle :P.
Server: The executable is a C++ server framework that embeds the Python interpreter, which also imports C++ extension modules. Again, high performance code, such as networking, movement, AI, and physics is in C++ (combining extensions and native code). Game code is in Python. But this is most of the code. Game code on the server consists of every system that has anything to do with the rules of the game, scripting, object interaction, combat, trade, inventory, etc. etc.
We do not use SDL, so I can't comment on it. However, I can say that, the right mix of Python and C++ is an ideal combination of technologies for game development. Just like any Python app, you have to keep the performance critical stuff in extensions, and minimize the calls between Python and C++. But the high level logic, game code, and other "fun stuff" lends itself to Python very well.
-- Matt Walker
SolarWolf has an all black background, which is just a screen clear, so that works fine. Escape of the Unicorn has an animated tile background. That's why it's chugging so much.
I agree with Matt Walker- if you do the engine in C++ and the game code in Python, it'll work.
What we really need in the Free Software world need is a C or C++ sprite, collision, and sound/music engine that is all wired up to host Python scripts, right out of the box.
I completely disagree with all of the negative mentions of PyGame/Python/SDL. If you know how to code, and know how well to code, you can easily drum up a game that is complicated (much more so than just 'animating backgrounds', yeesh) and hit an extremely fast framerate. I've created some platform game engines with multiple parallax scrolling layers, large environments and each layer having animated tiles, and I STILL need to slow it down on 200mhz machines. Of course, I'm used to programming on machines with limits, since my last job was programming a z80 chip in C and ASM.
Mandrake, who said that the game was just "animating backgrounds?" The game includes animating backgrounds. The game is not just animating backgrounds.
At any rate, we're talking about using SDL with Python.
And in that context, it's not good enough. You can't, at present:
* Program the game purely in Python. * Using SDL. (by PyGame, or PySDL.) * Have animated tiled backgrounds. * And expect to have more than say 4 FPS on a 450MHz computer.
And that sucks.
Sure, you can code up whatever you want in C. Be my guest. Go for it. I've done it myself. But here in Python-land: No-go. Not today. Not yet.
There is similar discussion on the Game Programming Wiki.
We may want to delegate discussion of Game Programming with Python to the Game Programming wiki, as it seems like the Python wiki is moving towards "official" Python work. I feel we'd have much greater energy at the Game Programming wiki.
The case for Python as a game programming language is not clear cut. First, as have said LionKimbro, It depends on the game. A graphic intensive game should be build with other tools. The cost of function call is simply too important (calculate the number of function call you need to have to get 60fps).
But, many games can be programmed with python. Before stopping as the first glimpse of lack of performance, It's important to realize that to get more performance, you need to be more pythonic. Frankly, Escape of the Unicorn should have decent performance in python (based on the small available screenshots).
Game programing is not only about programming Half-Life 3. It also means programing the next Zuma and, for this, Python is a good fit. It also a good langage to learn game programming and that is a very precious thing (I just miss design by contract, but that just me).
Maybe now. It's been several years. But when I was working on Escape of the Unicorn, with my 450 MHz using PySDL, redrawing the animated tiles for every frame was giving me a rate of 3-10 fps; I don't remember exactly what.
-- LionKimbro 2005-12-20 01:33:06
I have programmed PyZX, an emulator of ZX Spectrum personal computer, fully in Python+Pygame. The code is about 3000 lines.
Vadim Kataev Sun Feb 19 17:08:05 CET 2006
See also this paper by Bruce Dawson.
A postscript to the above discussion, now that CPUs are probably an order of magnitude more capable than the 450 MHz stated above. My own experience with PyGame is that a scrolling map, refreshed once per frame at over 30 frames per second is easily possible on fast hardware (> 2 GHz) and will still run acceptably on old hardware (< 300 MHz). The trick, especially with older hardware is to convert images (convert_alpha) for the display surface - this speeds plotting up considerably.
A convincing demonstration of Python's suitability can be seen in this PyWeek 4 entry which features parallax scrolling, albeit at a modest resolution. The developers of that game are PyGame experts, but even less experienced developers should be able to put together games which perform acceptably. Admittedly, effects like transparency over large surfaces can impose penalties, but libraries like Numeric (integrated with PyGame) may offer some solutions.
-- PaulBoddie 2007-04-11 09:20:00
I would recommend using [http://www.panda3d.org] I develop only on Linux and only if i can use python, i set the rules - its a hobby! But after using, and liking it, i would definitely want to be using it for a projects to feed myself. My programs run without change on windows (mac os X support is there but... there is no nice package b/c of low demand) and on many different hardware.
Developing games is much easier with [http://www.panda3d.org] then pyOpenGL it takes batteries-included python mentality taken to the next level . Its a full game engine from Cg shaders to perlin noise, from reading zipped virtual directorates ( if you don't want to show your data ) to patching them, from network to sound FMOD and openAL , from openGL to DirectX7, 8, or 9. It has lots and lots of stuff you would want from a 3d engine and then some! But if you are missing some thing you can always hack it together with python or c++; the engine is very modular.
--- Andre von Houck 2008-04-14 09:20:00