Is there support for other scripting languages?

Started by jmhimara, Wed 01/11/2023 19:18:57

Previous topic - Next topic

jmhimara

I found some really old posts mentioning support for Lua, but nothing recent.

Has there been an previous attempts to enable scripting in another language? What are the challenges or obstacles to this?

Theoretically speaking, how difficult would it be to embed another language, like Janet (which can be bundled into a single .c file and easily included in any C/C++ file)? Could this be done as a plugin?
How complicated is the implementation of the current scripting language? (On the surface, it seems like a thin layer over C).

eri0o

It's absolutely not a thin layer over C.

It's really hard, but yes it could be done as a plugin. The previous Lua implementation was two plugins, one for the Editor and other for the Engine, made by a person in the forums and not currently maintained - afaik it won't work nowadays easily and I don't think the Editor part was open sourced or the code that generated the plugin code was open sourced - only the final generated code at the time, I think around 12-13 years ago, and no one maintained. Probably would be easier to create a new one.

You can get the function address for the internal calls to each script API function, so you would have to generate some code that asks for each of these and make a translation to whatever language you want to support - this only in the engine plugin level. And then you would have to figure it out how to handle all this, like how you want to run that language interpreter and all that and abstract this in the engine plugin you are building. Any support for coding in whatever specific language you want you will be coming up with your controls, autocomplete, intermediary parsers and all that in your Editor plugin or use an external editor and hack stuff up.

I am not telling you "don't do it" but I am telling you "absolutely don't do it as your first experience with this 25 years old engine", if you have interest in AGS, I suggest to explore more the ecosystem, experiment with it, try building a very simple plugin, go slowly.

Khris

@jmhimara

The built-in language has its downsides*, however to me the bigger question is: is this really what's keeping your from using AGS? Disregarding the fact that Janet seems - to put it mildly - like the passion project of a single guy who for some reason thought existing languages don't use enough parentheses, what exactly would you gain if AGS did support other languages?

It's an honest question. If you rather want to write JS or C# or Python, why not pick one of the available engines that employ those?


* fewer and fewer all the time, thanks to amazing efforts by a bunch of people investing their free time, a big thanks to all of you!

jmhimara

@Khris

Haha, I'm guessing you're not familiar with s-expressions and Lisp family of languages. It's a great language and if you're at all interested in expanding your skills as a programmer / computer scientist, I highly recommend it. But that's besides the point. I wasn't suggesting Janet per se, I only brought it up as an example of a small language that comes with a single C file that can be embedded into an existing C/C++ project.

As for why I asked, mostly out of curiosity. I'm not suggesting it's a make or break feature of the engine. Far from it.

However, I think there are legitimate reasons to at least consider other languages. Aside from personal preferences (I don't like C/C++), I don't think the current scripting language is very beginner friendly. I've been under the impression that many people who use AGS come from background with little to no programming experience (correct me if I'm wrong). Whereas in the 90s it was common for people to be introduced to programming with a language like C, that is not the case anymore. Most people learn and become comfortable with languages like Python or Ruby or Javascript or something along the same lines. Plus the overall trend in the programming world is to move from imperative to declarative style.

However, I also understand the point that the other user made. It's not easy to do this in a 25-year old engine.

Khris

@jmhimara

I'm familiar, I learned Scheme back in the day :)

With regards to being beginner friendly: I don't think another language is going to make a difference.

I've been active in the technical forums for over 15 years now, and the scripting language itself is decisively not what beginners tend to have issues with.

Replace AGScript with Ruby tomorrow, and the technical forums would look exactly the same.
Here's a bunch of actual issues people have:

-pure isometric movement
-how big are 1024x768 backgrounds? pixel wise?
-walking on a conveyor belt
-exit arrows cursors
-before/after a dialog, fade in/out the GUI
-do not restart music if same as previous room
-do z after x and y are done
-parse error (didn't put code inside functions)
-replacement for unhandled_event()
-region events don't fire during blocking walks
-prevent/change interaction globally (because player is tied to chair)
-I want to draw backgrounds like LucasArts

To be clear, I would absolutely love to be able to use JS. Is it going to happen? No. But would it help beginners? Also no.

Crimson Wizard

#5
Adding another script language should definitely be doable through a plugin, with certain effort.

Previously we had Lua plugin and C# plugin afaik, they may still be found around.
I do not know if they will still work though, they did not have proper maintenance, and possibly few changes in the engine could break them.
But if there's a demand, then these could be restored (so long as somebody would like to work on that).

But theoretically that's pretty possible to add another language support. As eri0o explained in the above comment, the idea is to hook up game API from the engine within a plugin's code. This is done more or less in similar way to how function pointers are loaded from DLL ("get me an address of function "NAME").

The remaining problem will be the fact that the engine currently is hardcoded to run callbacks in AGS script. I think that's the primary reason why you cannot skip AGS script completely.
If that is "fixed" in the engine, then one could avoid using AGS script and only use alternate language.
Without such "fix", there has to be a two-way connection between two, where AGS script must pass callbacks into the alternate script through plugin interface.

1. Engine ---> Game event ---> callback in AGS script ---> plugin API call ---> run callback in an alternate script.
2. Alternate script ---> call game function through engine API ---> Engine


eri0o

Ruby beginner friendly? Are you in Japan?

Anyway, I did though had 8051 assembly as my first language - and Z80 assembly, and PIC assembly and then that the Motorola 68 assembly, and only after that they decided I could learn C. :P But that said Python and that it doesn't use types can be very tricky in runtime errors.

But if you want some intermediary solution other alternative is you could come up with other language and make a compiler for it to the intermediary instructions the AGS VM uses and just build the script object from this language. You would still have to come up with all your tools - a compiler and something to write your code in.

Overall I think AGS Script is an ok first language and I would recommend trying it out, as things are very integrated. There's a new AGS Script compiler in the alpha ags4 branch that fixes a lot of things and I think it should give a better experience in a not so far future.

jmhimara

I agree with the downsides of python. I'm a Haskell user myself, so I understand the benefits of a well designed type system.

To be clear, this is not an attack on the engine. I used it 6 or 7 years ago to make a game and I thought it was great. The language didn't bother me at all because I was used to coding in C. Now I've been to spoiled by the conveniences of modern languages, which is why I find it a bit harder to go back to C-like languages.

Again, I agree that this is not really a big deal in AGS because of how scripting is used. I was only curious about the possibility of using another language and how difficult it would be to implement one. From what I'm understanding, the API is not exposed by the C++ code, so you cannot call that directly. The easiest way would be to create a transpiler between AGS script and whatever X language. Which is not easy at all.

Crimson Wizard

#8
Quote from: jmhimara on Thu 02/11/2023 01:21:21From what I'm understanding, the API is not exposed by the C++ code, so you cannot call that directly. The easiest way would be to create a transpiler between AGS script and whatever X language. Which is not easy at all.

It is possible to call engine's API directly, if you write a plugin and use the engine's plugin interface. I mentioned that in my reply. Maybe we have a misunderstanding here?

SMF spam blocked by CleanTalk