http://www.ringojs.org/
Looks like it already has a following and lots of standard stuff we can use.
Looks like it already has a following and lots of standard stuff we can use.
Something to base the Mod API off of
- Thread starter AlbireoX
- Start date
That's a Javascript runtime, not an API as such? I mean if you are suggesting it might be an alternative to Rhino for Javascript integration then fine, but don't see what it has to do with the API as such. Although you probably just mean for modding in general.
-------
Some general thoughts I've had around modding and the modding API:
An API is typically the set of classes/interfaces and methods with which you interact with something. It is generally domain specific, if not specific to the particular thing being interacted with. For example, this is reference for the Unity API: http://docs.unity3d.com/Documentation/ScriptReference/
It has things in it like Vector2/3/4 math classes, the Time singleton, the MonoBehaviour class which is the class you extend to add components. You'll note that Unity supports three different languages - C#, Javascript, and Boo, but the API is pretty much the same for all of them with some minor variations. It also includes many normal .Net/Mono classes not mentioned - again, these are the same for all languages because that is how .Net works. JVM languages should work the same way, I believe.
So to me the Mod API for Terasology is mostly already there, although it needs some cleaning up - the math classes, the entity system, the world provider, the UI system, the engine components, the world generator classes. There still needs to be some other classes to let mods do some high-level mod stuff. But not that much as long as we use reflection to discover and hook things up where possible - in the Java world at least. Some of the discovery code is already present, just hardcoded against the main jar for the moment.
There probably also needs to be an interface for hooking into game lifecycle events, and an interface for gametype behaviour. Then some sandboxing should be done to limit mods to just what we want them to use (so no wiping players hard-drives or installing keyloggers, or connecting to arbitrary servers to send files off of the player's PC), possibly with a way a mod can request further access (causing the user to be prompted to allow it).
I have no issue with the use of Javascript as an additional modding language (I am firmly behind having Java), but feel that it should work atop the Java API, as a JVM language - although some shenanigans with auto-wrapping javascript files into classes or whatnot is fine. It should be able to interact with the interfaces and classes that are already present. And Java mods should be able to interact back the same way - everything compiles to jvm bytecode after all.
-------
Some general thoughts I've had around modding and the modding API:
An API is typically the set of classes/interfaces and methods with which you interact with something. It is generally domain specific, if not specific to the particular thing being interacted with. For example, this is reference for the Unity API: http://docs.unity3d.com/Documentation/ScriptReference/
It has things in it like Vector2/3/4 math classes, the Time singleton, the MonoBehaviour class which is the class you extend to add components. You'll note that Unity supports three different languages - C#, Javascript, and Boo, but the API is pretty much the same for all of them with some minor variations. It also includes many normal .Net/Mono classes not mentioned - again, these are the same for all languages because that is how .Net works. JVM languages should work the same way, I believe.
So to me the Mod API for Terasology is mostly already there, although it needs some cleaning up - the math classes, the entity system, the world provider, the UI system, the engine components, the world generator classes. There still needs to be some other classes to let mods do some high-level mod stuff. But not that much as long as we use reflection to discover and hook things up where possible - in the Java world at least. Some of the discovery code is already present, just hardcoded against the main jar for the moment.
There probably also needs to be an interface for hooking into game lifecycle events, and an interface for gametype behaviour. Then some sandboxing should be done to limit mods to just what we want them to use (so no wiping players hard-drives or installing keyloggers, or connecting to arbitrary servers to send files off of the player's PC), possibly with a way a mod can request further access (causing the user to be prompted to allow it).
I have no issue with the use of Javascript as an additional modding language (I am firmly behind having Java), but feel that it should work atop the Java API, as a JVM language - although some shenanigans with auto-wrapping javascript files into classes or whatnot is fine. It should be able to interact with the interfaces and classes that are already present. And Java mods should be able to interact back the same way - everything compiles to jvm bytecode after all.
http://www.ringojs.org/api/master/
I will read the rest of your post later, but it is time for me to sleep
