Is it advisable to use python in a full scale game?


27-11-2006 17:13:38

as the title says: is it advisable or even plausible to use python in a full scale game? (networked or just a single player one)

i just love python, it's methods, it's rapid development-ness (lol), it's clean structure and it even pushes you to OOP all the way. although, a full C++ game is defenitely faster than a python binded C++ one.

so... is it? cuz i'm currently having a grand time integrating pyode, pyogre and maya meshes. :D

i'm all ears to your opinions.


28-11-2006 09:33:33

Interesting question :)

I would say yes, its most certainly advisable. Remember, all the complex stuff is actually being done in c++ anyway, all you're doing is calling the methods via python, there is little or no delay between a python call, and the engine executing that statement via compiled c++.

I know python was used extensively in Battlefield 2 (cos i had a peek at the source), mainly for driving gamelogic and AI, with the actual graphics being driven by their own hard-coded engine, and a scripting system to load meshes / textures / anims etc. Sounds almost exactly like the ogre / python setup to me, and (I may be treading on dodgy ground here) I think Battlefield 2 was a pretty awsome game.

Even the python bits of your code need not be slow, as they say on, python code can potentially be much faster than compiled C, as it makes it much easier to write clever routines, and cut down on redundant functions. Also, with Ogre, you have lots of useful things exposed like Vector3's and Quaternions for doing things that would take some time to calculate via python. I've found that if you make use of these objects instead of trying to do positioning / rotation / distance solely in python, your game speeds up quite dramatically (of course, providing that you are not creating and destroying hundreds of them per frame, like I was originally :) )

my 2 cents:
Python / Ogre probably the perfect game design solution. The speed difference between it and a purely C++ solution should be negligable, and you more than make up for that with a fantastically simple development cycle, and easy to read code.

I love the python too :)


28-11-2006 09:44:32

bharling, thanks for that very detailed reply, it's very much appreciated.

i didn't know battlefield 2 had python in it! i never played it, but people near our neighborhood play it in internet cafes and the graphics are great and i bet the gameplay is too (cuz people scream while playing. hehe).

the reason for my query on using python is that, i have a group of friends who are willing to dive in the gaming industry and are quite serious about it. i've made a demo for them using pyogre and pyode and so far they're impressed with the capabilities of ogre, and that ogre was binded into python. they're only problem is that from what they know, python's used mostly for AI programming, and (as i've said before) application prototyping, so currently, they have huge doubts about expanding from the demo i made. (btw, my demo doesn't use the sample framework)

so basically, i could safely say that the python + ogre tandem could be likened to battlefield 2? wherein C++ codes (for 3d rendering, physics, etc) are used thru another scripting language: python? or rather... C++ APIs + python + right methods = hella good game? :lol:


28-11-2006 10:33:28

I reckon :)

I too am working on a little something at the moment, also without the sample framework. In the 'projects using pyogre' thread, theres a game called 'Violent World' which probably represents the most complete pyogre project I've seen to date. Usefully, they've also provided all the sourcecode (which I found incredibly useful in my own project). Its a great example of OOP game design using python, and also leaves lots of room for expansion and improvement. Check out the thread to learn more.

My current workflow is Blender (modelling / animation / prototyping) - GIMP (textures) - Xnormal (bump-mapping) - Python / pyogre (loveliness) - Audacity, pyFreeSL (sounds) - py2exe / NSIS Install packager (compilation).

I'm looking to integrate some multiplay options at the moment, but I'm unsure what to do with that as yet. A good option seems to be Twisted, or even Python's in-built sockets library. Also physics now that ODE and Newton are happily integrated into python-ogre.

Would be interesting to see the results of this poll, I'll bet that option 1 gets 100% all the way :)

What is the nature of your own project? I'm interested in doing something serious with pyogre, but I'm currently on my own. I dont mind sharing what I have so far if you have a team of serious people on the go. Myself, I've managed to put together a simple demo level, with some autonomous hunting characters walking around, and a 3rd person playable character, with some abilities like shooting, and jumping. You can also improve the characters abilities by practising his moves. At the moment, I'm working on some AI for a group of herding creatures, although I need to get the models and animations done first.....

