Easiest scripting integration with C++

[Pyabo]

I want to add some scripting support to a project I'm working on. I have some "entities" in a game and I want to modify their behavior easily and quickly without recompiling my game over and over again. And possibly have them react to in-game events as well.

Lua? Python? Ruby? Embedded perl?

What binding package is simple to integrate, but still supports accessing C++ class members and methods?

[ggambett]

I think the easiest is LUA, although I haven't used it. Unlike the others, it was designed to be embedded.

[jankoM]

yes Lua was made to be embeded and should be better for this (easier integration, much more lightweight...). There are some other alternatives however (also made to be integrated so it should be minimal fuss):

* gamemonkey (more like C than lua , runs on everything from pc, mac, psp...)
* squirel (interesting)
* spidermonkey - real JS (used in mozilla -don't know how big/small)
* io (diferent and unusual - concurrent..)

However, Lua is maybe the most widespread amongst those..
(I was very interested in trying various languages once)

[Nikster]

I would recomend either Lua or Squirrel, I personally use squirrel atm, but used Lua heavily before, both have C++ bindings, but I haven't use either, both take minutes to embed Lua has a bigger support base, Squirell is faster at rutime (hence why I used it) but only noticible on small embedded machines. So there you go ;)

[mot]

Or this one:

http://www.compuphase.com/pawn/pawn.htm

[timoh]

also look at angelscript (http://www.angelcode.com/angelscript/), very easy to integrate and does not need any wrapper-functions/objects.

[Pyabo]

Groovy. Thanks for the pointers.

[spellcaster]

Well, while Groovy is a nice language, it will be more useful for the java developers ;)

So far I've used JavaScript (via SpiderMonkey- the mozilla JS implementation) and LUA. From these two LUA is more easy to integrate.

[vjvj]

Lua is easy peasy and I love it.

Angelscript is something I've been meaning to look at when I have time, it looks cool.

[ManuelFLara]

As far as I know, the most automatic gluecode generation I've seen, and I've looked at several scripting languages alternatives, is Python + SWIG.

[jetro]

Another vote for AngelScript, I think it's far easier to bind to C++ API code than e.g. Lua, especially if you want to do some OOP in script code.

[Sharkbait]

Yet another vote for Angelscript. It is very easy to embed (static or dll), cross platform, native functions, variables and classes can be bound to the script directly without wrapper code, support structs and will very soon support in-script defined classes, inheritance etc.

I've used it to define the rules of Arcade and Puzzle modes in Atomixer, level definition and configuration.

[Applewood]

Do you actually mean full scripting ?

If you want to just have flexible content definition, I'd reccomend plain old XML and TinyXML from SourceForge to read it in.

My favourite scripting engine is LUA but that's not a hard credential to achieve - I've not tried anything else! (Actually, I guess that *is* actually a pretty good endorsement)

[Sharkbait]

I used Angelscript to write the actual game logic of Atomixer's two game modes. That means there is code to define how each level should be completed, wether it is a pre-designed puzzle, determine the speed of the game elements, implement difficulty levels and so on. I tried to abstract the logic from the native code and in theory I could add new game modes with very little amendment of the native C++.. just enough to expose the new modes to the game's interface and highscore system.

In hindsight I suppose using scripting was a bit of an overkill for the game's scope but I had just embedded the scripting engine in my own game API and was keen to give it a go... when you have a hammer everything starts looking like a nail! :)

[Expresionista]

Go for Lua. It is light and stable and it has a well-sized userbase. I really love Python but it is too heavy for an small game.

There is a JIT engine for Lua, also.

[luggage]

I've implemented 3 at various time so in order of my preference...

Angelscript
Lua
Python.

I recently ditched using scripts as users can't mod the game and I'd be the only one writing the scripts anyway. Can't see the point in making debugging harder and more work to save myself a compile.

[PaulModz]

Somewhere along the line I seem to have sold my soul to MS for access to their 90% market share, so I can’t help but suggest the same answer I seem to provide for almost every technical question, use .Net.

It's not hard to host the .NET CLR in an unmanaged application, there's even a sample application of doing just that in the DirectX SDK
(It’s a little simplistic, but it covers what might be the most important issue, code access security)

You get a rock solid interpreter which M$ probably spent more to develop that the GDP of most third world countries. You can use what is (IMNSHO) the most efficient language ever developed in your scripts, C#. On top of that, the language independence of the MSIL interpreter means you can use any supported .Net language you want to write you scripts, which include C#, Python, VB, C++, Eiffel, J++ and dozens of other boutique languages.

This technique really leaves everything else in the dust when you have written your application itself in .Net as well. When you host .Net scripts in a .Net application, you have almost identical access to your underlying object model from both scripts and compiled code. At this point, the line between compiled code and scripts read as text files at runtime becomes as blurry as you want it to be.

For example, the Solar System simulator I am writing is a C# application which uses C# as it scripting language as well. Since .Net gives you code level access to the compiler, my application compiles certain types of scripts (based on the object being scripted and the number of times the script is called) into their own managed assemblies (DLLs) so there is zero performance difference between scripts compiled by the app at runtime and C# code compiled by Visual Studio.

Someone stop me, I could rave about .Net all day. If you haven’t even tried using C# and .Net, do yourself a big favor and download the free Express edition of Visual Studio and try it out. I was a hard-core, dyed in the wool C++ programmer for 10 years before I started using .Net. I thought real programmers were man enough to manage their own memory and interpreted languages were for people who weren’t intellectually up to using a real language. After using C# for two weeks I never looked back, that was three years ago and I haven’t willingly used C++ (or any other language) since.

I know a lot of people can’t use .Net because of cross platform considerations, but there is hope that Mono will actually allow MS to see the light and write officially supported interpreters for Linux and OS X, which would be technically trivial if Bill decided to do it.

[Arkadesh]

Don't you need .net runtime to be able to use its goodies? And requiring separate download from indie gamers doesn't seem to be the right thing.

cheers,
Arkadesh

PS. My vote goes for LUA - adding support for it to my code was really simple.

[PaulModz]

Yes, the runtime is required to host the CLR, but it seems to be fairly ubiquitous now. The term “indie” is a little squirrelly as well. Sometimes it means games that grandma can download and run on her Windows 98 486 with a dialup connection, and sometimes it means novel and progressive games that are to main stream titles what indie movies are (or used to be) to Hollywood Blockbusters, but still require higher end hardware.

Is a 20MB dload really a deal breaker for a lot of developers? If so, I'm probably gonna be screwed ;) Depending on which version of DirectX a user has, the DirectX runtime can be an even larger download. I guess if you are trying to reach the grandma level mass market, you might want to reconsider, but even my Mom has a 2GHz Pentium and a DSL line.

I'm sure this has been hashed over in these forums thousands of times, and I'm talking straight out of my ass with no data to back up my hypothesis, but depending on the kind of game you're making, choosing to be compatible with low end hardware to increase your potential market seems like it might actually keep you out of the high end of the market that surely spends a lot more on games.

[Arkadesh]

Well, we're slowly moving to OT, but I think the biggest problems with additional download are:
1) in crowded casual market, when someone downloads a game and then he is informed that he needs to download something else to be able to play, I wouldn't be suprised if he just deletes the game and then goes to download another one - that will just work OOTB...
2) downloading .net runtime, installing it, etc - I don't remember how it looks, but it's quite possible it can scare away the less tech-savvy users.

cheers,
Arkadesh

[PaulModz]

Point 1 is well taken.

While testing .Net application installers on dozens of differently configured VMs, I'm intimately familair with it. One OK/Cancel dialog to start the installation, check the "I agree" radio button to accept the license, and one last OK dialog on the way out ;) If you launch it from your own installer, I'm pretty sure you can pass the .Net installer a few command line paramters so it will install silently.

[staigerman]

I don't know much by experience how well it works with Lua by comparison with others, but perhaps there are other factors that interest you? For example, if you think you might also be interested in developing filters for special fx, then it might be good to know what type of scripting is available in the GIMP, or in Project Dogwaffle, and in ArtWeaver. It is Lua.

That way, what you learn in Lua might also be useful for your filter dev.

[illume]

I don't know much by experience how well it works with Lua by comparison with others, but perhaps there are other factors that interest you? For example, if you think you might also be interested in developing filters for special fx, then it might be good to know what type of scripting is available in the GIMP, or in Project Dogwaffle, and in ArtWeaver. It is Lua.

That way, what you learn in Lua might also be useful for your filter dev.

This is the same for python. Python can be used to script lots of different art packages. From photoshop, to the gimp, blender, maya, paint shop pro, poser, and others.