Why chose Javascript for scripting

[Potter]

Hi Team,

Just curious as to why Javascript was chosen for scripting (except that it is a very popular language)...

From what I have observed, Games have been traditionally using Lua or other languages for scripting.

Any particular reason why Javascript was chosen?

[Jeru]

There was a huge argument/fight over it in 2003-2004. I just looked it up. Lua was considered alongside Ferite, which was the state-of-the-art language then but was not yet mature.

I'll copy-paste some posts from a thread where some programmers first wrote they liked JS:

Backend functionality (from the Scripting Backend Functionality thread)

FSMs:

1) Multiple script contexts. Check.

2) Ability to get/set a script variable value from within the engine. Check. (JS_LookupProperty)

Global variables are properties of the "global" object.

3) Ability to call script functions from the engine. Check. (JS_CallFunction)

4) Ability to call engine functions from the script. Check. (JS_NewFunction)

Data Structures:

1) Ability to create variables, arrays, and objects. Check.

2) Ability to expose complex engine data structures and classes (possibly with a custom interface).

You would create objects, and add methods and properties to them. I am unsure whether it is possible to assign a JS property to a C++ getter/setter.

General:

1) To pause scripts during execution and, later, resume them.

There's a debugging API (it is enough to drive the Venkman Javascript debugger used in Mozilla, so it should do it)

http://lxr.mozilla.org/mozilla/source/js/s.../src/jsdbgapi.h

I'm unsure whether another script can execute at the same time, sharing data with the aborted script. You can have several JS contexts (each of them bound to one thread at a time), but the docs doesn't say whether the different contexts (in different threads) can share their global object.

2) To restrict access to any unsafe features of the scripting language, if applicable: File I/O, network access, system diagnostic, etc.

JS supports a system similar to Java's security system. I haven't looked too much into it - but there's a framework for it, and I guess the framework is heavily used in mozilla (why else would it be there?)

3) (Preferably) To run like the proverbial bat out of Hell.

Unsure - haven't actually used spidermonkey anywhere (except my everyday usage in Mozilla). I think we should (have) run some speed tests on JS too.

Spidermonkey also has unicode-versions of most (if not all) APIs

Embedding seems to be well-documented. Whether it's as easy in implementation remains to be seen.

I looked through the frontend functionality post, and JavaScript basically supports the works.

Unknown whether JavaScript supports file/library inclusion natively, but theoretically it should be possible to import a C++ function that parses a file and adds all the stuff to the scripts namespace.

I just spent a pleasant afternoon trying to embed JavaScript. I'm impressed with how easy it actually is: From downloading the source to having functions, data, classes working within a script in about 3 hours.

As for the language itself, it feels just as C/C++-like as Ferite, or more so, and it seems far more likely to be around in five years time.

I've also checked against our backend lists: JavaScript supports Regex, Unicode, and most of the other requirements we had, and is the only one so far to have the security framework. The only thing that I'm uncertain it will do is the pause/resume of scripts. Also, there's a fair amount of JS tutorials on the web for learners, though most of them use an internet-based point of view.

I found another thread from '05 on the topic with posts by Philip (Ykkrosh). He is still on the team so you can pick his brain on this topic.

From the frontend functionality requirements thread:

>> Automatic Conversion: Data should be automatically converted when copied between variable types, especially when working with strings.

>> Basic types: No need for doubles, unsigned etc.

* int

* float

* string:

We really need string/array functions. XS kept scripters limited with options and even having to create workarounds because they lacked this.

I mean a REAL string class, NOT c-style strings

all major string features normally found needed, including automatic conversion and concatenation

* boolean:

* custom objects:

STRONG OOP, inheritance, etc

Real (or as real as possible) OOP: I want classes, objects, inheritance, and all that good stuff. It doesn't have be complete and standard OOP though.

