I know this has been asked before, but I want to approach it from a slightly different perspective.

I'm working on 2 games at the moment, a project I'm leading, and one my friend is. I'm thinking that it'd be advantageous in both to have a scripting language to control level layout/design, and cut scenes.

So I have a couple questions, the first would be which language to use. The ones I've looked at, but haven't tried to implement are:

Lua
Small
Object C (or something like that)
Spidermonkey (mozilla javascript c engine)
Java
Python
some homebrew language

I mention Lua because it's come up numerous times, but from what I've seen, the scripting language itself is hideous, almost basic-esque, and I really need a c or java style scripting language. If people are just recommending that one cause it's popular, that doesn't help me. I'd like to hear some pros/cons in comparison to the other languages.

Small is an interesting language I read about somewhere on this site, the fact that it has a compiler is a nice advantage (I really need a language that can work with compiled files so they're both smaller, faster, and slightly more difficult to modify). I started looking at the code examples, however, and it seems to have a number of rather odd syntaxes that are not from c, so I'm not sure how much I like it.

I don't know anything about object c.

Spidermonkey comes up because I love javascript, I think it's a great scripting language and the ability to extremely quickly design stuff in a very loose syntax sense is great. The main cons I see here are that it seems complicated to implement (although I haven't tried yet), and I haven't figured out if it has any kind of compiling system (it can compile at runtime, but I'm not sure about saving compiled bytecode).

Java, most likely this isn't a good choice, simply because it's so complex and has a lot of overhead. I might as well code the whole game (sans graphics) in java if I went that route. Plus it has to be compiled to use, and that makes dev time slower.

Python, don't know much about that, but I've look at the language a little when looking at jython.

And last of all, I could go all out and bug one of my friends to code me up a custom scripting language. Obviously this solves any possible problems I have, but takes longer, and perhaps is less reliable. There are certain advantages to using a knowing scripting language (though I'd probably try to get it based around javascript).

Ok, so that's part I. To decide on the language, it really depends on how I use it.

In a nutshell I need for sure some kind of OOP system, so I can have objects for enemies and call functions on them and whatnot. I don't want to be using global namespaces for all the functions, since that makes the scripts uglier and harder to manage.

The second part is how I should go about using the scripting language. I'd like to give level design quite a bit of control through scripting languages, such as enemy placement, setting up default parameters for them. Similar things could be used for cut-scenes, loading in characters, telling them where to move and displaying speech and whatnot.

But should I go so far as to have animation loading, playback, and enemy movement coded in scripting language? Obviously with a powerful enough scripting language it's not a problem of how to do this, or even repeated code, but whether the speed is there and if it's worth doing it that way.

I should note that these are both fairly big games, and will most likely be released as shareware of some sort, so licensing issues are also important. I'd favor the cheapest solution (not including own time).

So I think that about covers it, to sum up, which languages have you used and/or recommend, why, and how much do you use them for?

Thanks,

Marcello

Lua is actually quite C-like, once you get to know it. Lua scripts can be compiled, so that you can load compiled scripts rather than compiling at run-time. Also, Lua 5.0 has classes and inheritance. Via the LuaBind add-on, you can even give Lua a base class, let it derive a class from it, and then derive a class in C++ from that Lua-derived class and use it like a (mostly) regular C++ class. Kinda nifty.

Python is designed from the ground-up to be object oriented, so its OOP syntax is probably a bit cleaner than Lua.

I've always felt that the primary determinant with scripting languages that have decent syntax is the code-to-script interface. Via LuaBind, this interface can be made virtually transparent under Lua. I have no idea what Python's or Small's code-to-script interface is like.

-- for comments and lack of {}'s is pretty bad.

[edit]I was looking at http://www.lua.org/manual/5.0/manual.html#2 and I've decided I really can't stand that language, it's just too similar to languages I hate, and it's really stupid to use two different languages for the same problem (I have enough trouble switching between java, c++, and php as it is)

Marcello

python would be great, assuming you can get it to integrate with your program ok. It is a really stable language, and is quite easy to debug, which is what you want in a script, correct?

True, the significance of whitespace at the beginning can get quite annoying, but you get used to it after about 5 minutes. It also has a really short learning curve as well...

Marcello, don't judge a language by its syntax (... unless it's perl). You said you liked Javascript, Lua is really very similar.

Yeah, scripting languages aren't supposed to be more readable or anything

If you want to use C-syntax, why not just use C? Why bother with scripts at all?

What else is there to judge it upon? But I'm not asking people to defend lua, which is all I'm getting here, I want to know the alternatives and for example, what makes lua better/worse than them.

Well designed clean code in any c style language is quite readable. I'd like to say that for all languages, but perl is one of probably many exceptions.

