So here's the deal. As a fun hobby project a friend and I are creating a Japanese style RPG using C#/.NET as our programming environment and OGRE (via MOGRE) as our rendering platform. Now, what sets our game idea apart (I guess? hehe) is that we want to take the Final Fantasy XII idea of Gambits to the extreme. We want to offer an in-game interface and framework to actually script the AI of your party members. Not just with pre-defined components like the Gambit system, but full on scripting capabilities. This will include an in-game syntax highlighted editor, debugging environment and combat simulator to test your AI scripts. Of course, we will provide a series of pre-made script components that can be plugged in for less advanced players who just want to play. You will retain full control over the main character unless you choose to script him/her. We are really torn on what language to use though. Being in the .NET environment somewhat limits our choices, but so far we've come up with: Lua IronPython C# (via the Microsoft.CSharp namespace) Custom Language (I have experience writing parsers and VM's, so this is an option) Part of me is drawn to writing a custom solution, because I would really like language level support for tasklets (or fibers or whatever you want to call them) and states. I know there are scripting languages out there with these features (GameMonkey and Stackless Python come to mind), but exposing them to the .NET world is a pain. I guess I am just looking for some advice or some pointers to validate whatever decision I make, as it's going to have a HUGE impact on the game itself. Oh, one side note, we want to use the exact same scripting language and environment for all the enemy AI and world interaction scripting in the game.

One option would be http://www.lua.inf.puc-rio.br/luanet/

I think there is a CLI implementation of LISP.

Quote:Original post by tok_junior
One option would be http://www.lua.inf.puc-rio.br/luanet/

If we go with Lua, this will likely be our approach. Though, I am a little worried that it's no longer activley developed and is behind Lua by quite a bit.

We may end up using Tao.Lua and writing our own CLI wrapper using that if we go the Lua route.

Quote:Original post by smitty1276
I think there is a CLI implementation of LISP.

LISP is nice, but I would have a hard time justifying that to my partner who is adamant that the language be easy for a beginner to pick up (which is why Python and Lua are on the list, they are pretty easy to grasp the basics of).

This is another reason we may go custom, we can include a bunch of syntactic sugar that other languages may leave out. We would like novice programmers to be able to pick up the game and have fun scripting the AI of their party, as well as learning how AI works in general. In fact, we would like non-programmers to possibly use the game as a fun spring board in to learning to code. While I am behind the concepts of functional programmer, I am not sure how they would translate for the novice (though, I've been programming for so long, they may actually be easier and I don't know it).

Quote:Original post by Promit
IronPython sounds perfect to me, at least for a first pass prototyping. Oh, and if you get this functional, let me know.

I think we are leaning towards IronPython at this point, so your recommendation lends some weight to that choice. I am going to start working on some prototyping tonight, just to see how I could make the game object model gel together and if it works well, we will likely go with IronPython.

The advantage of doing your AI "scipting" language with .NET is that you don't need to be firm on it at this point - as Promit said, you could use IronPython for now and switch to something later (only the user created "gambit" scripts would be made obsolete). Of course you could go one step further: Since CLI abstracts the language away, you could create a thin wrapper plugin system so that any .NET language implimentation with a reasonable compiler interface could be used.

Quote:Original post by Michalson
The advantage of doing your AI "scipting" language with .NET is that you don't need to be firm on it at this point - as Promit said, you could use IronPython for now and switch to something later (only the user created "gambit" scripts would be made obsolete). Of course you could go one step further: Since CLI abstracts the language away, you could create a thin wrapper plugin system so that any .NET language implimentation with a reasonable compiler interface could be used.

Take in to account, we aren't going to be compiling these scripts down to CLI/IL. They will be executed by an in-engine VM of some sort, whether that's IronPython or not, who's to say. Any kind of compilation time that causes a hitch in the game is going to be detrimental to the idea of the "write script, test quickly, write more script" style we are going for. Everything must be self contained in the game interface itself. The script editor, the "compiler", the debugger, the testing simulator, etc. All of this will exist inside an in-game interface (accessed from the standard RPG menu). So while I may be able to support any old language from a compilation point of view, at some point I am going to have to write rigging for syntax highlighting and debugging of that language, which is a little more difficult to abstract away. Possible, but more difficult, at least on the debugging side (making an extensible syntax highlighting component is not real difficult of course).