Using JRuby instead of Javascript for modding

[AlbireoX]

Javascript does have a lot of people using it, but it's not class oriented and makes it a whole lot harder to make it interoperate with Java.

 

[Cervator]

Isn't JRuby supposed to be slower? That's really the key. And we don't even have benchmarks of any sort on JS yet, tho at least there's a starting implementation there. I think it might be premature to consider something else

Also not sure we'd be able to use the JS dark magic trick there. Could possibly require a fresh implementation from scratch on how to even do a modding API there?

 

[ironchefpython]

You can create dynamic Java objects at runtime regardless of the modding language.

JRuby performance is decent, comparable to Rhino

The choice of Javascript was based on number of developers who have used Javascript vs. the number of developers who have used other JVM languages.

AlbireoX, If you're having a hard time making it interoperate with Java, it's because you're trying to make Javascript act like Java, instead of writing idiomatic Javascript.

 

[AlbireoX]

You can create dynamic Java objects at runtime regardless of the modding language.

JRuby performance is decent, comparable to Rhino

The choice of Javascript was based on number of developers who have used Javascript vs. the number of developers who have used other JVM languages.

AlbireoX, If you're having a hard time making it interoperate with Java, it's because you're trying to make Javascript act like Java, instead of writing idiomatic Javascript.

Maybe I should let the professional do the programming then.

And the number of developers who have used Java is the biggest of all of them, at least in the Minecraft community. We aren't going to be getting people who haven't played/modded Minecraft here.

 

[dei]

Another question, already asked but never responded I think: If JavaScript was chosen only by dev-ranking, why not defining modding interfaces directly in Java, which can then be implemented in plain java and loaded by class.forName...?

 

[Cervator]

Another question, already asked but never responded I think: If JavaScript was chosen only by dev-ranking, why not defining modding interfaces directly in Java, which can then be implemented in plain java and loaded by class.forName...?

I think that's kinda-sorta Ironchefpython's goal. I could be wrong tho. Java on the inside, supports Java coming in from the outside, just also JS which actually covertly creates Java objects with the convenience of a dynamic language over doing it in plain Java.

 

[Immortius]

My original goals with the entity system work was in that direction - having a Java modding API, with mods loaded in a sandbox (using Java's SecurityManager and a custom ClassLoader) using reflection to load up relevant classes and link them up as necessary. This technique can be extended to allow dynamic recompiling (through Java 6's compile api) and reloading of mods. The entity system helps to enable this by allowing providing resilient serialization and deserialization of world state during reloads.

That would just be a Terasology mod API though. ironchefpython and Albireo are working on generic, standard modding APIs intended for use by multiple voxel games. And since those games potentially use non-Java engines they're looking at a scripting language that can be run on those engines as well.

 

[ironchefpython]

And the number of developers who have used Java is the biggest of all of them, at least in the Minecraft community. We aren't going to be getting people who haven't played/modded Minecraft here.

Actually, that was the goal, to open up modding to people who had not previously written mods in Java. My insane goal is for people to be able to use an in-game text editor to write (or more likely modify) a mod, to be able to use an in-game pixel editor to create or modify textures, and use a variation of the game's block placement mechanism to build models. And the user would see their changes in the creative game world immediately.

 

[Immortius]

Yeah, but you don't need Javascript to achieve that.

 

[AlbireoX]

Actually, that was the goal, to open up modding to people who had not previously written mods in Java. My insane goal is for people to be able to use an in-game text editor to write (or more likely modify) a mod, to be able to use an in-game pixel editor to create or modify textures, and use a variation of the game's block placement mechanism to build models. And the user would see their changes in the creative game world immediately.

However, 99% of the world's Javascript community is older, 20+, and only a fraction of them probably play Minecraft. I have yet to meet someone that knows Javascript moderately well around my age, and I haven't seen anyone who likes Javascript in #spout or #bukkit.

Maybe Jython, although the project as you said is dead? There's a few Python lovers out there, although i know you hate it, ironchefpython.

 

[dei]

I think everyone who is able to write mods in javascript is able to do so in java with less than 30 minutes overhead to learn the slightly different syntax. In my experience it boils down how easy the modding interfaces are to implement so lets rather concentrate on this than any fancy language parsing. When the interface(s) are well done it's not much more than filling in the gaps or overwriting some default super-methods.

Concerning reusability for other games: If you really have two distinct games, their functionality will IMHO be so different that it isn't possible to provide a common modding interface. Even implementing a modding framework would have to be veeeery generic (using reflection or something like that) so you were able to open up a functionality for modding without writing additional parsers etc. else the hurdle for devs are to high and it will take ages until new features become moddable (--> no fun neither for devs nor for modders).

Yeah, but you don't need Javascript to achieve that.

Indeed, you can do the same thing in Java using the "Java 6.0 Compiler API" and dynamic loading (Class.forName)...

P.S. When Python was mentioned already: Why don't we use Brainfuck for modding ? (Would even be a good syntax for 2D blocky art à la DF if we use something similar for textures or the like)

 

[Cervator]