Personally, I'd love to leave my rather under-paid programming job and go into game building full-time, as I'm sure is the case with lots of people.


28-11-2006 12:01:01

You can also improve the characters abilities by practising his moves.

this is a simple nice concept that when put to work could produce wonderful gameplay results! i like! hehe! :lol:

Personally, I'd love to leave my rather under-paid programming job and go into game building full-time, as I'm sure is the case with lots of people.

i know the feeling, but i am ahead of you, i already left my under-paid job. hehehe :lol:

my project.. rather our project doesn't have a gameplay / storyline plan that's solid yet. we're still at the brainstorming and 'can ogre / ode / etc do this?' stage. but so far, i'm experimenting with the creation of an engine. that's basically it. the engine so far incorporates multiplay characters (no networking yet) wherein each character loaded can have their own unique movement list.

physics gave me a really hard time because of unwanted bouncing of characters with walls, but so far everything's good, and unfortunately getting complicated.

so far i could directly load an exported mesh from maya and make it as my world map and apply collision detection, i can load meshes as characters and make em move (and switch from one character to another). the engine's structure isn't perfect yet. but in essence what i'm planning to do is to create an engine that can handle third-person-shooter (like gunz), and point-and-click (like ragnarok) gameplays all at once.

i've read the thread on 'violent world' already but am hessitant to try it out. it looks like the most complete project here, but i don't want my mind to be influenced yet by the structures of other developers.. i have the tendency to trash my code when i see that i'm waay off than what worked for others. haha! i'll just save that comparison when i've actually created something more stable, THEN i can learn from the structure. hehe!

and yes, hopefully we'll get option 1 all the way :D :D


28-11-2006 12:27:27

Yeah, I had the same problems with physics when I first tried it out. In the end, I coded my own very simple octree for doing collision culling, as my game does not really require full dynamics simulation by any means. Its written in python, so its quite slow. However I can dump all that now, as the octree scenemanager is now wrapped in python-ogre (just gotta figure out how to use it..)

So, I'm intrigued, have you left your job to go into game development full time? if so have you got some sort of funding from somewhere? how did you go about it?


28-11-2006 14:10:13

for now i'm doing freelance projects to get by. they pay more than regular jobs, but the problem is that occurance of getting projects is irregular. i'm game deving (or trying to) while doing those projects. then i guess if this gets big, i'll continue developing and create a demo for prospective investors, if this sinks, then i'll go back to regular jobs and just leave game devving as a hobby. hopefully i get something out of this, high risk is involved, so i'm just giving this stage in my life less than a year. oh, and my companions are somewhat doing the same.

sorry guys for the OT!

back to topic!

what's Xnormal? and is there a game oriented network api? :D


28-11-2006 14:39:12

Aha, a grimy freelancer eh ? :) I'd go that way myself, but I'm too pussy (not enough contacts I think).

XNormal is for making bump-maps for shaders a-la Quake4, basically allows you to make a billion-poly, high details model, and use it as a bump-map for a low-res version in game, without any of the overhead. Its by someone called Santiago Orgaz I believe, but I dont have a URL to hand. Its also free, last time I looked. Very useful prog.

Twisted seems good for game related networking goodness (dont quote me on that though). That said, I've seen some perfectly functional multiplayer demos written on blender game engine, using only python's native socket functions. Seems like the python socket module (combined with the threading module) is fine for dealing with small numbers of players over a LAN or internet.

But yes, back on topic:

if python.skillz and ogre.skillz and (plentyOfWillingArtists):
Game.sucess = True
MoneyMoneyMoney = True


29-11-2006 00:22:18

Dash it!, who's gone and voted No ? ! :roll:


29-11-2006 04:24:59

gasp! someone voted for option 2. kindly explain why though, the pros and cons :D


29-11-2006 11:08:51

why did you even include the option ? :lol:

should be:

do you think python / pyogre :

A) Rocks
B) Kicks Ass
C) Kicks all other solutions' Asses
D) Kicks the living crap out of all other solutions, and dances on their decaying corpses with much glee

perhaps i'm going a bit over the top with this....


04-12-2006 14:28:17

To add some more weight to the argument ...

