So what makes a great game scripting language? After a very interesting thread about language syntax several weeks ago I pose the question: What *features* make a great game scripting language? What exists in current scripting (or general programming) languages that is useful to extend and control software, with a particular interest in games? What features would be benefitial that are not yet implemented, or common, in computer languages? As I see it, the most important areas of scripting languages are host-binding, cross platform/host-language-independance, ease of use, and power/speed. For most of the discussion I would like to stay away from language syntax if possible. However, syntax is obviously a factor while discussing ease-of-use issues. To get the ball rolling, here are my immediate thoughts: Host-Binding: Integration between the scripting language itself and the language the host program has been written in. The host language should have an easy way to call scripted functions/manipulate script variables and vice-versa. For security, functions/variables should be exposed through a common interface, allowing other functions/data to remain hidden. A scripting language should, at minimum, support common data types among host languages: char, int16, int32 and float32, as well as arrays and structures of these types. How about an equivilant to "pointers to (script)functions?" Is the script allowed pointers, references or both? Are arrays bounds-checked? Are structures padded? how? Cross-platform/Language Independant: The scripter should not need to be aware of issues concerning the host CPU (endian-ness, # of registers, etc.) or Operating System. All such details should be handled behind the scenes of the script's runtime environment(Interpreter, VM, JIT...) and should adhere first and foremost to the standards of the host language. Ideally, binary scripts should be entirely platform agnostic and text-based tools such as compilers should accept both ASCII and UniCode input. Ease-of-Use: Admittedly, this is somewhat of a fuzzy matter. I believe this encompases two areas, learnability for the newbies, and productivity for the veterans. This applies mostly to language syntax, but does effect host-binding and other areas as well. I believe that a syntax should be "short, but sweet," or rather, "small, but complete." Keywords/operators should be kept to a minimum, for instance I find bit-manipulations to be pretty useless in scripting. The syntax should be consistant and avoid ambiguity. Take, for example, the classic C "== vs. =" error, perhaps keep "=" but replace "==" with "equalto," perhaps then "!=" could become "unequal". Sure its a few more keystrokes, but its much less error-prone for newbies and non-coders. Should a Scripting language support opperator overloading and/or the definition of new keywords? Do the benefits outweigh the confusion this could cause? What are some usefull constructs? foreach() comes to mind. How about native event handling features? Power/Speed: This is pretty clear, the ability to get the job done and do it as fast as possible. So, how much power does a scripting language REALLY need? As I stated above, bit-manipulations are probably overkill. Scripts probably don't need templates or multiple inheritance either (not that they wouldn't be nice, but are they really needed? Is the additional overhead/infrastructure worth it?) How about inter-script communication? Global data area (accessable to all scripts)? What are the pros/cons of both stack-based and register-based runtime environments? Should the runtime environment be built to support multiple source languages or should it be built/optimized to support just one? I'd like to discuss ideas freely, but keep in mind that this is not meant to be the Ultimate Do ALL Scripting Language design, but simply a design usefull in controlling and extending software, particularly games. Please feel free to point out anything I have overlooked, add your two cents, bring additional thoughts and ideas into the discussion, etc. And be forgiving of spelling/grammer this was typed between 3 and 4 AM Ravyne, NYN Interactive Entertainment [My Site][My School][My Group] [edited by - ravyne on May 16, 2004 7:28:51 AM]

Actually, I believe a scripting language shouldn''t be so close to the host language that the subtle differences between the two start causing problems. If you want a separate assignment operator, := is standard.

Coroutines are a must, so are bound functions of some form or another (or more generally, currying).

For numeric types, you only really need int32, float64 and bignum. Characters don''t ever need to be treated as number types, but simply as one-character strings. Array bounds checking is necessary, both dynamic and associative arrays must be builtins, but alignment and structure padding issues are mostly irrelevant to the definition of the language/feature set - they''re part of the embedding API.

Operator overloading is fine, though probably not used much outside of numerical/container extension types. Custom (infix) keywords/operators will require a sophisticated parser - or you may resort to some uglification, such as mandating that custom keywords start with a special character (e.g. foo @bar baz <-> bar(foo,baz))

For "useful constructs", just start by looking at the C++ standard library (<algorithm>, <functional>...)

As for existing scripting language, people here know my bias towards python.

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan

quote: Original post by Jotaf
I''m thinking that implementing something like this would be: Create a script object (call it a thread if you want) and run it. The "wait" function stops executing the script and creates some kind of a timer event that resumes execution of this script 5 seconds later. At the end the script object is destroied. If a scripting language provides this kind of tools so that (almost) native event handling, co-routines, etc are handled, do you think it would be enough so we could consider that co-routines and stuff like that are a feature of the language? Also what other nice features could arise from a system like this?

A better implementation would be:
Make a host variable that is accessible through a host function which is decremented every time click (most likely your native code should ahve a timer). Now, suppose your timer is 1/20 seconds, you would initialize that variable with 100 (5*20). When the variable is 0, call a custom scripting function, which will do the necesary thing (such as displaying a message) depending on the context.

quote: Original post by Ravyne
What *features* make a great game scripting language?

I think, the most important scripting language features are simplicity and game engine integration. Typically, scripting is used by non-programmers. All the other features are of less importancy.

The goal of scripting is to provide the level designer with the contorl over the game world without programmer''s assitance.


Alexey Suda-Chen
www.molebox.com
www.spritecraft.com