Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Game Scripting With Python

ScuttleMonkey posted more than 9 years ago | from the unsung-hero-of-programming-languages dept.

186

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

cancel ×

186 comments

Sorry! There are no comments related to the filter you selected.

FIST SPORT! (0, Offtopic)

ringbarer (545020) | more than 9 years ago | (#13587278)

Check out Zonk's Syphilis Engine [superzooi.com] !

Console Games? (3, Insightful)

CDMA_Demo (841347) | more than 9 years ago | (#13587289)


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? (0)

Anonymous Coward | more than 9 years ago | (#13587315)

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? (0, Troll)

sn0wflake (592745) | more than 9 years ago | (#13587322)

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

Re:Console Games? (0)

Anonymous Coward | more than 9 years ago | (#13587352)

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

Re:Console Games? (5, Funny)

UserGoogol (623581) | more than 9 years ago | (#13587565)

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? (0)

Anonymous Coward | more than 9 years ago | (#13587759)

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? (1)

qbwiz (87077) | more than 9 years ago | (#13587353)

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.

Lisp instead of Python (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13587295)

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 (4, Insightful)

hungrygrue (872970) | more than 9 years ago | (#13587312)

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/ [vim.org]

Re:Lisp instead of Python (0)

Anonymous Coward | more than 9 years ago | (#13587354)

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

CRCulver (715279) | more than 9 years ago | (#13587469)

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

Anonymous Coward | more than 9 years ago | (#13587548)

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 [wikipedia.org] . I'll leave you to it.

Btw, this still doesn't address my main point.

Re:Lisp instead of Python (1)

CRCulver (715279) | more than 9 years ago | (#13587603)

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

Python whitespace indentation (3, Insightful)

baxissimo (135512) | more than 9 years ago | (#13587516)

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 (2, Insightful)

FrostedChaos (231468) | more than 9 years ago | (#13587589)

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

vadim_t (324782) | more than 9 years ago | (#13587748)

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

Anonymous Coward | more than 9 years ago | (#13587758)

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

kraut (2788) | more than 9 years ago | (#13587659)

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

Re:Python whitespace indentation (2, Informative)

d2ksla (89385) | more than 9 years ago | (#13587742)

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 (2, Informative)

John Whitley (6067) | more than 9 years ago | (#13587986)

FWIW, it's also trivial to do the same thing under Eclipse using PyDev [sourceforge.net] . 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 (0, Flamebait)

Lord Ender (156273) | more than 9 years ago | (#13587826)

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:Lisp instead of Python (3, Insightful)

FrostedChaos (231468) | more than 9 years ago | (#13587623)

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 (1, Insightful)

Anonymous Coward | more than 9 years ago | (#13587713)

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

cduffy (652) | more than 9 years ago | (#13587642)

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

Anonymous Coward | more than 9 years ago | (#13587834)

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

Waffle Iron (339739) | more than 9 years ago | (#13587886)

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

tamnir (230394) | more than 9 years ago | (#13587550)

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

Anonymous Coward | more than 9 years ago | (#13587801)

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 (2, Informative)

shobadobs (264600) | more than 9 years ago | (#13587905)

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

Cytlid (95255) | more than 9 years ago | (#13587962)

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

Courageous (228506) | more than 9 years ago | (#13587780)

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 (0, Troll)

Waffle Iron (339739) | more than 9 years ago | (#13587415)

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

putko (753330) | more than 9 years ago | (#13587514)

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

Waffle Iron (339739) | more than 9 years ago | (#13587655)

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

putko (753330) | more than 9 years ago | (#13587816)

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

Anonymous Coward | more than 9 years ago | (#13587601)

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.

Syphilis in 3D? (5, Funny)

groovemaneuver (539260) | more than 9 years ago | (#13587303)

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

Re: Syphilis in 3D? (2, Funny)

Black Parrot (19622) | more than 9 years ago | (#13587320)


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

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

Re: Syphilis in 3D? (2, Funny)

RazorRaiser (895600) | more than 9 years ago | (#13587400)

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

Re:Syphilis in 3D? (0)

Anonymous Coward | more than 9 years ago | (#13587466)

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

Civilization 4... (5, Interesting)

Fortress (763470) | more than 9 years ago | (#13587317)

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

patio11 (857072) | more than 9 years ago | (#13587775)

[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... (4, Informative)

drxray (839725) | more than 9 years ago | (#13587817)

See the Unreal Tournament Community Bonus Pack [unrealtournament.com] , and the SuperStorm [earth2160.com] 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... (1)

norton_I (64015) | more than 9 years ago | (#13587913)

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"

Python is nice but consider LUA for game scripting (5, Insightful)

Anonymous Coward | more than 9 years ago | (#13587339)

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/ [lua.org]

Re:Python is nice but consider LUA for game script (1)

Bob of Dole (453013) | more than 9 years ago | (#13587374)

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

Re:Python is nice but consider LUA for game script (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#13587379)

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.

truth is flamebait, lies are insightful (0)

Anonymous Coward | more than 9 years ago | (#13587693)

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

Re:Python is nice but consider LUA for game script (4, Informative)

Coryoth (254751) | more than 9 years ago | (#13587448)

The point of using Stackless Python [stackless.com] (as opposed to ordinary Python) is that it provides a particularly good system for handling multiple threads and communcation for threads via tasklets [stackless.com] and channels [stackless.com] . 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 [usingcsp.com] . Multithreading is actually easy if you do it right - it's just that most languages don't.

Jedidiah.

Re:Python is nice but consider LUA for game script (0)

Anonymous Coward | more than 9 years ago | (#13587562)

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.

Re:Python is nice but consider LUA for game script (0)

Anonymous Coward | more than 9 years ago | (#13587716)

Multithreading in Lua is easy. Lua provides the coroutine facility. [lua.org]

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.

Re:Python is nice but consider LUA for game script (1)

GileadGreene (539584) | more than 9 years ago | (#13587781)

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.

Dataflow Languages (1)

fossa (212602) | more than 9 years ago | (#13587793)

The channels description made me think of Dataflow languages [wikipedia.org] . I'm not very educated in this area; would you agree that they are very similar, or am I way off here? Thanks.

Re:Python is nice but consider LUA for game script (4, Interesting)

Radius9 (588130) | more than 9 years ago | (#13587741)

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:Python is nice but consider LUA for game script (1)

Courageous (228506) | more than 9 years ago | (#13587788)

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

Re:Python is nice but consider LUA for game script (2, Informative)

chromatic (9471) | more than 9 years ago | (#13587969)

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

Re:Python is nice but consider LUA for game script (0)

Anonymous Coward | more than 9 years ago | (#13587950)

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.

EVE Online (5, Informative)

Dr_Barnowl (709838) | more than 9 years ago | (#13587340)

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

Other games that use Python (1)

The Evil Couch (621105) | more than 9 years ago | (#13587541)

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.

This is not a new idea (4, Informative)

SnprBoB86 (576143) | more than 9 years ago | (#13587366)

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

Anonymous Coward | more than 9 years ago | (#13587497)

: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 (2, Informative)

Osty (16825) | more than 9 years ago | (#13587508)

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 [wikipedia.org] (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 [wikipedia.org] , 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 [wikipedia.org] , which is a popular scripting language used by many other commercial game engines (such as Bioware's Infinity Engine [wikipedia.org] 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 (0)

Anonymous Coward | more than 9 years ago | (#13587954)

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/ [petezah.com]
http://www.petezah.com/projects/digipen/operation- stop-core/ [petezah.com]

Tweak the behavior to your heart's content.

A quibble (1, Informative)

Anonymous Coward | more than 9 years ago | (#13587390)

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.

Lua, Books (4, Informative)

Noksagt (69097) | more than 9 years ago | (#13587396)

It didn't make the front page, but the recent article [slashdot.org] 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 [amazon.com] , 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 [amazon.com] . This book is a wonderful overview.

Not new (2, Informative)

Anonymous Coward | more than 9 years ago | (#13587408)

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 (2, Informative)

HBI (604924) | more than 9 years ago | (#13587871)

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... (4, Informative)

nicholasfrancis (915635) | more than 9 years ago | (#13587417)

As for the language, we used Python in Unity http://www.otee.dk/ [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/ [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.

There's a REASON they're using Stackless (3, Informative)

cduffy (652) | more than 9 years ago | (#13587495)

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.

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

Anonymous Coward | more than 9 years ago | (#13587580)

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

Edward Kmett (123105) | more than 9 years ago | (#13587932)

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. (2, Funny)

Jerk City Troll (661616) | more than 9 years ago | (#13587419)

Did anyone else read that as "Syphilus3D"?

Re:Another one of those weird reads. (0)

Anonymous Coward | more than 9 years ago | (#13587570)

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

J.C.

Open Games (3, Insightful)

Doc Ruby (173196) | more than 9 years ago | (#13587434)

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

Anonymous Coward | more than 9 years ago | (#13587556)

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

shird (566377) | more than 9 years ago | (#13587820)

Heard of COM?

Re:Open Games (1)

LionKimbro (200000) | more than 9 years ago | (#13587909)

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.

Naughty Dog Used Scheme for this (2, Interesting)

putko (753330) | more than 9 years ago | (#13587436)

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.

Not limited to Python. (5, Interesting)

indy (23876) | more than 9 years ago | (#13587486)

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 [tnlgame.net] using this [ds9a.nl] C++ implementation of coroutines. There is also Io [iolanguage.com] , 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. (0)

Anonymous Coward | more than 9 years ago | (#13587617)

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

Re:Not limited to Python. (0)

Anonymous Coward | more than 9 years ago | (#13587626)

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

Re:Not limited to Python. (0)

Anonymous Coward | more than 9 years ago | (#13587688)

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.

Oooh! (2, Interesting)

keesh (202812) | more than 9 years ago | (#13587530)

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

Python to C++ Automatically (4, Interesting)

Anonymous Coward | more than 9 years ago | (#13587531)

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/ [blogspot.com]

http://sourceforge.net/projects/shedskin/ [sourceforge.net]

Either I forgot to do something, or Python is... (0, Troll)

planetoid (719535) | more than 9 years ago | (#13587549)

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.

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

Anonymous Coward | more than 9 years ago | (#13587612)

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

Anonymous Coward | more than 9 years ago | (#13587682)

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

Re:Either I forgot to do something, or Python is.. (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13587712)

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:Either I forgot to do something, or Python is.. (0)

Anonymous Coward | more than 9 years ago | (#13587772)

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:Either I forgot to do something, or Python is.. (1, Informative)

Anonymous Coward | more than 9 years ago | (#13587943)

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:Either I forgot to do something, or Python is.. (0)

Anonymous Coward | more than 9 years ago | (#13587953)

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.

Python game programming competition (2, Informative)

AMK (3114) | more than 9 years ago | (#13587557)

Another game-related Python activity is the PyWeek competition [mechanicalcat.net] , 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.

Erm... (3, Funny)

pixel_bc (265009) | more than 9 years ago | (#13587587)

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 (2, Informative)

Anonymous Coward | more than 9 years ago | (#13587605)

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.

Ogre 3D engine and Python (5, Interesting)

gsherman (30609) | more than 9 years ago | (#13587704)

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 [ogre3d.org] ).

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.

Don't forget that Battlefield 2 uses Python (2, Informative)

fjb4 (176395) | more than 9 years ago | (#13587717)

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

Virtualization and Game as OS (3, Informative)

DannyKumamoto (4636) | more than 9 years ago | (#13587981)

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 [ibm.com] .

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....
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?