AGS-Lua Evangelism

[Crimson Wizard]

Certainly you *could* cobble together a non-blocking say function but how would you chain calls in an easy way?

By queuing them, storing information in array for instance. That won't be hard to do.

I am actually curious how would I break the sequence if I use coroutines. Like what if something may happen during non-blocking "say". Can I trigger the exit from the function without executing the rest of custom "says"?

[Calin Leafshade]

Certainly you *could* cobble together a non-blocking say function but how would you chain calls in an easy way?

By queuing them, storing information in array for instance. That won't be hard to do.

What if i want to run a function once all the says are completed? What if i have a callback i want to pass to the function when it finishes? What if i want to run a different function each time? What if i wanted to do this 1000 times for my RPG?

Sure it's *possible* but i think we can agree that it would be horribly messy, require a lot of duplicate code and be impossible to modularise .

I am actually curious how would I break the sequence if I use coroutines. Like what if something may happen during non-blocking "say". Can I trigger the exit from the function without executing the rest of custom "says"?

If you dont want to resume the coroutine then just don't resume it.

[Crimson Wizard]

What if i have a callback i want to pass to the function when it finishes?
What if i want to run a different function each time? What if i wanted to do this 1000 times for my RPG?

That's a different topic, not related to non-blocking "say" directly
In AGS there would not be other way but to use event id and event handler functions with switches and whatnot.

[Sslaxx]

Frankly, I'd expect a paradigm shift like Inform 6 to Inform 7 to be worth serious consideration regarding changing AGS's primary language. Lua is not that shift.

[Calin Leafshade]

I think that would be a very bad idea.

Can you imagine something like Resonance written in an Inform 7 style language?

[Sslaxx]

I think that would be a very bad idea.

Can you imagine something like Resonance written in an Inform 7 style language?

It would be... interesting, I think. Best person to ask that question would be VinceTwelve though.

I don't necessarily mean a shift to something like Natural Inform (Inform 7). But equally I don't think Lua would be enough of a shift from the existing AGS Script language. Or at least you haven't given any reasons in this thread.

[Crimson Wizard]

But equally I don't think Lua would be enough of a shift from the existing AGS Script language. Or at least you haven't given any reasons in this thread.

I am not sure I understand those who say something like this either.

If I'd be able to write game scripts having at least C-language level of features, that would be a great relief.
By C-language level I mean: pointers to custom structs, pointers to functions, being able to declare function prototypes ahead and then define their bodies in any order.
Even if I'd stick to most common things and most common gameplay, those features alone would convince me to use the new scripting language, simply because they make scripting simplier, faster and less tedious. That would allow me to concentrate on gameplay instead of inventing workarounds for common problems.

But I didn't make any good game so far, so probably you'd still want to hear Vince Twelve's opinion .
By the way, there's AJA who made a whole adventure game with Lua plugin (Barely Floating). I was hoping he'd visit this thread to tell about his experience.

[Calin Leafshade]

I should be clear that I am not advocating for Lua *over all other languages*, merely *over AGS Script in its current state*.

If AGS Script were more C like (pointers to custom structs and so on) then I would not be as combative on the issue (Although I still think Lua would be preferable to C in a scripting environment).

The reason I advocate for Lua specifically is because its there and it works now.

[Sslaxx]

I should be clear that I am not advocating for Lua *over all other languages*, merely *over AGS Script in its current state*.

If AGS Script were more C like (pointers to custom structs and so on) then I would not be as combative on the issue (Although I still think Lua would be preferable to C in a scripting environment).

The reason I advocate for Lua specifically is because its there and it works now.

Then the aim should be to add those features to AGS Script.

My concern is more backwards compatibility than anything else. It comes across as "throw the baby out with the bathwater". If we're talking version 4+ stuff, maybe keep it around (but with the proviso that it's obsolete and Lua is the new primary language) for a while.

Natural Inform/Inform 7, by the way, is merely a fancy pre-processor. Inform 6 is never far away.

[Calin Leafshade]

Then the aim should be to add those features to AGS Script.

I disagree.

Lua (or AngelScript or Python or whatever) are established languages with a user base that eclipses AGS. Why bother writing and maintaining our own proprietary language when off-the-shelf alternatives exist which have far better testing regimens and far greater support upstream?

Also I should say that my argument was not necessarily in favour of changing the defacto language for AGS to Lua. Merely that users such as myself should consider it as a very viable alternative to ags script. What the AGS developers do is of no consequence to that discussion.

