Slashdot Mirror
Game Scripting With Python
P. Staurou writes "There is very interesting article about game scripting with Python over at Sylphis3d.com. It talks about how game engines should be structured as operating systems with actors being the processes. The proposed design is based on a special version of Python called Stackless and already successfully implemented in their own Sylphis3D game engine."
I don't see what is so new about this "news". Console games are designed with the idea in mind that the hardware does not have a full featured OS. We have to do almost everything, from memory management to thread syncronication, and guess what are the "processes" we are working on....? Is this a news story because noone has actually put this concept into words?
Ewww!!!! Oh I misread... Whoops...
..supposedly will use Python scripts for most of the AI behaviour. It's supposedly the most easily and thoroughly modifiable game ever. I can't wait to see what the community produces. In fact, I'd say that the developers will incorporate user-generated content in the official patch system.
The game company I work for does cross platform console games for XBox, PS2 and GameCube. We use LUA as a scripting language. LUA is a small clean language with simple but powerful syntax. The run time memory footprint is pretty small (~100 kB) which is great when your writing your game for a console with less than 32MB available.
If you are thinking about scripting languages for your games consider LUA. http://www.lua.org/
... is already using stackless Python, so it's a proven, successful multiplayer online game platform. EVE has upwards of 10,000 players most of the time.
This article presents the idea relatively well, but this is NOT A NEW IDEA.
I'm not sure if Epic invented it, but I can certainly tell you that microthreading, latent functions (such as the sleep in the door example, or a playanimation method that takes game time to complete), and this general idea has been around since at least the original Unreal Engine in UnrealScript (which is now a rather mature scripting language).
http://brandonbloom.name
It didn't make the front page, but the recent article on extending games with Lua is also worth a read. My personal preference is still for Python (I love all of the libraries that it has), but Lua is good if you need some small scripting engine.
In that article, I was asked about this book, which covers Lua, Python, and Ruby for games. Despite having all of the "right languages," the book is awful. For people wanting to extend games with python, I suggest Game Programming with Python. This book is a wonderful overview.
As for the language, we used Python in Unity http://www.otee.dk/ for the initial preproduction of GooBall. It was soooo slow. After that we switched to Mono. CPU usage in the scripting logic went for >40% to app. 5%... If you like the Python syntax, you can always include boo http://boo.codehaus.org/ which mimics Python very closely, but uses type inference to get type safety automatically. On another note: the article states that Unreal does not use microthreads. That is not correct.
Python, JavaScript, Java, Perl, VB, whatever. The big jump is making runtimes object oriented, with published APIs. We're now living in a programming culture where the old barriers, like "infraproject silos" that used to prohibit code in the same app from interoperating, have given way to classes with public and private access status. We've come a long way from "file scope" limits to "externs", while retaining the organization and manageability that scopes and explicit access specs offer. Now we can reuse code that we wrote for another project, or that another person wrote, without even looking at the code - just the APIs.
But only for programmers. We're still struggling with IPC facilities for programmers, and runtime IPC is rudimentary. Some programs don't even have pipeable STDIO. But if every app's GUI (or CLI, or other UI) always had an equivalent API, we could much more easily program them. We programmers should establish this pattern ourselves, ensuring every menu item, dialog box and UI buffer has a public API that can easily be wrapped in Python, C/++, Perl, Java or other calling wrappers. And bundle scripts with our distros that "kiddies" can easily hack into new versions.
We can leverage our "Open" culture from our programmer ghettoes to the user community at large. And since we're even more often users than programmers, we're immediately serving ourselves, too.
--
make install -not war
The point of using Stackless Python (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets and channels. If your game engine works by creating actors as threads then using a scripting language that has a simple to use, efficient, and platform independent threading model is likely of great importance, and Stackless Python offers that.
If you're generally interested in better threading models, and being able to think and reason about threads and their interactions more easily then you really ought to check out CSP. Multithreading is actually easy if you do it right - it's just that most languages don't.
Jedidiah.
Craft Beer Programming T-shirts
TFA is talking about the use of coroutines to avoid programming state machines. Coroutines are really very useful, as they allow code as simple as the following:
The code, which is supposed to make an airplane actor fly a looping maneuvre, is much simpler than the corresponding state machine code, which would consist of four states. I used this sort of programming in my hobby flightsim project Thunder&Lightning using this C++ implementation of coroutines. There is also Io, an embeddable language with a very small footprint which is easy to learn and nice to program with and which supports coroutines as well (actors in Io's terminology).Stackless is a completely different implementation from CPython, and has extremely different performance characteristics.
Consequently, your experiences with CPython simply don't apply here -- Stackless is largely focused around doing this kind of thing (microthreads and such) extremely well.
I was willing to believe that Python's whitespace indentation was a good thing. I wanted to believe. But unfortunately I just find it to be a pain. I like Python, but the using whitespace to indicate block structure is annoying. Why? Because auto-indenters don't work. When I'm writing the code the first time that doesn't really cause problems, but when I go start messing with existing code and rearranging things, refactoring loops and such, then I just want to hit my magic Ctrl-Alt-\ key sequence and have the editor reformat things for me. But if whitespace is the only indicator of block structure then it doesn't work properly.
Maybe it's just a problem with Emacs' python mode, but I don't really see a good way for it to automatically know what indentation level this chunk of code I just dropped in is supposed to go.
As part of Google's Summer of Code, someone with much code-fu has released the initial version of a Python-to-C++ converter.
Check it out:
http://shed-skin.blogspot.com/
http://sourceforge.net/projects/shedskin/
I'm not even going to read this thread - I'm sure someone made a similar joke, but I wouldn't use any technology that sounds like you could download it from a cheap hooker.
You can say, ``well, you're supposed to have code standards to handle that,'' and you'll be completely right. I agree with that, but that doesn't escape the technical problems associated with it. The Python parser needs to be able to handle it.
At the place where I work, tabs are always 8 spaces. There's a reason for that-- it's because we need to look at each other's code!
As far as newlines are concerned, I believe python accepts any of the popular 3 styles of newline. So that is never an issue.
I'm pretty tired of listening to people bitch about python's indentation rules. They are an elegant solution to the problem of specifying program control flow.
In contrast, bash has been sensitive to whitespace for decades, and yet you never hear anyone calling for us to move to a better shell. Why? Because bash is "the standard" and it's OLD. It seems like there's a lot of dinosaurs out there who just don't want to evolve.
"Any connection between your reality and mine is purely coincidental." -Slashdot
Last weekend I pulled in the latest Python (2.4.1) for Winblows, the Ogre 3D engine binary , and PyOgre (http://www.ogre3d.org/index.php?option=com_remosi tory&Itemid=57&func=selectcat&cat=1).
This combo rocks fairly hard.
Run a 27 line Python script, and boom, you're looking at a working 3d engine. It's fast, too, probably because the heavy lifting is being done in the Ogre runtime binaries.
For developing and prototyping, there's no time wasted (re)compiling changes; tweak some Python and away you go. And there's no reason the code or scene objects can't be tweaked while the engine is running, perhaps by means of a some sort of IPC, whether it's via a telnet/socket-type connection, or an XML-RPC daemon process, or whatever. Some people have even worked up demo on-screen overlays akin to the Quake console.
I'm looking forward to the day I can interact with a 3D environment and manipulate 3D objects with the same immediacy I'm accustomed to manipulating data in the Python interactive prompt. Heck, I'd even learn Smalltalk if they plugged Ogre directly into something like Squeak. But for now, Python + Ogre (PyOgre) seems to show a lot of promise.
Having worked on game consoles for years, and having worked on several games using both Python and LUA, I strongly disagree with your statement. I find both languages terrible for console development.
Although Lua didn't use much memory, I found it allocated and freed lots of memory. Lots and lots of it. This had the nasty side effect of fragmenting memory to all hell. This can be fixed by giving it its own stack, but its still an issue, especially if the LUA calls out to something that needs to allocate memory. It can get very nasty, very quickly. In addition, I found the language syntax to be fairly poor, I mean it was designed with configuration files in mind, and so it works great for configuration files, but it syntactically didn't fit with most of the AI we wanted to do. We just ended up calling C most of the time anyhow. On top of that, the use of LUA meant we didn't have a decent debugger (if any), which meant tracking down crashes and bugs was an adventure in tedium, using lots of printfs.
Python was a language better suited to Game AI, but once again, memory fragmentation was a big big issue. In addition, it was fairly slow and tended to access lots of memory, which killed the cache on most of the consoles nicely.
Overall, with all the performance considerations aside, I found the choice of Python and LUA to be poor mainly because they didn't solve the problem that they meant to address. One of the big things that everyone wants is non-programmers being able to edit game behavior. Both Python and LUA may seem easy to those of us who code, but it is incredibly difficult for most game designers, as most of them can not code at all. Generally, in the course of development, there isn't time or motivation for people to learn how to do many new things, and so the programmers end up doing most of the scripting. Once the programmers are doing the scripting anyhow, you may as well do it in C or C++, as you'll have better development tools. The other big argument I hear is that you can update AI in realtime, which sounds great, but in practice, is much more difficult to do than it sounds. If you are going to add scripting for this feature, then make sure if you can't implement the feature, then remove the scripting. You'll save yourself a ton of trouble. Anyhow, I'm sure lots of people will post examples of projects that succesfully used these scripting languages, and I'm sure there are some, but it certainly hasn't for any of the console based projects I've worked. Which isn't to say there aren't scripting style solutions that do work, I've seen them work and am a big proponent of them, but I haven't seen any that worked with a general-purpose scripting language. Remember, there is a price to be paid for it being general purpose, and if you have a specific purpose in mind, that price can be very high.
With Cell (which I've worked on for 3.5 years until last month), its Power core supports virtualization feature (or "hypervisor" mode as IBM likes to call it) as documented in Power Architecture V2.02.
This allows companies (I won't be surprised see if all 3 game consoles will support this) to allow game programmers to create RTOS (real-time operating system) like programs so that they have very refined control over program behavior (even OS like control) while the hypervisor SW (like Xen) will prevent any critical resources of games from clobbering each other (just as hypervisor supported OS will not hurt other OS running under hypervisor). Virtualization will give more control to the game programmer (more power and more responsibility) while the game console maker would retain minimal but critical control over the resources (mainly IO and memory). Pretty exciting world ahead for game developers in my opinion....
Danny Kumamoto
Dubya has a BASIC? I'd hate to see the syntax for that.
Does a Christian soccer team even need a goalkeeper?