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."

Comments

FIST SPORT!

[ringbarer]

Check out Zonk's Syphilis Engine!

Console Games?

[CDMA_Demo]

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?

Re:Console Games?

[Anonymous Coward]

This has nothing to do with how fully featured the underlying operating system is. They're simply saying game systems should be structured in a similar way to operating systems.

Re:Console Games?

[sn0wflake]

It's apparently big news on Slashdot because it's Linux related.

Re:Console Games?

[Anonymous Coward]

As far as I can tell Sylphis is only available for Windows.

Re:Console Games?

[qbwiz]

The point is not that the game engine is a library providing threads, but that the game engine acts almost solely as a library, one which provides lightweight threads to be used by the game objects: tens/hundreds of threads, 1 per object/process, each interacting with the game engine. That's very different from having 10 threads, each in charge of many objects and processes.

Re:Console Games?

[UserGoogol]

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 .

Re:Console Games?

[Anonymous Coward]

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 .

That is just about the funniest comment I have ever seen on /. Ever.

Re:Console Games?

[kiddygrinder]

You're my hero

Re:Console Games?

[EvilAardvark]

I hate to do this to you, but I can do better.

Sylphius uses Python. Monty Python included John Cleese. John Cleese was in The Big Picture with... Kevin Bacon.

Lisp instead of Python

[Anonymous Coward]

The only problem with using Python is how much of a moving target it is. Python is continually vacillating about Lisp thanks to the indecisiveness of Python's benevolent dictator.

Since Python is just a more useless Lisp with less parenthesis anyway, why not use the real thing? They can rewrite the language as they see fit anyway.

P.S. I really enjoy thinking of Python users eating shit on their compiles withe parser trying to determine what mystical combination of spaces and tabs results in an indentation.

Re:Lisp instead of Python

[hungrygrue]

P.S. I really enjoy thinking of Python users eating shit on their compiles withe parser trying to determine what mystical combination of spaces and tabs results in an indentation.

Ignoring the obvious fact that Python is not a compiled language anyway, why would you be mixing tabs and spaces? Maybe you need to find a better text editor if you aren't able to expand tabs. http://www.vim.org/

Re:Lisp instead of Python

[Anonymous Coward]

set nocompatible
set bs=2
syntax enable
set number
filetype on
set autoindent
set softtabstop=4
set laststatus=2
set ruler
set expandtab

I don't have any problems with code that only I read and modify, but what's going to happen when the next fella comes along with notepad and adds some CP/M style newlines and aligns his stuff with eight character tabs, or worse, changes one of my routines with that stuff?

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.''

Re:Lisp instead of Python

[Waffle Iron]

Python is continually vacillating about Lisp thanks to the indecisiveness of Python's benevolent dictator.

Haha. And how many dozens of incompatible dialects of Lisp are out there? How many object models? How many macro systems?

Re:Lisp instead of Python

[CRCulver]

If you're going to be a pedantic ass, then you should mention that there is a process to compile Python to native language

No, the process turns Python code into portable bytecode, not chip-native code. That still doesn't make it a compiled language.

Re:Lisp instead of Python

[putko]

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.

Re:Lisp instead of Python

[Anonymous Coward]

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.

Re:Lisp instead of Python

[tamnir]

Don't feed the trolls, I know, but can't help it now, since I was just looking at some LISP code last night... So, short LISP (Scheme) code sample from Gnucash I was looking at:

;; is leap year?
(define (gnc:leap-year? year)
    (if (= (remainder year 4) 0)
            (if (= (remainder year 100) 0)
                    (if (= (remainder year 400) 0) #t #f)
                    #t)
            #f))

Now here is how I'd write this in Python:

def isLeapYear(year):
        """Return true if 'year' is a lear year, false otherwise."""
        if (year % 400) == 0: return True
        elif (year % 100) == 0: return False
        elif (year % 4) == 0: return True
        else: return False

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...

Re:Lisp instead of Python

[Anonymous Coward]

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.

Re:Lisp instead of Python

[CRCulver]

py2exe keeps the program as bytecode, it just embeds a small-as-possible Python interpreter with the bundle.

Re:Lisp instead of Python

[FrostedChaos]

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.

Re:Lisp instead of Python

[cduffy]

I don't have any problems with code that only I read and modify, but what's going to happen when the next fella comes along with notepad and adds some CP/M style newlines and aligns his stuff with eight character tabs, or worse, changes one of my routines with that stuff?

Well, obviously, you don't accept his patch.

Re:Lisp instead of Python

[Waffle Iron]

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 works great, until you want to use somebody else's library.

Re:Lisp instead of Python

[Anonymous Coward]

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.

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 :). The indentation is the serious matter.

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).

Re:Lisp instead of Python

[Courageous]

Ignoring the obvious fact that Python is not a compiled language anyway...

It's compiled to bytecode, like Java. Just FYI.

C//

Re:Lisp instead of Python

[Anonymous Coward]

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:

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, ... and see how many comparisons each function makes.

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.

Re:Lisp instead of Python

[putko]

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.

Re:Lisp instead of Python

[Anonymous Coward]

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.

Re:Lisp instead of Python

[Waffle Iron]

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.

Likewise, a simple mechanical converter could transform any working Python program into compliance with your particular Python indentation standard. How is it any different?

Re:Lisp instead of Python

[shobadobs]

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.

Re:Lisp instead of Python

[Cytlid]

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. ;)

Re:Lisp instead of Python

[Cytlid]

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 ...

Re:Lisp instead of Python

[imroy]

Yuck. Here's my neater Perl version from the GP's Python:

sub isLeapYear ($) {
my ($year) = @_;

return 1 if ($year % 400 == 0);
return 0 if ($year % 100 == 0);
return 1 if ($year % 4 == 0);
return 0;
}

I like using Perl's inversed "(statement) (condition)" form for simple one-line tests. It helps to make the code more readable. No brackets and all on one line.

Re:Lisp instead of Python

[Anonymous Coward]

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.

Re:Lisp instead of Python

[Waffle Iron]

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))