[Clarvalon]

My 2p - I'll preface this by saying I think that, given they're primarily the work of one man, AGSScript and AGS Editor are terrific.  Writing your own scripting language and IDE with high-level features like Intellisense is no mean feat.  The sheer number of games produced using AGS is testament to that.

BUT:  For people with a programming background, who are used to using best-in-class languages and developer tools, it can be a little frustrating.  Granted I've written little AGSScript personally, but even in that time I've had to implement unusual workarounds to bypass the shortcomings of the scripting.  And as someone who regularly converts to a somewhat stricter language (C#), things like AGSScript's laissez-faire approach to static typing can be a pain.

BUT:  A counter-argument would be that you have to keep AGS's primary purpose in mind (highlighting mine):

What if i wanted to do this 1000 times for my RPG?

It lowers the barrier for entry for making Adventure Games significantly.  Having the scripting so tightly coupled with the editor is likely part of its success in bringing people in from a non-programming background.

[cianty]

Just a quick question... is this entire discussion about AGS vs Lua or is about using the Lua plugin in AGS to an extend as high as possible? I mean, AGS already comes as a framework with all things adventure game related already done for you. You just need to fill in the contents. Is there are similar - similarly powerful - library for Lua that would make is as easy to get a 2D point and click up and running in a short time? Or would have have to build up the basic stuff - like rooms and a "dialog engine" yourself? I did have a very quick look at Zoetrope recently and it seemed interesting. Still, I didn't bother preparing all the basics for a Lua adventure yet.

[Crimson Wizard]

Just a quick question... is this entire discussion about AGS vs Lua or is about using the Lua plugin in AGS to an extend as high as possible?

It's about using Lua instead AGS script to communicate with AGS engine, of course, not about writing your own engine on Lua.
Calin's point is that Lua allows to extend the engine more than AGS script (or more easily).

[Calin Leafshade]

Yes, the AGS-Lua plugin is essentially a drop-in replacement for AGS Script. All the functions and properties available to AGS Script (like rooms and dialogs and stuff) are all available to the Lua plugin.

[monkey0506]

A lot of your criticism of my argument is pendantry at best and just lying at worst.

The only portion of what I said that was even remotely debatable was my personal evaluation of your attitude toward AGScript. I never said or implied any of the AGScript solutions were better, I corrected your false assertions about difficulty or messiness of AGScript.

To argue that AGS can support some kind of function pointer functionality by coding a big if else block to run different funtions based on an enum is laughable. I mean do you even understand what a function pointer is and why they are useful?

Of course not, I'm an idiot. However, contextually the example I provided was functionally equivalent.

Your argument for predefined variables is one of language semantics and could go either way depending on your stance on such things. For a scripting language I'd argue that dynamic, non-typed variables are better but opinions vary.

Indeed they do and I said as much. I personally feel that dynamic typing should go no further than C++11's auto keyword. By contrast, I find PHP's typing to be terribly error prone in practice.

On writing intuitive modules:

Are you suggesting that, with the function pointer example (maybe an event of some kind), it is better and neater to tell your user to add a new value to an enum in your code, create a new function higher up in the script and add calling the function to the module code? As opposed to just telling them to pass a function? If so then lol.

Again, you seem to have missed the point I was making with this example.

On a custom say function: What if i don't want it to be blocking? What if i want the user to be able to answer yes or no to a question? In Lua (it's not an abbriviation by the way while we're being pedants) coroutines allow you to essentially have a kind of threaded system.

If you don't want it to be blocking then ffs don't make it blocking. You act as if it's even remotely complicated. Creating a per-Character queue of background speech isn't even difficult. You are pretending like these are impossibly hard tasks while in reality they are utterly trivial.

no doubt that such a system is perfectly possible in AGS but it wouldn't be as pretty and you couldn't make it non-blocking because AGS only has a single scripting thread and no coroutines.

The code example you provided attempted to trivialize the Lua implementation by not actually providing definitions. The resultant calls in AGScript would be extremely comparable in complexity. The definitions are where it would vary, and granted the Lua implementation probably would be simpler. But to suggest that the AGScript implementation would be horrendously more complex, or that it couldn't be blocking - this is just open and blatant slander.

AGS Script was a great idea 10 years ago. Computers weren't fast enough to have a JIT compiled scripting language and a pre compiled option was a good idea but now it's obsolete. Let's look at the things AGSScript doesn't have that lua does.

You still haven't provided a sufficient rationale for why AGScript should be deprecated - even in your later posts. There are more benefits to keeping and improving AGScript as a language than the detriment that would be done by replacing it with a non-proprietary language. Chris Jones knew what the hell he was doing, it would have been easier to use an existing language. AGScript has been custom designed to fit a purpose, which purpose has not dissolved or gone away.

dynamically typed variables (you don't get tired of IntToFloat?)

Not in the least. Automatic type promotion or demotion is error prone. Static casting is a better programming style, despite its verbosity.

preclude

lol, that's obviously not the word I meant, so that was well deserved. For the record I am aware of its meaning.

[monkey0506]

it's *possible* but i think we can agree that it would be horribly messy, require a lot of duplicate code and be impossible to modularise .

See, you seem to favor identifying easily managed tasks as being impossible. That is why I am not a fan of your technical opinion of things. Nothing against you as a person, but you speak a lot of untruths in the programming game.

That being said, Lua is a great language that does offer many features that AGScript is *presently* missing, which *could* result in a simplified workflow for *some* tasks.

[miguel]

Sorry for my ignorance, I feel I'm way out of my league here, BUT:

- does the AGS-Lua plugin allow me to completely code a game in Lua? I understand that all the character, hotspots, objects, etc, can be "called" normally?
- If so, why is this debate happening? If the plugin has no "side-effects" then it should be optional. No?
- where can I find some common "workarounds" to stuff like non-blocking functions? The search engine is a pain.

[Calin Leafshade]

- does the AGS-Lua plugin allow me to completely code a game in Lua? I understand that all the character, hotspots, objects, etc, can be "called" normally?

Yes

- If so, why is this debate happening? If the plugin has no "side-effects" then it should be optional. No?

It's entirely optional bu my contention is that its better in almost every way and i wsh to evangelise that to the people.

- where can I find some common "workarounds" to stuff like non-blocking functions? The search engine is a pain.

I would argue that there are no common work arounds because non-blocking stuff in AGS is difficult to easily modularise. Monkey may disagree.
The closest example i can think of is the Character Controller module that allows you to queue up actions for NPCs from a list of predefined actions.

This is a good example actually of a common problem in AGS that lua solves.

People often want to do something like this:

Make a character walk to a specific location and then do something when it's arrived while not blocking the interface.

In AGS one would do something like this:

Code: ags

bool sentGuy = false;

function MakeWalk()
{
    cGuy.Walk(300,300,eNoBlock);
    sentGuy = true;
}

function FinishedWalk()
{
    cGuy.Say("I have arrived at 300,300");
}

function repeatedly_execute()
{
    if (sentGuy && !cGuy.Walking)
    {
        sentGuy = false;
        FinishedWalk();
    }
}

I'm sure we can all agree that that is perfectly serviceable and works fine.. but can we also agree that it's a little unintuitive?

In Lua you could simply have a background coroutine for the room. Let's say I wanted a guy to do several repetative tasks in a room over and over again:

Code: lua

function backgroundThread()
    while (true) do
        cGuy:NonBlockingWalk(300,300)
        cGuy:NonBlockingSay("I have arrived! I will now walk back again!")
        cGuy:NonBlockingWalk(100,300)
    end
end

(The NonBlocking functions are just self-yielding, reuseable, wrapper functions which are easily modularisable)

Now see how much more intuative that is? Semantically, one can say that this guy will do this things over and over again in a loop, without interrupting program flow. We've essentially self-contained his behaviour into one function without having repex involved at all. Tell me that aint cool?

[Crimson Wizard]

I decided to test lua plugin a bit and try out those coroutines, and found out you actually should control its execution along the way.
That example above looks nifty, but, if I understood this correctly, in reality you have to write a custom function for EVERY lengthy action you want to be used in coroutine (walk, say, etc), or otherwise control when it suspends and resumes. I know that sounds like an annoyed noob ramblings, but I seriously felt like I was lied to.
Would you care to post full, working example?

[miguel]

(The NonBlocking functions are just self-yielding, reuseable, wrapper functions which are easily modularisable)

Now see how much more intuative that is? Semantically, one can say that this guy will do this things over and over again in a loop, without interrupting program flow. We've essentially self-contained his behaviour into one function without having repex involved at all. Tell me that aint cool?

Calin, it does look really cool. But it almost looks too easy.
I'm afraid I stand by Crimson Wizard and would like to see a full working example, please.