Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Game Scripting With Python 186

Posted by ScuttleMonkey from the unsung-hero-of-programming-languages dept.
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."
This discussion has been archived. No new comments can be posted.

Game Scripting With Python More

Game Scripting With Python

Comments Filter:

  • Console Games? (Score:4, Insightful)

    by CDMA_Demo ( 841347 ) on Saturday September 17, 2005 @07:05PM (#13587289) Homepage

    I don't see what is so new about this "news". Console games are designed with the idea in mind that the hardware does not have a full featured OS. We have to do almost everything, from memory management to thread syncronication, and guess what are the "processes" we are working on....? Is this a news story because noone has actually put this concept into words?
    • The 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.

  • Syphilis in 3D? (Score:5, Funny)

    by groovemaneuver ( 539260 ) <(groovemaneuver) (at) (gmail.com)> on Saturday September 17, 2005 @07:09PM (#13587303)
    Ewww!!!! Oh I misread... Whoops...

  • Civilization 4... (Score:5, Interesting)

    by Fortress ( 763470 ) on Saturday September 17, 2005 @07:13PM (#13587317) Homepage
    ..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.
    • [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.

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

    by Anonymous Coward on Saturday September 17, 2005 @07:20PM (#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 (Score:5, Informative)

      by Coryoth ( 254751 ) on Saturday September 17, 2005 @07:52PM (#13587448) Homepage Journal
      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.

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

        • 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

    • Re:Python is nice but consider LUA for game script (Score:5, Interesting)

      by Radius9 ( 588130 ) on Saturday September 17, 2005 @09:38PM (#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.
      • 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//
      • 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 mot

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

  • EVE Online (Score:5, Informative)

    by Dr_Barnowl ( 709838 ) on Saturday September 17, 2005 @07:20PM (#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.
    • 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.

    • 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 (Score:5, Informative)

    by SnprBoB86 ( 576143 ) on Saturday September 17, 2005 @07:27PM (#13587366) Homepage
    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 (Score:2, Informative)

      by Osty ( 16825 )

      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,

      • 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

  • Lua, Books (Score:5, Informative)

    by Noksagt ( 69097 ) on Saturday September 17, 2005 @07:37PM (#13587396) Homepage
    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 (Score:2, Informative)

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

  • Python? For 100s of game entities? Try Mono... (Score:4, Informative)

    by nicholasfrancis ( 915635 ) on Saturday September 17, 2005 @07:42PM (#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.

  • Another one of those weird reads. (Score:3, Funny)

    by Jerk City Troll ( 661616 ) on Saturday September 17, 2005 @07:42PM (#13587419) Homepage

    Did anyone else read that as "Syphilus3D"?

  • Open Games (Score:4, Insightful)

    by Doc Ruby ( 173196 ) on Saturday September 17, 2005 @07:46PM (#13587434) Homepage Journal
    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.
    • Heard of COM?
    • 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.
    • 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

  • Naughty Dog Used Scheme for this (Score:3, Interesting)

    by putko ( 753330 ) on Saturday September 17, 2005 @07:48PM (#13587436) Homepage Journal
    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. (Score:5, Interesting)

    by indy ( 23876 ) on Saturday September 17, 2005 @08:10PM (#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).

  • Oooh! (Score:2, Interesting)

    by keesh ( 202812 )
    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...

    • 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 ?

    • 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
    • Psycho [sourceforge.net] anyone?

  • Python to C++ Automatically (Score:4, Interesting)

    by Anonymous Coward on Saturday September 17, 2005 @08:24PM (#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]

  • Python game programming competition (Score:3, Informative)

    by AMK ( 3114 ) on Saturday September 17, 2005 @08:34PM (#13587557) Homepage
    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... (Score:4, Funny)

    by pixel_bc ( 265009 ) on Saturday September 17, 2005 @08:44PM (#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 (Score:2, Informative)

    by 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.
    • 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/ [codemasters.com]

  • Ogre 3D engine and Python (Score:5, Interesting)

    by gsherman ( 30609 ) on Saturday September 17, 2005 @09:24PM (#13587704) Homepage

    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.

  • 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 (Score:3, Informative)

    by DannyKumamoto ( 4636 ) <{dnk} {at} {prismnet.com}> on Saturday September 17, 2005 @11:13PM (#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....
  • "The Fall" is the one major game I know that was scripted with Python. It was horribly buggy upon release, and AFAIK still is. Especially the scripting was broken for many quests.

    This could have happened with other languages, but using Python did not prevent them from producing crappy code.
  • I mean every game has some built-in scripting language at some level, without it game development would be a much more major pain in the ass. Of course, most of these are not publicly available, yet still, how is it news, that python can be used to develop such a scripting language ? How would it be news if they said almost any other language can be used to build such a scripting language ? Ehh, sunday morning.

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

    by VC ( 89143 ) *
    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.

Slashdot Top Deals

The person who can smile when something goes wrong has thought of someone to blame it on.

Close