Re:Lisp instead of Python

[masklinn]

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.

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

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.

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

• It's less readable
• It takes less place

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)

Re:Lisp instead of Python

[masklinn]

If they specify ``Python'' as their language, then they are at Guido's whims as far as changes go

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)

Re:Lisp instead of Python

[some guy on slashdot]

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.

Re:Lisp instead of Python

[klovett]

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)))))

Syphilis in 3D?

[groovemaneuver]

Ewww!!!! Oh I misread... Whoops...

Re: Syphilis in 3D?

[Black Parrot]

> Ewww!!!! Oh I misread... Whoops...

You can tell they're not marketing to us dyslexic types.

Re: Syphilis in 3D?

[RazorRaiser]

poser! if you were lysdexic you'd have spelled it as such

Re:Syphilis in 3D?

[Anonymous Coward]

That's what you get for whipping out that Python at every available opportunity...

Re:Syphilis in 3D?

[jeblucas]

How very sophomoric. At my game engine company, lowbrow humor like this is neither tolerated, nor condoned with tacit laughter. Shame.

Jeb
President
Gon-o-Ria Inc.

Civilization 4...

[Fortress]

..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.

Re:Civilization 4...

[patio11]

[quote]In fact, I'd say that the developers will incorporate user-generated content in the official patch system.[/quote]

Keep dreaming. There isn't a legal department in the country that would sign off on that. Typically, if you send unsolicited ideas to an IP maker they discard them unread just to avoid liability.

Re:Civilization 4...

[drxray]

See the Unreal Tournament Community Bonus Pack, and the SuperStorm fan-made patch for Earth 2160. Both hosted on official download sites. The UT2003 community pack was actually included on the UT2004 DVD.

These are just the two examples I've played today...

Re:Civilization 4...

[norton_I]

The obvious way to solve this is to solicit ideas. i.e., "submit your best player AI or city advisor program and we will publish a collection of them online"

Re:Civilization 4...

[grazzy]

I think we need a new slashdot-tagline.

"In RIAA/MPAA/IP America... "
"... The industry owns YUO!"
"... The mon(k)ey TALKS!"
"... Freedom as owns YUO"!

Re:Civilization 4...

[damiangerous]

There was a boxed Civ II expansion whose included scenarios were almost entirely user submitted.

Re:Civilization 4...

[ldeviator]

Vampire the Masquerade Bloodlines also did this.

Re:Civilization 4...

[snuf23]

Valve highlights user created mods for Half Life directly through Steam. You just click on "browse games" and "third-party games" and you get a list of mods.
Offering the content is perfectly possible legally, they can waive responsibility via a EULA or just offer it as 3rd party content not directly supported by the company.

Python is nice but consider LUA for game scripting

[Anonymous Coward]

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/

EVE Online

[Dr_Barnowl]

... 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.

Re:EVE Online

[zenst]

http://www.eve-online.com/

Re:EVE Online

[Shinobi]

Never mind all the errors Stackless Python has. Many of the client-side issues that EVE has are to be blamed on not only CCP's shoddy coding practices(Run the code through a debugger sometime... I've done it... It's horrible), but Stackless Python itself. Just look in the error log folder and look at all the errors it coughs up hour by hour.

(Don't get me started on their backend design and management....)

This is not a new idea

[SnprBoB86]

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).

Re:This is not a new idea

[Anonymous Coward]

:truth
#zap parent
Hi there. Didn't you know that Epic has been around a lot longer than Unreal? True. In fact, all this 'innovation' has been around since Tim Sweeney created ZZT. ZZT has many micro-threads running in parallel with latent functions, and pretty much everything described in the article. Granted the environment is less expressive and all graphics are ascii. But it is amazing how much you can do with so little.
#end

Re:This is not a new idea

[Osty]

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).

