Sign in to follow this  
GnomeTank

.NET AI Scripting Language

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Whatever you choose IMO support for microthreads/fibers should be a requirement. They are extremely useful in AI and general gameplay scripting. Game Monkey has them, Lua has coroutines which are very similar, Stackless Python has them. .NET unfortunately doesn't afaik.

Share this post


Link to post
Share on other sites
Quote:
Original post by DrEvil
Whatever you choose IMO support for microthreads/fibers should be a requirement. They are extremely useful in AI and general gameplay scripting. Game Monkey has them, Lua has coroutines which are very similar, Stackless Python has them. .NET unfortunately doesn't afaik.


.NET having or not having micro-threads is irrelevant in this case. The scripting environment I use just needs to support them. I am not sure if IronPython does, but if I write a custom language, it most certainly will have tasklets, much like Stackless Python.

Share this post


Link to post
Share on other sites
I know a couple of you were semi-interested in this, so I thought I would update. My partner and I decided to go with something custom, for a lot of reasons. First off, I know how to do it, so it allows us to get something going quickly (in fact, I already have the parser and AST generator written using ANTLR). Second, it allows us to provide some syntactic sugar that we just couldn't coax out of another language.

We are calling the language Balance, mostly because it's a synonym for the engine code name (Stasis). I have the code generator mostly written, just need some tweaks, and the VM is about 30% there at this point. It's all stackless, providing the concept of microthreads/tasklets. It also has built in syntax for state handling and such.

I probably would have settled for Stackless Python if there were .NET bindings, or a Stackless version of IronPython, but it will take me the same amount of time to write my own stuff as it would to figure out how to make IronPython stackless. The gist I got form the IronPython guys was that no one was working on a stackless implementation for it, so I decided to go my own way.

The other nice thing is that using some .NET wizardy (aka code attributes), we can export certain parts of classes to different levels of security in the VM. For instance, we can export the Character class, but using code attributes, we can mark certain methods/properties as invisible to the scripts, visible only by the core game engine, or visible to user scripts. This is all on the VM/code infrastructure side of things, but it was something that was very important to us, to maximize code re-use and not have to use things like script proxies.

As a random side note, if you like writing parser and things of that nature, and you are in the .NET/C# environment, I really have to recommend ANTLR. I researched and discovered it for this project, and it's been a total joy to work with. It's actually written in Java, but produced CSharp code. The EBNF syntax it supports is really easy to use and understand (especially if you are used to writing parsers), and it's just been a real fun experience so for. I am "sold" as they say. It generates LL(k) parsers, and you can define k (for balance, I use a lookahead of 3 for instance). It's a real nice tool, and I doubt i will go back to yacc/lex (bison/flex) again unless I need to.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this