According to, the rather nifty space MMORPG 'Eve Online' is developed mainly in stackless python (an enhanced version of standard python - also freely available).


04-12-2006 18:07:13

To add some more weight to the argument ...

According to, the rather nifty space MMORPG 'Eve Online' is developed mainly in stackless python (an enhanced version of standard python - also freely available).

wow i just saw their screenshots.. unbelievably cool if these really are gameplay screenshots! more points to the py'iers lol


05-12-2006 11:33:23

I'm pretty sure python has nothing to do with the graphics/rendering, I think its the gamelogic, and networking stuff. Still its certainly a good sign for those of us trying this method.

The graphics on Eve are very nice though, I agree!


05-12-2006 12:15:59

I used decompyle on their Python code a few years back and from what I saw it's Python for game logic, high-level networking and misc glue code.
Then there is C++ for 3D, low-level networking, audio, ... But all of that is exposed as Python classes or modules.

So in essence it's what is always being said about Python: Design in Python and then migrate the slow parts to C/C++


05-12-2006 21:28:02

The only thing missing in Python is real multi-threading (aka, no global interpretor lock...). :)


06-12-2006 10:20:47

That's where stackless python comes in :)


06-12-2006 11:53:02

I seem to remember a thread somewhere around here dealing with using stackless python with pyogre. Anyone got any info on this ?


06-12-2006 12:10:14

I'm using it exclusively with Stackless. The win32 binaries that I host are built using the Stackless libs.
Pretty much anything, that doesn't care about the frame struct memory layout, should be safe to use in CPython or Stackless without modification.
The only module I have ever had to recompile is Psyco.

Here are the other threads:


06-12-2006 18:19:17

Nope, stackless still uses the GIL everywhere...


06-12-2006 23:15:27

Nope, stackless still uses the GIL everywhere...

What he meant was that Stackless lets you do microthreading, eliminating some of the need for threading. For example you can run a bunch of AI agents in parallel microthreads/tasklets.


09-12-2006 06:34:39

I actually stopped using stackless because stack-switching when a C stack was on the stack, rather then pure python through all levels, it was reduced to only about 80k stack switches a second, that is with the C stacks doing *nothing*. It dropped to unacceptable levels quickly when they actually started doing data. Made a pretty nice engine around it though, as long as you are not wanting a few thousand actors as I was... I tried to do things like only do a certain amount per frame to keep framerate up and so forth, but unless it can be made truly multithreaded, it just started to desync to much...

It was beautiful to program in though, even on the C++ side. :)


16-12-2006 05:22:13

I'm a bit late to this thread, but I didn't see anyone mention Civilization IV, which also uses python...


22-12-2006 11:19:09

I'm one of the authors of A Violent World, and it's very nice to hear that people find use in what we've done! :)

Although, I must say that I don't agree completely with the bold part in this statement:

In the 'projects using pyogre' thread, theres a game called 'Violent World' which probably represents the most complete pyogre project I've seen to date. Usefully, they've also provided all the sourcecode (which I found incredibly useful in my own project). Its a great example of OOP game design using python, and also leaves lots of room for expansion and improvement.


It worked quite nicely for us, but there is A LOT of improvement to be done. We made VW for the 4E4 contest, and we started a new game for the 4E5 contest this year from scratch. It uses a much nicer model, but unfortunately we didn't finish the game (didn't even come close), but the basic game architecture is there I guess.

Although since I've started at an actual game company (Avalanche Studios, makers of Just Cause) I've realized that there perhaps are a few things that are needed to a game. As it is now, it feels very code-driven, which isn't all that great I guess sometimes.


24-12-2006 23:43:35

Hi Srek :)

Well I thought it was good anyway (which is probably the reason you're now working for a game company, and I not!).

well for a total beginner as I was, it was very useful, although now with a few extra months experience myself, I agree there are lots of improvements that could be made.

I'm thinking of putting together a tutorial series on pyogre, based partly on what I learned from ViolentWorld and also other sources plus my own researches (if that sounds ok to you? I dont want to go stealing your hard work).

Mainly though I'm waiting around for Python-Ogre, seems to me that is going be the next big thing in this community. a half decent tutorial series on that will be useful to anyone I think.

Any master tips you have Srek would be greatly appreciated by all here I'm sure (if you're allowed to do such open source tings these days?! :))