Go back even further than that. The idea of building a game engine that acts as a virtual machine for scripts defining a game is a very old idea. For example, way back in 1987, LucasArts developed SCUMM (Script Creation Utility for Maniac Mansion), which is little more than an engine that runs scripts the define a game. All of LucasArts' adventure games from Maniac Mansion to The Curse of Monkey Island used SCUMM. After that, they built a new engine (GrimE, Grim Edit) that was used in Grim Fandango and Escape from Monkey Island and followed the same ideas they first built in SCUMM. This time they used Lua, which is a popular scripting language used by many other commercial game engines (such as Bioware's Infinity Engine used for the Baldur's Gate games, the Icewind Dale games, and Planescape: Torment).

Unreal's UnrealScript is a very powerful language within the scope of the Unreal engine, but it's certainly not the first implementation of the "game engine as an abstract operating system for scripts" idea. The technology of the scripting language may change, but the core idea is very old (and very good). There's nothing inherently special about using Python as the scripting language for a game, but it's neat that Python is now capable of doing so.

Re:This is not a new idea

[Anonymous Coward]

This article presents the idea relatively well, but this is NOT A NEW IDEA.

Indeed. I implemented Python AI for our last two projects at DigiPen (2003 and 2004 school years). Not a terribly new idea as far as my teams are concerned either.

Mirrored here if anyone is curious.
http://www.petezah.com/projects/digipen/thelema/
http://www.petezah.com/projects/digipen/operation- stop-core/

Tweak the behavior to your heart's content.

Re:Python is nice but consider LUA for game script

[Bob of Dole]

Instead of writing your games in C++, consider GW-Basic!

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

No kidding.

The thing is, Python is so much like a compiled language (ie. extremely verbose and not that helpful) that there is almost no point in using it. There are a ton of better languages out there.

A quibble

[Anonymous Coward]

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.

Re:A quibble

[HarryKal]

Some people will argue with the use of exceptions for handling game logic. But it is about programming style and not because it will make debugging difficult.

With try/except you specify witch exception you are interested and all others will produce the informative error message.

Lua, Books

[Noksagt]

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.

Not new

[Anonymous Coward]

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.

Re:Not new

[HBI]

TOEE from 2003 uses Python scripting.

It was a buggy mess that was only meaningfully amended by a couple years of volunteer work by people outside of Atari/Troika, but the Python scripting was probably a plus in terms of determining the nature of bugs and fixing them.

My beef with the article isn't that it is outdated. It's that the grammar is so horrible. It's not unreadable but it's like reading a bad book report.

Python? For 100s of game entities? Try Mono...

[nicholasfrancis]

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.

Re:Python? For 100s of game entities? Try Mono...

[Anonymous Coward]

Gooball is freakin awsome. Still cant get past that level with the bowls ): i bought the game about 6 months ago, havent played it much cause i'm stuck, wish there was a way past that level.

Game runs good on my 867MHz power book.

Re:Python? For 100s of game entities? Try Mono...

[Edward Kmett]

Stackless python is a completely different animal. Normal python is just about useless for embedding when you have large numbers of agents and need real time performance. Stackless flits between agents with very little overhead thanks to all the continuation stuff.

Another one of those weird reads.

[Jerk City Troll]

Did anyone else read that as "Syphilus3D"?

Re:Another one of those weird reads.

[Anonymous Coward]

Yeah, I did. But I'm just an old perverted Jewish carpenter, so your mileage may vary.

J.C.

Open Games

[Doc Ruby]

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.

Re:Open Games

[Anonymous Coward]

Oh thank goodness object-oriented programming has finally given us the miracle of code reuse! How did I manage all these years...

Seriously, it's not the OO part of it, it's the fact that there's an API at all, and that it's stable and published.

Re:Open Games

[shird]

Heard of COM?

Re:Open Games

[LionKimbro]

Absofrigginlutely correct.

And, yes, we do need COM for Linux, but what the parent said is much more than just COM; it's also a set of introspection facilities on top of it, and support tools, and, ... ...but it's absolutely the way we need to go.

And when we do, exactly what the parent said will happen: Programming will lift out of the programmer ghetto.

Re:Open Games

[glasse]

My bet for this is DCOP.

Ethan

Re:Open Games

[LionKimbro]

As a GNOME guy, I can tell you: I totally savor DCOP. Bonobo has been a disaster.

That said, what the parent was talking about was a bit more.

We need more than just an IPC system between components; We need an infrastructure on top of that IPC system that allows for:

• Automatic retrieval of documentation.
• Automatic discovery of relevant APIs.
• The ability to select a menu item, and ask the system: "How do I automate that?"
• The ability to record, manipulate, parameterize, and more deeply edit sequences of manipulations.

That is, we want to make a software component as transparent as possible, so that a programmer with little knowledge can start automating any app within seconds, and feel confident that all the know-how and ability to connect easily will be there.

DCOP is just a (good) mechanism for communicating with components. Okay, the components can talk with each other. But what words are they speaking to each other? We need a sophisticated language on top of that communications channel.

Re:Open Games

[Doc Ruby]