I find this EXTREMELY important whereas im basing most of my design upon this.....basically im allowing anything "related" ot the game (GUI objects, chat, certain messages, unit/building/object attributes etc etc to be used in an almost trigger fashion (condition/effect)...i have found OOP not only beneficial to this, but almost necessary

for example:

CODE

if( button1.is_pressed() ) {

unit1.attack += 5;

// somehowe find a scriptable and clean way to make this change back after so much time without too much lag

//(this is a special ability)

}

(I know from WC3 scripters thet WC3 allows scripts in the editor that allow for is_pressed() type ideas...)

As for inheritance, this is required for the whole object setup etc

Lastly, but not least, we will need to be able to make custom objects of some sort possibly....not quite sure yet tho.....extending hard-coded ones might be enuf, but im thinking they wont

* Null value:

NOT necessary, but nice.

* const:

keyword or whatever the language would call it (ferite calls it final).

* array:

In AoM this was surprisely used a LOT...however since there was no array available, scripters needed to make pseudo-arrays that were horribly sloppy, inefficient, difficult, etc etc....often scripters would opt not not to use arrays due to this very fact. If im correct the pseudo-array was rather an ugly/pseudo- meta-table. Go here for more info on this: http://www.woadcreations.nl/articles.php?g...&artid=1#arrays

Arrays can be used in various items ranging from actual game data code to AI queues to random map and scn scripting....thus I feel proper and easy/clear array syntax and representation is a MUST. smile.gif

* Tables, DBs, multi-dimensional arrays:

I can see quite a few uses for these, including in AI and random map or scenario scripting....mainly to layout the map and identitfying coordinates/positions..

* Queues, Stacks, et al

Ive seen numerous usage of these, including for message queueing and random map and scn scripting. If at all possible, i would be preferable that these be 'dynamic' altho if not possible, this might be implemented via a good array system.

* regex:

Its too much to explain all the uses of this in scenarios and AI, etc etc, the most important use being parsing chat dialogue....adds a new and powerful element

GENERAL:

>> Conventional coding: Typical C/C++/Javascript/perl/php/java syntax, functions, types, objects, control statements and scoping.

>> Ability to allow scripters to create their own modules/function libraries.

>> Error handling: Error messages, debugging tools, etc etc for creating a debugging tool like XS had would be a very welcome sight!

LIBRARIES:

1) Library Inclusion: ABSOLUTELY MUST ALLOW THE INCLUSION OF SCRIPT FILES/LIBRARIES INTO ANOTHER SCRIPT. svede can glady rant about this as his biggest problem with XS.

2) Math Library: Access to sin, cos, sqrt, etc in the engine, so scripters don't have to write their own.

[Jeru]

A post by Zeusthor from March 2004:

Version History:

7th April 2004 - Gee - Review, OK.

25th July 2004 - Stuart - Indexed.

Summary:

Why we settled on Javascript as our scripting language.

SUMMARY OF SCRIPTING LANGUAGE DECISION

by Jeffrey Tavares (Zeusthor); edited by Stuart Walpole (Acumen)

11th March 2004

OK, now that the fog of war has cleared away from language debates and Javascript has claimed victory over our lands... err, forums ... it's about time I came up with a little recording of how we came to that choice, for future reference.

Lua was going to be the language until I came along which may have bummed some of you, but some of you might agree that it's for the better that we changed . Lua gave a bad taste in the mouth of Svede and I.

Python was discussed twice within 0 A.D's long life during early 2003. In early 2004, Ferite started to show its true colours. When things started to look golden for Lua again, olsner presented Mozilla's Javascript Engine (SpiderMonkey). I, of course, bent towards not coding in Lua, investigated SpiderMonkey some more and pushed its acceptance.

So, what made Lua so bad, you say? Back-end wise, Lua is superb. It's fast, small, compatible, and easily embeddable. As there were more programmers than scripters, this made it an easy choice.

When I joined and took a look at it, I honestly took the effort to read some of the manual and get to know it, but my first impression was bad and my last impression was worse.

The syntax was too forgiving: you may or may not use parentheses, semi-colons, etc. Would your English professor give you the choice to miss punctuation if you felt like it? This would have presented code readability issues as scripts got complex.

The second big reason why I didn't want Lua was the meta tables concept which is supposed to replace arrays, classes, and the whole lot of stuff. I'm sorry, but there is no way you can create a Swiss army knife to replace programming concepts and expect it to be a better solution. Call me stubborn and close-minded, but I didn't like the way things were done in Lua.

With Svede agreeing with me, I knew I wasn't too far off in judging it the way I was. So, he had me find an alternative and so I did.

The first alternative was Ferite. I spent a few hours looking through google, sourceforge, and freshmeat. It was the only one deemed "acceptable" for my standards, probably because it was very similar to C#.

I read the language manual in full, and did some speed reading of the backend manual and thought it was able to compete and advertised it in the forums to see what the programmers thought, which started a civil war.

In the end, Ferite's developers didn't keep to their word on release dates and weren't dependable. The engine was trivial to implement, took a bit longer to understand, and to this day, hasn't been ported to Windows even though the main developer stated a release near early January of 2004. Despite the language features, I had to let it go because the engine wouldn't put up and the developers didn't put out.

Along my opening of Ferite, Python popped into the discussions somehow. Python was obviously powerful, and has proven to be successful in many applications. I don't have much to say for Python because it wasn't actively in discussions.

