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?
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/
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
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.
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
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.
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.
:). The indentation is the serious matter.
It's not that elegant of a solution. It forces the parser to have to be far more complicated than it should be. Furthermore, it makes the program sensitive to something that can't always be seen by a human. If some doofus sees your spaces and thinks ``that's one tab,'' and makes modifications, then he may not know that he's screwed up.
As far as newlines are concerned, I believe python accepts any of the popular 3 styles of newline. So that is never an issue.
It's also not that hard to code. Search for stupid style newlines and replace them with UNIX styles newlines...problem solved
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!
I prefer fewer spaces because you get the readability without pushing stuff as far to the right. I also hate it when I come across the tab character. Like I said before, coding standards are great and I completely agree with you that they should exist, but making them a part of the language creates problems that can't be solved with good coding practices, while good coding practices solve the problem that Python's indentation rules are meant to solve.
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.
First, bash isn't ``the standard.'' The original Bourne shell is the standard, with csh being the next closest thing. Second, I completely agree with you about needs a new shell. A few things have been invented since the shell methodology was dreamed up, and it's time to use them. Compatibility modes (ksh, bash, and tcsh) solve the upgrade problems nicely (not that anyone ever should've written scripts in csh to start with).
I really wish people would stop promoting languages just because *insert name of project they like* is using it. Why should LUA be used over Python? Ok, it has a small footprint, but what features does the language itself offer?
Don't give me "it's small, clean and power", many advocates of their favorite language say that. When people say that, it actually raises red flags for me that the person doesn't actually know what they're talking about, since that's about as in depth as they can get.
Are you even a programmer? You even used LUA or Python? Why should a PC game developer be concerned with such a tiny memory space when they have so much memory available?
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
Lua was specifically designed to be used as a scripting language embedded in programs written in other languages, that's why you should consider it.
Python, on the other hand, wasn't: the domain it was designed for is OS-level scripting and general-purpose programming.
That's not to say Python couldn't be a good scripting language. It's simply that it's not the domain it was designed for, whereas it IS the domain Lua was designed for, and - generally speaking - using tools for the purpose they were intended tends to work better than forcing them to solve a different problem.