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]

My thoughts are:

1. A scripting language really needs to be simple, but similar to the host language. Especially in syntax. This means less retraining and fewer errors. An example would be, using a scripting language where = meant equality, for a C programmer, could get very awkward, programmers switching between native and script will get confused.

2. Run-time performance is not usually an issue. Scripting is for determining high-level behaviour, and as such, the program spends hardly any time in the script. Rendering and low-level logic (such as collision detection, motion handling) should not really be scripted. Collision HANDLING could be scripted, but not collision detection.

One particular thing I''d like would be to be able to use coroutines in a sensible way. From looking at the documentation, I think I can do this using Lua, possibly not in Javascript / Spidermonkey.

Binders are very good in principle and can save a lot of time, but only if they work properly and are robust.

Mark

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

IMHO this is what a script should have :

-> Coroutines
-> Simplicity
-> Full binding with the language
-> Integration with the tool ( naming a object in the tool, and using the same name in the script )
-> For console, memory issues should be taken care of.

-> Stop speaking about speed for a script system. If you need speed, then your design between script and language is bad ( okay,perhaps it could be different for RTS and MMO )


I''m using Python for PC.

UnrealScript is a very good example of a VERY GOOD SCRIPTING LANGUAGE...

Yes, UnrealScript. That about encompasses the perfect scripting language to me, I''ve been hard-pressed to think what I would change.

Ok, you made a point there with native event handling
It''s definitely a must for any scripting language. Don''t tell me that this is not useful:

say "Hi!"
wait for 5 seconds
say "Welcome to my humble cottage."

(the typical script for the typical village NPC in an RPG)

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?

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

What can I say, Python is the best scripting language I can imagen.

Dynamic arrays (in any dimension), classes, overwrites (of anything since all are Objects), fast, the possibility to bind functions, classes and variables with the Host program.

Typeless (so in an array I can put anything of any class I want).

A very good example is the game Star Trek Bridge Commander. If you compare it with the "stock" game and the modded game (all customizable with little to no overwrites), then you wouldn''t almost recognize it.

quote:
-> Stop speaking about speed for a script system. If you need speed, then your design between script and language is bad ( okay,perhaps it could be different for RTS and MMO )

I think you are missing the boat on what script languages can do for you and development. There are two kinds of script languages: those used by non-programmers to set high-order behavior, and those that are used by programmers to bind dynamic behavior to the underlying system.

For the latter Speed is essential, and I believe you will see more and more of that type of thing going on.

quote:
I''m using Python for PC.

I am not really surprised.