A Python scripter, Oluseyi, provided us with an assessment of Python, and concluded that if the system core was scripted (minimal data passing/conversion), or we were using parallel execution threads, then the features and robustness of Python would make it a good choice. We're using the scripting language as a simple extension mechanism for the core, so he advised it wouldn't be an appropriate choice.

We all ended up choosing Javascript because it fulfilled backend and frontend requirements set by the team. It has been proven in two game engines, the browser, and a 3D development application, which gave us a sense of security along with the fact that it's being used and developed by Mozilla.

Javascript is a well-known language which will help public acceptance when the game is released, and it is fairly easy to implement.

Alan has been working hard to do some real testing of its capabilities especially speed and it has proven to fare well under anticipated conditions (although this was questionable at an early stage).

It seems like we will be staying with Javascript. It is stable, powerful, fast enough, recognisable, and progressing (2.0 is on the way).

[aleReimondo]

Any selection of language (syntax and/or semantics) is imposed

by economy of resources.

Young systems are written in small number of languages,

and most of them die before maturing to support diverse

forms of expresion.

For games the "scripting solution" has emerged to reveal the

contrains imposed by components idea(ls).

Object Technology is still unused for games in practice,

and most game developers do not use the main diference

between objects and components; so they don´t want/need

more than components...

A pluggable scripting engine is a first step to promote

multiple languages to dynamically change behabior (and shape).

best,

Ale.

[Potter]

Wow. I didnt expect such technical depth would have been discussed while choosing the language

Anyway, I feel that Javascript has been a good choice, as with the recent browser wars, everyone is tripping over others to optimise Javascript engines ...

I also got hold of an interesting statistics that says that the Javascript V8 runs faster than Lua and that Spidermonkey is fast approaching V8 in performance. So,

[Ykkrosh]

The syntax was too forgiving: you may or may not use parentheses, semi-colons, etc. Would your English professor give you the choice to miss punctuation if you felt like it? This would have presented code readability issues as scripts got complex.

JavaScript has optional semicolons too, so it doesn't seem much better; in any case I don't think optional syntax is really a problem since you can just enforce some coding conventions to keep things consistent and readable.

The second big reason why I didn't want Lua was the meta tables concept which is supposed to replace arrays, classes, and the whole lot of stuff.

JavaScript uses pretty much the same concept - everything's an object with string-named properties, including arrays (which also have a magic 'length' property) and classes (which are function objects with a prototype property with function properties).

