While we are on the subject… other cool things you can do with Groovy…
You can enhancing existing Java classes by adding new methods to them… even operator overloading. In fact, you can do this as an extension module that is then automatically available to any Groovy code running with that classpath.
In fact, I’m working on an extension module for the JME Math package to add common operator overloading for Vector3f, Quaternion, Matrix, etc… That way in groovy code you can do stuff like:
Yeah, I’m oldschool so I don’t edit groovy (or Java for that matter) in the SDK. I’m used to doing my imports myself.
The thing is, you are kind of complaining about a feature that wouldn’t even be available at all in other scripting languages: the ability to import Java classes. So I’m not sure it’s fair. I’m sure the Javascript editor and the lua editor support won’t auto-import Java classes either.
Using this technique makes sandboxing a lot harder but still possible. Never used it personally. And it uses reflection if I remember correct so should have problems with performance when overused.
We use Java 8 and hence opted for Javascript as our scripting language. We are currently writing our game such that the vanilla version of it is a mod. We’ve “sandboxed” the script engine by disallowing any interaction with the Java API unless through the interfaces we’ve created and bound to the engine context. Works pretty well for us so far. We might look into producing an article about it later on.
The problem with the sandboxing is, that it does not prevent resource starvation (mission critical for me).
As one script could try to eat up all ram, or block the cpu required to run the gameserver.
Btw. I kinda do the same, my initial ship is already heavily using the shipcomputer for all kinds of basic behaviours.
Btw. LuaJ is kinda complete, I did not find a single real flaw compared to the normal lua runtime.
Is it secure? I’ve tried a bunch of different libs and all had sandboxing stuff, but at the end of the day, no security was actually achieved. The problem could again be between the chair and the computer though :D.
I’d be interested in reading that article if you write it later on. Empire_Phoenix solution seemed quite solid too.
I wonder how wow managed to protect itself against all turpitude when allowing custom lua scripts. Because any weakness would have exploded in their face.
“Btw. I kinda do the same, my initial ship is already heavily using the shipcomputer for all kinds of basic behaviours.”: I find that very VERY VEWY VEWYYY exciting… I just don’t see how it could be secure on a mmo server. On a server shared by friends, yah, but don’t think you going that way from last time we spoke.
NB: idiot speaking here
Well, they way we sandbox the JS engine is by telling it to not allow access to any built in Java libraries. We then have to put the interfaces we want to expose in the engine scope. There was another topic which sort of side tracked on to this.
Yah, that’s the first step of sandboxing and about all libs allowed that; the problems came after that. It was a while ago, so I’m uncomfortable writing what problems came after that because I don’t really remember right and some problems may be due to me. I do remember that a simple loop could be used to put everything down though. And there were potential problems with logging, but those are somewhat ok-isch problems as long as the scripts don’t run on the server.
I think reflection had to be turned off or something too and so on.
But really, not pretending I know what I’m talking about, so eagerly awaiting your eventual writing on the subject later on :).
That’s an interesting case actually by using a loop to force a thread into lock down. However in our environment the script engine is running on it’s own thread. I just tested this by putting a while(true) loop in one of the mod scripts. The game kept on running, the object controlled by the script stopped though. After a while the game became unresponsive.
Yah :D. Although, if it only means that the client can go tits-up, it’s not too much of a problem.
My nightmare was that scripts could became a way of doing way more nasty stuff… and I didn’t end up thinking there weren’t nastier holes… but again, could very well be me.
Well I directly plug into the lua interpreter, in its main loop, so no instruction can go by without me noticing it.
To prevent while(true) and similar stuff, you are force suspended (via lua coroutines, you run everything in one coroutine) after a few instructions. Also i keep track of all allocate d objects, and enforce maximum memory limits as well. Similar to danny, i need to expose everything to lua manually, and no java method is callable. However lua itself offers similar to js quite some librarys already, which should be fine for most cases.
If the luavm goes over any limit, I just force terminate it (aka shipcomputer bluescreen)
For the parts where I kinda want to force the userscrips to use a unified api I offer some basic systems,.
For one, there is a virtual terminal hardcoded, where all println from the script are redirected to.
There is a central evenbus provided (written in lua tho) with an java part that allows native code to publish events to it.
There is a central usermanagement, with some hardcoded checks, (eg a turret will not fire at the own captain, no matter what the scripter does)
→ This is necessary to prevent some players designing ships, that will kill the buyer and return to the ship dealer
There are dozens of similar failsafe and anti asshole systems in place.
local module = {}
function module.getHumanName() return "Simple Door System" end
usermanager.addRole("door_security");
usermanager.addRole("door_normal");
usermanager.addRole("door_airlock");
computer.registerEventHandler("doorRequest",function(eventtable)
if (usermanager.hasRole(eventtable["user"],"door_normal")) then
doorlib.toggle(eventtable["door"]);
else
doorlib.deny(eventtable["door"]);
end
end)
return module
I would offer that your use-case is slightly different than most games because you support scripting as part of your game itself. ie: the players in the game can write ‘mods’.
Normally a mod is something that the player installs outside of the game and won’t accidentally get during normal gameplay. In that case, there can be a sort of ‘buyer beware’ assumption about installing strange things on your computer.
Mythruna’s approach to modding is to allow a ‘total conversion’ level of modding. The new engine’s plugin system literally lets you replace any part of the game, to include the whole game and main menu, splash screen, etc… Which is the total opposite. I have a fondness for games that supported that level of modding and so that’s the way I went.
At any rate, much of this is kind of off topic for this thread since the original poster specifically asked for ways to avoid having to register all of the stuff like he’d have to do with a heavily sandboxed approach.
For stuff like registering callbacks in a large scale there are things like annotation preprocessing in NetBeans. I used it last time to generate my Lua wrappers around my Java API when I was too lazy to do it by hand.
I can vouch for the love @pspeed has for Groovy. I’ve had a lot of success with it. Not in gaming but in the Financial Industry. The language is very natural for Java developers and you can do so much more with it. One of the things we allow in our applications is dynamically editing the scripts. If you cached the compiled scripts, and use the hashCode of the script as the key of the cache, you could allow people to dynamically edit the mod while the game is running.
Also, the ability to add methods to classes that already exist is really nice. You can also create a BaseScript class that all the mod’s compiled scripts extend so you can provide helpful utility methods that can be accessed from within the script.
It also is good for creating DSLs. So if you wanted to create a DSL for some functionality of your game you could. I’m not an expert in the DSL area but from my understanding you could create things like:
I’m going to give groovy a shot, and eventually a non-developer friendly code generator that creates the groovy files from some kind of GUI. Modding really seems to give people ownership of the game, which is great for retainment.
Hey Guys,
Sorry for that really really late reply, I was busy because of the holidays.
If I have seen that right, Groovy can be coded exactly as if it was java code (syntax-wise) but I could also leave out some stuff (return type, access modifier, parentheses) so it’s more scripty.
I only wonder what the people are used to (LUA was Standard for many games).
Also in my Questing-Scheme I currently have:
So I wonder what’s the best for such inline-statements. I thought of JS because XML and JS are somewhat connected as a WebDeveloper.
Other than the Maintainability is there a reason to not have wrappers for groovy, js and lua at the same time? (Like Groovy seems easy and js is shiped with jre8)
I don’t care yet about the Security as there maybe will be “certified mods” (for which I checked the source code) and also it’s to some extend the users’ responsibility (many mods come with an installer so you don’t have to copy the code… If they already run an executable…)
And the last Question: Groovy seems object oriented. Is it possible to evaluate single statements like the above? (Without adding like an inner class with a method)
