using high level languages like Python for game logic

Quote:

Original post by graveyard filla anyway, my question is are people writing games in C++ and then writing a lot of the logic in Python?

It seems that the majority of modern games are turning to scripting languages to script dynamic events in games. I'm not sure if many are using scripting languages to create the game logic, though. Even if you coded the speed-critical parts in C/C++, it would still seem to be quite an inefficent way of doing things, and something that DLLs would be much better suited to.

I'm also not sure how much Python is being used. I know for a fact that Paint Shop Pro 9 uses Python (in much the same way that 3ds max uses MaxScript), but there are a range of scripting languages available (AngelScript, Lua, Python, etc.), and from what I've heard, Lua is very widely used (although the interface is horrible, apparently). I also know for a fact that Warhammer 40,000: Dawn of War and World of Warcraft use Lua; they might be worth checking out, if only to get an idea of how a professional game uses a scripting language. UnrealScript, and the scripting language that Doom 3 uses, are good examples of in-house scripting languages. UnrealScript is based very much on Java/&#106avascript, and the Doom 3 scripting language is based on C/C++.

My apologies for any mistakes/general misinformation in the above post; I have had a bit to drink. There might be a few spelling mistakes, too...

Quote:

Original post by iNsAn1tY Quote: Original post by graveyard filla anyway, my question is are people writing games in C++ and then writing a lot of the logic in Python? It seems that the majority of modern games are turning to scripting languages to script dynamic events in games. I'm not sure if many are using scripting languages to create the game logic, though. Even if you coded the speed-critical parts in C/C++, it would still seem to be quite an inefficent way of doing things, and something that DLLs would be much better suited to.

why would it be inneficent though? i mean, is Python really THAT slow? if i embedded C++ to do networking, AI, rendering, physics, etc, you think it would still be very noticable?

Quote:

I'm also not sure how much Python is being used. I know for a fact that Paint Shop Pro 9 uses Python (in much the same way that 3ds max uses MaxScript), but there are a range of scripting languages available (AngelScript, Lua, Python, etc.), and from what I've heard, Lua is very widely used (although the interface is horrible, apparently). I also know for a fact that Warhammer 40,000: Dawn of War and World of Warcraft use Lua; they might be worth checking out, if only to get an idea of how a professional game uses a scripting language. UnrealScript, and the scripting language that Doom 3 uses, are good examples of in-house scripting languages. UnrealScript is based very much on Java/&#106avascript, and the Doom 3 scripting language is based on C/C++.<br/><!--QUOTE--></td></tr></table></blockquote><!--/QUOTE--><!--ENDQUOTE--><br/><br/>i currently use Lua in my RPG, however i am strongly thinking about switching to Python. Lua is much easier to embed into C++, however i find Python to be a much nicer overall language. <br/><br/>well, i guess by the lack of replies on this thread, that there really is very few people who write the game logic in Python type languages. i was thinking that i would make development time much faster while costing little in performance..

According to the 80/20 rule of thumb, 80% of the cpu-time is spend in 20% of the code. Let's say Python was 10 times slower than c++ for example (which is somewhat realistic).
Then writing that 20% of the code in c++ and leaving 80% in Python results in an app that takes 0.2*10+0.8=2.8 times the time per frame of a 100% c++ version.

Not too bad. Probably good enough unless you are working on a big commercial game.

personnally, I think it makes sense to use a high level scripting language to do non time-critical parts of the code. Most of the time, as said before, is spent doing physics, AI, sound, rendering stuff. Logic takes very little. So, having a bunch of DLL for the low level stuff, and plugging everything together using Lua or Python could be a way to do it. That's just my uneducated view actually, I'm just a C++ coder at the moment.

I'd bet in most games the majority of the CPU time is going to be eatten by (in no real order)
- gfx update
- gfx submission
- sound management
- physics (if needed)
- animation (for example, working out bone positions)
- AI

Now, aside from the last one I wouldnt want to put scripting into any of those parts as most of them do need the raw power you'll get from C++/C/assembler (as needed).

However, AI however can be worked out over frames and is a bit less taxing in general and is ideally suited to being shoved into a script, even if your main hook is still C++ you could have the way it reacts to events handled in a script file.

Same goes for effects, say you had a weapon which required a certain set of effects you could hardcode it and be forced to recompile it for each little change, or you could script it and at worse you'd have to restart the game (if you were feeling clever you could put a script editor into the game as part of the UI [wink]), however its very well suited to this task because its a one shot deal, you'd call the script, it would setup the effects and trip any animations or sounds required and then thats it until next time it needs to be called.