(For those unaware or wondering, it is an actual programming language, but still sort of a joke: http://en.wikipedia.org/wiki/Brainfuck)

 

[ironchefpython]

I think everyone who is able to write mods in javascript is able to do so in java with less than 30 minutes overhead to learn the slightly different syntax.

My experience is exactly the opposite. Writing Java means setting up an IDE, managing a dependency chain, worrying about packaging, more dependency issues at deployment, etc. And there are FAR more differences between idiomatic Java and Javascript besides a "slightly different syntax". The first question I hear from someone seeing Java for the first time is, "how do I make a function?", and then you have to explain that you can't.

Writing javascript takes a text editor and a browser.

 

[Cervator]

As much as I like Java I can agree that setting it up just right can be tricky. I like the idea of being able to write a quick mod in Notepad then run the game to test it, no other steps needed. Java on top of that? Cool, if you want it.

In the very beginning I was just hoping to be able to drop extra blocks into a directory (editing them there via straight text editor as desired) and have them get parsed and work purely by their presence and naming. Having that for mods too? Spiffy.

You in theory could do the same with Groovy... but pleasedonthurtme

(And many other languages, but lets not get into that again, heh - point is: dynamic vs compiled)

 

[dei]

Writing javascript takes a text editor and a browser.

Provided our modding api and game can be run in a browser, yes but it will hardly be the case with Terasology. And you can write Java in a plain text editor as good as JavaScript. (You have to comply to the interface-checker, be it a JS parser or a java compiler)

By the way: Nice story on your link.
I know of the differences between Java and JavaScript very well (duckTyping, Closures, etc.) and highly estimate them when programming JavaScript, but why the hell would you want to use them in a Java project? To use these features in Terasology we would have to map every of these JS-peculiarities to a Java-peculiarity which can be very difficult, not to say impossible.

managing a dependency chain, worrying about packaging, more dependency issues at deployment, etc

Dependencies are not here to bug you, but to help you building things out of existing parts (You have the same thing in JS when using jQuery etc.). By the way: That would in no way affect modding, as you most likely not depend on whole new libraries in your mods, so that's no point for JS.

For Modders...
... doing the same thing than in JavaScript, Java is in no way more complicated (assuming you're able to write "public void doSomething()" instead of "doSomething = function()") for a user/modder. Ok, you have to encapsulate functions into a MainClass but if you don't wanna turn your JS-Code (if it's more than a thousand lines) into chaos you make the same thing using classlike-functions, prototypes or simply files.
(If it makes sense we still could write the class-body around the code at loading-time, so you won't even see it while modding)

Of course Terasology code is more complicated than the average website's javascript code but it incorporates waaay more functionality than the average website.

So I still conclude that if we're designing the modding interfaces simple enough, there wouldn't be any significant disadvantage when using Java over JavaScript for average joe modder. (Even advantages because he can use IDEs with syntax-completion if he wants)

BUT for core developers...
... it takes a hell lot more to lay a Terasology-feature open for modding when using JS than using Java. In Java you only have to write a simple interface for your moddable coreClass, for JS support you would have to write a whole new syntax-checker and parser for every new moddable interface.

We could make a markerInterface "Moddable" which says the mod-classloader that this interface can be modded. This way it can limit the moddable-classes and eventually automatically export all modding-interfaces (using reflection) so that a modder only needs to download these for his modding job and not the whole Terasology source.

Any questions left?, Anyone else wanna try to convince me of another modding-language than Java? *MeLovesDiscussingSoftwareArchitecture*

P.S. One little drawback with Java for me as a developer I must commit, is the missing delegate (function=object) concept but I think a normal modder wouldn't fully understand them (with all side effects) anyway and therefore will not miss them if not present.

 

[dei]

Even if it seems the opposite in my above post: I'm a big fan of JavaScript's flexibility and weak typing in general. (Had a 5k lines of code project done in JS)

heh - point is: dynamic vs compiled)

Not exactly. With its dynamic classloader Java is some kind of dynamic language too. The question here is static typing vs dynamic (duck) typing. And if writing all syntax and parser-logic again even if java provides it already, is worth the effort only to have a slightly different syntax?

If you would have implemented Terasology in Javascript (with some nasty WebGL perhaps), then: go for it, let's start modding in JS right away!

 

[Cervator]

Not exactly. With its dynamic classloader Java is some kind of dynamic language too. The question here is static typing vs dynamic (duck) typing. And if writing all syntax and parser-logic again even if java provides it already, is worth the effort only to have a slightly different syntax?

I yield on the details, wasn't too sure, but hey, somewhat close

As for the modding interface - being that we're using the ES on the Java side, and @ironchefpython's dark JS magic, do we need to expose stuff individually? Maybe most the examples so far have just been adding new stuff, where you can just define your way to new Java ES objects on the inside, while we need some code examples of how you interact with existing stuff, like adding new GUI elements? The engine will end up with very little stuff in it other than core stuff like that?

I'm shaky on the details as usual, but got the impression we let Java be Java and don't worry about providing anything translated for JS. In theory anything that can use a Java API can mod. We just should pick one or two things (Java + JS) by convention to keep focused.

 

[ironchefpython]

Provided our modding api and game can be run in a browser, yes but it will hardly be the case with Terasology.

Why not? Assuming that Terasology has the ability to load Javascript text files, why wouldn't your development toolchain be a text editor and Terasology?

Even better, put a text editor into Terasology, and your toolchain becomes Terasology and nothing else.

 

[dei]

That's what I mean and is perfectly working in Java. What I said is that Terasology itself runs in the JVM and not in the Browser, so there's no point in selecting a modding language that can be interpreted by a browser. (Terasology will parse/compile it ingame anyway)

 

[Cervator]

I don't think JS being related to browsers has ever come up as an argument, that's more of an origin story

Point is Rhino and stuff like that I guess can run it on the JVM and in-game as well as any ole well-performing scripting language. Groovy too with its interpreter, but it is just slow as molasses.