On the game project I'm working on(as a designer) we use an internally developed scripting language that was originally meant for simple timelined cinematics. It was, according to the author, made in one day.
Each line gets a time in seconds followed by a call on some entity: hello world is "0.0 Script:Print("hello world")". The syntax quickly gets verbose from there - and no multi-line statements allowed!
Some of the flaws of this language:
-Miserable computational abilities. Until just this morning we were unable to add two numbers together. The main limitation is poor access to information - getting things like the x position of an entity requires a language extension - an easy one, but when it's not there....
-A vague notion of types. Variables attached on entities are typically enclosed in quotes: "true", "100", etc. But in arbitrary instances you can also use space-delimited vectors, for example: Script:Goto(100) or Entity.SimpleMovableInst:SetPosition(0 0 0). If you use the wrong thing, you will be lucky to get an error message. Usually it just silently fails.
-Lexical macros. These were added in order to cut down on the number of custom scripts we were using: instead of cut-and-pasting "switch1...door2....etc." variables we could say "$[target]" and it would be replaced at runtime with the contents of variable "target" on that entity instance. But they have the effect of giving a lot of false errors in the cases where we don't need to use those variables on a rich, multi-purpose entity. Worse, if I forget to add a variable necessary for the script, that instance will fail and I may not realize why.
-The parser doesn't recognize delimitation of strings, among other things. Putting a colon inside a print statement causes an error message.
It is no surprise that endless grief has resulted from these various flaws. I fixed bugs resulting from all of the above just today.
It works fine for timelines, but I'm hoping to get Scheme(or something with similar potency) for the next project.
Lua is designed for exactly the type of work you describe here. I wrote a Lua interface for The Nebula Device (Open-sourced 3d game engine from Radon Labs.) It took about a weekend, starting from scratch. Interfacing to C or C++ code is dead simple. And the language itself draws a lot of inspiration from Scheme without abandoning a more familiar syntax. You get first-class functions, closures, lexical scoping, coroutines, and a clever "metamethod" system for defining object behavior. It's an extremely quick and efficient implementation written in strict ANSI C, and it works well in constrained environments like games. It's quite popular in both console and PC games for higher level functions on top of a low level engine. Give Lua a look-see!
I integrated Lua once for a project of my own. But on this project the choice wasn't mine - we ported over existing technology to a new console to meet a five-month ship deadline.
Also, Lua is imperfect for games: Squirrel is considerably more attractive because it is designed to work in real-time situations(no GC interference). I also had issues with Lua's error-handling.
And now with Lunatic Python, you can even use Python from Lua or Lua from Python, two-ways! So you can do Lua-in-Python-in-Lua-in-Python if you have that desire.
Seconded. Lua is especially popular for games, and for good reason. However, I've had peculiar bugs when interfacing Lua with C code on occasion (related to my own incompetence, not Lua itself), so do be aware of where you place your code.
Each line gets a time in seconds followed by a call on some entity: hello world is "0.0 Script:Print("hello world")". The syntax quickly gets verbose from there - and no multi-line statements allowed!
Some of the flaws of this language:
-Miserable computational abilities. Until just this morning we were unable to add two numbers together. The main limitation is poor access to information - getting things like the x position of an entity requires a language extension - an easy one, but when it's not there....
-A vague notion of types. Variables attached on entities are typically enclosed in quotes: "true", "100", etc. But in arbitrary instances you can also use space-delimited vectors, for example: Script:Goto(100) or Entity.SimpleMovableInst:SetPosition(0 0 0). If you use the wrong thing, you will be lucky to get an error message. Usually it just silently fails.
-Lexical macros. These were added in order to cut down on the number of custom scripts we were using: instead of cut-and-pasting "switch1...door2....etc." variables we could say "$[target]" and it would be replaced at runtime with the contents of variable "target" on that entity instance. But they have the effect of giving a lot of false errors in the cases where we don't need to use those variables on a rich, multi-purpose entity. Worse, if I forget to add a variable necessary for the script, that instance will fail and I may not realize why.
-The parser doesn't recognize delimitation of strings, among other things. Putting a colon inside a print statement causes an error message.
It is no surprise that endless grief has resulted from these various flaws. I fixed bugs resulting from all of the above just today.
It works fine for timelines, but I'm hoping to get Scheme(or something with similar potency) for the next project.