Here is my scripting system for my game. It''s actually a very simple bunch of value pairs, but it is flexible enough to be used for many purposes. Here is an example of an animation state machine : category Biped { category States { category Still { int Time = -1 bool TurnAllowed = true bool AttackAllowed = true category Transitions { string Jump = "ReadyJump" string Forward = "Forward" string Backward = "Backward" string Idle = "Idle" string Hit = "Hit" } } category ReadyJump { int Time = 20 bool TurnAllowed = true bool AttackAllowed = true category Transitions { string Forward = "Forward" string Backward = "Backward" string Hit = "Hit" string TimeOut = "Leap" } } } } Everything is a group of nested categories. You can query for strings, bools, etc by name from within the actual code. The cool thing about this system, is while it is not a full scripting system, it allows state machines like above, which are a good 80% of what you need. I''m also using this system for RenderSettings ( 32 bit, texture format, etc ) Rendering Scripting ( Texture * diffuse + specular ) Material database ( grass, "Grass2.tga", elasticity = 0.5 ) Keymappings ( "W" = MoveForward, "Space" = jump ) etc. I though I''d share this b/c it is fairly simple to implement ( I have an associative array class to handle pairs that uses a std:: ), but I wish I''d have done this 5 years ago!! What are you guys doing for scripting/configuration/game databases?

I''m trying to make my scripting system a general language. It''ll handle entity events like collisions and damage, as well as loading levels and stuff.

I read this tutorial about Jedi Knight''s scripting, I''m kina basing mine on that. I''m making a C-like language that the engine "compiles" when it loads. The engine converts the script into a simple assembly language for a virtual machine, like:
a=b+3
becomes:
ADD b 3
EQT a (result of ADD)

only it''s in a struct like:

struct command {int cmdcode;variable *left;variable *right;variable *result;command *prev;command *next;};

So it should be fast and simple to execute. The only problem is the parsing of the script text and compiling to the command list. It''s doing my head in. Aarrrrrrrrggg.

Do you think this is too over the top for an in-game scripting language? I don''t want to use it for things like rendering, keymapping, they''ll be handled by the engine with interface functions in the script language like "bindkey".

I was doing the same thing - a general purpose language but used only for scripting. It can be very powerful if done right.

I got the parsing pretty much done, and a bunch of the internal runtime data structures, but the stack machine thing seemed so ugly. I mean, to a non-programmer, how is he/she supposed to know what ''by value'' and ''by reference'' means? It just seems a little arbitrary and I wanted to do something better. I tried to come up with another way, but didn''t succeed.

After thinking about XP ( extreme programming - check out the book on this ), I remembered that one of the main principles is : *Do the simplest thing that could possibly work*.
The idea is to put a little bit of thought on the requirements, and just try something simple that you think might work. If it doesn''t work, you will know better what you need for the next try, and if it does work, just go with it. This helps you only add complexity where it is necessary and not "cool" or "orthogonal", or whatever.

I decided that I would slightly extend my category stuff, which was made only to handle d3d render option stuff, to see if I could get it to do other things. All I did was to add the nested category feature. This turned out to be the key feature that makes it usable as a state machine, etc.

It''s not a huge leap from this to a real language, but I''m more interested in making a game than technology for its own sake, so I would say to put a week or two into trying to do a real language, but be willing to back off for something simpler rather than letting the parser/runtime, etc. bog down your whole project, like it did mine...

Another question is how to handle state machines. Do you really want your scripters wto use switch statements, etc? Maybe you should build in support for states like they did in UnrealScript...