I don't think those sound like convincing technical arguments for JS over Lua - it seems more like it was down to personal preferences of a couple of people, and I guess I wouldn't have agreed with the decision if I was around back then (and wasn't as inexperienced as I would have been then). But I'm quite glad they made that decision despite the reasoning, since JS has grown in performance and popularity since then and is a nice enough language for our needs

Anyway, I feel that Javascript has been a good choice, as with the recent browser wars, everyone is tripping over others to optimise Javascript engines ...

Yeah, I think we started with version 1.5 as in this graph, and now use the rightmost version, so there's definitely been an improvement, and they're not stopping yet

[Chakakhan]

Back then, I would have pushed for Lua. It was the standard game scripting language at the time and Lua performance was much better than JavaScript.

Now, JavaScript is a great choice! I think their arguments were weak, but I am glad they made the choice they did.

[historic_bruno]

Thanks for digging that up, Jeru, I was always curious about this

[Jeru]

Thanks for digging that up, Jeru, I was always curious about this

You're welcome.

For a contemporary observer, it's really quite striking how developed the project was in many respects as early as 2003. It's quite evident from the level of discussions, the documentation, the social interactions and decision-making processes, etc. Consider that this is back when other collaborative projects like Wikipedia were in their infancy.

That is one of the secrets of 0 A.D.'s success, probably.

[WhiteTreePaladin]

3 hours ago, stanislas69 said:

Well LUA is usually the performance choice for scripting. Do you happen to have a link to a thread where we explain why we did choose one over another ? I get that question a lot and I don't have a solid answer. 

I remember someone saying that it turned out to be a good decision that JavaScript was chosen due to how browsers have spurred many JS performance improvements. That was years ago though, and I couldn't find the post. There is a little here in this thread, but for the actual details, I've asked elexis to check the relevant meetings if possible.

https://wildfiregames.com/forum/index.php?/topic/12716-scripting/&tab=comments#comment-202793

 

[Guest]

More insight.

Thats all I could find (maybe I am forgetting a thread, this was found a long time ago), there might be more in the old logs / staff forums. Archives from 2005 only show a dev report about researching scripting alternatives followed by a delay and a new report mentioning some significant JS implementation progress. (I search quite extensively)

Edited April 20, 2019 by Guest

[Wijitmaker]

More on the scripting decision here:

 

 

 

[GunChleoc]

Those are internal posts

[elexis]

4 hours ago, WhiteTreePaladin said:

I've asked elexis to check the relevant meetings if possible

It was meeting #19: on January 17th 2004

1 minute ago, GunChleoc said:

Those are internal posts

We're currently trying to release some more meeting contents, because it important information on 0ad development as demonstrated by this thread. But it's not easy, since the people involved should be contacted where possible.The link to Avivs post that smiley dug out contains quotations from https://wildfiregames.com/forum/index.php?/topic/712-look-at-javascript/&do=findComment&comment=7389, so at least there is something. Perhaps we can can publish a bit more, maybe this meeting, but I can't decide that alone.

[Stan`]

Thanks @Wijitmaker, @elexis and @(-_-) it will be useful for my presentation, when I get to work on it again...

[Stan`]

I'm falling a bit short of arguments, while there were extensive discussions, it feels a bit like that the decision was rushed by one's skill and not motivated by hard facts. I believe that's because the two languages both did the job so it ended up being a matter of preference. @Wijitmaker can you give me your light on that ? Here are the three slides that will be integrated in the 40+ other slides presenting 0AD.

Why JavaScript.pptx

[nani]

@stanislas69 when will it be, stream?

[elexis]

1 hour ago, stanislas69 said:

I'm falling a bit short of arguments

Did you check these links? One can open them by replacing the topic ID of current forum URLs.

(Even if the decision was based on one mans discretion, then there are still arguments posted for that language, I guess all over the place.)

On 3/11/2004 at 6:17 AM, Zeusthor said:

Related Links:

- Meeting Summary for the Final Scripting Debate

- Announcement of final scripting decision

- Scripting Backend Functionality

- Scripting Frontend Functionality

- Lua & Javacript Performance Tests

- Javascript Proposal

- The Great Scripting War

- The Scripting Flame War

- Macros for Lua Inheritance

- The Preprocessor Alternative

- Initial Language Vote

(For a presentation that should explain why JS instead of other scripting languages is used, one might also compare the 2004 decisions against the 2019 reality of scripting languages (whatever that may be) and check whether it was a good choice or one worthy of improvement.)

[Guest]

(It really doesnt matter even if the reasoning was the name js being one character shorter. We are stuck with it.)

[Stan`]

1 hour ago, nani said:

@stanislas69 when will it be, stream?

Won't be unless I reuse the presentation. But I might release the slides

39 minutes ago, elexis said:

For a presentation that should explain why JS instead of other scripting languages is used, one might also compare the 2004 decisions against the 2019 reality of scripting languages (whatever that may be) and check whether it was a good choice or one worthy of improvement.)

I couldn't load the meeting nor find it in the archive server.

20 minutes ago, (-_-) said:

(It really doesnt matter even if the reasoning was the name js being one character shorter. We are stuck with it.)

It matters a bit. Always nice to know the why especially when you can back it up.

I'm happy they chose JavaScript

[elexis]

4 minutes ago, stanislas69 said:

I couldn't load the meeting nor find it in the archive server. 

See this post for the exact URL, path is oldfiles/users/code/resources/meetings/170104-ProgrammingMeetingLog.txt. (Otherwise there are forum topics with plenty of information on the topic. First try, then try harder, then ask others which have limited time.)

[nani]

@elexis all your links are private or redirect to play0ad.com

Edited April 23, 2019 by nani

[WhiteTreePaladin]

6 minutes ago, nani said:

@elexis all your links are private or redirect to play0ad.com

I think those links have to do with the change from http://forums.wildfiregames.com/0ad/index.php?showtopic=[....] to https://wildfiregames.com/forum/index.php?/topic/[...] It should just be a matter of putting in the correct topic, but it wouldn't work for me either since I wasn't sure what the topics were. The second post had a link to a private post, but Stan has access.

[Stan`]

1 hour ago, elexis said:

Otherwise there are forum topics with plenty of information on the topic. First try, then try harder, then ask others which have limited time.

Weird I went there and Ctrl + F and didn't find it. I will try again.

I am sorry I am wasting your precious time.

[WhiteTreePaladin]

18 minutes ago, stanislas69 said:

Weird I went there and Ctrl + F and didn't find it. I will try again.

I don't know why, but it defaults to the end of the page, rather than the correct post when I click that link. @stanislas69 I've sent you a message with the information you need.

Edited April 23, 2019 by WhiteTreePaladin