So some related topics have come up here and there lately, but get jumbled together and could use some clarity
Extensibility is a heavy focus for us, that's no big surprise, that's a big part of what makes sandbox worlds so irresistible. User friendliness inside and outside the code base is paramount, and metouto is my classic example of how well we can invite in user contributions already
We don't have a lot of concrete modding implementation so far, and do need to get there. Some important questions are at hand for that.
1) Language. We could write everything in Java, but probably want to take advantage of a dynamic language for work outside the core, a.k.a. a "modding language". My initial personal preference was using Groovy as it is super easy and keeps the barrier of entry low. It also runs on the JVM and can do API-less access for development and debugging. Scala might have potential too. Yet Javascript could also be embedded via Rhino and ironchefpython has been advocating its advantages on higher activity than something like Groovy. Although I think JS might be a little less easy to work with?
As several people have noted we want to keep the total number of languages in check, although I'm still not sure whether to count Java/Groovy/Scala as more than one. JSON/GSON might also be replacing Groovy for "definition" files (data that I used to think might contain Groovy scripting to register with some sort of event handler / API)
2) API vs API-less - I think it would be easy to agree on wanting to make an API and forcing outright mods to use said API rather than allow direct calls into the codebase (currently doable via the GroovyConsole) or even outright replacing Java classes. Yet at the same time API-less debugging via the Groovy Console (or any equivalent console) is all kinds of, well, groovy. Maybe an advanced toggle available to users in a "Creative" mode. Multiplayer would eventually need a way to force no fancy console tricks, tho at the same time there's no need to limit it for a long time - cheating concerns isn't exactly a problem that's on the current horizon of interest.
3) Where does the core engine end and modding start? Internal modding / API usage could start very early, with many core systems implemented more or less as internal mods so they can be extended or replaced easily. Intending to convey the distinction here with when/where we want to enter "API-land" within the core game implementation as opposed to what is internal ES, in-game custom content, and out-of-game mods, tho it is a tricky distinction and I may be off my rocker here...
4) In-game modding tools and a somewhat related topic of where does the ES (game core) end and modding begin? This came up on IRC some, good discussion there. Second Life is a good example of what you can do, although you will never find a more wretched hive of scum and villainy nor more empty "rooms" so the game itself is not necessarily a model to emulate
Previously I had just figured we'd allow in-game (within the expectations of what the "game" is) block modification (imagine shrinking a 4x4x4 selection of block to a single block dynamically), but there might be potential in going beyond that, creating outright blocks, loading / modding shapes or textures, attaching scripts, etc. That's an advanced area and not one I'll step into without commitments from people willing to give it a shot, but it sounds like harrison (on IRC; soren renner on the forum) and ironchefpython might be up for something in that area
Also, I'm not sure how blurry the line would get between how flexible the ES and game itself would be, the possibility for user-generated content in-game (beyond the confines of the "game"), and outright external mods.
I know this post will come off as somewhat confusing and wall-of-text'y, so please do ask for clarification. I post it now so I won't take hours of waffling between descriptions that'll still feel lacking somewhere anyway
Finally, there's also some talk about knowledge exchange with the good folks over at Spout, who are all about this whole modding area (being a mod framework for Minecraft in a very brief and poor description, that's now evolving beyond that). We'd be foolish in not trying to learn what has worked and not worked in their experience, and likewise we've got client know-how they may feel free to inquire about
Extensibility is a heavy focus for us, that's no big surprise, that's a big part of what makes sandbox worlds so irresistible. User friendliness inside and outside the code base is paramount, and metouto is my classic example of how well we can invite in user contributions already
We don't have a lot of concrete modding implementation so far, and do need to get there. Some important questions are at hand for that.
1) Language. We could write everything in Java, but probably want to take advantage of a dynamic language for work outside the core, a.k.a. a "modding language". My initial personal preference was using Groovy as it is super easy and keeps the barrier of entry low. It also runs on the JVM and can do API-less access for development and debugging. Scala might have potential too. Yet Javascript could also be embedded via Rhino and ironchefpython has been advocating its advantages on higher activity than something like Groovy. Although I think JS might be a little less easy to work with?
As several people have noted we want to keep the total number of languages in check, although I'm still not sure whether to count Java/Groovy/Scala as more than one. JSON/GSON might also be replacing Groovy for "definition" files (data that I used to think might contain Groovy scripting to register with some sort of event handler / API)
2) API vs API-less - I think it would be easy to agree on wanting to make an API and forcing outright mods to use said API rather than allow direct calls into the codebase (currently doable via the GroovyConsole) or even outright replacing Java classes. Yet at the same time API-less debugging via the Groovy Console (or any equivalent console) is all kinds of, well, groovy. Maybe an advanced toggle available to users in a "Creative" mode. Multiplayer would eventually need a way to force no fancy console tricks, tho at the same time there's no need to limit it for a long time - cheating concerns isn't exactly a problem that's on the current horizon of interest.
3) Where does the core engine end and modding start? Internal modding / API usage could start very early, with many core systems implemented more or less as internal mods so they can be extended or replaced easily. Intending to convey the distinction here with when/where we want to enter "API-land" within the core game implementation as opposed to what is internal ES, in-game custom content, and out-of-game mods, tho it is a tricky distinction and I may be off my rocker here...
4) In-game modding tools and a somewhat related topic of where does the ES (game core) end and modding begin? This came up on IRC some, good discussion there. Second Life is a good example of what you can do, although you will never find a more wretched hive of scum and villainy nor more empty "rooms" so the game itself is not necessarily a model to emulate
Previously I had just figured we'd allow in-game (within the expectations of what the "game" is) block modification (imagine shrinking a 4x4x4 selection of block to a single block dynamically), but there might be potential in going beyond that, creating outright blocks, loading / modding shapes or textures, attaching scripts, etc. That's an advanced area and not one I'll step into without commitments from people willing to give it a shot, but it sounds like harrison (on IRC; soren renner on the forum) and ironchefpython might be up for something in that area
Also, I'm not sure how blurry the line would get between how flexible the ES and game itself would be, the possibility for user-generated content in-game (beyond the confines of the "game"), and outright external mods.
I know this post will come off as somewhat confusing and wall-of-text'y, so please do ask for clarification. I post it now so I won't take hours of waffling between descriptions that'll still feel lacking somewhere anyway
Finally, there's also some talk about knowledge exchange with the good folks over at Spout, who are all about this whole modding area (being a mod framework for Minecraft in a very brief and poor description, that's now evolving beyond that). We'd be foolish in not trying to learn what has worked and not worked in their experience, and likewise we've got client know-how they may feel free to inquire about