FakeFishGames / Barotrauma

A 2D online multiplayer game taking place in a submarine travelling through the icy depths of Jupiter's moon Europa.
http://www.barotraumagame.com/
1.72k stars 401 forks source link

Implementing a scripting engine for the game (Lua or other - Pitch in and discuss!) #194

Closed NilanthAnimosus closed 5 years ago

NilanthAnimosus commented 6 years ago

This would be a very good place to have a discussion below, anyone interested in modding barotrauma should toss in their thoughts regarding this on alternatives and other such.

I am sure this may have been brought up and thought of before, from security on how its handled, clients syncing or otherwise, what it should be able to do/access.

What I'm suggesting is to add a scripting language to the game, allowing item components to be virtually anything, more complicated logic circuitry for considerably less resource usage and custom code in general.

This would allow Modders the ability to create their hunger/food mechanics, new devices without needing hard-coded classes to support them, and other general neat changes such as hooking into various existing areas of the game.

These could then be included as a sort of implementation where a user can load multiple mods, such as a separate mod overhauling reactors and another mod adding new weapon mechanics like a mining tool and ore code.

Content packages wouldn't become useless, they could define certain mods to use the scripts from, alongside what XML files to use - the XML files themselves could reference names from the script mods installed - and the script mods could make use of the data inside the XMLs (Such as implementing a component from a script called "Flashlight" which has toggle functionality in an Assault Rifle from a script mod again, which its stats, looks and other item-related definitions in the XML).

Eventually this could be used for anything from the menus of the game to extending the GUI, but even partial implementations could at least be used to add new item components and types to the game and their behaviour.

Even if it is not used much at first or at all - this could be integrated into what already exists in the game over time as this would still be interesting to slowly/partially implement over time, even if tacked onto the game but largely unused or by default disabled entirely.

Lua (As of itself) is C code, and requires a wrapper or different interpreter to work in .NET, The two common ones (Wrapper/writeup to interpret into c#) I personally found were:

[http://www.moonsharp.org/] ([https://github.com/xanathar/moonsharp/])

[http://nlua.org/] ([https://github.com/NLua/NLua])

I did originally have more suggestions, only to realize Squirrel and base LUA are written in C and thus require more effort to implement as-is into C#.

DifferentLevelDan commented 6 years ago

C# is a scripting language. We can sandbox it and run it. See: Space Engineers

d34d10cc commented 6 years ago

C# is absolutely not a scripting language. There are example of it being used as one and sandboxed, yes, but it's either really hard or involves very hacky ways of disabling users from abusing it. I suggest you look into other options, and leave C# as a last resort.

NilanthAnimosus commented 6 years ago

C# would probably just flat out be a red flag on the security (I'm sure a sandbox helps with preventing access to things - but even code inside of a sandbox can be dangerous) or even just an insane understatement in effort to implement, Of course I don't know that much on using a high level compiled language as a scripting language such as C# - but that wouldn't really be considered the norm.

The games code is in C# though, and I do love me some C# - but I have no idea how you'd ever implement a script interpreter for such a high level language as that.

This is more towards having a more efficient method for various forms of modification, scripting, entities and items without having to edit the game directly for the most part if possible.

Preferably without requiring compilation, DLL's, additional components and other potentially insecure ways about modding - but instead as simple text files to be read and reloaded at run time for rapid tweaking that could access what the game does and add to it with its own logic and GUI (And if this becomes good - perhaps migrate aspects of the game into this).

Lua is a popular one and the first I figure I would throw in, proven in games like Garry's Mod with its game modes + entities and such (Picture missions, and items in Barotrauma are essentially the same thing).

I did look into C#-like interpreters. and yes, they can exist, I found one such example here; (https://github.com/oleg-shilo/cs-script)

But I have no idea if this is actually a safe scripting language or if it could effectively do almost anything (If it it even runs well, it could be terrible performance wise - I've not exactly heard of it).

Lua has tons of examples and documentation by comparison.

juanjp600 commented 6 years ago

IronPython looks interesting: https://github.com/IronLanguages/ironpython2

Personally I'd like to see CS-Script + Sandboxing with AppDomain, not sure if that's going to be a viable solution though.

Crystalwarrior commented 6 years ago

Oh yeah AngelScript is a thing that exists and what Overgrowth is using

robinlahtinen commented 6 years ago

Lua is better

ZealanL commented 5 years ago

I know this is quite an old thread, but this still seems like a great idea. Maybe a scripting language isn't even needed - just an API that can be used without having access to the games entire source code.

Regalis11 commented 5 years ago

We're moving feature requests from the issue tracker to the Barotrauma forums. From now on only actual issues (bugs, crashes, design flaws, oversights) should be reported here. We're doing this because the issue tracker has started to become extremely cluttered - it's getting harder for us to find the more critical issues when they're mixed in with hundreds of ideas and feature requests. And even though we are closing the existing feature requests, we are still planning on implementing many of them further down the line.

So from now on, please post your feature requests on the Collaboration section on the Barotrauma forums.