Standard Scripting Library about tsc HOT 9 CLOSED

Is Ruby already accessible in SMC?

Has any thought been given to making Python accessible as a 2nd language option? Offering multiple scripting languages might offer some flexibility (though the core game levels probably need to stay consistent)

from tsc.

Is Ruby already accessible in SMC?

SMC embeds mruby, a minmal Ruby implementation similar to Lua in its goals. Have a look at the development subforum for more information on scripting. Also, this is mentioned in the README.

Has any thought been given to making Python accessible as a 2nd language option?

No. It is already a huge amount of work to maintain mruby inside SMC, therefore no other language will be added.

Offering multiple scripting languages might offer some flexibility (though the core game levels probably need to stay consistent)

The main point of scripting is to gain flexibility over what you can do with SMC’s ordinary level editor. This is independent of the language used, and Ruby is a very flexible language. What extended flexibility to you expect from embedding another language, and how does this flexibility compare to the giant amount of work generated by embedding multiple scripting languages?

Also, mruby is not a fully-fledged Ruby. No gems, no standard library, just the bare Ruby core and the classes defined in SMC. This issue is about making some helper classes which are directly written in Ruby to ease e.g. the creation of level exit doors, which is a more complicated task.

Vale,
Quintus

from tsc.

Sorry, thank you for clarifying the state of scripting. It will be good when you finish the requested Ruby changes.

My idea was that people experienced with Python would find having this language accessible useful, and this is the flexibility gained. If it is as tedious to maintain as you say, it probably doesn't make sense to change it.

I will have to check out scripting when I get a chance.

from tsc.

I will have to check out scripting when I get a chance.

The main scripting implementation nearly exclusively resides under the smc/src/scripting directory, with initialization/cleanup code in level.cpp and event code in all relevant objects distributed over SMC. Also, each SMC object instanciatable from the scripting API has a member Create_MRuby_Object() to allow this.

Vale,
Quintus

from tsc.

I wonder how difficult it would be to eventually replace the MRuby implementation with Parrot (as like a 4.0.0 thing :P). That way you'd have a single virtual machine and all you'd need is for level packages to depend on language packages with the bit of Parrot code required to process the code. Then SMC'd be able to handle anything Parrot's capable of, including Ruby, Python, and Perl 5/6. ;)

from tsc.

Yeah, I was just thinking about that (thought I didn't know Parrot is a tool for doing this). As far as I know, there are a lot of tools out there that are script-language agnostic.

Again, for standard levels for the standard-game, it might be good to have one scripting language.

For user contributed levels, maps, or "user games", freedom can be good.

from tsc.

I wonder how difficult it would be to eventually replace the MRuby implementation with Parrot

I know of not a single program employing such a complex concept of scripting, and I will not support it. If any one of you wants to code that, fine, but I simply don’t see the point of creating such a giant amount of work. Plus, people editing levels can be sure that their predecissor used a given language (mruby). They don’t have to learn a new language, just because their prededissor found Haskell to be the better choice.

Vale,
Quintus

from tsc.

I disagree that it's that complicated, but I do agree about the problem of inconsistent language choice. It could be annoying for some people (e.g. people who aren't me) having to know twenty different programming languages to edit whatever level they want. (I personally relish the chance to learn a new programming language, but I wouldn't want to force other people into it.)

from tsc.

The SSL already contains a few scripts by now. It will further evolve over time, so I don’t think we need this issue anymore.

Vale,
Quintus

from tsc.