• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 External Lua Scripting

J

Joshua Allen

Guest
While working on boss 101 we found that it would have helped our development if we had some sort of external scripting. It was too late to properly integrate a scripting language but in the future it would be nice to have the ability to utilize them out of the box.


I’m only suggesting Lua because it is a very popular scripting language but I would be happy with anything.
 

csanyk

Member
I would assume that you can create an extension that would allow you to run Lua. So essentially this is already possible, just needs to be built.
 

hippyman

Member
I've thought about trying this before in the past. But I recall "looking into it" and feeling like it was over my head. It's definitely possible to do with extensions though. Anything is possible with a little c++ magic.
 
J

Joshua Allen

Guest
Yes, the ability to run scripts can be done with an extension so why should yoyo add this ability?
  • Scripting speeds up development a lot because it gives the ability change code of a compiled program.
  • It allows for easy modding for released games.
  • Lua is very fast because of its jit compiler.
  • A lot of people know lua so if game maker was marketed with that capability it might bring in more developers.
Yoyo has added many thing that could be done with an extinction, box2d for instance, so it never hurts to ask for a feature that would make game maker a better program.
 

Mike

nobody important
GMC Elder
It's not something we're looking at, and doing an external language means you won't get access to internal variables etc. But as long as your happy with that, extensions would do it fine,
 
H

HammerOn

Guest
But can I bind GML with the scripting language extension?
I suppose it requires the function address but we can't get a pointer to GML scripts.
 

Mike

nobody important
GMC Elder
You will not get access to any internals. The Lua script will be totally external and contained in the DLL.

Not sure about YYC.... that generates C++ code, so you might get more access there....
 

FrostyCat

Redemption Seeker
You will not get access to any internals. The Lua script will be totally external and contained in the DLL.

Not sure about YYC.... that generates C++ code, so you might get more access there....
Would it be possible to add a function that enumerates a list of string names for instance variables? Since it is already possible to get at variables via string names, this is the last piece of the puzzle. It enables external language parsers and general state-saving scripts to have full access to instances.
 

babyjeans

Member
I believe you could make some sort of GML 'glue' between GML stuff and Lua stuff, passing ids to Lua since under the hood, ids are just Reals.
 

Mike

nobody important
GMC Elder
This stuff just isn't on our radar I'm afraid. On top of that, string lookups for every variable would be incredibly slow.... you need direct variable access to make it work.

With YYC it might be possible, as you have C++ code - you might be able to hack it in.....
 

FrostyCat

Redemption Seeker
This stuff just isn't on our radar I'm afraid. On top of that, string lookups for every variable would be incredibly slow.... you need direct variable access to make it work.
All of us who have a genuine use case for this knows the inherent speed problem with string-indexed lookups. But we aren't necessarily looking for speed in this, we're looking for possibility. Speed hits across the runner-extension barrier can be minimized with proper design on our part.

With YYC it might be possible, as you have C++ code - you might be able to hack it in.....
But will it last? GMAPI from 8.1 is a prime example of what could happen if we do that.
 

Surgeon_

Symbian Curator
There was somebody on the forums who made a primitive stack based virtual machine which runs in GML. Do you think this idea could be expanded on? I mean, you write your scripts in external files, and once you start the game they all get compiled to the VM's format, and then executed when needed (the VM could read the instructions from an array or list as if from actual memory in an actual computer). I know I'm talking about a VM inside a VM at this point, but it could be optimized to an extent, and it's the one solution which doesn't require YYG's intervention. Bottom line, you could do it while in testing/debugging phase of the game, and write it in GameMaker itself once you're happy with the code. Or you compile with YYC so you don't have two nested VM's. Do you think it could be viable?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
This stuff just isn't on our radar I'm afraid. On top of that, string lookups for every variable would be incredibly slow.... you need direct variable access to make it work.

With YYC it might be possible, as you have C++ code - you might be able to hack it in.....
Exposing a single script_execute function equivalent to DLLs would have been sufficient to make DLL<->GML interfacing much easier.
While I can think of some impressing workarounds involving heavy misuse of asynchronous event functionality, I do believe that such things are best left unseen for sake of everyone's sanity.
Edit: Just tested to find that it queues up events rather than calling immediately. Maybe for the better.

There was somebody on the forums who made a primitive stack based virtual machine which runs in GML. Do you think this idea could be expanded on? I mean, you write your scripts in external files, and once you start the game they all get compiled to the VM's format, and then executed when needed (the VM could read the instructions from an array or list as if from actual memory in an actual computer). I know I'm talking about a VM inside a VM at this point, but it could be optimized to an extent, and it's the one solution which doesn't require YYG's intervention. Bottom line, you could do it while in testing/debugging phase of the game, and write it in GameMaker itself once you're happy with the code. Or you compile with YYC so you don't have two nested VM's. Do you think it could be viable?
It is viable, but requires substantial investments.
I'm working on pretty much what you've described for the past several months (gif thread), and it had grown to be the largest GameMaker module that I had ever seen (6.5K lines of code in source / 7.5K LOC with macros expanded), despite still not having complete coverage of desired features to date.
Running in GML, the speed with YYC is only about that of GM8, but I was able to partially make up for that by extending the scripting language to do things that are not normally viable in actual (compiled) code (e.g. delayed asynchronous execution).
 
Last edited:

Mike

nobody important
GMC Elder
Running in GML, the speed with YYC is only about that of GM8.....
This isn't my experience at all.... my C64 emulator jumped from about 4-6fps to around 250fps...... YYC (if doing code heavy apps) is massive - as long as its structured right I guess. Emulation is obviously a great test of heavy code use due to it's nature, and isn't the "norm" for games, but does show it's much better than the VM when done right.

Edit: Just tested to find that it queues up events rather than calling immediately. Maybe for the better.
Yeah has to, or could be getting call backs on other threads etc.... imagine the carnage that would cause!
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
This isn't my experience at all.... my C64 emulator jumped from about 4-6fps to around 250fps...... YYC (if doing code heavy apps) is massive - as long as its structured right I guess. Emulation is obviously a great test of heavy code use due to it's nature, and isn't the "norm" for games, but does show it's much better than the VM when done right.
This to say, 8.x level of performance isn't too bad, but evidently could have been better.
YYC:VM performance scale is around 5x in my case.
Would likely have been much better if buffers could be used (instead of arrays containing instruction data), but writing a compiler+runtime that would work with registers/"memory" buffer would have been a whole different level of trouble.
There's probably something that I don't know about optimizing for YYC, because I've just made minor tweaks required to compile "VM" part of the thing for JS, and it runs 15x faster than it's GML counterpart despite the generated code being close to identical between the two:
vm-gml.png vm-js.png
 
S

Storyteller

Guest
the ability to code in something other than GML is a strong request.
ideally C#, but simply getting anything else working first would be good. A proprietary language just seems out of date, I had thought GMS2 would seek to remedy the strict requirement for GML
 
Top