If you look at games which are around thats the kinda thing they will use it for and given that games such as DoW and WoW and even Neverwinter Nights use the like of Lua, with others still using Python i'd say its a pretty safe bet that its a way to go for the bits that will suit it.

So ends the broadcast of the Scripts are great in games Party [wink]

I generally just code the whole thing in python with help from pygame and my soon-to-be game engine (which will also coded entirely in python). If it gets to be too slow, which it almost never is, I'll recode the slow parts after using a profiler. The benefit of doing it this way is that you don't waste time coding parts in C++ that don't need to be.

I'm a teacher who works at the Entertainment Technology Center at Carnegie-Mellon. One of my co-workers helped implement "ToonTown Online", which is written half in python, half in C++ (the graphics engine is C++, everything else is python). As for myself, I implemented "A Tale in the Desert", which is 25% C++ and 75% a custom scripting language.

- Josh

Quote:

Original post by graveyard filla Quote: Original post by iNsAn1tY Quote: Original post by graveyard filla anyway, my question is are people writing games in C++ and then writing a lot of the logic in Python? It seems that the majority of modern games are turning to scripting languages to script dynamic events in games. I'm not sure if many are using scripting languages to create the game logic, though. Even if you coded the speed-critical parts in C/C++, it would still seem to be quite an inefficent way of doing things, and something that DLLs would be much better suited to. why would it be inneficent though? i mean, is Python really THAT slow? if i embedded C++ to do networking, AI, rendering, physics, etc, you think it would still be very noticable?

It depends, I suppose. Traditionally, game logic has either been built into a game, or put in a DLL and run through an engine. There's nothing faster than pure machine code. However, scripting languages have evolved, and it could actually be possible now to write all your game logic in an interpreted scripting language without any noticable slowdown.

You really might want to look into the Unreal Engine for an answer to this question. Try and find out to what extent UnrealScript is used. Is it used to define game modes, or even the logic for a whole game? Perhaps try and find out how much Dawn of War or World of Warcraft relies on Lua to drive game features, things like that...

Quote:

Original post by oliii personnally, I think it makes sense to use a high level scripting language to do non time-critical parts of the code. Most of the time, as said before, is spent doing physics, AI, sound, rendering stuff. Logic takes very little. So, having a bunch of DLL for the low level stuff, and plugging everything together using Lua or Python could be a way to do it. That's just my uneducated view actually, I'm just a C++ coder at the moment.

I agree. I'm currently working on an MRPG entirely in Python, and the testing seems to do just fine.

I myself like the Python language quite a bit more than Lua. However, it seems that Lua is a bit more widely used within games for scripting aspects. So far I havent found any extremely noticable lags with using Python in my game engine.

I don't know much about the scripting languages. Can I safely assume that they are kind of like a higher level language than C or BASIC etc... Like assembly>>C as C>>python. If I can assume this, than I'd say that it is a good thing, but I might not would use it for lower level logic and/or graphics in a game. If the graphics engine is in C/C++, I think python/lua/whatever would be good for organizing higher level logic, like these characters go here, do this, when you get to this tree, this enemy pops out, hilgher level logic. But the lower level animation etc... I think would be better in C/C++. I don't know about the actual speed, but I like having good control on lower level routines. That's what I like about C++. Can someone answer my above question though please?

Quote:

Original post by kburkhart84 Can I safely assume that they are kind of like a higher level language than C or BASIC etc... Like assembly>>C as C>>python.

No. Assembly is a one-to-one symbolic/mnemonic translation of machine code. Each assembly language operation directly translates to a single machine language opcode. C is clearly an order of magnitude more complex, and an early approach to implementing C was to compile it to assembly language first and then invoke the assembler on that. To a certain extent, this is close to what still happens with C (and C++) compilers today, as the machine code → assembly language conversion is trivial.

Python is nowhere near that related to C. It's architecturally closer to Java, for example, in that it is bytecode compiled and interpreted. C (and C++) can be used to write extension modules, which are imported into the interpreter namespace and which can be more performant than native Python. I stress can, because Python is better at certain high-level tasks than C because of the language definition. Implementing a reflection framework in a C program, for instance, would impose performance and data constraints that are unusual for the language, adversely affecting runtime. Python, on the other hand, maintains that data for all objects natively.