25-12-2006 14:49:41

Well, the nicest thing (for us) in the code was how we made a separate class for each Actor. That made it real easy for us to add stuff like the volcano eruptions, cannonballs, divide the turrets into different parts etc. Sadly we used it in a kind of ugly way, because Python is really slow at calling functions, so most of the functionality was put in the framelistener instead of in the actors themselves.

That's one of the reasons why we have a lot of "if == xxx" and "if actor.state = yyy" everywhere, the other is probably just due to our lack of game architecture knowledge and skills. :)

In our new framework (can't really call it a game even though there are some gamespecific stuff in it right now, all of which is easily removable) we have a much nicer structure. Still have the Actor as a base class, and it will probably work in about the same way, although the hierarchy will be flatter this time I think (that is, just keep Actor as the base class and have all other Actors inherit directly from it).

But I have an idea for the AI (anything from moving in the direction the actor is facing to doing more advanced thinking stuff) that will still put the code not in the Actors themselves, but in other "systems". I've only started coding this so I'm not sure how it will work out, but I think it makes sense.

Basically, an actor can at any time have a number of [0-*] states, such as "Moving", "Firing", "Planning_Zombie_To_Wall_Attack". These are just a list of strings (iirc). Then, there are a number of "subsystems", basically framelisteners, that are allowed to go through each actor and check their states against anything that the subsystem can do with that.

So you can have a MoveSystem that looks like this:


def updateAllActors( self, aliveActors ):
for actor in aliveActors:
if "Moving" in actor.states:
actor.position += actor.direction * actor.speed


The benefits of this architecture is that the actor classes become quite small, and that they work independently of the AI. Just like they don't know how to draw themselves (OGRE does that), they don't know how to apply their AI. So one person could be responsible for building a collection of Actors while another is independently working on creating a bunch of AI scripts.

The states themselves are changed using a fuzzy state machine right now (a special system handles that), but that isn't really important.

Also we have a kind of a stack for handling changing of game states, so you can simply push a "Pause game state" on top of the normal game state, and the game will only continue when it is popped from the stack again. A game state is simply an ordered collection of subsystems right now.

Makes any sense? Sounds ok?


25-12-2006 23:27:44

Yeah, that sounds really good :)

The movement stuff you reference about having external listeners check and deal with the states of actors is just how I have started doing it in my own project. It does seem to make more sense to have that side of things controlled as centrally as possible, thus reducing the bulk of the code. I'm using about 3 layers of inheritance in my actor structure (eg: actor -> runningActor -> WeakSoldier), I'll try out your suggestion of having less layers and see if anything improves. I'm also doing something similar with the AI, as in just making it a state setting excercise, and leaving the rest to the engine. I've also tried splitting AI updates between frames, which does wonders for the framerate, but hurts continuity quite badly :(

I'm liking your main event stack concept, that seems like an excellent way to deal with gamestates. Are you using the Queue module for that?

Well, I am certainly going to embark on a video tutorial series (which will be free at showMeDo) in the new year. My aim is to produce a 1-level simple tank shooting demo, hopefully making use of sound via pyFreeSL, and physics with the ogreNewt wrapping in python-ogre. If I'm feeling really ambitious, I might try and shoehorn in some multiplayer deathmatch action ('why, sounds so simple!' - I hear you shout:)) I'll also touch on blender for character and model creation (using some of the new stuff like render-baking etc.). Of course it will most likely not be the best way to do pyogre, but I'll give it a damn good go.

Many thanks for your thoughts Srekel :) I dont mean to keep heaping on the praise, but your work has been an inspiration, and I've found it very useful.

Oh, and Merry Xmas to all Pythoneers (and everyone else for that matter)


26-12-2006 00:11:24

The idea of having a flat actor hierarchy is just an idea so far, nothing I've tried or anything. But it feels like it makes sense to do so since the actors will mostly be data. Otherwise you might need to check multiple files ( -> ... -> to find what makes an actor behave a certain way.

