In the end it depends on how large the game is, and wether or not you plan on reusing your engine. If the engine is crafted well, and the scripting engine works, you can save ourself a ton of headaches months or even years from now on future projects.

But you're right, it is a lot of scripting. Definately DEFINATELY get some kind of editor to handle it all. You can't imagine how complex something like this can get, and trying to keep it all in your head will make your ears bleed.

If you've seen 'Pi', you know the dangers of keeping too much information in your head. [wink]

Am I correct in understanding that you sort of have a different scripting language (i.e. a unique syntax) for each purpose, or do you have it all in one language?

For me, when I hear or say scripting language, I think execution -- a list of statements (if it's a Turing-based language) that are each interpreted and executed, one after another (according to whatever code flow layout there is). If I were designing it, I think I'd have a single language that can get or set values as appropriate; or add, modify, or remove items; or whatever else you'd like to tweak the game state (which would start out fairly blank) and start the program execution by running a bunch of these scripts to fill in the blanks. I'd have this language be fairly broad in expanse and provide functionality for basically changing anything in the game I'd want, and I'd make it so code in one script file can reference code in another. That way, it doesn't matter how many files you organize your code into -- you could do it all in one, or in many, however you'd like, arbitrarily -- and you could change that per project, as appropriate, at your whim.

So my advice them is to make it as simple a fully expressive language that you can, then add in mechanisms for all the intra- or inter-script activity you'll want, and then write little programs in your scripting language that do what you want. Remember that the goal would be to design the language to be as easy to write in as possible -- so you don't necessarily have to model it after any language you already know like C++ or what-have-you, just make something up that works for you, is useful, and is very easy to read and write. For scanning and parsing, look up flex (or lex) and bison (or yacc) -- they are tools that make it all really easy.

There are certain things that don't need to be scripted -- I think the raw data for the heightmaps shouldn't be in scripts, for example, but perhaps should be in bitmaps. Those would be extremely easy to edit, and take complication out of your scripts that don't need to be there. Likewise, for any numbers that could be algorithmically calculated, take the numbers out of the script and have the interpreter crunch them for you.

Oh yes; and make sure your scripting language supports commenting. :) And do so -- a lot!