We need that object messaging infrastructure (API UIs) to be part of the OS. Not just the desktop, like GNOME or KDE. If that were good enough, we'd already have X events. To be extreme, I prefer a microkernel which merely ensures secure messaging between hardware and objects, including the task scheduler. But then, I also want it to run on a CPU with a 16MB register cache, and FPGA interconnects between devices (bypassing the ALU/CLU once configured/init'ed). But just asking for "Linux DCOM" seems ambitious enough already.

Re:Open Games

[Doc Ruby]

Yeah, and I like AppleEvents, too. And I liked CORBA, too. Linux isn't yet saddled with the wrong object model that we're locked into, with all the baggage of those other OS object models. So I want the right thing, like (D)COM and those others. Learned from their mistakes. And right away. Before someone sticks us with the wrong model, and we're stuck with it.

Re:Open Games

[Doc Ruby]

If you're just finding out about OOP, I can take your statement as naive, instead of sarcastic. But of course I know it's sarcastic, even though I didn't say that OOP was just arriving. To the contrary, I'm pointing out that we aren't using it enough. FWIW, OOP is the way to manage both reusable interfaces by users and reusable code by programmers. Look into it sometime - you'll like it.

Naughty Dog Used Scheme for this

[putko]

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.

Re:Python is nice but consider LUA for game script

[Coryoth]

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.

Not limited to Python.

[indy]

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:

void Airplane::flyLooping() {
    levelOut();
    centerStick();
    pullElevator();
    while(!flyingUpsideDown())
        yield();
    while(flyingUpsideDown())
        yield();
    centerStick();
    levelOut();
}

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).

Re:Not limited to Python.

[Anonymous Coward]

is that joke code?
since you can get rid of the while loops btw

Re:Not limited to Python.

[Anonymous Coward]

Umm.. calling functions within a function is hardly a new or revolutionary programming concept..

Re:Not limited to Python.

[Anonymous Coward]

Umm.. calling functions within a function is hardly a new or revolutionary programming concept.

Ummm... first go learn an inkling of what a *coroutine* is, then try your post again.

Re:Not limited to Python.

[Anonymous Coward]

You can use generators in python to implement coroutines.

Re:Not limited to Python.

[indy]

The while loops is where the interesting thing happens. They are like "wait until the looping is completed". As the whole maneuvre takes more than one iteration of the main loop, you need coroutines to write it that way. Instead of keeping your state in a state machine (with states LEVELING_OUT_BEFORE_LOOPING, FIRST_HALF_OF_LOOPING, SECOND_HALF_OF_LOOPING, LEVELING_OUT_AFTER_LOOPING) you keep the state in the execution context of a coroutine, preserving the expressiveness of the imperative programming style.

There's a REASON they're using Stackless

[cduffy]

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.

Python whitespace indentation

[baxissimo]

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.

Re:Python whitespace indentation

[FrostedChaos]

I think you are confused.

Auto-indenters are just tool for re-arranging indentation based on brace structure.
If there is no brace structure, then there is no need for auto-indenters.

The fact that the same information is being represented in two ways-- as the brace structure, and as the indentation-- is the problem that auto-indenters are designed to solve. This problem does not exist in python.

Re:Python whitespace indentation

[kraut]

Well, you're using Emcas. That's the problem ;)

Re:Python whitespace indentation

[d2ksla]

I use Emacs for editing both C and Python. With Python, it is just a matter of marking the block you'd like to indent/dedent (CTRL-space at the beginning of the block, and ALT-w at the end), and then use "CTRL >" or "CTRL <" to indent/dedent the whole block. This saves a few keypresses compared to C, where the extra braces have to be inserted/removed.

Re:Python whitespace indentation

[vadim_t]

I think what he means is:

Let's say in C you have this:

while(foo) {
      do_stuff();
}

now it turns out that you want this to be optional. No problem:

if( enable_do_stuff ) {
while(foo) {
      do_stuff();
}
}

Now it looks a bit ugly, but no problem, hit a button and it's automatically indented. But since python has no braces, you need to do the indentation manually.

There's a potential bug there as well, in that you need to make sure that you correct the indentation correctly, or it doesn't work right, while in C if you opened a brace the compiler will tell you if you didn't close it.

Re:Python whitespace indentation

[Anonymous Coward]

Exactly. If you're editing in IDLE, the included Python IDE, all you do to change an indent level is a block select followed by Ctrl+[ or Ctrl+]; this is not hard even for a very complicated nesting that you want refactored. The programmer is held responsible, of course, for knowing where he wants his indents to go; it's better than braces in my opinion since no counting or other tricks are needed. It's a visual approach to structure.

Re:Python whitespace indentation

[Lord Ender]

If posts that complain about Python's indentation syntax are ever moderated as anything but "Redundant," the moderator in question should be shot. Obviously, huge numbers of developers and businesses (like Google and Pixar) don't have problems with it. But there are some people who just plain don't like that syntax. That discussion is decades old. REDUNDANT!

Re:Python whitespace indentation

[John Whitley]

FWIW, it's also trivial to do the same thing under Eclipse using PyDev. Mark a block of text, then hit tab or shift-tab to indent/unindent. If you're an Emacs user, turn on Eclipse's built-in Emacs keybinding set and it's home away from home...

