Python...

[Dom]

We are considering using a scripting language for our next project, and having heard 'Python' being bandied around, I thought it would be wise to see if this can save us time. So:

1) Is it easy to use?
2) How easy is it to integrate into a C++ game? Are there free interpreters available that can be linked into our game?
3) if not, is the syntax simple enough to write your own interpreter?
4) Is it easier to just roll your own script engine?
5) If you have used it in a game, would you do it again?

Thanks in advance,

[Nemesis]

1. Can't say. but I've mostly looked into Lua and seemed to have developed a narrow-minded preference for it :) Also, AFAIK lua is a functional language while Python supports object orientation.

2. AFAIK Python requires the inclusion of a DLL and can be used freely even in a commercial product.. but I'm not sure of the latter.. why not check the website? Lua (there I go again) can be either dynamically linked (DLL) or statically linked.. i.e. no extra DLL to package with the download, but your binary will be larger.

3. That's practically equivalent to point 4.

4. Rolling your own script engine vs. using an established library is like building your own graphics API versus using OpenGL or DirectX. If you get a kick out of doing techie things, have time (and money in a sense) to spare and have or are willing to learn compiler theory and are generally a masochist then go for it. If this does not deter you, get Game Scripting Mastery by Alex Varanese. I found this a very insightful book with a sample game using scripting! The book guides you into building your own scipting engine and compiler (virtual c-like language + virtual assembler + embeddable virtual machine) and you can actually use the finished code provided on the accompanying CD. The bottom line is that avoid re-inventing the wheel unless it is a very special kind of wheel that nobody has made already.

5. Never did, but working on my current project has made me appreciate the advantages of in-game scripting. I've settled for the next best thing - isolate scipted behaviour as native code in separate modules. For a smaller project such as a puzzler or a simple platformer I might not do it.. for anything larger.. you bet!

[ggambett]

1) Extremely
2) Very; yes
3) N/A
4) Probably not, but a popular alternative is LUA, and apparently it's easier to embed
5) Haven't used it, I'd probably use LUA. I do use Python for a lot of stuff (build scripts mainly) and I love it.

[Coyote]

1) Is it easy to use?
Brilliantly. It's easy and EXTREMELY powerful. I'm not using Python directly in my game, but I'm using it in a lot of tools, and on the website.

2) How easy is it to integrate into a C++ game? Are there free interpreters available that can be linked into our game?
Yes. Full open-source, extremely generous license. And tutorials. And LOTS and LOTS of community support.

3) if not, is the syntax simple enough to write your own interpreter?
No need. And while the syntax is fairly simple, the language is advanced and feature-rich enough that you really wouldn't want to do this.

4) Is it easier to just roll your own script engine?
See #3. No need, and it's too feature-rich now to even imagine doing it.


5) If you have used it in a game, would you do it again?
I have only used it in support of my game (server-side programming, and tools). I can't BELIEVE how easy it was to make some things happen. Like an on-line matchmaking service for a multiplayer game... it took about 100 lines of Python code.

Python will add a few megs of overhead to your download. And I had some problems with a recent Python build mixed with PyGame (an SDL implementation for Python). It's not great for speed-intensive work (rendering, collision detection, AI pathfinding, etc.). But it's great for a lot of what I call "butt-in-chair" work, which typically represents at least 50% of game development anyway (scripting, saving / loading games, web connectivity, string manipulation / parsing, etc.)

[Dan MacDonald]

I think LUA adds 70kb to your release executable size with no external dll, it is DESIGNED to be embedded where as Python tends to work best as the primary language with C++ modules plugged in where you need performance. It is possible to "embed" python but not as trivial as lua. With pythons object oriented features, there's also a memory impact. Each object incurs memory overhead cost to manage it's object oriented features.

One of the cool features I like about lua is that you can set your breakpoint in one of your functions, then call that function from a lua script, the minute the script calls that function execution will stop in the debugger at that breakpoint.

For me I had no scripting language knowledge, I was able to download lua, build it , and put a simple scripted trigger system in my game in about 4 hours. I can't say that I've ever looked back since.

[Diodor Bitan]

Original post by Dan MacDonald
One of the cool features I like about lua is that you can set your breakpoint in one of your functions, then call that function from a lua script, the minute the script calls that function execution will stop in the debugger at that breakpoint.

And if that function activates a C hook function that gets called once per lua line, and you add a breakpoint to the hook function, you can actually step through the lua code. I suppose it should be easy to make a more advanced hook function, that displays a dialogue box with the current lua code line, the values of the local variables, and also has a console to allow executing lua code (for instance to display the value of global variables).

Me, I've been getting just fine with debugging within an interactive in-game console. Write a function, reload file, test it in the console, repeat :) REPL languages rock.

[Dom]

