Forwards compatibility and scripting discussion

[AllyTally]

Since #867 was closed, and the conversation was quite valuable, I thought I'd open a new issue with the goal of continuing this discussion further. What was already discussed was the possibility of breaking forwards compatibility to add new features making custom level creation easier, and the idea of a Lua API for more control over the game, to do what scripting currently cannot.

Additionally, I've created a thread in the (unofficial) VVVVVV Discord server for discussion on what a hypothetical Lua API would look like; however this is just implementation details to make sure that if we end up adding a Lua API, it'll be a good one.

And continuing from the previous issue, I would rather VVVVVV not become a mess of everything we'd like to implement, and forwards compatibility features be added in moderation, with hopefully more than one reviewer on the PR when it's time to merge. I do not want VVVVVV to go the same way as Community Edition, and I doubt a lot of other people would, either.

As a personal note, VVVVVV is an important game to me. I've always loved creating cool systems in things that were never intended to be used as such. I absolutely love abusing internal scripting and pushing the engine to its limits for maybe only a few seconds of gameplay. I find this kind of thing fun; it's problem solving taken to the extreme, with the huge payoff of being able to step back and see that you, in fact, made this huge elaborate system in a level editor for a game from 2010. With the addition of a Lua API, some of that charm would go away, and I believe this is the case for a lot of other people. However, I would rather this not stop progress, because what a small group of people enjoy in a game shouldn't stop the rest of the level creators from getting a much better system to create what they want. I'd rather lose that specific enjoyment than stopping everyone else from being able to make what they want.

With all of that said, I hope this sparks a discussion.

[AllyTally]

I'm going to add onto this actually; I don't believe that VVVVVV scripting should be REPLACED with this new system; VVVVVV scripting is great for what it is, which is just a good cutscene system. When people try to use it for what it's not intended to be used for, that's when it becomes a problem; which is where the Lua API should come in. The two could even work together; the Lua API having methods to register custom commands for the scripting system, which would be extremely useful and flexible.

[mothbeanie]

i really like the idea of using lua to enhance the scripting system, not replace it! maybe levels which use lua hooks could have them in a /lua folder in their levelname.zip, or something? this feels like an idea with a lot of promise and one which would absolutely be able to maintain the game's charm!

[flibitijibibo]

Changing or adding any scripting mechanism wouldn't be considered until at least 2.5, after #356 is done and we know for sure the scripting system is 100% locked in and finished for the retail data.

I do work on titles with Lua, Ruby, C#, etc. pretty regularly and at the end of the day, any scripting language you add to an engine still has to interact with the engine, and because it would expose the engine itself to userspace it would mean having to establish an ABI, which is way out of scope for a project like this.

While I don't think the mod tools should never change, it's worth treating VVV more like GZDoom or Build, rather than something like Unity or Godot.

[leo60228]

IMO Lua scripting should be an alternative to forking the game, not an alternative to internal scripting. Even an API that just exposed an abstracted view of entities, rooms, and scripts would be a ton of flexibility without having to commit to much more than we already do for internal scripting.

[AllyTally]

That was the plan, I don't think anyone says scripting should be replaced. (Plus I explained this to you on Discord already)

[InfoTeddy]

(Plus I explained this to you on Discord already)

Well, it's still good to write it down here. Not everyone is on the Discord server and they shouldn't have to be to participate in these discussions.

[SoniEx2]

instead of exposing the engine to userpsace (and having to deal with abi details such as "windows-only"), what about embedding a wasm interpreter?

you can even include a wasm version of lua.

[InfoTeddy]

instead of exposing the engine to userpsace (and having to deal with abi details such as "windows-only"), what about embedding a wasm interpreter?

you can even include a wasm version of lua.

I'm unsure of how WASM would help here.

What Ethan is referring to when he says ABI is that we would have to establish an interface for external tools to interact with the game engine. Ideally, this interface would be backwards compatible indefintely. Call this ABI, API, or whatever, but these are completely orthogonal details from "abi details such as 'windows-only'" (which we wouldn't have to worry about anyway since Lua is cross-platform).

If we decided to embed WASM instead, we would still have to establish an interface between the game and the code, and that's the bigger problem here.

[SoniEx2]

wasm helps because if you're making a level, you don't need to ship 200 binaries for every os/arch you wanna support. (also, thanks to wasm, you also can't just ship a trojan (unless the API allows for it obviously).)

wasm is also neat because you're no longer tied to any specific language. wanna make levels in C#? wanna make them in rust? it pretty much "just works". :3

[flibitijibibo]

I don't get the impression that this advice is based on experience with VVV in particular or any game I could buy right now. We're not using wasm or anything web-adjacent; and even if we wanted to that's not the issue, this is specifically about exposing native entry points from the main executable to managed code.

This is the only warning: Anything about discussions other than the interop layer is getting hidden from here on out.