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."
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.
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).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/
Sylphius uses Python. Python is Open Source, as is Linux. Linux was programmed by Linus Torvalds. Linus Torvalds was in Revolution OS which was narrated by Susan Egan, who was in Death and Texas with Charles Durning, who was in the made-for-TV version of Mister Roberts with Kevin Bacon .
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor
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.
Dubya has a BASIC? I'd hate to see the syntax for that.
Does a Christian soccer team even need a goalkeeper?