Re:Python whitespace indentation

[gomoX]

Any text editor with a featureset larger than notepad.exe's can indent a selected block of code. You just have to pay attention to this with python, just like you pay attention to braces in C.

I do agree on the potential indentation mistakes. Still, unless you have a badly b0rked text editor (which, if you are a programmer, is a no-no) it's hard to have a problem with this.

Re:Python whitespace indentation

[baxissimo]

Sigh.

Pardon me, your exhalted highness, Lord Ender. I too have seen dozens of rants about whitespace, and I agree with you that mostly they are pointless. I find most of the complaints I read about the whitespace in Python to be pretty silly, the answer generally being "well duh, get a better editor". But I've not seen anyone mention the issue I raised above, which isn't solved so easily just by getting a better editor. Basically in a nutshell you could just phrase it as auto-indent not working so well.

vadim_t pretty much described the type of situation I'm talking about. Another example is when you've got an existing block of code and you paste in a big chunk from somewhere else that was at a different indentation level, it's a bit annoying to get it lined up. In a curly-brace language I just sloppily select the whole area plus a little bit extra perhaps on either end, and hit "reindent". But in Python I find I have to be very careful to select just the right lines, and then indent the block to the right level using block indent commands like "indent-region", rather than the catch-all "reindent-region". So it just means that with Python I have to stay on my toes and know what the right indent level is. That's all.

And it wasn't intended to be a troll. If there's some way make it work nicely in emacs that would be great to know. But I'm afraid indent and unindent block commands that make me pay attention to the indent level aren't as easy as an oblivious "reindent-region".

I'm not saying that it's a showstopper. Far from it. I still continue happily to use Python. Python is great. I just think that that's one genuine annoyance that you can't get around when using whitespace to indicate structure.

Oh, bother. Why do I even try. And I was doing so well for a while there just ignoring Slashdot. My apologies for posting an off-topic comment. But redundant and troll, I think not.

Re:Python whitespace indentation

[cheesybagel]

Another problem is cut and paste. It is quite common to copy a block of code from a section to another. If you do this in Python, you usually need to re-indent by hand. If you copy it from something someone posted on IRC, then you are SOL.

Re:Python whitespace indentation

[Anonymous Coward]

Yes! Someone else that actually gets it. Languages that are overly whitespace sensitive are very difficult to use in shared environments because you can't just "tell" someone a code snippet. Instead, you have to send a complete file and hope that the transport medium didn't garble your whitespace. I do "AI" scripting for a mud. When someone has a coding question, it's very common for me to write some code, test it on the commandline, and then tell it to the person (all in a single line). Helping people wouldn't be nearly as simple if we used a language that uses whitespace for block structure.

I also wholeheartedly agree with you about moving code between levels. Yes, in the real world people actually do refactor code. And that usually means grabbing a block of code and moving it somewhere else at a different indentation level. When you're using a language with curlybrace block delimiters, you can just reindent and you're good to go.

Re:Python whitespace indentation

[grumbel]

### The fact that the same information is being represented in two ways-- as the brace structure, and as the indentation-- is the problem that auto-indenters are designed to solve. This problem does not exist in python.

True, that problem doesn't exist in Python, the problem that exist in Python however is *FAR* worse. While code that gets crudly copy&pasted into C might not look pretty, its easily fixed with a single button press, code that gets crudly copied in Python actually does break and does the *wrong* thing and one has to manually fix it and one has to notice it in the first place.

I have really done little in programming that is more painfull then refactoring in Python, since one constantly breaks code all over the place, which in other languages simply doesn't happen.

The throuble is that Python represents its structure in form that is constantly broken by routine operations (copy&paste, search&replace, ...) in a text editors, none-whitespace language on the other side have a structure that is extremly robust against those same operation and basically impossible to break.

Re:Python whitespace indentation

[grumbel]

### Any text editor with a featureset larger than notepad.exe's can indent a selected block of code.

Yes, and those editors also have auto-indent, so why does Python force one to those non-automateable indentions in the first place?

### You just have to pay attention to this with python, just like you pay attention to braces in C.

One doesn't have to pay attention to braces, since they don't break with copy&paste.

Re:Python whitespace indentation

[gomoX]

1) Auto-indent works fine with Python, as long it's the while-you-code type. Any nice indenter should check for existing indents and respect whatever they used (spaces or tabs), or let you specify it.

No one is forcing anything on you. I think the fact that you have to put some attention to what you code is actually a feature, not a bug.

Either way, a Python-aware editor can do the tab/space conversion for you (and most of them do).

2) I don't know about you but if i'm going to be copying and pasting large nested blocks of code that can "break", I might as well use PHP instead.

Just give Python a try and see by yourself if the benefits outweigh (or not) this "downside".

Re:Python whitespace indentation

[grumbel]

### No one is forcing anything on you. I think the fact that you have to put some attention to what you code is actually a feature, not a bug.

