Completed projects made w/ Python?

[bentlegen]

I was wondering how many users here have built successful games written primarily in Python. I'm not looking for a C++ vs. Python debate here, just who's done what.

Thanks,
ben

[ggambett]

I believe The Witch's Yarn is a Python game.

[MadSage]

This site has a list of projects: www.pygame.org

[bentlegen]

This site has a list of projects: www.pygame.org

Yeah but very few of them are of production-level quality.

I guess as an amendment to my earlier, post, I'm thinking of working on my next game in Python, and was wondering what kind of success people were having with it as a development platform. Immediately it comes to mind that the number of resources available out there (libraries, source code, etc.) are small compared to C++, for example.

[MadSage]

True. I thought perhaps you were just wondering what can be created with it.

Until you started this thread, I didn't even know people were creating games using it, so I had a quick look around. I've read about python being used as a scripting language to write game logic, and apparently it's Lua's biggest competition in that sense, but I had no idea it was possible to create a complete game with it.

[jankoM]

Witch's Yarn is production quality game and from older days I remember Solarwolf, Zephulor, pathological and Funki who were more serious ones.. they are all on pygame website however.

What kind of a game are you trying to make? I was programing for years in python but I wouldn't do a game in it.

[bluejay]

I believe Civilization IV uses some python.

edit: opps, you meant using primarily python, nevermind. :p

[Fost]

Isn't the entire of toontown online built using it?

The Panda3D engine basically runs main game loop in python, and the entire thing is build to use it. (Don't quote me though!)

http://www.panda3d.org/

[Ryan Clark]

If you haven't already, definitely check out Adventures on Planet Zephulor:

http://games.hollowworks.com/

[jankoM]

Uh thanks Fost for rteminding me of Panda3D now that I have ADSL and can finaly download it (I wanthed to try it for years). Zephulor has really interesting organic sound effects :) I think (my assumption only) the maker did them with his mouths. Zephulor was nice to play.

[tentons]

Prairie Games (http://www.prairiegames.com/) made Minions of Mirth with Python (ie, not embedded as a limited script tool). They used Torque as the game engine, but it's all driven from Python.

Also, all the game logic for Eve Online (http://www.eve-online.com/) is stackless Python.

There's no reason not to use Python for games.

[soniCron]

There's no reason not to use Python for games. Unless you need any of the modules available for Python, Lua is a far better solution for game embedding. It's smaller, faster, and much easier to embed.

[tentons]

Maybe, but I wasn't talking about embedding Python. :) (Except in the case of Eve Online.)

I meant using Python for everything except the inner-loop stuff (rendering etc). That is, start the game as a Python app. That's just what Minions of Mirth does. Also, the Python libraries provide a huge amount of cross-platform code that will save you gobs of time. I don't want to start advocating here, so I'll just stop now. :)

[soniCron]

:) That's embedding. And that's what Lua is particularly great for. I've got an entire engine worked up just like you described, and it's an excellent platform that I recommend you look into -- you very well may change your mind! ;)

[ManuelFLara]

:) That's embedding. And that's what Lua is particularly great for. I've got an entire engine worked up just like you described, and it's an excellent platform that I recommend you look into -- you very well may change your mind! ;)
That's extending, actually. Embedding is calling Python code from a C++ app, and extending is calling C++ code from a Python app.

[tentons]

As Manuel said, I'm referring to extending Python, where your C++ library is called from Python. Ie, you start the game by invoking "mygame.py," which would start the Python interpreter and from there would import your C++ library as a Python module. To use Prairie Games again, they turned the Torque Game Engine into a DLL and drive it from Python.

There's also a good binding for OGRE (ie, allows you to import OGRE as a Python module), which is what I plan to use for future 3d games.

[soniCron]