Surely you agree that learning a entirely new and different syntax just for a freaking scripting language (I mean, wtf is ::= or :== wtf... that's just messed up).

That's a silly question. I'm not gonna hardcode the levels, that means the level design can't be separated from the coding. That means more debugging, slower level design, and it requires someone who can code in c AND knows how to compile, link, etc. with the rest of the what could quite possibly be incomplete or in development source code. If it's all offloaded to a scripting language, it means more control, more separation, and frankly, cleaner code in the end.

Marcello

And extensibility drops to rather near nil, because you can't go around distributing DLLs for new levels.... I doubt people would like that

I can say that python has been used at least once in a professional game dev environment: disney's prime 3d Game Engine (now partly open sourced at http://www.etc.cmu.edu/panda3d) seems to use it heavily. So it's probably going to be viable in terms of efficiency and etc for whatever project you may be conceiving. And it's a very well developed and well liked language, and it's known for being pretty ("pseudo-code that compiles"). And it seems to have been designed around, and to support with tutorials and docs, methods of interacting with C/C++ code. Soo ... you may want to give it a closer look.

As a side note I would say that a script being "slightly more difficult to modify" is not exactly a good thing; imo the more accessible your game is to modder types the more likely it is to have a loving fanbase and etc. Can't see why this is such a bad thing. But if you're really worried about it you could try encrypting the files and naming them oddly, which (though obviously not perfect) should keep away idle prying while only slightly increasing load times.

Anyway, take my advice with a grain of salt, of course; I'm no expert

Actually it's more of a problem of modding the scripts to cheat at the game and get ahead. It's not a big deal, but there are obvious speed benefits to compiling beforehand, for example if there are lots of comments and excessive syntax, there's no point in extra load time.

Marcello

Well, I suppose you could always, in the final release, have the main level files encrypted but also include some mechanism for providing seperate, different level files / config files. Definitely if you're going to have an extensible program, it'll be worth it to consider adding a mod system

Anyway, as another plug for python, it does do the bytecode for fast loading thing, just in case you didn't know.

You didn't understand what you were reading. I can understand that, because it took me a while to figure out that the ::= stuff wasn't part of the language.

The document you were reading is a very technical document about Lua; it specifies the language as a grammar. Unless you understand how to read a grammar (and I don't mean as in English grammar. I mean a descriptive grammar), some of the symbols they use can confuse you.

::= isn't part of Lua. They just use '=' like everybody else. When the document says something like, "var ::= Name", what they mean is, "The concept of a variable is defined by a thing called a 'Name'". When they say, "stat ::= for Name `=´ exp `,´ exp [`,´ exp] do block end", they're saying that the stuff after '::=' is a statement.

Really, the Lua manual sucks for learning the actual language. I'm of the opinion that the manual is why Lua isn't nearly as widely used. It's best to take a look at functioning Lua code.

With dynamic linked-libraries, this is not the case. You can easily build "scripts" as plugin-type .DLLs. In fact, it would be much easier than the simplest scripting system, because it is just native C/C++.

If you're writing low-level C. But, good, protected, high-level C++ can be just as "bug-free" as a scripting language; ask to Gillius about that.

However, more importantly, when something needs debugging, it gets debugged with a C/C++ debugger. I know of no scripting language that has a debugger that can compete with VC++. As such, when a script does have a bug in it, it is much easier to solve in C/C++ than in a scripting language.

Bah. Why is it any slower? Granted, it depends on what the script is supposed to do. An AI script will look a lot like C, but a map script (that tells the system where to spawn things, for example) written in C is pretty ugly, since it really is just a list of strings and positions.

Of course, this argues against a C-like syntax in your scripting language.

<quote>and it requires someone who can code in c AND knows how to compile, link, etc./quote]

Well, they need to code in C in order to deal with your C-like scripting language, right? Also, compiling is simple: press F7. If it's more complicated than that, get better compiling tools.

Hence the .dll paradigm.

Actually, it means less control. Because you're programming in a limited scripting environment, you can't do all of the little low-level tricks that a C program could; that has to be offloaded to other code.

.DLL's give you just as much separation as an actual script.

As far as clean code is concerned, it is uglier to bind to a scripting language. As clean as LuaBind is, it is still cleaner to not have the LuaBind commands/variables that bind the class to Lua. These commands, whether they are LuaBind, the Lua API, the Python API, etc, are layered on top of an existing class interface; an interface that could be directly used by a .dll. As such, the .dll interface is the cleanest you can possibly get. It has the bare minimum code: a C++ interface.

As such, the advantage of using a scripting language at all is ease of writing the game. Your scripting language should make it easier at the given task than C/C++. Otherwise, just build a .dll interface and leave it at that.

DIE!

Korval, you're argument makes a lot of sense. I've never thought of it that way before. So, yes I can see the advantages of using a .DLL file. I agree with you on this one.

Anyone who thinks "LuaBind" is a clean interface is at least as crazy as I am.

So you do think it's a clean interface then?

As for using DLL's - my opinion is that you're unnescessarily restricting yourself to people using one particular operating system, so I'd recommend against it for that reason.
If you don't care about portability, sure, it may be a useful thing. Otherwise, I'd stick to a plain scripting language.

As I understand it, one of the advantages of using a scripting language is that it does not have to look like C, but can be more high-level. Have a look at Amit's page for some (old?) links and discussions on scripting languages.

No, I'm just crazy

It doesn't get much cleaner than LuaBind, really. Just create this templated thing that looks surprisingly like a class declaration, and you're done. It's all template meta-programming magic and so forth that is completely hidden from your code.

The only way an interface can be cleaner is if it reads and parses C/C++ and can just take a class and turn it into an interface without any added code.

You can use Linux .so's, too. You'll have to do a little #ifdef'ing around the code that actually loads the .so/.dll files (since it's OS specific), but after that, the interfaces are all the same: you get function pointers and call functions via them.

Any platform worth developing a serious game on has some form of dynamic linking, so the paradigm will work on any modern platform.

Hmm ... one advantage of a scripting langauge is that ideally you will be able to change the script code very quickly and while the engine is running (much less significant compile time pauses, etc) such that you can tweak scripts and such in real time, and quickly. I would guess you lose this in a .dll approach; the process of recompiling the scripts and such would probably slow the tweak process by a somewhat relevant amount.
As a side note, python has a debugger, and there do seem to be commercial, fully-featured ides for it, though I can't say I've tried one, unfortunately.

I've yet to see a scripting system that will actually re-load the script in the middle of using it. After all, it's not like the interpreter is constantly reading the script file from the disk.

Also, since the script is running at the time (it may have instanced classes and variables and so forth), changing it without restarting could very well have highly negative consequences. At the very least, the domain of the script needs to be restarted. If it is an AI script, the AI character should be respawned. If it is a map script, the map needs to be reloaded.

For $150-200. Hardly a reasonable price for a scripting language IDE. I would have been willing to go with $50 or so.

I don't know, once I finally get my VM done (ohy...) it wouldn't be hard to reload a script everytime its saved. Not a big deal if you just replace the code. There can be problems, but that should be expected.

Also imagine having a console in the game that lets you run commands, load/reload scripts at runtime.

I think I'm gonna try spidermonkey, see how difficult it is to implement. Mainly because it's my favorite scripting language. :-)