Of course Python is forcing me todo the indention, without indention a Python programm simply can't work, a C programm however can. Anyway, the point is that restructuring a Python programm is made *A LOT* harder by the fact that the structure is lost on every copy&paste operation that goes into a different block level, any language that has explicit begin/end block marker has absolutly zero problems with it.

### Just give Python a try and see by yourself if the benefits outweigh (or not) this "downside".

Thanks, but I already moved to Ruby. Python is a language that looks pretty when not looking close at it, but I found working with it extremly annoying, since far to often it made the job harder not easier.

Oooh!

[keesh]

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...

Re:Oooh!

[ultranova]

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?

Freedom Force used Python and ran just fine on my gigaherts Duron sneeze pump.

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...

What is so fucked up about it ?

Re:Oooh!

[icepick72]

Larry Wall ... is that you?

Re:Oooh!

[Anonymous Coward]

In reply to the other replies to the parent: I think he's talking about the fact that classes are implemented with hash tables. If you make a method call, the runtime has to do a hash lookup before it can actually dispatch the call. (If you thought it was slow to call a C++'s virtual member function, wait 'til you try Python. You won't ever call C++ slow again.)

A "more sensible" implementation would involve using type declaration/inference to allow compile time resolution of member functions. Even if it only managed to resolve a pointer to a pointer, it would still be at least several times faster. Unfortunately, that would defeat one of python's major selling points: dynamic classes. Thus, it's not really such a sensible option.

So in conclusion I can't really suggest a solution, but I thought I'd at least try to explain the problem.

Re:Oooh!

[Forkenhoppen]

Psycho anyone?

Python to C++ Automatically

[Anonymous Coward]

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/

Re:Python to C++ Automatically

[Chandon Seldon]

Amazing. They've invented the compiler.

Other games that use Python

[The Evil Couch]

Vampire the Masquerade: Bloodlines
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.

Re:Other games that use Python

[NuShrike]

Toontown Online uses plain Python. http://www.toontownonline.com/ (IE only)

It uses the open-source multi-platform Panda3D http://panda3d.org/ engine.

And the SourceForge http://sourceforge.net/projects/panda3d/ link, the Helix community https://panda3d.helixcommunity.org/, etc.

Works pretty well, 10K+ players.

Re:Other games that use Python

[kdart]

A bit off topic, but it is interesting how they use open source to implement their service, yet I get the following when I access the web site:

This browser is not supported by Disney's Toontown Online.

Disney's Toontown Online requires Microsoft Internet Explorer version 5 or higher, running on a Windows PC.

Things like this really annoy me.

Either I forgot to do something, or Python is...

[planetoid]

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.

Python game programming competition

[AMK]

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.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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.

Erm...

[pixel_bc]

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.

Python Already in Use for Commercial Games

[Anonymous Coward]

There are many, many games using python for scripting. Battlefield 2 being the most recent I've noticed.

Search your game folders for .py files, you may be surprised.

Re:Python Already in Use for Commercial Games

[rg3]

The oldest one I remember was Severance: Blade of Darkness. It ran perfectly in a P3 500. Released in 2001. It also featured some really revolutionary graphics and other technologies. For example, real-time lights like in Doom3 except that not so-well done and with more restrictions; and also a physics engine. Sorry for being a little off-topic here, but that game impressed me when it was released.

http://www.codemasters.com/severance/eng/

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

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.

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

What??? os is a standard module. You must have spilt coffee on your installation.

truth is flamebait, lies are insightful

[Anonymous Coward]

Heh, going coward was a wise decision for you - you dared to criticize one of the sheep god's favorites.

Ogre 3D engine and Python

[gsherman]

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.

Re:Ogre 3D engine and Python

[00lmz]

Squeak may not have Ogre, but it has something called Alice which is an "interactive world-building and scripting environment" (that's what the page says...).

I recall it was included in recent Squeak releases which I downloaded. The demo was a bunny or something and you moved it using syntax like this (from here):

bunny move: forward
bunny move: forward distance: 2
bunny move: forward distance: 1 duration: 4
bunny move: forward distance: 1 duration: 2 asSeenBy: camera

bunny moveTo: { 0. 1. 0} duration: 2
bunny moveTo: {0. 0. 1} speed: 4
bunny moveTo: {asIs. 0. asIs}

bunny head pointAt: camera bunny head pointAt: camera duration: eachFrame

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

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.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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.

Don't forget that Battlefield 2 uses Python

[fjb4]

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.)

Re:Python is nice but consider LUA for game script

[Radius9]

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.

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

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

Re:Python is nice but consider LUA for game script

[GileadGreene]

Multithreading in Lua is easy. Lua provides the coroutine facility.

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.

Re:Python is nice but consider LUA for game script

[Courageous]

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//

Dataflow Languages

[fossa]

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.

Re:Dataflow Languages

[GileadGreene]

There is some similarity, but perhaps not as much as you think. Dataflow programs are essentially composed of stateless filters which accept inputs and transform them into outputs. CSP-like languages, such as Stackless, implement concurrent processes that can retain state, and exhibit reactive behavior (i.e. an "actors" model of computation rather than a "filters" model).

