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.
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.
And when the parser gets to be able to handle it, all that means is that it's sufficiently complicated to handle any mix of whitespace. That sounds terribly overcomplicated for something that's just supposed to parse out some code, and that complication will bite them in the ass.
Ignoring the obvious fact that Python is not a compiled language anyway
If you're going to be a pedantic ass, then you should mention that there is a process to compile Python to native language; otherwise, you should stop trying to whittle posts down using minor, offtopic parts of it. ``Compiles'' is a better word in that case than ``interpretations.''
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
Instead of writing your games in C++, consider GW-Basic!
I respond to your sigs
The author uses examples with 'try' 'except'. Handled wrong, that makes debugging a LOT more difficult because if your error is in the 'try', you won't get an informative error message. The author has 'except' printing 'oops'. In anything but the most trivial program, you have to be a tad more informative about what's causing the error.
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.
Haha. And how many dozens of incompatible dialects of Lisp are out there? How many object models? How many macro systems?
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
No, the process turns Python code into portable bytecode, not chip-native code. That still doesn't make it a compiled language.
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.
Why does it matter how many variants of lisp there are? Is that such a bad thing? Lisp/Scheme is like the fundamental equations that describe how the universe works -- if you alter them a bit, you have a different lisp. None of the differences is so important once you understand that.
Also, I don't get your point about there being too many incompatible object systems. If you have the lambda calculus and static scoping, in any form (even ML), building an object system takes a few pages of code. It is such a small amount of work that you would expect to see one per project, perhaps tailored to the needs of each application. That was the point of CLOS, right?
A reasonable way to implement Python would be on top of a lisp/scheme -- that way you'd get the benefit of the lisp compiler. That's how ML was first created -- as a domain-specific-language in a lisp program.
http://www.thebricktestament.com/the_law/when_to_
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/
Battlefield 2
Nexagon: Deathmatch
Toontown
Blade of Darkness
Freedom Force
Temple of Elemental Evil
There are probably other games out there. I'm not sure which use stackless Python,though, as I don't know what stackless Python is. At any rate, people have been finding it useful in games for awhile and that's not likely to stop any time soon.
The World's Worst Webcomic!
That still doesn't make it a compiled language.
I had been referring to py2exe (I don't know what you're referring to) going off of my memory, but I can't find any docs that actually say how it works, and don't care enough to be bothered to look them up.
The word compile there is still an accurate enough description of the process that turns the python source into the bytecode; one language is turned into another language. If you want to spend any more of your Saturday night going over semantics, here's a starting point: http://en.wikipedia.org/wiki/Compile. I'll leave you to it.
Btw, this still doesn't address my main point.
Either I forgot to do something on my system, or Python is, in my experience, unreliable at best. 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, 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). The only program I've used that works seamlessly with Python without fatal problems has been Blender; then again, it only works with Python 2.3.
Slashdot requires you to wait longer between hitting 'reply' and submitting a comment.
Now here is how I'd write this in Python:
I'll take the Python version over the LISP one any day, thank you very much. Now, I have been using Python a lot, I may be biased... Oh, and to feed the grandparent: setting up my editor correctly to deal with the indentation is something I did once and for all a long time ago. Fighting with n levels of imbricated parenthesis is a neverending chore in LISP. Guess which one I prefer...
I code, therefore I am.
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.
Wow, I had never really looked at stackless python. Im kinda surprised they chose blocking communication as the default mechanism ... maybe people are finally seeing the light, only took a couple of decades.
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's a Lisp standard. They can pick a standard Lisp, pick a nonstandard Lisp, write their own that does whatever they want, or anything else. If they can't come up with a reasonable result with the most powerful programming language ever invented they're too stupid to be bothered with anyway.
If they specify ``Python'' as their language, then they are at Guido's whims as far as changes go, and things are changing pretty fast, mostly towards Lisp in every way but power and syntax.
py2exe keeps the program as bytecode, it just embeds a small-as-possible Python interpreter with the bundle.
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
It must be just you. I never had a problem with getting a Python program running in Linux. But then again, I program in Python and can figure out fairly quickly what it needs and Debian packages typically include most of the needed modules.
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
That works great, until you want to use somebody else's library.
What??? os is a standard module. You must have spilt coffee on your installation.
Heh, going coward was a wise decision for you - you dared to criticize one of the sheep god's favorites.
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.
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).
Multithreading in Lua is easy. Lua provides the coroutine facility.
The reason the original post is modded +5 is that Lua really is an excellent game scripting language. Anybody who is looking at stackless Python as a game scripting language should at least know about Lua.
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.
ive build curent blender to use python 2.4 because
that official build didnt whant to use my python 2.4
installation. it turn out that all my export script
worked perfectly.
All you need to use >2.3 is to change somme build
script.
-Bob
Ignoring the obvious fact that Python is not a compiled language anyway...
It's compiled to bytecode, like Java. Just FYI.
C//
Coroutines are not the same as threads. Coroutines provide what is essentially sequentially executed (i.e. single-threaded) functions with preserved state between function calls. This is not at all the same as the interleaved execution of mutliple threads of control that a truly concurrent system provides. Please do not conflate the two.
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.
WHAT?!?!?!?
C//
The channels description made me think of Dataflow languages. I'm not very educated in this area; would you agree that they are very similar, or am I way off here? Thanks.
You're stupid. The only reason there are n levels of parentheses in the lisp example is that they're comparing to 4 first instead of 400. If you did that in Python, you'd have:
... and see how many comparisons each function makes.
def isLeapYear(year):
"""Return true if 'year' is a lear year, false otherwise."""
if (year % 4) == 0:
if (year % 100) == 0:
if (year % 400) == 0: return True
else: return False
else: return True
else: return False
This looks n times uglier. Did you ever stop to think that maybe the gnucash people did it that way because comparing with 4 first is several times faster? Try out your function and the gnucash function with 1, 2, 3, 4, 5,
I've done extensive programming in scheme, other lisps, and python, so I'm probably not nearly as biased as you. I'd choose scheme over python when it comes to beautiful syntax any day. Just compare the length of the scheme language spec to the the python language spec to see why.
I don't get the problem. Suppose you give me some code to create your "object" abstraction (a few pages) and a library that uses it. I want to use it with my own object system -- fine. I've got two object systems in the same application. No big deal. As long as both systems are small, it doesn't ruin things at all.
Maybe I even use macros to translate the one object notation into another, to avoid having two object systems.
http://www.thebricktestament.com/the_law/when_to_
Well, obviously, you don't accept his patch.
Arg. It may be for a codebase we bought from someone else, or one we're trying to fix for someone who bought it from someone else. It could be written in FORTRAN 66 and have its first versions on a punch card. There are other ways to get bad code than from having the stupidest guy in your organization write it.
Python is one of those ways. Consider that I could take every single Lisp program ever written, remove all newlines and nonrelevant whitespace (ie, stuff outside of quotes), and a simple converter could make every bit of it entirely consistent in whatever format I wanted. With Python, I could change the newlines around, but it'll take much more logic to match the indentation levels, and it could be different for every guy that wrote it.
P.S. I might be approaching my daily limit of posts. It's making me wait a very long time in between them.
Likewise, a simple mechanical converter could transform any working Python program into compliance with your particular Python indentation standard. How is it any different?
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.
Something is screwed up. "os" is standard (and indeed, one of the most essential standard library modules). If this is broken, no wonder you're having problems.
;)
Anyway, just like most programs written in other languages, python programs often require dependencies.
These can often be found in that really useful "README" or "INSTALL" file in the project's top-level directory. You *did* read them, didn't you?
Almost all python stuff I've used was correctly installed by a meagre "python setup.py build && sudo python setup.py install". Occasionally I'll need to install a 3rd-party package. In which case I repeat the steps above for it.
Are you serious? Lua is a functional language like Scheme or Lisp. If those two languages sound familiar it's because they dominate AI research.
Come on people. Why the fuck are you modding this UP? Yeah, Python simply doesn't work. The thousands of projects and hundreds of companies relying on it are figments of our collective imagination. It's utterly broken. That's why nobody uses it. Oh wait.
Looks nifty in Perl to me:
;)
$answer = ($year % 4) == 0 ? "" :
($year % 100) == 0 ? "n't" :
($year % 400) == 0 ? "" :
"n't";
print "\n$year is$answer a leap year.\n\n";
Oh and you do want it in that order, I assume it was a typo that you had it backwards. Didn't work for values 1000 or less.
FLR
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
http://scienceworld.wolfram.com/astronomy/LeapYear .html
...
Oh geez I am dumb. It must be late. Coulda always made it a sub and checked to see if it was >= 1900
FLR
Sounds like your distro is broken if it's not automatically grabbing the dependencies.
LOAD "SIG",8,1
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.
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?
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.
You're stupid. It compiles to python bytecode, just as javac compiles to jvm bytecode. It doesn't make javac any less of a compiler that there aren't any commercially viable processors for running java bytecode natively.
The enemy ships in Galaga were controlled via scripts. Take THAT, you punk kids!
Okay, okay... the "scripts" were really just an array of bytes that had opcodes defining where to turn, when to shoot, etc. etc.. I agree that the idea of scripting parts of your game is not a new idea, but the article is still a good read.
Besides, I don't think that anyone (even the author) is trying to sell scripting as a new idea. Rather, I think what *is* new is that general purpose scripting languages are starting to be used. I think this really neat because it gives you a pool of modders who won't have the added learning curve of a new syntax. They already know language xyz so now they can concentrate on the learning the pieces unique to the game. I imagine it also frees up the programmer from rolling their own scripting language, though I don't know if the job of exposing the game engine to the script interpreter is any easier (guessing it would be but dunno). Although, I reckon putting a general purpose scripting language in your game ain't all that new either. Isn't the scripting of Quake3 done with interpreted C?
But who cares if it isn't new, I don't think this means this story shouldn't be on Slashdot. It's geeky and an interesting read, so why not?
rofl.
Shh.
Game AI generally uses relatively simple techniques. Think about the AI you see in games. In general the enemies are basically finite state machines with straightforward rules governing state transitions.
a=1 //indicating an error
b=0
try
___return a/b
except
___puts 'divide by zero'
end
return -1;
Thus removing 50% of the advantage that exceptions give, or at least structured exception handling. So now, many years later, we have a generation of developers who think that they are supposed to catch exceptions within the method that generated them instad of letting them spin right out to the top level (or they trap in the caller, which is usually almost as bad).
Disaster!
Even worse that Java re-inforced this heretical use of exceptions (see the Artima website for some interesting articles about how crappy java's exceptions are for larger projects).
The poor mites are generating reams of error display code because they weren't told the truth right from the beginning: that raising exceptions should out-number trapping by at least 10 to 1, and the better the underlying libraries the less the trapping. For example its poor form for a library to raise an exception for a non-exceptional condition wihtout a non-excepting alternative, for example : not being able to make a connection, which in many circumstances is non-exceptional. But many libraries do this, and so innapropriate trapping is necessary, .
I'm glad I could finally find some criticisms of Lua (it doesn't seem commonly-used enough to easily find them hehe). I recently picked it up as another language to learn, knowing it's occasionally used in games and embedded system development, but have yet to do anything serious with it. It's quite a syntactically elegant language and I've not had a hard time learning it (wish I could say the same for PROLOG which I'm taking this semester... *shudder*), but what you say worries me some. It certainly doesn't sound like a scripting language one would want to use in a time-critical game or application. Maybe turn-based gaming, but not realtime games. Perhaps by the time I "fluently" know Lua enough to comfortably use it in one of my projects, 5.1 will be out at the end of the year and will hopefully remember some of these efficiency problems. Not sure about that, though, but I'm sure Roberto Ierueclmf...whatever-his-name-is is aware of these issues, I hope.
Slashdot requires you to wait longer between hitting 'reply' and submitting a comment.
Dubya has a BASIC? I'd hate to see the syntax for that.
Does a Christian soccer team even need a goalkeeper?
"The Fall" is the one major game I know that was scripted with Python. It was horribly buggy upon release, and AFAIK still is. Especially the scripting was broken for many quests.
This could have happened with other languages, but using Python did not prevent them from producing crappy code.
I mean every game has some built-in scripting language at some level, without it game development would be a much more major pain in the ass. Of course, most of these are not publicly available, yet still, how is it news, that python can be used to develop such a scripting language ? How would it be news if they said almost any other language can be used to build such a scripting language ? Ehh, sunday morning.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
I've done extensive programming in scheme, other lisps, and python
Then you probably should realize that you could save a lot of typing with:
def isLeapYear(year):
"""Return true if 'year' is a lear year, false otherwise."""
return not (year % 4 or (not year % 100 and year % 400))
Congratulation, you're a failure, py2exe doesn't compile shit it merely embeds both a Python interpreter and your software (along with the required libraries) into a single exe
Wrong again, Python bytecode isn't the result of a compilation, it's the result of a translation and optionally the stripping of some comments. The only things that a .pyc file has over a .py one are
Other than that, it's exactly the same file, there is no optimization or structure modification from .py to .pyc, merely some name mangling to ease the interpreter's work (who can use raw .py anyway)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
And as far as I know this hasn't deserved Python too much in the past, and you are allowed to mail Guido or talk to him on the MLs you know...
And given the fact that Lisp is probably one of the most powerful languages out there, "moving towards lisp" seems to be the common factor of each and every progressing language. As long as Python keeps being more readable than lisp I don't quite see the issue (yes I could code in Lisp, no I don't want to, polish notation, parens and braces burns my eyes)
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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
In KDE. Look at it. It's being replaced for political reasons, but it's awesome, and the best part is it happens with no programmer effort at all. Whenever you create an "action" in your program, which is used for menu items, toolbar buttons, context menu items etc., there's a corresponding dcop call made available, and you can call it from any language you like, even shell scripts with the "dcop" utility. E.g. to send a particular instant message to a friend every 5 minutes with kopete I just wrote and ran a 2 line shell script. To get now listening information from any kde media player, encrypt something with kgpg, whatever you can do with the gui, just import the python dcop module, or the perl one, or whichever language you choose.
I am trolling
I see LUA and Python mentioned, but has anyone tried TCL for game scripting?
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
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.
Somebody has to put a joke involving snake in here, after all, python is a snake...
People complaining about Lua memory management performance and multi-tasking scalability are behind the times.
The 5.1 development version of Lua, due for final release late 2005, includes an incremental garbage collector and has been enhanced by Mike Pall with optional patches that allow for the efficient multitasking of large numbers of scripts (http://lua-users.org/wiki/ResumableVmPatch and http://luajit.luaforge.net/coco.html). Note that those patches fit a niche similar to stackless Python. Running scripts in different threads was already supported in prior Lua versions with only a small amount of C-side infrastructure.
In addition, Mike has recently released a JIT (http://luajit.luaforge.net/) extension for even better performance.
That's a piss poor argument. First of all, just because a language is designed to be "embedded", doesn't mean it's good.
Second of all, that's not really a design issue of the language itself--that's a design issue of the interpreter and the interfaces it provides to other languages.
Third of all, Python embeds well with C/C++ programs. In fact, there's a Boost (C++) Python library that makes it pretty easy.
Fourth of all, the domain of Python is of an interpreted language for general purpose programming. Embedable languages are a subset of that domain.
Fifth of all, your argument is based on (incorrect) generalizations that are admittedly based on ignorance of the Python and LUA languages.
And I have no idea where you got "OS-level scripting" from.
Ungh, how did the parent get moded up? Oh yeah, it's Slashdot.
Lua is a multi-paradigm language, not a functional language. Those languages only dominate academic AI research. They are dead in AI outside of it.
Ha. You're being funny.
C//
Agreed, I certainly second this vote for LUA. For me, has provided a beautifully simple approach to a game engine which now has the time-critical engine and graphics components written in C++ with level scripting, object control, AI and event scripting all done in LUA. The ease of embedding LUA was surprisingly refreshing, the ease of development afterwards has brought a massive boost to productivity. As it is, we have not used the threading options available, however based on the other replies here, I will certainly be checking out the threading in LUA and take a look into Stackless Python.
Java is a compiled language, even though it compiles to portable bytecode. Why, then, shouldn't Python also be considered compiled? The only real difference between the Java and Python methods -at least as far as this is concerned- is that Python makes the compilation process transparent.
Certainly there are many differences between Python and Java at the language level. When it comes to compilation, though, they're basically the same.
Why ? I've never run into any version incompatibilities. Sure, some modules spit out a string of deprecation warnings when I use them, but who cares ?
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
See here for the details. They used Common Lisp for what it excels at - implementation of a domain-specific language which they could prototype in CL, then use a CL-based compiler to generate console code.
To a Lisp hacker, XML is S-expressions in drag.
Assembly programmers find C and C++ too bloated and slow. Film at 11:00.
seriously, low-level programmers dealing directly with memory, registers and GPUs will never get the benefits of very high programming languages... like writting far better and more flexible NPC AI behaviour in far less time.
I don't feel like it...
Yeah, what's so fucked up about Python's hash tables implementation? Python is an excellent language for gaming (well, in fact, it is an excellent language for pretty much everything.) because it makes the programming sooo faster, easier, and, most importantly, elegant (I think that the pythonic coding style is excessively elegant).
You know, not every part of the code of a program (even games) needs to be super-asm-style-optimized. You only have to find your bottlenecks and optimize them (You can easily mix C and Python code together, so you can code your optimized parts in C) until the performances are acceptable.
perception is reality
Python may have a lot of tools, but you will have to modify them all to work with the game console, which is quite a bit of work. You also state that its easier to write code for than C++, and you're right, but I still don't think its easy enough for a non-programmer to pick up.
What has served me well in my career is rather than coming up with tools that I think would be useful, its better to ask the end-user, the artists and game designers, what their ideal tool would be. If they say "something like Python", then great, go ahead and put in a Python interpreter into your game, but I can almost guarantee that they won't tell you they want something like Python. Just because it's easy to us programmers, doesn't mean it will be for anyone else. I find that the best tool is one that I design after asking them "If you could have anything you wanted to help you do game AI, what would it be?".
I don't know much about LUA, but their website is one of the simplest, nicest I have seen in a while.
A few very easily accessible code samples would be nice, though.
The Cloud - because you don't care if your apps and data are up in the air.
Neverwinter Nights, KOTOR 1/2 and Far Cry used Lua.
Battlefield 2, Blade of Darkness, Eve Online used Python.
These are real-world examples you can mess with right now, rather than speculating about which is better.
I kind of like Python more than Lua because the syntax is more straightforward, which is good for non-technical level designers. I'm sure programmers will have other opinions, but what's the point of using scripting if it's going to be as difficult as C++? Does it really save that much time?
If you don't like the moderation, go elsewhere. Don't let the door hit you on the ass on the way out.
As a programmer, I'd prefer a real programming language like Python for modifying AI rather than the basic event scripting usually available. But I can see that it's only necessary for games with sufficiently advanced AI. Hopefully this is a good indicator for the quality of the Civ4 opponents.
I am trolling
BZZT! No, but thanks for playing.
"Compiled" Python is basically just pre-lexed. If you "compile" your python, it still has to be run through the Python interpreter. You're just saving it the process of parsing your code character-by-character. Since you can run Python code from plaintext without compiling, this would make it non-compiled. Anyone who has ever actually written in Python would know this. Idiot.
I heard that his version as really good data security especially for data you want to keep secret. Just name a data structure "WMD" and it and its content disapears in thin air, never to be found again...
Remember... A boomerang IS NOT the best way to deliver a bomb.
Not sure if anyone else finds this straight-forward, but it is how I would write the function in Scheme.
(define (leap-year? year)
(let ([0-% (lambda (n) (zero? (remainder year n)))])
(or (0-% 400) (and (not (0-% 100)) (0-% 4)))))