That just seems rather inefficient to me, though I may just be seeing problems where they don't lie. My engine works by creating a Lua VM in C++ and loading "startup.lua" The Lua scripts then call extended functions which add things to the entity heap or call for the engine to load a sprite, for example. The main program, a standard C++ app, then loops and solves logic while every logic frame calling a Lua function which in turn contains any game related code that needs to be updated. I suppose it's an amalgamation of embedding and extending. Anyway, I just don't understand why you'd want to invoke your app by calling a Python script... especially since you lose any opportunity to encrypt, hide, or otherwise obfuscate your main game code.

[impossible]

Games not mentioned yet in this thread include Basegolf (written entirely in python with pygame), the Battlefield games (1942, Vietnam, BF2) and Temple of Elemental Evil.

The main reason to code in Python over Lua is because of the Python libraries and because Python is a very nice language to code in. It seems very feasible to write a game engine in C or C++ that extends Python and Python for all of your game code.

[bentlegen]

There's also a good binding for OGRE (ie, allows you to import OGRE as a Python module), which is what I plan to use for future 3d games.
PyOgre looks like a fantastic resource. Not what I was looking for with this thread, but I appreciate it all the same ;)

[tentons]

That just seems rather inefficient to me...
Well, the C++ is where your inner-loop would be (timer, rendering, event dispatcher), so ideally Python would execute during event calls, initialization, and everything in between. But honestly Python is not that slow. :) I did some testing with OpenGL hardware rendering for 2D using pure Python (no C++ at all) and got decent framerates (30-40fps on a 1.2ghz machine with no real game logic running). I decided it's probably not yet feasible to do that for a commercial game, but it's certainly not impossible if you don't mind slightly higher (mid-range) system requirements. Then again, I could have used Pyrex (http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/), and it would have all been C++ and that would have solved the performance issues.


I just don't understand why you'd want to invoke your app by calling a Python script... especially since you lose any opportunity to encrypt, hide, or otherwise obfuscate your main game code.
Obfuscation isn't very important to me. But the big attraction (apart from the language itself, because I'm very disenchanted by C++) is the huge libraries available. It's pretty much got everything covered and then some, and it's all cross-platform, and I don't have to bugfix any of it. :)

[HairyTroll]

But honestly Python is not that slow. :) I did some testing with OpenGL hardware rendering for 2D using pure Python (no C++ at all) and got decent framerates (30-40fps on a 1.2ghz machine with no real game logic running).

Wow. What you are saying is that 40fps is the absolute maximum frame rate achievable using pure python on a 1.2Ghz machine? That seems awfully slow to me. I get well over 100 fps when rendering ~50K lit/shaded polys using interpreted Lisp. Were you using display lists at all, or only immediate mode?

[tentons]

Actually, I don't know. It was based on Simon Wittber's implementation. From what I examined it looked very brute force. But also lisp could be faster than Python, though I have never tried to compare or even read about comparisons. I'm sure it could be made faster, but IMHO it would be best to just acquisition some solid rendering library like OGRE than to write it all from scratch in Python anyway. Less code for me to maintain! :) I'm all about using other people's code to save me time and let me get straight into the game logic.

Sorry to be OT here! To get back on track, here's "A Violent World" (http://www.gamedev.net/community/forums/topic.asp?topic_id=357195&forum_id=71&gforum_id=0) which was created with PyOGRE for a contest. Cool RTS type game.

Edit: Wait a minute.. 50 thousand polygons (triangles? so, 25k quads?) at 100fps on a 1.2ghz machine?? Were you doing any texture state changes etc at all? That seems impressive to me even for a C++ app. :)

[HairyTroll]

Edit: Wait a minute.. 50 thousand polygons (triangles? so, 25k quads?) at 100fps on a 1.2ghz machine?? Were you doing any texture state changes etc at all? That seems impressive to me even for a C++ app. :)

Not when you use display lists, hence my earlier question. I think execution speeds for interpreted Python and interpreted Lisp should be comparable.

I create an OpenGL display list containing 100 spheres, each sphere is created using 512 triangles == 51,200 polys.

- Each frame the pointer to the display list is passed to OpenGL so with a couple of calls from Lisp the whole screen is rotated/moved/redrawn.
- If you use immediate mode then your application must redraw each poly for each frame which sucks down a lot of CPU time.