Note that it is possible to implement a state-free, dataflow-style program using a CSP-like language. But the stateful style is much more common (and has obvious relevance to game scripting).

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

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. ;)

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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.

Re:Either I forgot to do something, or Python is..

[Anonymous Coward]

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.

Re:Python is nice but consider LUA for game script

[chromatic]

You know, tools such as StackGuard, ProPolice, Valgrind, Splint...

Virtualization and Game as OS

[DannyKumamoto]

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....

Blame Python?

[Nasarius]

Sounds like your distro is broken if it's not automatically grabbing the dependencies.

Re:Either I forgot to do something, or Python is..

[planetoid]

Hmm, I figured it out, I think; there is a PYTHONPATH environment variable I should have set to /usr/lib/python2.4.

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 /usr/lib/python2.4 has fixed this.

Now if I can remember the name of that music tracker I wanted to try a week ago...

Re:Python is nice but consider LUA for game script

[njyoder]

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?

just a nitpick to counter...

[nobodyman]

Never messed with Lua but if thats all a coroutine does then your comparison is absolutely correct. However, after reading the article it kind of sounds like the threading model of Stackless Python shares more with a Lua coroutine than with threading as how we think about it in the OS world. From the article:

The only solution is non-preemptive multithreading. This necessity also solves many synchronization problems. A non-preemptive environment rarely needs locks and can be deterministic.

Which sounds to me like thread2 doesn't start until thread1 completes execution of a routine (or explicitly calls sleep() ).

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.

Re:just a nitpick to counter...

[GileadGreene]

Well, Stackless itself implements "tasklets" (lightweight threads) using a round-robin scheduler (which does not schedule tasks that are blocked on channel communications) - see here for more. This approach was apparently heavily influenced by things like CSP and occam.

I have to admit that I'm not clear on what the original article means when they talk about using non-preemptive multithreading (do they mean somehow overriding the Stackless tasklet scheduler?). They seem to be worried about the need for locks on shared-state variables. However, the correct approach to building a Stackless-based system would probably be to follow the CSP paradigm of avoiding shared-state completely - such systems are lock-free and can be completely deterministic. But perhaps I am completely misinterpreting what they are trying to get at.

Re:just a nitpick to counter...

[Anonymous Coward]

When dealing with UI not having true pre-emptive threading is a PIA.

Take something like the ToEE UI code. If you ever played it you know it's slow as hell. That is because it has an interactive cursor which shows what the effect will be of clicking on a certain spot, this determination includes a pathing calculation ... this pathing calculation takes significant amounts of CPU, each time you move the cursor this calculation determines the time between frame updates.

Now this is just plain bad coding however you look at it, having pre-emptive multithreading makes it much easier to solve though. Without it you have to do these kinds of calculations with bad old cooperative multitasking code ... ie. structure your code such that it hops to a scheduler at relatively even intervals.

Id rather be able to just stop threads of computation at will, and have them be able to interrupt eachother at any time (outside of locks) such that time budgets are easy to assign.

I can trump both of you whippersnappers!

[nobodyman]

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?

Re:I can trump both of you whippersnappers!

[Osty]

The enemy ships in Galaga were controlled via scripts. Take THAT, you punk kids!

Oh yeah? Well Zork's Z-machine, designed to run "Zork Implementation Language" code, was written in 1979, a full two years before Galaga shipped in 1981! So there!

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.

Maybe, but then again languages like Lua (which could be considered "general purpose") and Lisp (remember Abuse?) have long been used for games. Nothing new here.

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.

Only if the pool of modders overlaps with the pool of people who already know the language. Then again, games like Quake 2 have used well-known languages like C (in the form of compiled DLLs). You still have to learn how to interface with the game engine.

Isn't the scripting of Quake3 done with interpreted C?

I thought Q3 used normal C? Or was that Quake 2, and Quake 3 returned to the QuakeC idea from the original Quake? Meh. If it was QuakeC, it wasn't exactly interpreted C but a C-like language designed explicitly for use with Quake (lots of stuff for working with "entities" and "cvars", IIRC).

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?

You forget, this is Slashdot. We nitpick things to pieces, especially when the article claims something that's easily refuted (that game engines haven't been viewed as an "operating system", providing the basic functionality for a game and letting scripting do the rest). Neat idea, but it's already well-known and done in many areas. Maybe not so much in the FPS realm (though the OP's Unreal argument refutes that), but certainly in other genres, with adventure games being some of the best examples. That's probably because the bulk of the work in an adventure game is writing the story, providing the art, and building interesting puzzles. The game engine itself doesn't need to be very complex at all, so it's a prime candidate for abstraction into a virtual machine so you can make a small investment up front and reap the benefits on multiple games (see my SCUMM example). Comparatively, FPS games tend to be in a technological arms race, rewriting engines every couple of years, trying for that ever-elusive "photo-realistic" end point. Developers like id like to throw everything out and start over fresh each time, even to the point of changing how modders interact with the system (Doom wads to QuakeC to DLLs to whatever Q3a did). In that kind of environment, the rest is secondary (*cough*Doom 3*cough*), and so it's no wonder that not a lot of thought is put into making the engine into a sort of virtual machine for game script. Unreal is the lone standout here.

