Game developing with Python?

Started by
3 comments, last by drakostar 15 years, 5 months ago
I have a few questions about developing games with Python. Do you know of any limitations... or pitfalls? What kind of productivity can I expect? What's the .NET version like? Why are most games -- not using this language? Anything else, you feel worthy of throwing at me..related to Python game development... please go ahead. It's a subject, that has recently caught my attention.
Advertisement
Quote: Do you know of any limitations... or pitfalls?

The most often heard complaint is speed. It is an interpretive language and as such it must be "deciphered" at run time by the interpreter. This, of course, is not as fast as having machine code being sent to the cpu.

But, there are things in the works to improve python. I think Python is awesome. There is also psyco. Psyco is a just-in-time (JIT) compiler. Another cool project is PyPy.

Quote:What kind of productivity can I expect?

As much as you can produce! I don't think there are that many limitations on that. To give examples, 3D projects are being created in Python with Python-Ogre and Panda3D.
Quote:Why are most games -- not using this language?

Some are: Python Games.

Overall Python is cool. I'm not saying don't learn and program in other languages as well, but programming in Python is easy and fun.
Quote:Original post by RebNyx
Do you know of any limitations... or pitfalls?

Limitations... performance and memory usage mostly, depends on what kind of games you want to create and what libraries you use though. Pitfalls... don't know. It's a pretty easy language to learn and to use.

Quote:What kind of productivity can I expect?

It's pretty good. I'm using Python a lot for prototyping before implementing things in other languages. It's also very useful for small tools (conversions, text processing, etc).

Quote:What's the .NET version like?

I've got no experience with the .NET version, so I can't tell.

Quote:Why are most games -- not using this language?

Scripting languages are becoming more popular, although their use is mainly limited to gamecode (not the most performance-heavy, changes relatively often) and (build-)tools, as far as I've seen. At work, I use it a lot for tools, but not for the actual games, because we're working with resource-constrained consoles.
Create-ivity - a game development blog Mouseover for more information.
Quote:Original post by RebNyx
Why are most games -- not using this language?

Most games are using C++ because professional developers have programmers with C++ experience and a lot of reusable code already written in C++. Most hobbyist developers use C++ because they aspire to become professional developers and wish to emulate them and acquire relevant skills.

However, Python is a more than adequate language for most types of game. Expect productivity to be far higher than with C++. Pitfalls might be a lack of support, whether that be libraries that aren't written to work with Python, or people who are unfamiliar with the language, or even that Python experts tend not to bother with games.

Quote:Original post by signal_
To give examples, 3D projects are being created in Python with Python-Ogre

I want to love Python-Ogre, but unfortunately it's sporadically maintained, Windows/binary-centric, and perpetually unstable. If you're reasonably competent with C++, you're probably better off building your own slightly-higher-level wrapper with Boost.Python.

PyGame, on the other hand, is fantastic for 2D games. It's a mature, popular and well-maintained wrapper for SDL, and creating a simple game with it is very easy.

As mentioned, Psyco provides a significant performance boost, though it isn't exactly a JIT *compiler*. It only does type specialization, which is simple, reliable, and very effective. The major performance issue with Python that's worth noting is the GIL (Global Interpreter Lock); multithreading in Python doesn't work quite as expected, since only one thread can use the Python interpreter at a time. The multiprocessing module in 2.6/3.0 solves this nicely, albeit with the memory overhead of extra Python interpreter(s).

This topic is closed to new replies.

Advertisement