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.
EA/Dice currently use Python scripts in the latest Battlefield 2 game. You will actually find quite a few games that currently use python already. I dont know why it should be news when game developers already do so and have for a while now.
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.
Did anyone else read that as "Syphilus3D"?
Join Tor today!
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
Naughty Dog (JAK) used scheme for this. The guy in charge is from MIT, so he's a lisp/scheme hacker.
They had Franz lisp make it for them -- this I found out at gamasutra.com
I think the only big deal about this is that they use Python, as opposed to some other language.
http://www.thebricktestament.com/the_law/when_to_
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.
So now as well as having to buy faster graphics cards, we'll have to buy faster CPUs to cope with Python's "Oh shit, you seriously want me to call a function? Woah. Hang on a minute..." feature? I'm all for open source, but Python's fucked up hash tables implementation is a perfect example of how more eyes won't get around to fixing things if they're not looking in the right places...
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/
Another game-related Python activity is the PyWeek competition, where entrants have one week to write a game. Unfortunately you've just missed this year's competition; it's held in August, and the winners were just announced.
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.
There are many, many games using python for scripting. Battlefield 2 being the most recent I've noticed.
.py files, you may be surprised.
Search your game folders for
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.
Anybody shipping a serious app should probably include an private copy of the Python engine along with the subset of Python libraries required to run the app.
Battlefield 2 uses Python too (look around in the game's directories, you'll find lots of *.py files). In fact, I'd guess that it's the most widely played game right now that uses Python.
What's interesting to me is that they were able to utilize Python and still develop a state-of-the-art, performant 3-D FPS. (People with slightly older computers might argue about "performant", but it does actually run very well even with the Pythion compiler/interperter baked in.)
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.
I don't like that code either; I'd write
(define (gnc:leap-year? year)
(cond ((= (remainder year 400) 0) #t)
((= (remainder year 100) 0) #f)
(else (= (remainder year 4) 0))))
As the other poster pointed out, Python can be written moronically too.
You know, tools such as StackGuard, ProPolice, Valgrind, Splint...
how to invest, a novice's guide
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
Hmm, I figured it out, I think; there is a PYTHONPATH environment variable I should have set to /usr/lib/python2.4.
/usr/lib/python2.4 has fixed this.
However, some Python-using software still doesn't load module "os" (and presumably any of the other default modules), even after setting this env var; so I ran Python and did "import sys", then "sys.paths". Python itself was still, for some reason ignoring my PYTHONPATH variable, but there was a series of nonexistant subdirectories in my home directory it was looking for. Making one of those a symbolic link to
Now if I can remember the name of that music tracker I wanted to try a week ago...
Slashdot requires you to wait longer between hitting 'reply' and submitting a comment.
Not a knock against Stackless Python, though. In fact, I agree with the author that preemptive threading in the context of scripting a game probably causes more problems than it solves. In a game, you can be more trusting of its processes/threads(aka scripts) than a general pupose OS would be. On the other hand, with games like UT where you can have have multiple "mutators" running simultaneously that were created by the modding community and not an inhouse designer, maybe preemptive threading would be a good idea.
rofl.
Shh.
Dubya has a BASIC? I'd hate to see the syntax for that.
Does a Christian soccer team even need a goalkeeper?
Eve online (crowd control software) is the main user of stackless python. Most of the patches are either contributed by them or requested for them. BF2 also uses python for most of its non engine work. (not sure about the AI though.)
Rock on python.
Official GOD FAQ.
Python's popular enough to have a lot of good tools (IDEs, debuggers etc.) and, IME, a lot easier to write code for than C++. You can do things in a lot less programmer-time and a lot less LOC, and it's more readable for maintainability. I would recommend using python for anything not performance-critical, not just AI scripting. And for those designers who do have the time and motivation, it's a lot lot easier to learn than C/C++.
I am trolling
You did something wrong. Python works perfectly on my system.
Most Linux programs that utilize Python that I've downloaded, didn't work; there's usually a missing, necessary Python module the program needs which either requires downloading from an obscure site or doesn't seem to exist at all from Google searches,
Most C/C++ programs have a missing library which requires the same steps. Your package manager ought to handle it.
or even with names that seem they ought already be included (like a module named "os" from a Python-using music tracker program I tried to run).
If you're missing the os module your python install is majorly broken.
I am trolling