Thanks for the feedback!
I think Ill have to take a ganders at Lua (70k overhead seems reasonable, several Megs doesn't)
Thanks again :D

[Kai Backman]

If you use C++ you might be interested in LuaPlus which is a slight branch from the official Lua 5 (they merge with the main branch at every big release). It is specifically designed to be more easily embedded into C++ code. I tried most other wrappers (tolua, luabind, the raw C interface) and found LuaPlus the easiest to use. It also features a remote debugger interface and a debugger to go with that.

www.luaplus.org

[princec]

...and also, of course, LuaJava (http://www.tecgraf.puc-rio.br/~cassino/luajava/) :) (Thought Dom might be interested in that one)

Cas :)

[Larry Hastings]

I plan on using Python as the scripting language for my next engine. Python is a terrific language, very pleasant to program in. It's a breath of fresh air.

Here are some notes I've collected over time.

Python has an MIT-ish license. IANAL, but my reading says you don't even need to mention it in your documentation, simply leaving their copyright string in a binary somewhere should be sufficient.

There are some neat integration tools for Python. For instance, SWIG (www.swig.org) will actually read your .h files directly and generate glue code automatically. There are lots of editors that do Python syntax highlighting (I'm using CodeWright).

I pushed and crushed and mangled the Python interpreter using ZIP and 7Zip. (I also experimented with .tar.gz, and .tar.bz2, but they were actually larger than 7Zip, so I gave up on 'em.) An absolute bare-bones Python interpreter with no libraries (just python23.dll and PyWinTypes.dll) ZIPs to 487k, and 7Zips to 403k. Including all the Python libraries balloons it up to 1371k for ZIP and 1032k for 7Zip... but that includes things like a simple web server, several kinds of internet mail support, support for the Gopher protocol... lots of stuff you won't need. A medium-sized distribution was 802k as ZIP and 633k in 7Zip.

I haven't spent much time looking at Lua; it looked, well, adequate. But Python looks dreamy! *contented girlish sigh* For instance, Python has lovely preprocessing; not only do scripts "execute" when they're included, but you can crack open the Python interpreter and poke around it from the inside while it's running (like Java "reflection"). I don't know about you, but I like a good preprocessor.

In the final analysis, I predict Python support will add less than 550k to my installer. That's markedly more than Lua, which ZIPs to about 45k. If it's size uber alles for you, then Lua is obviously a better choice. But, if you can possibly afford the extra size, I exhort! you to look seriously into Python.

[mathgenius]

If it's size uber alles for you, then Lua is obviously a better choice. But, if you can possibly afford the extra size, I exhort! you to look seriously into Python.

Right on!! My game is not just scripted with python... it is entirely python :D. I am actually looking forward to including such web services as automatic updates, high scores etc. These things will only take a few lines of python code :p.

Simon.

[Bluecat]

Larry,

you don't need to manually remove any of the libraries. There are a number of applications, including Py2exe that uses Disutils to create an exe version of your python game. These only include the files that are needed.

[Larry Hastings]

Larry,

you don't need to manually remove any of the libraries. There are a number of applications, including Py2exe that uses Disutils to create an exe version of your python game. These only include the files that are needed.Sure, but AFAIK those are for pure Python projects. I doubt those work if I was using Python as an extension language to a non-Python .exe?

Anyway, it's no big deal. My plan, which I just realized is what I should do, is to have a directory just for Python core libraries I ship with my game, and point the Python interpreter at it. I start out with it empty, I write my Python code as normal, and every time I add an import from the Python library I copy that .py (or .pyc) in. That wouldn't detect files I stopped using, though... guess if I wanted to be super-slick I'd write a Python script to grep for "import" statements and figure out which ones aren't used. Anyway, it's all a solvable problem ;)

[Bluecat]

Sure, but AFAIK those are for pure Python projects. I doubt those work if I was using Python as an extension language to a non-Python .exe?

You can write modules in C/C++ that are callable from Python, and these can be included into the exe.



Anyway, it's no big deal. My plan, which I just realized is what I should do, is to have a directory just for Python core libraries I ship with my game, and point the Python interpreter at it. I start out with it empty, I write my Python code as normal, and every time I add an import from the Python library I copy that .py (or .pyc) in. That wouldn't detect files I stopped using, though... guess if I wanted to be super-slick I'd write a Python script to grep for "import" statements and figure out which ones aren't used. Anyway, it's all a solvable problem ;)
You could also look at Boost.Python. I believe, that it incorporates the Python interpreter. What I planned to do was to create any performance critical components like the renderer in C++ and provide an interface to Python using Boost. Then write the application using Python calling the interfaces and when complete, use Py2exe to create a single executable. Since the C++ is compiled into a .pyd dll file, it is also incorporated into the exe.

In fact, you don't need Boost either for this. Linking your application with python.lib includes the interpreter.

cheers

John

[oNyx]

...and also, of course, LuaJava (http://www.tecgraf.puc-rio.br/~cassino/luajava/) :) (Thought Dom might be interested in that one)

I also started using a scripting language for my java stuff... it's *gasp* java itself! :D

I'm (ab)using the neat-o-matic janino (http://www.janino.net/) lib for that. It can compile java source code on the fly and load it directly (without creating any intermediate files). It's pretty fast (way faster than javac). And of course you get the usual speed this way.

Once you're satisfied with everything and ready to ship you can compile it the usual way. So there is no need to distribute your source and that 200kb lib.

I think it's really hot. You can load your media once and let your application run all the time... change parts of the logic and compile+instanciate it (from your app) within a splitsecond. My machine feels so goddamnfast all of a sudden ;)

[Nemesis]

Cool! That's what in-game scripting is all about!

[tentons]

Does anyone know how Python compares in speed to C#? Is there any objective data on this?

From what I've read, it seems that C#/Mono might be easier to interface with other code (ie, C++). Is that the case, or is it just that I haven't researched enough yet?

[princec]

C# should be an order of magnitude faster, approaching ordinary C++ or thereabouts for many tasks.

Cas :)

[Larry Hastings]

Just posting an agreemsg. C# is one of the nicest development environments around today; whether or not it's better than Java is up to personal taste, as they're both wonderful. The biggest downside to C# is the size of the .Net runtime; if that isn't a problem for you, I'd say go for it.