Splitting the AI is probably a very good idea, but only to the extent of making sure that a specified maximum number of actors are allowed to evaluate their AI per frame. That is, don't spread one actor's AI over multiple frames.
For some cases it might be a good idea, like if you want to evaluate the entire playing field for an RTS player AI (which might be a cpu-consuming process), but for the most part I think it's something you want to skip, if for nothing else but to ease debugging.

I considered making a video tutorial some time ago too around the framework I was designing (the one we've started to expand on for the game we started on). :) Though there's much I'd need to prepare before being able to do something like that. Oh and don't worry about "stealing our hard work", I think I speak for all three of us that did VW that more than anything, it's cool that people find use in what we did. :)

Merry christmas!


27-12-2006 06:17:09

First off, merry Christmas!!! also, advanced happy new year guys!

That's one of the reasons why we have a lot of "if == xxx" and "if actor.state = yyy" everywhere, the other is probably just due to our lack of game architecture knowledge and skills. Smile

yea i had this too! but i altered the actors classes to have their own physics/whatever call back functions, while the listeners would check for collisions/whatever then call the actor's respective function. works for now :D

btw, i'm breaking up with pyODE & pyOgre and moving to python-ogre and its ogreNewt. i found out that pyODE wasn't really a binded up c++ api, but was a python module with ODE-like classes. it was slow for my processes and objects kept going through each other.

im dumping pygame as well, i didn't like the unfocus-on-the-pygame-window-and-stall-it thing. dunno what i'm going to use though, it's either wx (don't even know how to full-screen a wx window!) or ogre's default. any suggestions?

hence now.. i'm going through major porting and reconstruction, while the code length isn't that sky-high. sigh.

just random thought typing :wink:


27-12-2006 07:18:50

What pygame functionality do you use/want??

I ask in the context of our Python-Ogre development and am interested in what 'other' libraries we should look to wrap (and potentially include as part of the Python-Ogre package)..

We are focusing on our existing set (Ogre, OIS, CEGUI, OgreNewt, OgreRefApp), and will limit ourselves to these until we get a 1.0 release out - but are interested in the next iteration :)

FMOD (for sound) has been mentioned, although it's an ugly thing to wrap (a challenge is always good) and PySonic is already available..



27-12-2006 12:44:46

i was going to use pygame for sounds (but like you said, there are other available solutions to sound such as pySonic). as of now, i was only rendering into pygame's window (might move to wx? not sure though). at the start though, i was supposed to use also the keyboard inputs of pygame, but soon didn't bother with that and just used pyogre's, and will now move to OIS in python-ogre.

i think i read a while back that someone was asking if landscape paging could be wrapped for python-ogre. i have no idea yet if i'm going to use that, or if i would use bsp (i just recently saw counter-strike source, and believe they're using bsp's for that, correct me if i'm wrong)

the existing set is good though, i'm using (or going to use) everything except OgreRefApp. why not OgreRefApp? cuz i don't know what it is yet :lol: :lol:


29-12-2006 10:11:17

im a bit confused myself :lol:

i think the ogreRefApp is to do with newton but not sure how it works. re: the paginglandscape scenemanager: In the ogre documentation for scene managers, ogre.ST_EXTERIOR_REAL_FAR is listed as the paging landscape SM. This appears to be in python-ogre, though i have not tried it yet.

correction: duh!, sorry ogreRefApp is the ODE wrapping


29-12-2006 11:50:19

I'll probably start a documentation wiki on the python-ogre web site to help answer some of these questions in the longer term..

However for now........

OgreRefApp wraps 'the' Ogre reference application, which is a simple wrapper for ODE and Ogre -- the only demo that uses it is

OgreNewt is the Newton wrapper, check out some working (and some not) demos in the ogrenewt demo directory..

I haven't included the pageing landscape manager in the windows binary distribution, however considering how active it's CVS is I think I will try and do so in the next release. I don't think this will require any additional Python-Ogre work as it's a plugin to Ogre...

And we probably won't include a sound wrapper in the near term (although we may wrap FMOD etc in the future just to prove the usefullness of Py++ :D )


29-12-2006 14:23:26

:shock: ... keeewl :) :P