To respond to the original premise, writing your game's performance-critical libraries (aka "engine") in C or C++ as extension modules and using Python as the "glue" makes perfect sense. It makes so much sense that I'm embedding a Python interpreter as the core of my current project (for school; it's supposed to be C++ only, so shhh! [smile]) and exposing my top-level objects to Python.

Happy hacking!

Quote:

Original post by graveyard filla EDIT: im not talking about scripting the game, but rather writing the actual core logic in it, e.g. all the classes and the interaction of the classes, and then just embed C++ into the core (speed critical parts) of rendering, AI, networking, etc.

Code everything in Python, optimize with psyco, profile, then optimize whatever still isn't fast enough in C++.

I'm eagerly waiting for IronPython, though, when I can use Python from the top to the bottom of the stack. I hope Jim's still working on it...

Just a thought - if people can get Java to run fast enough for a whole game, shouldn't Python etc be similarly acceptable? They're both using an interpreter at some level aren't they? Or does Python 'compile' scripts into .obj/.exe format?

BTW the game company I worked with used Python but I think only for level scripting.

Python is a viable alternative for several game genres. I'm writing a 2D arcade style game (similar to asteroids, but some of them shoot back) with Python and Pygame and it runs fine on a 1.8GHz, 256 MB RAM, 32 MB VRAM machine. No profiling or optimizing yet and haven't tested on lesser machines yet either. Still, so far I've been very pleased with the performance aspect.

Sixth months ago I was a C++ programmer and wouldn't consider writing a game in anything else. Now for this type of game, I wouldn't consider using anything other than Python. Why deal with the headaches of C++ when you don't have to?

What is the overhead/time of taking C++ modules and making them accessible to Python? I've been wondering if its worth facilitating the changes to make room for Python, in a game that's well underway in development.

- carb

Quote:

Original post by carb What is the overhead/time of taking C++ modules and making them accessible to Python? I've been wondering if its worth facilitating the changes to make room for Python, in a game that's well underway in development.

At work, I use SWIG to call C++ from Perl code, but it works with a variety of scripting languages, including Python. Very easy to use - eats header-like files, spits out code.

Quote:

Original post by d000hg Just a thought - if people can get Java to run fast enough for a whole game, shouldn't Python etc be similarly acceptable? They're both using an interpreter at some level aren't they? Or does Python 'compile' scripts into .obj/.exe format? BTW the game company I worked with used Python but I think only for level scripting.

Python compiles to .pyc files which are a bytecode not unlike Java's .class files. (You should know this if Python was used at your company - next time, show more interest in the technologies your company uses :) ) AFAIK there is no JIT for Python however. There is also more overhead in Python because of (a) information (and run-time checks) needed to support the dynamic type system; (b) run-time properties of things that aren't present in Java (like doc strings).

Even in Python's own documentation, there is reference to the notion that a C equivalent "can be up to 1000 times faster" (in reference to the Pickle module, which offers both Python and C implementations). Of course, numbers like this are almost completely meaningless, but comparing Python to C or C++ - or even to Java - is not necessarily in the same category as comparing Java to C or C++.

OTOH, in many cases it is still acceptable. I do a lot of work in Python these days to support my J2ME development, and I have really grown to love it. Never going back to Perl again, I tell you.

Quote:

Original post by dmikesell Python is a viable alternative for several game genres. I'm writing a 2D arcade style game (similar to asteroids, but some of them shoot back) with Python and Pygame and it runs fine on a 1.8GHz, 256 MB RAM, 32 MB VRAM machine. No profiling or optimizing yet and haven't tested on lesser machines yet either. Still, so far I've been very pleased with the performance aspect. Sixth months ago I was a C++ programmer and wouldn't consider writing a game in anything else. Now for this type of game, I wouldn't consider using anything other than Python. Why deal with the headaches of C++ when you don't have to?

This doesn't really prove anything. Such a game as you decribe could run on a 386 (or 486 in a decent resolution with some 3D models). You PC is approx 20X faster than that... QBASIC could also do it!
Modern PCS are fast enough that even a really slow language will let you do simple games. If we remember DOOM would run on a medium spec 486, say 50MHz, then a 2GHz machine is up to 40X faster (depending on memory speeds, SIMD optimisations, CPU cache etc - maybe 20X is more realistic). So you can write DOOM in a pretty slow language!
The speed of languages isn't probably an issue for most hobbyist developers here, simply because our games rarely drain the system's resources (apart from possibly the GPU).