If Stackless Python can make a dent, more power to it. Ultimately, the ideas are not specific to Python or any other language. The only thing it brings is a slight advantage in familiarity. And that's very slight. I hate to keep going back to UnrealScript, but it's very C/C++/Java-ish, such that the syntax was never the real bottleneck. The biggest hurdle is learning how to interact with the system, and knowledge of the general-purpose language doesn't get you nearer to that.

Buddy.

[headkase]

rofl.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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.

Re:A gigantic quibble

[midnighttoadstool]

I think this error is the fault of the manuals. The docs for exception usage that I have seen have tended to show examples of inappropriate exception usage. Real example (in Borland's Object Pascal language guide, modified to pseudo-code) :

a=1
b=0
try
___return a/b
except
___puts 'divide by zero'
end
return -1; //indicating an error

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, .

Re:Python is nice but consider LUA for game script

[planetoid]

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.

Re:Python is nice but consider LUA for game script

[deaddrunk]

Dubya has a BASIC? I'd hate to see the syntax for that.

The Fall

[jeti]

"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.

Re:The Fall

[trouser]

my powers of coding are unstoppable

Python 2.3.5 (#2, May 4 2005, 08:51:39)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> pront "Hello World"
  File "<stdin>", line 1
    pront "Hello World"
                      ^
SyntaxError: invalid syntax

so this is new now

[l3v1]

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.

Re:so this is new now

[ctid]

You have to read the article to fully understand what is different about this guy's approach, but you can get a hint just from reading the summary:

It talks about how game engines should be structured as operating systems with actors being the processes.

Eve Online and BF2

[VC]

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.

Re:Python is nice but consider LUA for game script

[m50d]

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.

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++.

Look at DCOP

[m50d]

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.

Re:Look at DCOP

[Doc Ruby]

I looked at DCOP, and I liked it. I use GNOME, and I want one OS object model (not per-desktop-system), like the DCOM other replies in this subthread have mentioned. What are they replacing DCOP with?

Re:Look at DCOP

[m50d]

Anything can use DCOP, it's not tied to KDE or Qt, and works on multiple OSes. It's being replaced with DBUS, a freedesktop.org standard, which should improve interoperability on linux, but since gnome applications don't seem to be in a hurry to adopt it it looks like it might just be a lot of work to replace one standard not used outside kde with another, and the only reasons DCOP didn't become the freedesktop.org standard seem to be political. (Is it me or does freedesktop.org always seem to standardise on the gnome way? Maybe they've just seen that KDE developers are much more flexible)

Re:Look at DCOP

[Doc Ruby]

If DCOP is that flexible/usable, won't wrapping it in DBUS be fairly easy, preserve its features, and allow legacy DCOP objects to run in an OS DBUS wrapper?

Re:Look at DCOP

[m50d]

If DCOP is that flexible/usable, won't wrapping it in DBUS be fairly easy, preserve its features, and allow legacy DCOP objects to run in an OS DBUS wrapper?

It's a two-way street. You need DBUS to be equally featureful, and you need to be able to have DCOP calls translate properly into DBUS messages as well as the other way. I don't know the details, but there have been difficulties, and it does look to be a lot of work, and I think part of it's simply because they use different models of how things work.

How about TCL ?

[zhenga]

I see LUA and Python mentioned, but has anyone tried TCL for game scripting?

Re:Either I forgot to do something, or Python is..

[m50d]

Either I forgot to do something on my system, or Python is, in my experience, unreliable at best.

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.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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.

Obligatory Snake Joke

[Anonymous Coward]

Somebody has to put a joke involving snake in here, after all, python is a snake...

Re:Python is nice but consider LUA for game script

[Eukariote]

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.

Re:Python is nice but consider LUA for game script

[njyoder]

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.

Re:Python is nice but consider LUA for game script

[njyoder]

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.

Re:Python is nice but consider LUA for game script

[Courageous]

Ha. You're being funny.

C//

Re:Python is nice but consider LUA for game script

[0xygen]

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.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

But, after seeing Stackless Python in action, I'm less than impressed. It's a pile of steaming bullshit.

Sure it does...

[Millennium]

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.

Re:Either I forgot to do something, or Python is..

[ultranova]

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.

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 ?

Actually, Naughty Dog Used Common Lisp

[alispguru]

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.

in other news

[namekuseijin]

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.

Fucked up hash table implementation?

[hsoft]

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.

Re:Python is nice but consider LUA for game script

[Radius9]

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?".

Re:Python is nice but consider LUA for game script

[obarthelemy]

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.

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

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?

Re:Python is nice but consider LUA for game script

[Anonymous Coward]

If you don't like the moderation, go elsewhere. Don't let the door hit you on the ass on the way out.

Re:Python is nice but consider LUA for game script

[m50d]

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?".

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.

Re:Python is nice but consider LUA for game script

[Nosferax]

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...