Marcello

Marcello, I thought you would have usd rhino in your java apps anyways....

Any serious game should have a console in it for entering commands. That's a vital debugging tool.

I'm guessing that there are IDEs in the $50 price range as well, and I wouldn't be surprised to see one for free, either. I'm simply not using python enough yet to make it worth searching around. I didn't mean to imply that that was the only IDE for python with an graphical debugger; it was just meant as a demonstration that such things exist for the language.

Jesse Schelle (developer of Toontown Online, works at CMU's Entertainment Technology Center) mentioned exactly this kind of action in an IC speech (as part a freshmen CS course [IC] that is basically a lecture series meant to define CS through examples; features basically a researcher a week explaining what cool stuff they work on). So I think the technique is certainly feasible.
I do agree that there would be some issues with it, but still, the faster one can see what the code does, the faster one can iterate through the development cycle and such; it sounds like a nice feature to have.

Annnyway ... good luck, Marcello!

I don't really see what the problem is, especially if each object has its own scripting system instance.

- Close the object's script
- Clear object states
- Load the script anew
- Relink object's script hooks
- Initialize object state

If multiple objects share the same scripting system instance, then provide an interface for accessing that instance and do everything under the hood. Have the script-reload post a message to all objects using the particular script instance to reset themselves and re-link.

Wouldn't it make more sense and be less of a hasle to just go back to the main menu, change the script, then start again? Although, changing it while it's running shouldn't be too hard, either.

Which is not the same as reloading the script while using it. The state information is lost. As such, if it's an AI script that's doing something odd, you can't just reload the script in the middle, as the state information could be responsible for the oddity.

So anyway, I'm trying to compile this spidermonkey thing and it's designed for msvc++, though it does compile on unix/gcc and mac... I could compile the dll in msvc++, but I'd rather work on the game itself in mingw.

Any ideas as to how to get that working in mingw (supposedly the entire mozilla tree can be compiled in mingw since v1.4b, not all features supporting, but I'd assume javascript is a critical part (considering the entire interface is coded in it)).

Here's an interesting link: projects using js engines Couple game-related projects there.

Thanks,

Marcello

Yes. And people have written raytracers in PostScript, of all things. That doesn't mean that it's a good idea.

Not that I'm saying that JavaScript is unreasonable for a game; I've never used it. But it was designed for something wildly different from games, or even being embedded in C/C++ programs, unlike Python or Lua.

I believe if you try this in Lua it should just work. (i.e. call lua_dofile again) Even if you do this in the middle of a lua method it will just rebind the method's name to a new instance, and the old one will eventually get garbage-collected.

Any comments, Korval?

Pete

it was defined as a scripting language. That's why there's a "script" even in the language name.
And I'm pretty sure that there're more games written in JavaScript than games written by you in c/c++.
There's even a diablo clone done in JS.
I also think that most browser are written in C/C++, so it was designed to be embedded in C/C++ programs.

And if you can create neat games using JavaScript in a browser, just imagine what could be done if that javascript has access to game specific native classes.

Here's a link from the game developer's conference next year - there's going to be session devoted to Lua.

Pete

If the state information is stored in the object and not the script, this is not an issue; the object can keep its original state. If the state information is stored in the script, the state's details can be saved, and then restored after the script is loaded. It isn't a problem that's unsolvable, it just takes the proper logic to do what you want it to do... just like any programming problem.

I don't think that will necessarily work. At least, not for the way that I use Lua. What I prefer to do is have each Lua script file represent a class (thanks to LuaBind), with an exposed global function that generates instances of that class. Which means that Ai scripts are actual instances of the pure-virtual AIObject base class, for example.

A LuaBind class is built out of a table of functions. Even if you change the file implementing the class, instances that have already been created will still point to the old methods.

PostScript has "script" in it's name. That doesn't make it an appropriate language for writing ray-tracers or non-printer code, even if it can be done. Just because you can do a thing in a language doesn't mean that it is the appropriate use of that language.

God, it was really nice not having you around.

Most printer drivers are written in C/C++, too. That doesn't make PostScript embedded. A scripting language is considered to be "embedded" in another language if the server language can expose an arbitrary API to the script language. Normal JavaScript doesn't have this facility, but both Lua and Python do.

I admit that it is possible to have hot-swapping of scripts. However, it isn't a trivial exercise, nor does it just come with any particular scripting language (unless you write one with that in mind. Which is doable, and might be a laudable goal for a scripting system). You have to do work at it to make it happen. Granted, C/C++ can't do it at all, even with .dll's.

Was that necessary? >_<

My whole point is that you said that JavaScript can't be used to code games. Which is wrong. And the funny thing is, that you can't argue about that, since there're enough games which were coded in JavaScript.

I must admit, that I have problems following you here. I guess the idea is that since both "JavaScript" and "PostScript" have "script" in their name, and postscript is not intended to be used as an embedded language, JavaScript can't be used as an embedded language as well?

Agreed. Of course it's not the server language, but the server that's exposiong an API which can then be used inside a script.

Um... of course not, since the (to use your words) the "server" is exposing the API.
The DOM exposing the structure of a HTML document is not part of javascript. It's just an object exposed by the server (the browser).

Wow. That's news to me.
Last time I had to write wrapper functions in C and register these functions to LUA.
Can you tell me how Lua (or Python) can do this diretcly? Would make things more easy

BTW, the way of using LUA as an embedded language in your own programm is almost exactly the same as using SpiderMonkey

To make a long story short: You can easily use javaScript for games, and there's nothing wrong with that.

JavaScript is an embedded Scripting Language. In fact, it was desiged to be an extension language.

And even in an environment not specific to games (web browsers), you can use it to code great games. Now imagine what you can do with it if you embed it in a game specific environment.

Ok, arguing is all very fine and well, but does anyone have an answer to my second question about how I actually can use spidermonkey?

Marcello

I just downloaded the spider monkey source.
In order to compile it, I had to do some changes.

First of all, you have to define
-DXP_PC -DWIN32 -DEXPORT_JS_API -D_declspec=__declspec

Then I changed jstypes.h to make sure the gcc int64 version is used even if win32 is defined:

#elif defined(WIN32)
typedef long long int JSInt64;
typedef unsigned long long int JSUint64;

In jslibmath.h change

#if defined(_WIN32) && !defined(__MWERKS__)
#define JS_USE_FDLIBM_MATH 1

to

#if defined(_WIN32) && !defined(__MWERKS__)
#define JS_USE_FDLIBM_MATH 0

Then I got an error like this:

D:/GameProgramming/JavaScript/spidermonkey/prmjtime.c:429: undefined reference to `JSLL_Zero'

Which was fixed by replacing JSLL_Zero with 0.

Then it compiled without any errors...

[edit]
The reason it was not defined was that I removed the jslong.* files from the project.
After I added these files I had to change some lines in jslong.h

static JSInt64 ll_zero =  0x0000000000000000LL;
static JSInt64 ll_maxint = 0x7fffffffffffffffLL;
static JSInt64 ll_minint = 0x8000000000000000LL;

Forgive me if this sounds ungrateful, but how exactly do I 'compile'? I looked through the readme, and tried: nmake -f js.mak (builds the vc++ version), make -f Makefile.ref, gives me the following:

sed: -e expression #1, char 2: Unterminated address regex
cat: ../../dist/WINNT4.0_DBG.OBJ/nspr/Version: No such file or directory
d was unexpected at this time.
make: *** [all] Error 255

But mainly I haven't a clue what I'm doing.

Marcello

Take the .c files in the directory and feed them into a compiler.
In the worst case you'd line up all .c files

I'm using this makefile, which was generated by slickedit after I told it to use all files (but js.c - since this file is a demo).

I found his tone to be unnecessarily condescending.

<quote>My whole point is that you said that JavaScript can't be used to code games. Which is wrong. And the funny thing is, that you can't argue about that, since there're enough games which were coded in JavaScript.quote]

But I didn't say that. Indeed, I pointed out that PostScript could be used for very non-printer-related tasks a number of times. My point was that just because you can use a hammer to screw in a nail doesn't mean that you ought to. And just because others do something doesn't mean that it's a good idea.

No, I was simply refuting your assertion that the fact that JavaScript had script in the name meant that it was intended as an embedded language. You did say, "That's why there's a "script" even in the language name," thus suggesting that the fact that it had "script" in the name was meaningful in terms of it being an embedded language.

Not an "arbitrary" API. It exposes a particular one, but if it can't expose arbitrary one, then the scripting language cannot grow and change. It can't be used for an arbitrary purpose without having to build it all in JavaScript.

I understand that there is a way to run JavaScript using new API functions. But, it was not designed with that in mind originally. And I would imagine that this more recent addition probably isn't that well integrated into the rest of the language, much like making classes in Lua was difficult (until LuaBibd just did it for you). Granted, I could be wrong, but it certainly stands as a possibility.

Use LuaBind. It's GoodStuff(tm). It writes them using template metaprogramming/magic. It's a bit strange to look at, as I can't see how some of it is valid C++.

BTW, technically, you don't have to use wrappers at all. All you need to do is have your C/C++ code use the Lua stack for function calls

Not that this would be a good idea. Indeed, it probably ranks up there with using PostScript for raytracers. Or maybe JavaScript for games

But the script in JavaScript is used to show it's a embedded language.

Sorry. What I meant was "They even put a script in the name to show it's a scripting language".

Korval, the API used to access the server is not implemented in the scripting language. Not is is exposed by it.
It's implemented in the language the server is written in, and exposed to it.

You can't expose an API using LUA. You can create wrapper functions using LuaBind, but this doesn't produce "pure Lua" code.
That was my whole point: That your argument that Lua and or Python can expose an Api, but JavaScript can't is just bogus.

Korval, there's no need to "add something" to JavaScript. You're not changing the language. All you do is to expose some new objects and or functions to it.
And JavaScript was designed as an embedded language... I'm nost sure why you try to make up here...

And still it would be the server that's doing the work. Which makes sense

If you compare the way the integration with C/C++ is handled in Lua, Python and Javascript, you'll realize that it's almost the same.

Don't try to insist that JavaScript isn't a good choice. Try to keep an open mind.

I have the impression that you still link "javascript" with WebBrowser because that was the first application using JavaScript as an embedded language.

Hm... I think using JavaScript for games is better then talking garbage about PostScript raytracers
As I said, there're are many good games written in JavaScript.

But before we get down to that level again, could you please give me 1 reason why JavaScript should not be used as an embedded language for games?
Besides the fact that the name reminds you of postScript?

Not too intrude on the discussion of titans here; but javascript specifically has come along way from just scripting webpages; it even has a standard -

http://www.ecma-international.org/publications/standards/ECMA-262.HTM

Javascript is an integral part of the Mozilla browser project:

Using Spidermonkey is much like using Lua in that the api gives you a stack to pass values back and forthe to the interpreter.

It isn't garbage; it's the truth. That code exists out there somewhere, as strange as it may sound.

Because it wasn't designed for use as a general-purpose embedded language. It is a web browser language that was eventually extended with the ability to be used in more applications. Lua and Python are designed with general purpose programming in mind. Lua, for example, was built for speed. Can the same be said for JavaScript?

I think the better question, considering that there are two other, quite viable, alternatives, can you give me a reason to use JavaScript for non-web browswer tasks?

I know there's a JavaScript raytracer ...

Please tell me, what feature you need is missing?

Not true.

While JS was certainly not built to be the fastest kid on the block, it is pretty fast.

This is not the point here, but I'll give you some reasons later on. First I'd like to notice that "because other solutions are around" is not a very strong point. That's why there're quite a few languages besides C.

Ok, now that we have agreed on that there is no technical reason not to use Javascript as a scripting language for games, we come down to taste. Why would somebody want to use JavaScript for games?

The obvious reason is "because you can". On allegro.cc are at least 3 people at the moment using a javascript engine. And if you consider the small amount here actually interested in scripting , that's not bad at all.

But why do they want to use it? Why not Lua?
Hm... but why Lua if you can use JavaScript?

JavaScript is a powerful language. It's object oriented but is also great for procedural jobs. So the language itself is easy to use and offers lots of features.

Easy to learn It really is

Debugger support That's an important point for me.

Number of users JavaScript has a high user base. If I use JS as a scripting language I've a lot of people who could design levels.

Scripting system is easy to set up I downloaded SpiderMonkey when Marcello asked for help. And now I've a running scripting system. Neat.

Contexts I can execute scripts in different contexts but need just one runtime.

Security I can run scripts with different security levels easily.

For me "powerful language" and "number of users" was the key. I was toying around with the idea of using javascript for some time, but after I realized how easy it is to set up (which is the 3rd point) I'll be using it from this point forward.

I want to close with:

I gave you several above. Can you give me one reason not to use it?

Just a quick question: How big is the spidermonkey library (or VM or whatever) - i.e. if I add JavaScript, how much overhead does it add.

I ask because one of the benefits of Lua is that it's a small language.(liblua on my system is <100K)

Also, what about Guile or Io?

Pete

The js lib has around 550kb on my system. I'm not sure if I can reduce that (I didn't really look at the source, I just compiled it). But I guess you can get a smaller executable if you include only the unicode or non-unicode version of the string functions.
I'm also not sure how much of the debug stuff can be thrown out for a release lib.

But yes, liblua is smaller.

Another language that I found to be very nice was C-Smile. It is more like java, but has certain traits of javascript.

I'm surprised no-one has mentioned C#. The great thing about C# is that the .net framework gives you an interface to the C# compiler, so it's a simple matter to compile C# source files on the fly. C# is useful as a scripting language because it's faster than Java but much more easy to use than C or C++.

Wow, C# sounds great aside from the unfortunate platform dependancy thing.... [/sarcasm]

edit
This doesn't count, its not even a 1.0 release yet...

And why not? I've heard it's very good at what it does.
EDIT: Wow, this thread is getting long, and interesting. I'm probably going to make a 2D game engine when I'm done with all of my other projects and want to have a scripting language in it, but I don't know whether to go with javascript (which I already know) or lua (which I don't know, but looks easy to learn, and is smaller). I guess I'll have to try both.

Speed?

Interesting, render a flower took 27.74 sec…=_="

Ok, let's see... I got spidermonkey working and integrated into an extremely simple C++ wrapper so I could integrate it into one of my games to experiment with.

Speedwise, I loaded a script (var i=6000,n=0; while(--i>=0)n+=i; print(n);), compiled it, ran it every game 'step' (60"f"ps), and it had no impact on speed, going up to 7000 started to affect the framerate, but there will be very little looping in-script for my engine, so I'm not concerned about speed.

Obviously speed-critical components will be written in C++ no matter what language I'm using, so it's all rather academic. I'm not gonna write a ray tracer in it.

Guile, Io, both are syntaxes I'm not familiar with, so there's no real point in going with those over python for example.

c-smile looks pretty cool, considering it's java and javascript. I'll have to check that one out. From the site and downloads (haven't grabbed it yet), it's not clear if it's intended to be embedded or standalone. Plus there's no mac port, but I'm guessing that's not uber difficult considering what it is. (Not to mention another 'new' syntax, although it looks identical to javascript with better in-script class support.)

As for C#, allow me to say, no. If I were to go that far, I'd use java. But both are overkill. Plus C# sucks by definition.

I don't know. I don't use it. But there could very well be something, considering its origins.

That's not a reason; that's a justification for a decision that has already been made.

That's hardly an open-minded statement, as it presupposes the notion that JavaScript is a better language.

What makes it "easy to use"? In what way does it "offer lots of features"?

What is the C/C++-to-JavaScript API like?

What do you mean by context?

Can't you do that by simply restricting the API that the script is allowed to use?

That gives me an idea. I've had this raytracer notion in the back of my head for a few years now, slowly refining it. And there are a number of non-performance parts of it that it would not be a bad idea to script (material/lighting computations, camera/ray generation, etc). This would make it easier to write shaders and so forth for the system.

you have no idea, but you think it's best to bash it first? Have you considered to STFU if you don't know what you're talking about?

You have no idea what you're talking about, do you? Please enlighten us... what is that cruel origin?

You realize that I just reversed your statement ("But why use Javascript if you can use Lua")? Of course you do.
And I totally agree.

Browse to the spidermonkey website and read.

See above.
But mainly you provide a callback dealing with get / set requests for the different attributes (that's something lua can't do) or just wrappers for the differnt functions.
Pretty much the same in every embedded language.

Again, check the spidermonkey website for a more detailed explanation.
Mainly it's the context the script operates in. Providing the environment for the scripts.

That's (mainly) what you do. Just using a well defined niterface. Again, just read the intro pages on the spidermonkey webpage.
Infact, had you read them before starting this discussion, we could have avoided all this.

With one significant exception. Lua was designed with 2 features game developers like: small size and speed. And LuaBind builds off of this (granted, the template metaprogramming kills off the code-size benifit) by adding ease-of-use.

Lua ought to be highly considered by anyone who might want to use a scripting language for games, for the above reasons alone. JavaScript has to justify its use, because it doesn't have the above reasons.

I did. The result was hardly what you expected.

The API is no better or worse than what you get with Lua. LuaBind completely blows it out of the water in terms of ease of use.

As far as the language itself is concerned, I didn't see anything in particular that was significantly better or worse than Lua. Sure, it has a well-defined notion of classes and inhieritance, but LuaBind gives Lua a similar notion (I recently discovered that it actually extends the Lua language a bit).

Why would you want to?

Assuming what I read was actually anything valuable. However, what I found was a language/API that was no better than vanilla Lua. Considering that Lua is smaller (library size) and likely faster, there's nothing here to convince me to switch, or even recommend it as a good alternative to Lua.

The API isn't the hacked-on API that I imagined that it could have been, but it doesn't show any real improvement over plain Lua. And plain Lua has LuaBind to cover up the nastiness.

As an example of what LuaBind can do, observe:

Let's say that these are classes we want to expose to the scripting language. One of them is just an API class. The other is a base class that we want the script to override with a new one:

39 lines.

The following is 100% of the LuaBind code required to register these:

33 lines. Fewer lines than it took to declare and define the classes to begin with. I seriously doubt that the SpiderMonkey API can do that.

Also, note the lack of possibility for errors. If I change the signature of functions, unless the function is intended to be overriden (and those API's should be virtually frozen the moment they were first used in a script), I don't have to change anything in the registering code. It implicitly knows the function signature. The other exception to this is function overloading, where you have to specify an explicit signature. So the potential for registration errors is quite low, even with the exceptional cases.

Does it do the same with C? If the LuaBind api is just C++, thats a reason not to use it. For me at least.

Tomasu: "void MyFunc()" <-- No lua state (I think that's right, but I wouldn't know)

Right. That's we wre telling you from the beginning. As I said, if you had read the site, the whole discussion had never started.
And since you realized this now (phew... took quite some time), maybe we can stop this discussion now? Thanks.

Mainly because you can then do stuff like this in your script:

sprite.frames = "image.bmp";

Which is exactly the same as

sprite.setFrames("image.bmp");

Just without the function call. That means you can use attributes like attributes while you still ensure that you only have a single point of access. That's neat.

We never inteded to do that.
If you take alook at the discussion here, it was you who tried to convince the others not to use spidermonkey

Since it's older than LUA, I guess that's ok. And it's pretty easy to write some wrapper generting code, and the c -> js connection is IMHO simpler than the way LUA is doing it... so I don't miss LUA bind much.

As I said, that's nothing I'm concerned with. The API functions are exposed once, it's not something that I need to change often.
But yes, it would be neat to have something like luaBind.

But that's just a hassle for the engine coder. The gained benfit from javascript is IMO worth the extra (one-time) work. (Before Korval asks what benefits, I'd like to add a "see above").

Can anyone point me to a place where I can download spidermonkey in a zip or tar package (preferably zip)? I tried their website but all I can find is an online listing of all the files, and I really don't want to have to download each one seperately.

at the top of http://www.mozilla.org/js/spidermonkey/ it says:

The mirrors link led me to http://mirrors.xmission.com/mozilla/js/ and I grabbed it there.

[edit]
And now to continue the discussion/argument:

My choice for javascript was because, a) I've been using javascript in web for about 7 years now (the days of "ripping off" scripts and tweaking them), b) I worked with the Rhino engine (a java implementation of javascript) for scripting my own java app (although I got so into messing with rhino, the app ended up being a pretty funky javascript interface, but not what I had intended), c) lua looks ugly as hell.

Some of the nice things about javascript come from its uber-loose interface, such as the feature to leave out semicolons if you have a newline.
In one of the games I'm working with a game designer who hasn't used any programming languages before, and I'm not gonna make him learn some syntax for a language even I'm not familiar with.

As mentioned before, I don't switch between languages very easily and have trouble enough going from java to c++ within the same day (mainly because of bool/boolean though ), so it only makes sense to stick with a scripting language I'm actually real good in.

Although I haven't looked at lua scripting much, so perhaps it has this functionality, but to be able to do stuff along the lines of:

character.name = "Alexis"
character.age = 23
for (attribute in character) {
    print("character attribute " + attribute + ": " + character[attribute])
}

is one of my favorite features of javascript.

Plus this is pretty cool:

character.onhit = function (event) { ... }

You can even dynamically generate functions at runtime using eval():

function characterHit(event,character) {
  print(character.name+" got hit! HP -"+event.hitloss)
}
function makeCharacterHit(char) {
  return eval("function(event){characterHit(event,characters." + char + ")}")
}
characters.bob.onhit = makeCharacterHit("bob")
characters.fred.onhit = makeCharacterHit("fred")

Of course, that's pretty evil and it could probably be done a little cleaner than that.

[edit numero 2]
I should probably mention that I'm not trying to change what scripting language someone else is using, I was just trying to get an idea what was out there and what people felt about them. Though, I'm thinking of sticking with js, I'm obviously not going to try to convert anyone who's already using lua and liking it, since obviously they've taken the time to learn the language and are familiar with it.

I should also mention that the 500kb overhead added to the exe isn't really a big deal since the games will most likely be over 10 megs each, and possibly on CD.

Marcello

Ok, thanks. I got to that page already, but I downloaded the wrong thing (the jsd one :/)

Just for your information (and for fun!):

character.name = "Alexis"
character.age = 23
for (attribute in character) {
    print("character attribute " + attribute + ": " + character[attribute])
}

is done in lua that way:

character.name = "Alexis"
character.age = 23
for attribute in character do
    print("character attribute " .. attribute .. ": " .. character[attribute])
end

-- faster alternative:
for attribute,value in character do
    print("character attribute " .. attribute .. ": " .. value)
end

Function can also be dynamically generated:

function characterHit(event,character) {
  print(character.name+" got hit! HP -"+event.hitloss)
}
function makeCharacterHit(char) {
  return eval("function(event){characterHit(event,characters." + char + ")}")
}
characters.bob.onhit = makeCharacterHit("bob")
characters.fred.onhit = makeCharacterHit("fred")

becomes:

function characterHit(event,character)
  print(character.name .. " got hit! HP - " .. event.hitloss)
end
function makeCharacterHit(char)
  return function(event) characterHit(event,characters[char]) end
end

characters.bob.onhit = makeCharacterHit("bob")
characters.fred.onhit = makeCharacterHit("fred")

As can be seen, the syntax for generating function is actually simpler in lua, (IMHO, at least )

I don't see why you find lua so ugly! But then seeing how the languages are similar in these examples, I suppose JavaScript can be an alternative, if its speed is correct. What I like about lua is the fact that everything is a (pretty fast and convenient hash table). But I don't know much about JavaScript...

No, sorry.
What you had to do in Lua would be more like this

for attribute in character do
    if character.listAttrs[attribute] do
         print("")
    end
end

Since you can specify what attributes should be listed in that for loop.
But yes, Lua and JS are very similar

except lua uses end/do which is lame by default.

Marcello

Well there's nothing one can do about other people's tastes

HAH!
All these loosely-typed, object-oriented,interactive,clear-syntaxed,
cross-platform scripting languages are for LOSERS!

REAL men (and women) use DOS BATCH SCRIPTS

Kuba, you are mistaken Real men use a hex editor.

No, real men hard code everything in asm!
Anyways, I can't seem to compile spidermonkey. I use:

C:\spidermonkey>gcc -c jsapi.c jsarena.c jsarray.c jsatm.c jsbool.c jscntxt.c js
date.c jsdbgapi.c jsdhash.c jsdtoa.c jsemit.c jsexn.c jsfile.c jsfun.c jsgc.c js
hash.c jsinterp.c jslock.c jslog2.c jslong.c jsmath.c jsnum.c jsobj.c jsopcode.c
 jsparse.c jsprf.c jsregexp.c jsscan.c jsscope.c jsscript.c jsstr.c jsutil.c jsx
drapi.c prmjtime.c -DXP_PC -DWIN32 -DEXPORT_JS_API -D_declspec=__declspec

And I get a whole bunch of errors. Here's the end of it:

I can't show them all because there are too many (it goes past the maximum amount of text on a ms-dos window ) and gcc just doesn't feel like redirecting it's output to a file (I do gcc ... >output.txt and it still go to the screen, I'm starting to think it uses a different stream, such as stderr). I've never had good luck with compiling packages like this.
EDIT: Also, I did follow spellcaster's instructions on how to compile it.

REAL (wo)men write out circuits for ROM chips. Assembly. That's for lamers!

Ah, the good ol' days of circuit-based games. It's amazing how far we've come.

Real men/women build their own cpu with the game in the registers

I had to use -XP_WIN instead of -XP_PC.

Marcello

It still doesn't work

Didja try the makefile spellcaster pasted earlier?

Here's my slightly modified version.

Marcello

Yep. I get this error:

C:\spidermonkey>make -f makefile.txt
makefile.txt:42: *** missing separator.  Stop.

Which is this line:

# Pattern rules
COMPILE=gcc -c  -g -ggdb -Wall -Werror -w -o "$(OUTDIR)/$(*F).o" $(CFG_INC) "$<" -DXP_PC -DWIN32 -DEXPORT_JS_API -D_declspec=__declspec
...
$(OUTDIR)/%.o : spidermonkey/%.c
    $(COMPILE) # <----- this one

That's cause you need to convert the spaces to tabs. Try my version.

Marcello

Yeah, your version worked. One question, though. Do you happen to know the command to make a shared library in gcc? Thanks, btw.
EDIT:
Ok, I found it.

Just while we have so many people all fired up talking about scripting languages, I have a small question:

Is there an easy way to remove functionality from embedded Lua, or from Python or JavaScript for that matter?
I mean, if I use some scripting language, and I don't want the user to have the ability to erase files using a script in my program, then is there an easy way for me to just say "look. I want you as the scripting language, but you can't bring the following functions with you: fopen(), system(), ..." or whatever.

In Lua, you just don't give the script that ability.

The way it works, you have an object called the "lua_state". This object, conceptially, represents an instance of the interpreter. To give a script the ability to call a particular function, you register it with Lua. Now, Lua comes with a library of standard functions, one of which is for IO. If you don't register the IO library, and you don't expose user-defined functions to allow the script to write to a file, then it can't have IO.

If you want to have some scripts that can do this and others that can't, then you have several "lua_state" objects. For some "lua_state" objects, you allow IO, for others, you don't.

Yes, we all know how much you love lua, time to stop ranting.

javascript doesn't have fopen/system/etc. Plus it has a security interface thingy:

http://www.mozilla.org/js/spidermonkey/apidoc/jsguide.html

Although it doesn't seem uber-simple, I'm not sure how powerful you need that stuff in a game. That security manager is so you can have like core scripts in the game which can't be screwed up by scripts users load in.

Marcello

Python also has a system to run 'untrusted' scripts without being a security threat. By default, however, python lets a script do anything, so it would be a good idea to remember to implement that if you want to implement a user addon system.

TF: Actually, his comment was a relevant and good answer to the question, I thought. He probably only mentioned LUA because that's what he knows about.

Bear in mind the NJS Javascript interpreter (google for it)

It's probably not as complete as the Mozilla one, but a lot smaller, simpler, and can be extended by adding new classes quite easily.

There is a class which enables File I/O, but I'm sure it can be removed at compiletime (or possibly runtime, by just setting its constructor to null)

Mark

What I read of that post, he's already said at least once in this thread.

Does njs javascrit interpreter have a compiler?

Marcello

I appologize for answering his question.

Where? I may have mentioned that it was possible using Lua, but I certainly didn't mention the specific mechanics involved in actually accomplishing the task. And the specific mechanics involved are important to know when one is evaluating a language for use, based on a set of critera.

Come on guys, stop the bickering. Sure it might be entertaining for you guys, but for the rest of us it's just spam.
If you want to talk about how much you hate each other or whatever it is, you should get together on MSN or something equally as not-near-me.

"Hey, how's it going?"
"Oh sure, I'm great."
"You would say that wouldn't you, you always think you're the greatest."
"Oh, and I suppose you think that you're better? You should just go back to your little hole."
"At least I have a little hole..."

heh.
Sorry, I'm just entertaining myself with the idea if having a hate meeting. If there is one thing I like, it's to hate.

As for the scripting stuff, thanks for the reply. If I feel like using one of those things, I think I'll go with PYTHON! It seems that it is just as good a language as the others, and perhaps a more useful language outside of scripting. I'd rather learn a useful language than a language just for the few games with scripts that I make.
Not to say the others aren't useful, I just like the look of Python. Lua, by the sound of it is the easiest to plug into your game, but I was put off by it about a year ago when I couldn't get the damn thing to compile without stuffing around with it for a long time... I figured that if compiling it was this bad, then making it work with my game wasn't going to be easy.

Well. Back to lurking for me.
waves

Heh, I use javascript more frequently than any other scripting language. Mainly because I can use java and C++ for serious stuff. But between web and flash, javascript is used quite a bit.

I guess now that I have this possibility I should go back to paper and start designing the interface.

Marcello