Hello everyone,
Wasn't sure where to put this.. its sort of technical but not technical enough to warrant the tech forum.
Anyway, I have come to the conclusion that everyone should stop using AGS script and move over to Lua for a wealth of reasons. it seems like a no brainer to me and yet I have seen a lot of resistance. I would like to know why that is and I would like to help wherever I can.
Are there modules you need for lua that I can code for you?
Are you just not sure how to link ags and lua together?
Are you afraid of putting in the effort of learning a new language?
Do you not see the benefits?
Tell me why, AGS forumers and I will do my best to help and ease the transition because I think it is a wasted opportunity for all you cavemen still languishing in AGSScript land.
What would you say are the key benefits of using Lua instead?
I understand that LUA should be a more powerful language than the one we get with AGS, but is it as easy to learn?
The one thing that gets people into AGS is its easy learning-curve.
Usually one would need a reason to use something above the standard features. That reason should be strong enough to stimulate learning (and using).
The reason appears when standard features are not enough to make what you want. This depends both on complexity of your game and your programming skills, or, maybe, programmer's way of thinking. Novices are often using very basic techniques to produce overcomplicated code simply because they do not know that they are doing it wrong. Even when you become more skilled, it may not be obvious that your program will become better (optimized, terse) if you'd use features that exist in other scripting language and do not exist in the one you are using.
In other words, people should know not only a list of features, but also a distinct examples of what they may do with them. Not "for fun", but serious practical examples of code (preferably fit for adventure game) that is not possible with AGS script, or requires too much effort with AGS script, while possible to do with less effort with Lua.
I suppose I did put the cart before the horse and should make my case first. Ok here I go.
First I should be honest. In terms of actual results, there isnt much that lua can do that AGSscript absolutely can't do but it might be *alot* easier in lua.
Ok a quick example. In my latest adventure game I have a contextual interface. That is to say that when you right click a hotspot you get a list of named actions. I tried to code this in AGSScript before i had lua and it was a fucking nightmare. If/Else statements coming out my wazoo. Because functions pointers dont exist in lua i had to tie all my interactions to cursor modes to separate them which was messy, made no sense and was stupid.
In lua however, i can set up a system where i can add an interaction to a hotspot like this:
RegisterInteraction(roomNumber, hotspotIndex, "Hit the table", function()
player:Say("I hit the table!")
end)
And I can do this for as many hotspots and interactions as i like with no limitation.
Notice that I used a function like a variable. In lua you can do this which is *very* useful for adventure games.
Another example is that I can add arbitrary values to ags objects at runtime. Let's say my NPC had a 'suspicion' level and when it reached 100 he found me out in my misdeeds or whatever.
In ags I would store this in a different variable. If i had one for each npc I would store it in an array somewhere probably. In lua i can simply type:
ags.cNPC.Suspicion = 50
And it's done, it's all in the same object and it makes semantic sense.
Also, all lua function and variables do NOT have to be declared before use. In AGS it's impossible to organise nice systems that depend on one another. Say you have a Camera struct and a Map struct and the camera wants to interact with the map but the map also needs to know where the camera is. This is impossible because AGS has no system for forward declaration which means your code has to be messy and shitty.
Reason 4 or 5 or whatever i'm on is that Lua is an established language with a lot of resources available. If you want code to do some pathfinding then there are dozens of Lua scripts already available in nice little modules.
Lua has a couple of plugins for oft-requested ags functions including TCP/IP.
Lua has coroutines which I've use in my RPG engine to have a custom say function which isn't hashed together bollocks like is required with ags and a million if/elses in repex.
Speaking of my RPG engine, I've managed to make an (almost) fully working RPG system with a nice inventory and map system in lua and it took me a few days max. Something no one else has done (to my knowledge) in AGS for a long time.
Lua will allow module makers to make more intuitive modules because we can have classes and inheritance and events and function pointers.
AGS teaches you a worthless skill badly.
AGS script is basically like C but with all the good bits missing and what this does (in my opinion) is teach you to be a poor programmer. You don't learn in terms of data structures because in AGS working with data structures is a chore. Not being able to pass structs either by value or by reference is a *massive* problem when it comes to teaching people how to code. Also, AGS script is only used in AGS. You might as well learn Lua and have another skill to add to your repetoir.
Sorry for the brain dump.. i just kept typing.
(And this before i've even mentioned the magic of tables)
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50
In lua however, i can set up a system where i can add an interaction to a hotspot like this:
RegisterInteraction(roomNumber, hotspotIndex, "Hit the table", function()
player:Say("I hit the table!")
end)
And I can do this for as many hotspots and interactions as i like with no limitation.
That's funny because I've written and used similar systems for AGS. For example, Quasar uses one for the NPC interactions. Maybe I should put that up on the forum as a game template.
As i said, most of what lua can do (with the possible exception of coroutines) AGSscript can also do in a roundabout fashion. But I think the lua version is likely to be cleaner and more intuitive.
Well, personally I have no objections to use this myself (if I'd ever be making my game, that is (roll)).
But I am not sure how easy it would be for scripting beginners to use lua. Also, working on engine with JJS made me concern portability more.
The lua plugin is as portable as any other plugin and lua itself is exceptionally portable so I doubt portability is a concern unless you're talking abotu running it on a toaster or something.
Also, i'd argue that lua is easier for a beginner because it doesnt have some of the weird idiosyncracies of AGSscript (no forward declarations, weird variable casting and so on)
The main reason people wouldn't want to swap to LUA is that they know AGS already, and any time and effort taken to learn LUA would be unnecessary. Also, people who are in the middle of one or more game projects would have to start again from scratch.
Quote from: AGA on Mon 24/12/2012 17:11:18
The main reason people wouldn't want to swap to LUA is that they know AGS already, and any time and effort taken to learn LUA would be unnecessary. Also, people who are in the middle of one or more game projects would have to start again from scratch.
This, 100% this. I'm sticking to AGS while I learn how Unity works, and don't need to have to figure out Lua from scratch as well!
If the LUA plugin for AGS appeared very early on when I began working on my game, there were high chances I would have used that scripting language. Mostly for coroutines which my game relies a lot. And lots of lots of data management.
I would say I know mastered coroutines with the AGSscript, but I agree looking back at it I would surely use it as a weapon to kill coders with an aneurysm. Also there are a couple of stuff I wanted to code into my game that I didn't, because it was very difficult (read lots of work) to make it run properly while keeping track of everything.
While I can't switch on LUA with my current game, I will surely try out that scripting language on future games. Personally I think I maxed out the possibilities I can do with the AGSscript.
I think few demo games, demonstrating some tasks implemented in lua, would help to a) understand what is it all about, b) compare to AGS script.
IMO, it is not much of problem to learn new syntax, it is usually a time-consuming to learn new ways of making things you made in AGS script before. I mean - learning effective use of a new scripting language.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50In terms of actual results, there isnt much that lua can do that AGSscript absolutely can't do but it might be *alot* easier in lua.
I'm not familiar with this British term "alot". Care to clarify for me? :P
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Because functions pointers dont exist in lua i had to tie all my interactions to cursor modes to separate them which was messy, made no sense and was stupid.
First of all:
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Because functions pointers dont exist in lua
lolwut. :)
Function pointers may not exist in AGS, but that doesn't mean you couldn't set up a custom function to handle the work internally anyway. Your issue of function ordering (which you address later) does come into play, but it's not terribly difficult to do this (although in fairness Lua's function pointers would simplify things via function pointers):
function SomeDelegatedFunction(int param1, int param2)
{
// ...
}
function OtherDelegatedFunction(int param1)
{
// ...
}
enum DelegatedFunction
{
eDelegateSomeDelegatedFunction,
eDelegateOtherDelegatedFunction
};
function CallDelegatedFunction(DelegatedFunction func, int param1, int param2, int param3, int param4, int param5, int param6) // optionalized in import
{
if (func == eDelegateSomeDelegatedFunction) SomeDelegatedFunction(param1, param2);
else if (func == eDelegateOtherDelegatedFunction) OtherDelegatedFunction(param1);
}Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Another example is that I can add arbitrary values to ags objects at runtime. Let's say my NPC had a 'suspicion' level and when it reached 100 he found me out in my misdeeds or whatever.
In ags I would store this in a different variable. If i had one for each npc I would store it in an array somewhere probably. In lua i can simply type:
ags.cNPC.Suspicion = 50
And it's done, it's all in the same object and it makes semantic sense.
While it may make semantic sense in Lua, many would argue that this creates more pitfalls than the potential benefit. What happens if I mistype "Suspicion" as "suspicion" or "Suspcion"? I've inadvertently created an entirely separate variable which, at a glance, may not be readily apparent. I would actually advocate taking the idea of AGScript's extender methods further by allowing static extender methods and member extenders (via accessors, which AGS is already using internally anyway, so the precedent is already set). Of course it's an open matter of debate and preference here, but the fact that AGScript doesn't allow undeclared extensions is a
feature IMO, not a drawback.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Also, all lua function and variables do NOT have to be declared before use. In AGS it's impossible to organise nice systems that depend on one another. Say you have a Camera struct and a Map struct and the camera wants to interact with the map but the map also needs to know where the camera is. This is impossible because AGS has no system for forward declaration which means your code has to be messy and shitty.
This is just blatantly false. AGS has a well defined mechanic for forward declaring a struct (case in point: GUIControl and its child types). To be fair though, an undefined (but declared) struct is only useful for defining pointers, and AGScript doesn't allow pointers to user-defined types. So instead of pouring filthy misrepresentations of AGScript, I feel that perhaps the pointer mechanic it already includes should be extended to allow pointers to user-defined types. Even if you could only define pointers to "managed" types (meaning it uses the AGS "managed" keyword) with a static Create and member Destroy method, that would give all the functionality you'd need.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Reason 4 or 5 or whatever i'm on is that Lua is an established language with a lot of resources available. If you want code to do some pathfinding then there are dozens of Lua scripts already available in nice little modules.
Lua has a couple of plugins for oft-requested ags functions including TCP/IP.
These are actually good rationales for using Lua, but that doesn't preclude replacing AGScript with Lua altogether.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Lua has coroutines which I've use in my RPG engine to have a custom say function which isn't hashed together bollocks like is required with ags and a million if/elses in repex.
I'm not sure if you mean to indicate extender methods as "hashed together bollocks" or you instead meant a "from scratch" function which doesn't use the built-in Character.Say or Character.SayBackground methods. In any case, I know for a fact that AGS can't handle a million else clauses, but I've never tried a million separate if statements (or a combination thereof summing up to a million). Oh wait, that was a hyperbole? Must have been your British accent causing the confusion. :P Still, I've personally written dozens of custom say functions (both with and without the use of the built-in methods) and I would be hard pressed to refer to the experience as "hashed together bollocks". Then again, I've never seriously looked into coroutines, so I can't much speak on how Lua might make it easier.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Speaking of my RPG engine, I've managed to make an (almost) fully working RPG system with a nice inventory and map system in lua and it took me a few days max. Something no one else has done (to my knowledge) in AGS for a long time.
I would say challenge accepted if I weren't so bloody apathetic at this point. The only reason I'm posting this is because you, Calin, have a dirty habit of spreading lies about AGScript and it disgusts me. :D
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Lua will allow module makers to make more intuitive modules because we can have classes and inheritance and events and function pointers.
AGScript already allows module writers to use classes and inheritance. I've already addressed that function pointers aren't inconceivably difficult to work around. As for events, it's true that AGS doesn't have a separate construct for user-defined events, but in the end wouldn't that just be syntactic sugar for an if-statement inside of repeatedly_execute? What's more, since the module can have its own rep_ex, it's not like it would even have to contend with the code from other modules - many of my modules have their own rep_ex with just a few lines.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50AGS teaches you a worthless skill badly.
I see nothing worthless in learning the basic principles of programming. Just because it's a separate language doesn't mean it is wrong. With the plethora of languages that exist, AGScript makes it easy for someone with any level of programming experience to make adventure games - which, by the way, is what
AGS is designed for. :P
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50AGS script is basically like C but with all the good bits missing and what this does (in my opinion) is teach you to be a poor programmer. You don't learn in terms of data structures because in AGS working with data structures is a chore. Not being able to pass structs either by value or by reference is a *massive* problem when it comes to teaching people how to code. Also, AGS script is only used in AGS. You might as well learn Lua and have another skill to add to your repetoir.
I agree that learning a mainstream language may have more real-world benefit than learning a proprietary one. I am a living testament to this. However, I feel that you are extremely poorly educated and excessively critical in terms of AGScript. The one change of being able to define pointers to user-defined types (even with stipulation) would fit your every requirement for making the user-side of AGScript more object-oriented. I will admit that this is a valid point when scripting more advanced features, but only in terms of OO languages. There are still many non-OO languages that are highly popular.
As for function pointers (coming back to that), you yourself wrote a plugin that exposed a way to dynamically link functions in AGS. By your own admission the plugin was a simple task - exposing this directly to the engine itself would be trivial. Most of "the good bits" that you claim AGScript has removed are there in some fashion. It would require changes to the engine to include the functionality that you are seeking. The relatively few number of changes that would need to be made to add these features though, to me that stands as all the more justification for
not scrapping AGScript.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50(And this before i've even mentioned the magic of tables)
My very primitive understanding of tables in Lua is that they're basically the Lua equivalent of a struct or class (the ability to add members simply by referencing them is an inherent part of the Lua language itself). The meta table in so far as I can tell would be comparable to overloading operators and such.
All in all, I'm not saying that AGScript is better than Lua (or vice versa), I'm just making a point that AGScript isn't the wretched creature everyone tries to make it out to be. Honestly, I feel that
both should be an option, and more should options should be added. I do not feel that AGScript should be removed any time in the near future however, because it does have a relatively low learning curve, and it is far more capable than many would like to assume.
I'm sure there's a shorter way to say "I'm a pedantic prick".
No, I checked. There's not.
A lot of your criticism of my argument is pendantry at best and just lying at worst.
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?
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.
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.
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.
player:MyCustomSay("Hi!")
if player:Ask("Are you a pedant", "Yes", "No") == "Yes" then
player:MyCustomSay("You are a pedant")
end
Now, I have 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.
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.
dynamic, multi dimensional arrays
function pointers
ternary ops
for loops
dynamically typed variables (you don't get tired of IntToFloat?)
keyed arrays
*proper* forward definition
functions as first-class citizens
the ability to pass data structures (seriously lol)
I could go on.
Quote
These are actually good rationales for using Lua, but that doesn't preclude replacing AGScript with Lua altogether.
Look up 'preclude'.
For a stock-standard adventure game, I can't think of anything I'd want to do that is actually difficult in AGS script, or overly messy, to be honest.
I've been writing in AGS script for years, and it's not that I feel that another style of coding would be less efficient, it's that I feel that I as the designer would be less efficient at using the script. It's hard to be bothered to move over to another style of scripting when I know I can do pretty much anything I want in AGS script and more importantly, I already understand how.
In saying that, your custom say function looks interesting. This is something that would maybe convince me to move over, because it's a practical, and instantly obvious with how it is easier to use.
But yeah, it's hard to want to learn new stuff when I can already make the games I want to make with the stuff I already know. I think you need to illustrate your point in a more compelling light - perhaps create a quick example game script which illustrates the simplicity and functionality you are trying to promote.
Of all the things being said above,
This:
Quote from: monkey_05_06 on Tue 25/12/2012 02:51:23
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50Another example is that I can add arbitrary values to ags objects at runtime. Let's say my NPC had a 'suspicion' level and when it reached 100 he found me out in my misdeeds or whatever.
In ags I would store this in a different variable. If i had one for each npc I would store it in an array somewhere probably. In lua i can simply type:
ags.cNPC.Suspicion = 50
And it's done, it's all in the same object and it makes semantic sense.
While it may make semantic sense in Lua, many would argue that this creates more pitfalls than the potential benefit. What happens if I mistype "Suspicion" as "suspicion" or "Suspcion"?
was my concern too. Actually I found this behavior unacceptable, and if there would be some kind of "switch" to disable it in lua, I'd set it by default.
It would be more convenient, if Lua just allowed to define new variables in certain place. Maybe it does?
The AGSScript-way of implementing "function pointers" is just terrible, though. Same about user events... The whole idea of computers is automatization of human work, and sticking to such constructions doesn't do any good.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50
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.
<...>
Now, I have 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.
Now. That's simply not true. I can make a non-blocking custom say function in AGSScript, since AGSScript has repeatedly_execute functions it is possible to organize a classic state machine there. The fact that it has only one thread means only organizational problem (but so does multi-threading). To be frank, I found this statement quite naive... not to offend you, Calin, but how do you suppose any program could run any number of simultaneous tasks having one thread? Such things are, of course, possible and valid.
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50
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.
I was rewriting AGS script interpreter, making it a more type-safe along the way, and recently a user of PSP port reported that certain game became quite slow because of that. And this is still precompiled AGS script.
I don't want to make any assumptions here, but it would be good to know how fast Lua actually works when handling lots of scripting tasks.
(There's of course such thing as optimization. The problem I mentioned may be related to the way AGSScript handles basic operations)
In any case it would be interesting to compare benefits of using Lua (or other script language) and developing AGSScript further. But I am afraid this gets beyond the topic.
Using fully developed language is a huge benefit on its own. And to be honest, the monkey_05_06's position looks like defending something only because he got used to it, or devoted a lot of time for it.
Quote from: Crimson Wizard on Tue 25/12/2012 08:06:20
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50
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.
<...>
Now, I have 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.
Now. That's simply not true. I can make a non-blocking custom say function in AGSScript, since AGSScript has repeatedly_execute functions it is possible to organize a classic state machine there. The fact that it has only one thread means only organizational problem (but so does multi-threading). To be frank, I found this statement quite naive... not to offend you, Calin, but how do you suppose any program could run any number of simultaneous tasks having one thread? Such things are, of course, possible and valid.
Not naive, factual.
Certainly you *could* cobble together a non-blocking say function but how would you chain calls in an easy way?
For instance:
player.CustomNonBlockingSay("Hi There!");
player.CustomNonBlockingSay("Uh oh.. this function has run immediately after the preceding one...");
player.CustomNonBlockingSay("Oh no! Now i've missed two say functions because the function kept running!");
Lua avoids this problem with coroutines.
Quote
Quote from: Calin Leafshade on Mon 24/12/2012 14:24:50
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.
I was rewriting AGS script interpreter, making it a more type-safe along the way, and recently a user of PSP port reported that certain game became quite slow because of that. And this is still precompiled AGS script.
I don't want to make any assumptions here, but it would be good to know how fast Lua actually works when handling lots of scripting tasks.
(There's of course such thing as optimization. The problem I mentioned may be related to the way AGSScript handles basic operations)
My preliminary findings suggest that Lua is faster than AGS Script when doing pure arithmetic and stuff that is confined within the Lua universe (string operations and so forth).
It is slower than AGS when accessing AGS functions because of all the interop stuff going on.
EDIT:
I should point out that coroutines are not actually threads in the traditional sense. They are just a way of having parallel functions running in a single threaded environment like a scripting thread.
Quote from: Calin Leafshade on Tue 25/12/2012 08:19:05
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"?
Quote from: Crimson Wizard on Tue 25/12/2012 08:43:01
Quote from: Calin Leafshade on Tue 25/12/2012 08:19:05
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 .
Quote from: Crimson Wizard on Tue 25/12/2012 08:43:01
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.
Quote from: Calin Leafshade on Tue 25/12/2012 08:49:12
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.
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.
I think that would be a very bad idea.
Can you imagine something like Resonance written in an Inform 7 style language?
Quote from: Calin Leafshade on Tue 25/12/2012 16:07:41
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.
Quote from: Sslaxx on Tue 25/12/2012 16:23:44
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.
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.
Quote from: Calin Leafshade on Tue 25/12/2012 17:06:49
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.
Quote from: Sslaxx on Tue 25/12/2012 17:15:36
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.
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):
Quote from: Calin Leafshade on Tue 25/12/2012 08:49:12
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.
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.
Quote from: cianty on Tue 25/12/2012 23:23:17
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).
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.
Quote from: Calin Leafshade on Tue 25/12/2012 05:47:43
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.
QuoteTo 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.
QuoteYour 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.
QuoteOn 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.
QuoteOn 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.
Quoteno 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.
QuoteAGS 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.
Quotedynamically 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.
Quotepreclude
lol, that's obviously not the word I meant, so that was well deserved. For the record I am aware of its meaning.
Quote from: Calin Leafshade on Tue 25/12/2012 08:49:12it'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.
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.
Quote from: miguel on Wed 26/12/2012 11:42:44
- 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
Quote from: miguel on Wed 26/12/2012 11:42:44
- 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.
Quote from: miguel on Wed 26/12/2012 11:42:44
- 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:
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:
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?
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?
Quote(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.
Well, I won't lie and say that what I posted is simple to *set up* but it is simple *to use*.
but ok I will try and compose a quick example of exactly how the system would work:
A coroutine is basically a function that can be stopped (yield) and resumed. So to use it would look like this:
activeCoroutines = {} -- a new table for all our coroutines
function FireCoroutine(f)
activeCoroutines[#activeCoroutines + 1] = f -- add our coroutine to a table
end
RegisterEvent("AfterFadeIn", function() -- this all happens in After_FadeIn
FireCoroutine(backgroundThread) -- fire our coroutine off
end)
function backgroundThread() -- our coroutine
while(true) do
cNPC:AsyncWalk(300,300)
cNPC:AsyncWalk(100,300)
end
end
RegisterEvent("repeatedly_execute_always", function()
for i,v in ipairs(activeCoroutines or nil) do
coroutine.resume(v)
end
end
function ags.Character:AsyncWalk(x,y)
self:Walk(x,y,ags.eNoBlock)
while(self.Walking) do
coroutine.yield()
end
end
Yes, there is a lot of set up there but the set up only needs to be done *once* and not *by the user*, it can be done by a module maker.
Also, this is not the best way to do it and this code would cause problems like the coroutine being fired everytime the room is entered but you could engineering a very nice system whereby each character was essentially a closed system, each with its own behaviour all contained within a single function
Well, sorry, I finally got it myself. Although my head nearly exploded in the process. Exactly the Lua ability to invent new variables when I make a typo or forget to add "ags." prior to AGS function calls. :P
(Or maybe it hides all runtime errors?)
http://www.mediafire.com/?82ahevtx9po0994
I did this:
function ags.Character:NonBlockingWalk(x, y)
self:Walk(x, y, ags.eNoBlock)
self:SayBackground("Where I am going?")
while (self.Moving) do
coroutine.yield()
end
end
function ags.Character:NonBlockingRamble()
self:SayBackground("What am I doing here?");
ticks = 0
while (ticks < 120) do
coroutine.yield()
ticks = ticks + 1
end
end
local function BemanWalkAroundAndRamble()
while (true) do
ags.cBman:NonBlockingWalk(ags.Random(300),ags.Random(200))
ags.cBman:NonBlockingRamble()
end
end
local co
function OnRoomEnter()
co = coroutine.create(BemanWalkAroundAndRamble)
end
function OnRoomTick()
coroutine.resume(co)
end
In AGS Script:
function room_FirstLoad()
{
<...>
Lua.Call("OnRoomEnter");
}
<...>
function room_RepExec()
{
Lua.Call("OnRoomTick");
}
Quote from: Crimson Wizard on Wed 26/12/2012 14:57:21
(Or maybe it hides all runtime errors?)
Oh yea, another thing Lua can do that AGS can't. (Exceptions)
Played your testgame CW, very nice indeed.
But you guys can code much better than me, I hate not understanding what I'm doing.
Anyway, I would use modules made with Lua, that's for sure.
Good points from both sides.
Here are my thoughts, based on my experience working on Barely Floating, which has around 10 lines of AGSScript and slightly over 32000 lines of Lua code. Excuse me for my excessive babbling.
So, why did I try the Lua plugin? Basically, I was sick and tired of AGSScript. It had serviced me fine for the many years I'd made games with AGS, but having to jump through all sorts of hoops to create workarounds, even for some simpler things, had become a nightmare. Back when I was working on this (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=35027.5), I tried to script a custom dialogue option system that would give me a bit more freedom to do things my way. In the end, I had a global script full of all kinds of crap because I couldn't do forward declarations for some things and spread them all neatly inside modules. I think that was the last straw. The next games I worked on were OROWs so I didn't have the time to experiment with the Lua plugin until I started work on Barely Floating.
In the meantime, I had also made a remake of one of my OROW games with an engine made by myself. That thing was scriptable with Lua so I already had some ideas how the framework should be organized on Lua's end (dialogue systems, interactions, etc.). So, my mission statement for Barely Floating was to write a framework (based on my earlier work) that required you to do only a minimal amount of scripting in AGS. Everything should be in Lua scripts. Everything should be modifiable without even opening AGS: adding hotspots (rectangles), working with hotspots, regions, characters, dialogue trees, etc. It took a while to make but in the end, I don't think I would've finished the game if I'd had to rebuild the game every time I made a change in AGSScript. In the end, the executable was over 1 GB in size, so rebuilding was not instant, even if I made no changes to the graphical assets.
Since most of the discussion has been about the low level features of AGSScript vs Lua, I'll concentrate on things you can build with the Lua building blocks.
Here's some things the Lua framework did that I couldn't live without:
1. Script console. One of the first things I made for the framework, and one of the things I used most: press a button, an input box appears, write some Lua code, hit enter and the code gets executed. Want to jump forward to a specific puzzle? Easy. (Check #6 aswell.) Quickly test calling a function. Move things around. Pretty much anything you could do with one line of code since AGS doesn't support multiline input boxes.
2. Reload interaction scripts. While the game is running. Seriously, what a time saver. Found a typo? A character walked to the wrong spot? Fix it in the script, press a button to reload it, and test again.
3. Coroutines. This has been mentioned many times in this thread and it really makes seemingly multi-threaded interactions really simple to make. Of course, you'll eventually run into problems with concurrency, like a background thread controlling a character and then the main thread needing to control that character at the same time.
4. Return self and being able to chain method calls. Here's an example of what my interaction scripts are full of. The methods seductive/concerned would change the character's facial expression accordingly.
cDude:seductive()
:say( "What's up, love?" )
:say( "How about we go for a walk?" )
:concerned()
:say( "Do you think I'm asking too many questions?" )
5. Edit mode. Press tab and you can move characters, objects and hotspots, create new hotspots and finally export the room's Lua script so you can do simple AGS editorey things within the game.
6. Puzzle tracking. All the game's puzzles are defined as simple state machines that also modify the game environment when certain states are reached. I was pretty lazy about this, so basically, when you reach the end of a puzzle the puzzle's end state makes sure the game is in the correct state: hotspots are turned on/off, objects moved, etc. And then comes the best part, you can skip puzzles, and the game will be in the correct state, as if you'd played through the puzzle. Very handy when debugging. Of course, you need to be careful that the puzzle script actually changes the game state correctly.
7. Making a table (~array) log any changes made to its indexed values. Very handy for debugging.
cDude.state.happy = true
-- Prints to the log something about key happy being set to true
As with most things, there are drawbacks:
1. You need to be really careful with interpreted languages like Lua. You don't get a neat list of errors when you compile your game, informing you of critical typos and such. Nope, you only get a crash or an error message or worse, nothing at all, when you reach the part of the game where that invalid piece of code gets executed. This is, in my book, the greatest drawback of interpreted languages, however the flipside of it is also their greatest asset: not needing to wait for it to compile, ability to reload scripts, etc.
2. Until there is a publicly available AGS-Lua framework, most of the advantages I listed earlier would have to be created from scratch which is going to take some time depending on what you need. I still haven't had the energy to clean up my framework for public release, unfortunately, even though I promised months ago. :(
Can't think of any more major drawbacks right now. Learning new syntax isn't really a drawback. You usually get the hang of it quite quickly when you start scripting. Syntax only becomes a drawback when it prevents you from doing things. There's one such thing in Lua that annoys me: not being able to do "value++", instead you have to do "value = value + 1".
Many of these things I've mentioned are most likely not of much interest to beginning scripters but to more experienced ones, I'm sure they'll find at least one or two things they wouldn't want to pass up on.
And since the coroutines are a hot topic right now, here's my Thread class from Barely Floating (comments are in Finnish but I hope you get the idea): http://www.serpentpictures.net/randomia/Thread.lua (http://www.serpentpictures.net/randomia/Thread.lua)
Quote from: AJA on Wed 26/12/2012 15:20:56
There's one such thing in Lua that annoys me: not being able to do "value++", instead you have to do "value = value + 1".
There isn't even "value += 1" ? Odd.
Why isn't Lua included with AGS? I haven't used AGS in awhile, but if I were to use it, the only thing holding me back from using Lua is laziness. lol
Nope. Can't remember why, though. It had something to do with the design of the language.
Quote from: AJA on Wed 26/12/2012 15:20:561. Script console. One of the first things I made for the framework, and one of the things I used most: press a button, an input box appears, write some Lua code, hit enter and the code gets executed. Want to jump forward to a specific puzzle? Easy. (Check #6 aswell.) Quickly test calling a function. Move things around. Pretty much anything you could do with one line of code since AGS doesn't support multiline input boxes.
Adding a
proper mechanic to equate function pointers would be trivial, as already proven by a plugin Calin wrote. Adding a new control type for multiline text boxes (text areas) would probably be more complicated, but is something that should be added to AGS
anyway. A text-script parser could then be supplied or custom designed with these features.
Quote from: AJA on Wed 26/12/2012 15:20:562. Reload interaction scripts. While the game is running. Seriously, what a time saver. Found a typo? A character walked to the wrong spot? Fix it in the script, press a button to reload it, and test again.
Since AGScript is compiled and not interpreted, this is a by-design "con" of the language. However, C++ stands as a strong proof that compiled languages are still viable.
Offering interpreted alternatives such as Lua should be a goal that is kept in mind by those updating the engine, but should not be included in the engine itself. Alternate languages should be provided via plugins, as extensions to AGS.
It might be useful to consider moving toward an interpreted design, perhaps even just for the debugger, but I don't view being a compiled language as a direct flaw in AGScript.
Quote from: AJA on Wed 26/12/2012 15:20:563. Coroutines. This has been mentioned many times in this thread and it really makes seemingly multi-threaded interactions really simple to make. Of course, you'll eventually run into problems with concurrency, like a background thread controlling a character and then the main thread needing to control that character at the same time.
I understand how coroutines are useful, but I haven't heard many specific examples of how they would be used in making an adventure game. Queued background speech is something that has been done multiple times (my module is updated to work with recent AGS versions, although I don't believe it uses any of the 3.2 audio functions). The CharacterControl module handles queuing various other types of interactions. The examples I've seen here of coroutines have applied to simplify the process, essentially just negating the need for the modules. But the modules have already been made publicly available, and the resultant code is of comparable simplicity.
I'm not trying to sound close minded here, allowing AGScript to create and run separate threads in the engine would be nice for advanced users. I simply don't feel that a compelling case has been made for this point, more just that this is one more thing added to the list.
Quote from: AJA on Wed 26/12/2012 15:20:564. Return self and being able to chain method calls. Here's an example of what my interaction scripts are full of. The methods seductive/concerned would change the character's facial expression accordingly.
cDude:seductive()
:say( "What's up, love?" )
:say( "How about we go for a walk?" )
:concerned()
:say( "Do you think I'm asking too many questions?" )
Personally I feel that chaining unrelated function calls is simply bad practice. You're doing this solely for the purpose of avoiding having to reference the object again. It's ultimately a matter of preference I suppose (for languages that support it), but it could lead to confusion or error-prone code. For example, what if I have a function that just happens to return a Character*, but uses null for an error case? If you've used it in your chain without knowing about the error case then you could have some difficulty debugging the code.
Quote from: AJA on Wed 26/12/2012 15:20:565. Edit mode. Press tab and you can move characters, objects and hotspots, create new hotspots and finally export the room's Lua script so you can do simple AGS editorey things within the game.
I'm not certain what you're referencing here. It would be simple to set up a debugging interface for moving things around, turning them on and off, etc. There are modules that provide some of this generically. As far as creating new hotspots, the AGS engine itself doesn't allow new hotspots to be created at run-time so I'm guessing that you're managing this yourself in Lua code? I imagine that it would be of comparable complexity to implement something similar in AGScript (but then I'm not sure how you're doing it).
Quote from: AJA on Wed 26/12/2012 15:20:566. Puzzle tracking. All the game's puzzles are defined as simple state machines that also modify the game environment when certain states are reached. I was pretty lazy about this, so basically, when you reach the end of a puzzle the puzzle's end state makes sure the game is in the correct state: hotspots are turned on/off, objects moved, etc. And then comes the best part, you can skip puzzles, and the game will be in the correct state, as if you'd played through the puzzle. Very handy when debugging. Of course, you need to be careful that the puzzle script actually changes the game state correctly.
A finite state machine is something that is incredibly simple to set up in AGScript. You could use rep_ex to keep the game state consistent with the machine state for now. When function pointers are eventually implemented in AGScript you could add a callback function instead of having to manage it in rep_ex. All in all this would be comparable in implementation.
Quote from: AJA on Wed 26/12/2012 15:20:567. Making a table (~array) log any changes made to its indexed values. Very handy for debugging.
cDude.state.happy = true
-- Prints to the log something about key happy being set to true
While AGS doesn't have something like this built-in, logging changes like this would be simple to set up with encapsulation. You could either just have the accessor methods exposed as part of the public interface or use attributes to mask that nastiness. In either case the actual data would be protected and in the accessor methods you would call the logging function.
I'm really not trying to oppose Lua as an alternative to AGScript, but I am trying to debunk this idea that AGScript needs to be replaced. Just because there are a few things that need to be added doesn't mean that AGScript is suddenly obsolete and should be deprecated entirely.
Quote from: Calin Leafshade on Wed 26/12/2012 15:07:14Oh yea, another thing Lua can do that AGS can't. (Exceptions)
The connotation represented by this statement is that AGS will never have exception handling. The fact of the matter is that AGS already detects both run-time
and compile-time errors (the latter being something that Lua, as an interpreted language "can't do"). AGS doesn't currently have a way for the user to handle exceptions (such as a null pointer being (de)referenced), but that doesn't mean it couldn't (or shouldn't) be included at a later time. Isn't improving the current state of AGS the entire point of releasing new versions of the program?
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
Adding a proper mechanic to equate function pointers would be trivial, as already proven by a plugin Calin wrote.
To be clear, my plugin wasn't even close to allowing true function pointers. It simply queued a script function which is not the same thing at all. There was no control over the params and you couldnt manipulate the pointer in any sense. It was entirely faked.
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
A text-script parser could then be supplied or custom designed with these features.
You need more than simplistic access to user functions to make a sciprt parser. Unless you plan on implementing all the other language constructs by hand which would be amusing.
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
Quote from: AJA on Wed 26/12/2012 15:20:562. Reload interaction scripts. While the game is running. Seriously, what a time saver. Found a typo? A character walked to the wrong spot? Fix it in the script, press a button to reload it, and test again.
Since AGScript is compiled and not interpreted, this is a by-design "con" of the language. However, C++ stands as a strong proof that compiled languages are still viable. Offering interpreted alternatives such as Lua should be a goal that is kept in mind by those updating the engine, but should not be included in the engine itself. Alternate languages should be provided via plugins, as extensions to AGS.
No one is arguing that compiled languages are not "still viable" for a lot of things. But they are not (or less) suitable for game scripting. There is a reason that a huge majority of games use interpreted languages for their content and it's exactly the reason AJA mentioned. It is invaluable, especially when making someting like an adventure game which is mostly scripted content as opposed to engine stuff.
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
Quote from: AJA on Wed 26/12/2012 15:20:564. Return self and being able to chain method calls. Here's an example of what my interaction scripts are full of. The methods seductive/concerned would change the character's facial expression accordingly.
cDude:seductive()
:say( "What's up, love?" )
:say( "How about we go for a walk?" )
:concerned()
:say( "Do you think I'm asking too many questions?" )
Personally I feel that chaining unrelated function calls is simply bad practice. You're doing this solely for the purpose of avoiding having to reference the object again. It's ultimately a matter of preference I suppose (for languages that support it), but it could lead to confusion or error-prone code. For example, what if I have a function that just happens to return a Character*, but uses null for an error case? If you've used it in your chain without knowing about the error case then you could have some difficulty debugging the code.
Well the point is that in Lua this is *possible*, not mandatory. In AGS you can't reference function returns as objects in an immediate fashion. (prove me i'm wrong with incredibly complex #defines or accessor functions or something as is expected)
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
I'm really not trying to oppose Lua as an alternative to AGScript, but I am trying to debunk this idea that AGScript needs to be replaced. Just because there are a few things that need to be added doesn't mean that AGScript is suddenly obsolete and should be deprecated entirely.
Although this was never my argument, I do think that AGS Script should be replaced. Not necessarily by Lua (although Lua is an excellent choice) but I think the strongest reason to keep AGSScript is that "everyone knows it". Which I don't think is a good reason. It could be replaced with Angel Script which is functionally equivilent to AGS Script in most ways but has many more features and has good support upstream.
I have to say, I am disappointed to see this thread is turning towards "improve AGSScript VS replace with Lua".
That's an interesting topic on its own, but it belongs to engine development.
If I remember correctly, the point of this thread was that in current state Lua may be better than AGSScript.
So far my impression was that it is easier to write advanced stuff. Maybe because you don't have to keep various AGSScript restrictions in mind (that thing sometimes have a psychological impact). But having much experience with coding, I am using it rather intuitively.
I am yet unsure how easier that would be for beginners to learn it. I think only people can tell.
Quote from: monkey_05_06 on Thu 27/12/2012 21:15:34
compile-time errors (the latter being something that Lua, as an interpreted language "can't do").
This actually isn't quite right, Lua is not interpreted but compiled to a virtual machine bytecode, so any genuine syntax errors (as opposed to typos creating unintended new variables)
can be caught and cause an error at compile-time.
Reading this thread, I think CW is correct that the question of what's better is unnecessary. It seems that Lua has advantages for some complex scenarios and AGS Script has advantages for those who would like to keep it simple.
I seem to recall this discussion already took place in another thread and one option was decoupling the language from the editor, making Lua an option, but retaining AGS Script capabilities. Was this approach discussed and abandoned or simply ignored?
Quote from: SpeechCenter on Sat 29/12/2012 17:27:39
Reading this thread, I think CW is correct that the question of what's better is unnecessary.
That's not really what I meant, but okay. :)
Quote from: SpeechCenter on Sat 29/12/2012 17:27:39
I seem to recall this discussion already took place in another thread and one option was decoupling the language from the editor, making Lua an option, but retaining AGS Script capabilities. Was this approach discussed and abandoned or simply ignored?
I am afraid that many discussions about improving AGS end in nothing because no one starts working on them. At least that's how it seems.
Since I am acquainted with the engine more than with editor, and also was working with script interpreter for a while now, I can mention that, in my opinion, it is pretty possible to make abstract "script runner" interface, and hide script interpreters behind one. By doing so we will allow to either put more than one implementation into engine, or implement interpreters (AGSScript too) as more specialized plugins.
Quote from: SpeechCenter on Sat 29/12/2012 17:27:39
It seems that Lua has advantages for some complex scenarios and AGS Script has advantages for those who would like to keep it simple.
In my opinion, this statement is completely wrong.
AGS Script is as "simple" as a TV with only a knob for controlling channels. Having to get up to turn the dial instead of what is normally efficient and easy by just using the TV remote. I found with AGS Script I had to wrap myself around a telephone pole 6 times before I could do something beyond its scope.
As Calin said, AngelScript or something similar to C (or Java - Monkey loves Java!), has nearly the exact same syntax as you're familiar with in AGS Script. It just has more capabilities. This is why I'm so confused why someone as intelligent as Monkey keeps saying all we need is AGS Script, because he enjoys 20 workarounds to do something ordinarily simple. :-\
Quote from: Crimson Wizard on Fri 28/12/2012 08:58:57
I am yet unsure how easier that would be for beginners to learn it. I think only people can tell.
Not at all being qualified to weigh in on any of the other stuff, but I don't think that THAT specific scenario is really the problem at all. If someone who knew nothing about either AGSscript OR Lua approached making a game in AGS, I'm not sure learning either language would be more difficult than learning the other.
Again, I don't know about the other problems, or the technical issues in either Lua or AGSscript so I am not qualified to speak on those, but it is true, even with me being knowledgeable about programming languages in general and how syntax would usually work in most languages, sheer laziness would definitely be a major factor in me continuing to use the usual AGSscript, as opposed to downloading the Lua plugin and using Lua to code in AGS (even though I should probably learn Lua at some point :D, seeing how widely used it is in the game industry especially).
I think the *best* way forward would be a language agnostic system with several different bindings for different languages.
However, my original argument was simply that right now it's silly to use AGS Script when Lua is available.
To me, the biggest argument in favor of dropping the AGS language is that its grammar has loopholes; and the object-oriented inheritance system's implementation is half-baked. I'm ok with any syntax as long as that syntax has been proven consistent by armies of languages specialists -- instead of invented along the way (no offense to CJ -- as it's been said before, he used the appropriate technology level at all times, and provided amazing tools on his own).
I support the idea of moving to a "language-agnostic system with several different bindings for different languages" (these are Calin's words).
For the time-being and a smooth transition, would it be possible to provide both in the template? Why not offer the choice of mixing the languages, using tags in the code? (just a silly idea).
The very least would be that, at first, the Lua version looks exactly the same as the AGS one in its structure (execute_always, etc.) and function names. This would be an incentive to migrate to it.
Quote from: Calin Leafshade on Sat 29/12/2012 19:45:43
However, my original argument was simply that right now it's silly to use AGS Script when Lua is available.
I can see two arguments:
- More AGS developers know it so there would be more options to recruit a person to a game.
- As far as I know there are some editor functions that would not work with the current plugin, such as creating a translation file. This means that the specific plugin would have to produce all those functions on its own.
I'm not arguing against Lua, just that there may be cases where AGS Script makes sense in the current state.
Moving over to Lua would be a good move for the future development and propagation of the engine and the community. Lua is a de facto standard in the games industry and lots of people program in it outside of that. It's meant to be one of the easiest languages to learn. Already, now that I've learned that AGS uses Lua, I'll be more likely to think about doing some serious development in AGS rather than looking at something else like Unity (at least to start with).
It's worth thinking about what will benefit the community and development of AGS long-term. It's open source now - you want to think about pushing the Lua side so that more people will get involved.
For me (new to AGS) it is not clear in what direction AGS is heading to:
- 2D retro (fan) games with easy to use development tools
- "state of the art" adventure games playable on multiple platforms with the option of using 3D characters or even environments (probably steep learning curve)
The first group (artists) probably isn't interested in learning how to handle exceptions and all the stuff a full featured programming language comes with. My guess is they will be fine with the current language. The second group is probably afraid of having to switch to another tool and drop AGS in order to get their (commercial) adventure games running in less time/for less money, etc. Lua also seems to be a kind of standart in game programming. So probably developers having used other tools with Lua support would have an easier start / be easier to find.
So the actual question to be answered is in what direction is AGS supposed to go? 8-)
Marcus
I actually think the strength of AGS is that it's capable of both.
AGS is remarkably good at just being an adventure game engine with a very low barrier to entry but it's also remarkably good at being extensible. Or rather it *could* be in my opinion.
AGS can do some very nice things such as those seen in games like Resonance but it's also effective at recreating, faithfully a more classic style of adventure like the BJ series.
Quote from: Milhouse on Sun 30/12/2012 13:16:25
The first group (artists) probably isn't interested in learning how to handle exceptions and all the stuff a full featured programming language comes with. My guess is they will be fine with the current language.
Well, Lua's exception handling is actually pretty weak. It doesn't have native
try/
catch blocks like most other exception-supporting languages. Instead you use a special function called
pcall to call a function instead of running it normally - pcall(myFunction, parameter1, parameter2) instead of myFunction(parameter1, parameter2) - and what you get back if there is an error is just an error message string, not a full object with additional information. (Actually, if you throw your own errors using the
error() function, you can use any value, it's the built-in errors are all only strings.)
Also, in some ways Lua is
less of a "programmer's language" than AGS-Script. Lacking "mutation" statements like
a++ and
a += 2 has already been mentioned. Lua also does not have binary operator support, although this is possible through an extension module (http://bitop.luajit.org/) (that I should probably get built in to the plugin), but then it is functions rather than operators - e.g.
bit.bor(a, b) instead of
(a | b),
bit.band(c, d) instead of
(c & d) and so on. (Lua 5.2 does have its own version of this module built-in, but for various reasons I intend to stick to version 5.1 for the plugin for now.)
Also, like JavaScript, Lua only has one kind of number (double-precision floating point). The way these bit operations work is all arguments are converted to 32-bit ints, the operation is done, and the result is converted back to a double. (Again, the same is true in JavaScript.) So if you want to do something that really relies on using true 8-bit/16-bit integer values like
char and
short, you will find this a lot easier to do in AGS-Script than Lua.
Lack of bitwise functions is actually a serious problem when dealing with ags colours and stuff. I was going to mention that in the lua plugin thread.
The things that Lua has and AGS doesn't have (and haven't been mentionned yet) are :
- A consistent syntax
- No need to map the darn AGS objects/variables to your wrapper every time you create one (IMO that's the main reason why plugins have limited features: because the guys who make them doen't go through the effort of mapping the hundreds of available functions of the underlying library to AGS). For example, the Direct3D plugin is fine, but the guy didn't implement everything into AGS. And I'm sure there is already a complete Lua/Direct3D wrapper somewhere out there.
- Libraries for data storage (arrays, trees, hashmaps, etc.). This is a BIG BIG issue in AGS at the moment. Every time you want to program a puzzle of some sort: "oh no, I'll have to code a search function yet again". Existing modules in AGS help, but overall it's still a real pain in the neck.
Calin - It's not going to fast, definitely not something you want to be using a lot every frame, but there is a pure-Lua module for bitops you could use for now: http://files.luaforge.net/releases/bit/bit/luabitv0.4 (http://files.luaforge.net/releases/bit/bit/luabitv0.4)
Quote from: Denzil Quixode on Sun 30/12/2012 15:01:27
Calin - It's not going to fast, definitely not something you want to be using a lot every frame, but there is a pure-Lua module for bitops you could use for now: http://files.luaforge.net/releases/bit/bit/luabitv0.4 (http://files.luaforge.net/releases/bit/bit/luabitv0.4)
Then it might be a good idea to expose some functions to us in the API to get colours from AGS colours since thats the only reason we'd need bitwise functions anyway probably.
I've been thinking about making the Lua plugin even more powerful by allowing for scripts that get run in the editor, rather than in-game. I was going to post about it here but I think the plugin thread might be a better place.
You're all right actually. I was just resisting change. AGScript should never be used by anyone. It's practically worthless. You can't do anything with it. It has no features. It doesn't even remotely resemble a scripting language. Chris Jones is borderline mentally challenged for putting as much effort into creating AGScript as he did. In fact, AGS should basically just be rewritten from scratch. None of the program is usable in any fashion whatsoever. You guys have truly opened my eyes. I think we should write AGS v4 in Lua with a new engine and editor, and only allow Lua scripts to be used. All praise Lua forever.
I really hoped I never would have to say something harsh like this, but
Quote from: monkey_05_06 on Sun 30/12/2012 20:16:36Chris Jones is borderline mentally challenged for putting as much effort into creating AGScript as he did.
You do realize that people make mistakes that become visible only after number of years?
You do realize that something that was enough 15 years ago, may become not enough after 15 years?
You do realize that although the person's experience and skill grow over time, and he sees his past mistakes, he sometimes cannot change anything, because he does not have enough free time to do that properly?
You do realize that sometimes even program author decides to rewrite his past creation from scratch - exactly because he became more experienced and sees his mistakes? Did not Chris Jones himself remade AGS Editor from scratch? Was it because previous AGS 2.* editor was completely worthless?
For how many times I read the code I wrote like 5 years ago and wanted to make a "facepalm"... Did not that ever happened to you?
Haven't Chris Jones himself told that, quote:
Quote from: Pumaman on Wed 27/04/2011 01:55:57
DO NOT use this source code as a learning resource or a guide on best practice.
The state of the source code is VERY BAD and should in fact be considered an example of BAD PRACTICE.
Unlike the AGS Editor code which is relatively modern and a generally good standard, the engine code dates back 12 years to 1999, and has a severe case of the another-bit-being-bolted-onto-the-side disease. It also retains compatibility with old versions which means that some of the old and particularly dire code paths cannot yet be removed.
So just to be clear, YES I KNOW that the code is in a bad state. You don't need to tell me that.
Why do you have such a zeal to protect Chris Jones from something that is not even an attack on him?
Quote from: Calin Leafshade on Sun 30/12/2012 15:13:13
Then it might be a good idea to expose some functions to us in the API to get colours from AGS colours since thats the only reason we'd need bitwise functions anyway probably.
Oh, like the Colour Finder you mean? I do have a function for that:
local floor = math.floor
local low32 = {
[-1] = 0x000000; -- COLOR_TRANSPARENT
[ 0] = 0x000000; [ 1] = 0x0000A5; [ 2] = 0x00A500; [ 3] = 0x00A5A5;
[ 4] = 0xA50000; [ 5] = 0xA500A5; [ 6] = 0xA5A500; [ 7] = 0xA5A5A5;
[ 8] = 0x525252; [ 9] = 0x5252FF; [10] = 0x52FF52; [11] = 0x52FFFF;
[12] = 0xFF5252; [13] = 0xFF52FF; [14] = 0xFFFF52; [15] = 0xFFFFFF;
[16] = 0x000000; [17] = 0x101010; [18] = 0x212121; [19] = 0x313131;
[20] = 0x424242; [21] = 0x525252; [22] = 0x636363; [23] = 0x737373;
[24] = 0x848484; [25] = 0x949494; [26] = 0xA5A5A5; [27] = 0xB5B5B5;
[28] = 0xC6C6C6; [29] = 0xD6D6D6; [30] = 0xE7E7E7; [31] = 0xF7F7F7;
}
function getRGB(agsColor)
if agsColor < 32 then
local rgb = low32[agsColor] or 0x000000
return floor(rgb / 0x10000) % 0x100,
floor(rgb / 0x100) % 0x100,
rgb % 0x100
end
return (floor(agsColor / 0x800) % 0x20) * 8,
(floor(agsColor / 0x20) % 0x40) * 4,
( agsColor % 0x20) * 8
end...to be used like this:
local r, g, b = getRGB(65535)
I guess we need more practical examples like this, because I'm starting to like the idea. I'm quite fond of AGSScript but of course miss the stuff it doesn't support (yet).
Say I want to use lua tables to store all my tile info for an RPG.
What do I do to draw on a room background? Do I still use AGS's raw drawing?
(Apologies in advance if this is plainly obvious in the plugin's documentation, I haven't looked at it yet.)
Quote from: Khris on Sun 30/12/2012 21:32:14
Say I want to use lua tables to store all my tile info for an RPG.
What do I do to draw on a room background? Do I still use AGS's raw drawing?
Yes, you'd still use the same functions essentially, just with (slightly) different syntax. Here is a Lua equivalent for the manual's example (http://www.adventuregamestudio.co.uk/manual/Room.GetDrawingSurfaceForBackground.htm) for Room.GetDrawingSurfaceForBackground():
local surface = ags.Room.GetDrawingSurfaceForBackground()
surface.DrawingColor = 14
surface:DrawLine(0, 0, 50, 50)
surface:Release()It should seem pretty familiar... the tricky one is that method calls on the
surface object must use a colon ':' rather than a dot '.' before the method name, while property accesses still use the dot, and so do static function calls on the
Room type.
Quote from: Crimson Wizard on Sun 30/12/2012 20:52:19Why do you have such a zeal to protect Chris Jones from something that is not even an attack on him?
Lol, no. I'm
agreeing with you. We're better off without Chris Jones.
Finally we can take the
extremely easy step of replacing AGScript with the glory and power that is Lua. Only by doing this can AGS move forward. I agree. Good job. Sorry it took me so long to see the light guys. :)
@Khris re: RPG
Take a look at my very unfinished RPG engine made entirely in Lua (with a little AGS Script support).
https://dl.dropbox.com/u/27247158/NightThorn.zip (source)
It still contains a lot of AGS script but i've converted a lot of it to Lua and just havent removed the original ags script version.
Features include loading maps (it all takes place in a single room) and a rudimentary inventory (press esc)
(Also, monkey stop being a cock)
(Second also, I love syntax like this:
local r, g, b = getRGB(65535)
Multiple returns from a function is cool as shit)
Quote from: Calin Leafshade on Sun 30/12/2012 22:13:03
(Second also, I love syntax like this:
local r, g, b = getRGB(65535)
And I don't :/. That looks like defining two variables with undefined value and initialize one variable with function's return value.
Quote from: monkey_05_06 on Sun 30/12/2012 21:59:50
Quote from: Crimson Wizard on Sun 30/12/2012 20:52:19Why do you have such a zeal to protect Chris Jones from something that is not even an attack on him?
Lol, no. I'm agreeing with you. We're better off without Chris Jones. Finally we can take the extremely easy step of replacing AGScript with the glory and power that is Lua. Only by doing this can AGS move forward. I agree. Good job. Sorry it took me so long to see the light guys. :)
...
Now I feel extremely stupid and embarassed for replying first time.
Quote from: Crimson Wizard on Sun 30/12/2012 22:20:12Quote from: Calin Leafshade on Sun 30/12/2012 22:13:03(Second also, I love syntax like this:local r, g, b = getRGB(65535)
And I don't :/. That looks like defining two variables with undefined value and initialize one variable with function's return value.
If it disturbs you too much, you can always stick 'em in a table :)
local rgb = {getRGB(65535)}
local r = rgb[1]
local g = rgb[2]
local b = rgb[3]I know they're unusual, I think Google's "Go" is the only other language I remember seeing with multiple return values. There's some interesting things you can do with them. You can use multiple return values as multiple arguments to another function, for example:
ags.SetFadeColor(getRGB(40892)) -- a nice eggshell blue...The standard Lua function
assert() takes two arguments. If the first argument is
false or
nil, it throws an error, using the second argument as the error message. Otherwise, it returns the first argument unchanged. For example, if you want to get the current active inventory item and throw an error if there isn't one, you could do this:
local activeinv = assert(ags.player.ActiveInventory, "there is NO active inventory item!!")
-- ...do something with activeinv...In combination with multiple return values from functions, this can be a useful coding-pattern. For example, if you try opening a file to read but the file doesn't exist,
io.open() will return
nil instead of a file object:
local f = io.open('i_dont_exist.txt', 'rb')
if f == nil then
print('unable to open the file!')
else
-- ...do something with f...
end...except it doesn't just return
nil - it also returns a "file not found"-like error message string, as the second return value. You don't notice here because it just gets discarded. So, if you want to throw an error if the file cannot be opened, rather than handling it yourself:
local f = assert( io.open('i_dont_exist.txt', 'rb') ) -- /!\ ERROR: i_dont_exist.txt: No such file or directory
-- ... do something with fIn this way, when you write a function you are not forced to choose between throwing an error if it is unable to get a valid result (which can be annoying if it's not a fatal problem), or just returning
nil (which is "friendlier", but sometimes it
is a fatal problem to your code, and it's helpful to have a handy error message around - especially if there's several different things that could have gone wrong).
Quote from: Denzil Quixode on Sun 30/12/2012 23:05:55
I know they're unusual, I think Google's "Go" is the only other language I remember seeing with multiple return values.
There are others, say Matlab (which I don't like the language)
[r g b] = getRGB(40892);However, as you mentioned, the multiple return values problem is that it's easy to discard them, Matlab suffers from the same problem
c = getRGB(40892);would work and c will have only the first return value.
Other languages cope with it by returning a tuple, like Scala
def addAndSub(a:Int, b:Int) = { (a+b, a-b) }
val (sum, diff) = addAndSub(2, 3)
val bothValues = addAndSub(2, 3)
Here you can either assign them individually or assign a tuple to bothValues so nothing gets discarded silently.
Quote from: Denzil Quixode on Sun 30/12/2012 23:05:55
local f = assert( io.open('i_dont_exist.txt', 'rb') ) -- /!\ ERROR: i_dont_exist.txt: No such file or directory
-- ... do something with f
This is considered very bad coding in any language that has a notion of debug and release compile as usually the whole assert statement is not compiled into anything in release (it's true that it doesn't usually return value, but this difference is easy to forget). It's a source of very nasty bugs in those environments. Solutions like Scala's Option can help cope with null return values or simply, use exceptions.
Given that Lua is a very flexible language, it would require using some kind of style guide, otherwise the resulting code can become a horror to maintain.
Quote from: SpeechCenter on Mon 31/12/2012 07:07:14
Quote from: Denzil Quixode on Sun 30/12/2012 23:05:55
local f = assert( io.open('i_dont_exist.txt', 'rb') ) -- /!\ ERROR: i_dont_exist.txt: No such file or directory
-- ... do something with f
This is considered very bad coding in any language that has a notion of debug and release compile as usually the whole assert statement is not compiled into anything in release (it's true that it doesn't usually return value, but this difference is easy to forget). It's a source of very nasty bugs in those environments. Solutions like Scala's Option can help cope with null return values or simply, use exceptions.
I don't see it as a problem because assert will throw an exception on failure. It's similar to a try/catch block except the catch is always the calling function.
Quote from: Calin Leafshade on Sun 30/12/2012 22:13:03Take a look at my very unfinished RPG engine made entirely in Lua (with a little AGS Script support).
I did and I like!
So the two LuaControl scripts are used to keep the usual AGS events and would pretty much be essential for anybody willing to switch, right?
When I tried to compile the game, the "official" plugin couldn't deal with the Lua.Scripts/ScriptCount functions; I guess you added those to the plugin yourself?
(I called the scripts manually and it compiled fine.)
I'm still wondering though whether it's actually reasonable to use AGS and 99% Lua. It seems like you'd either use another engine entirely or stick to AGS/AGSScript and only use Lua when necessary, depending on whether you're creating mostly a classical adventure game or not. Does AGS's engine part warrant building a Lua game...?
And let's not forget that the current editor for the lua scripts is nothing more than a colorful Notepad. There's no jumping to functions, no auto-completion, no code folding.
Quote from: Khris on Mon 31/12/2012 12:42:34
Quote from: Calin Leafshade on Sun 30/12/2012 22:13:03Take a look at my very unfinished RPG engine made entirely in Lua (with a little AGS Script support).
I did and I like!
So the two LuaControl scripts are used to keep the usual AGS events and would pretty much be essential for anybody willing to switch, right?
When I tried to compile the game, the "official" plugin couldn't deal with the Lua.Scripts/ScriptCount functions; I guess you added those to the plugin yourself?
(I called the scripts manually and it compiled fine.)
Yes, those extra script function Denzil added specially for me on request. And yes, those scripts are basically my interop between ags and lua. I think it's pretty unintrusive and neat tho.
Quote from: Khris on Mon 31/12/2012 12:42:34
I'm still wondering though whether it's actually reasonable to use AGS and 99% Lua. It seems like you'd either use another engine entirely or stick to AGS/AGSScript and only use Lua when necessary, depending on whether you're creating mostly a classical adventure game or not. Does AGS's engine part warrant building a Lua game...?
I use AGS for a couple of reasons. Firstly I understand the systems and it's a very stable platform. Secondly, I can save the whole state of the game with a single function call. That should not be underestimated as a time saver. And thirdly AGS encapsulates animations and stuff very nicely. I think AGS still has a role but that using Lua to script it is a wholly better idea.
Quote from: Khris on Mon 31/12/2012 12:42:34
And let's not forget that the current editor for the lua scripts is nothing more than a colorful Notepad. There's no jumping to functions, no auto-completion, no code folding.
I don't use the AGS editor for the lua scripts. I edit them in notepad++. The plugin is clever enough to see changes and grab the latest versions. There are Lua editors with full support for lua with syntax highlighting and function completion and stuff.. You aren;t limited to using the ags editor.
True, savegames are a good argument.
I use notepad++ myself and it's good to know that you don't have to copy-paste stuff to and fro.
QuoteI think the *best* way forward would be a language agnostic system with several different bindings for different languages.
This! :)
Leave AGS Script, but add the ability to use LUA Script as well and the user can then choose which language to develop in. Might make it easier to support backwards compatibility as well.
Quote from: Khris on Mon 31/12/2012 12:42:34Does AGS's engine part warrant building a Lua game...?
Lol stawp trolling.
Let me clarify, in case anybody else too didn't get the point I was trying to make (and could have worded a bit more elaborately).
If I want to build a game, and that game's going to benefit greatly from the stuff Lua can do that AGSScript doesn't support (well) because the game is far removed from a classical adventure with rooms and characters' walk cycles and the like, do I really still need/want the AGS engine as base? Say I want to make an Angry Birds clone or something of the sort; shouldn't I use something else for the backend, for instance something with built-in cross-platform support?
I'm saying that at the point where I'm writing huge parts of the actual game engine in Lua, isn't this a job for something other than AGS?
(And wasn't this more or less the original topic of this thread anyway?)
Quote from: KhrisIf I want to build a game, and that game's going to benefit greatly from the stuff Lua can do that AGSScript doesn't support (well) because the game is far removed from a classical adventure with rooms and characters' walk cycles and the like (...)
Well, back when I originally made the plugin I did intend for it to be used for adventure games. (I don't think I even had RPGs in mind, I'm not much of an RPG guy myself.) What I really hoped for is that it would be helpful to someone who wants to make an adventure game that pushes the bounds of what an adventure can be, without losing its identity
as an adventure game. I would love to help people do ambitious, experimental,
new things in their adventure games -- ideally, things that would be as new to us today as the interface in
Loom or the Virtual Theatre system in
Lure of the Temptress were, 20-odd years ago.
That's the dream, anyway. So it depends what you mean by making a "classical adventure"-like game: whether you only mean going with specific conventions and mechanics originally established by those games, or whether there is also room for trying to continue in the spirit of inventiveness, experimentation and upheaval that a lot of those games actually had at the time they came out.
I think, if you will be writing your own "co-engine" (in Lua, or AGSScript, or C++ - as AGS plugin) using AGS as a backbone for animations and similar stuff, then sooner or later you'll cross a line, beyond which the percent of used internal AGS features will be smaller than percent of unused AGS features. So the real question would be, what's more important for you: to have a clean engine optimized for your game genre, or to save your time (or be lazy ;)) and just use what you already have.
Another thing is Editor, ofcourse. Writing tools/compilers take time; and some people may consider that most boring part in game development.
I think AGS is a fantastic platform to make games in and Lua just enhances that.
I also think that Lua can help make advanced things even within adventure games. Take a look at the kinds of things Barely Floating did and how short a period they managed to do it in.
Barely Floating *felt* different. It didn't feel like an AGS game it just felt like an adventure game.
Quote from: Denzil Quixode on Tue 01/01/2013 15:56:44
What I really hoped for is that it would be helpful to someone who wants to make an adventure game that pushes the bounds of what an adventure can be, without losing its identity as an adventure game. I would love to help people do ambitious, experimental, new things in their adventure games -- ideally, things that would be as new to us today as the interface in Loom or the Virtual Theatre system in Lure of the Temptress were, 20-odd years ago.
This is probably off-topic, but I think the reason AGS games - and adventure games - work is that we've found a formula that doesn't age that badly. It's simply a concept that works, and that's why most people prefer to stick to it, instead of trying to modernize the genre. After all, even if we do make the games much more advanced, featuring all sorts of advanced scripting and hi-tech GUIs, we only end up with games that look like they are 10 years old instead of 20. It's not like we're ever going to cater to new audiences.
I'm a huge Lure of the Temptress fan, but ojectively I can tell that it sucked. And it sucked mostly because of the virtual theatre thing, which was just clumsy and unnecessary. I'd much prefer if the characters simply were positioned here and there, maybe with an idle animation or two, like in traditional adventure games, instead of restlessly and aimlessly wandering around in fixed patterns, bumping in to me all the time and causing frustration.
When I'm making my game, I'm reluctant to trying out new languages or engines not because I learn code slowly (although I do) but simply because there's nothing I would like my game to do that can't be done with AGS, and I think most people feel the same.
Quote from: Andail on Tue 01/01/2013 23:38:41
When I'm making my game, I'm reluctant to trying out new languages or engines not because I learn code slowly (although I do) but simply because there's nothing I would like my game to do that can't be done with AGS, and I think most people feel the same.
Just to be 100% objective: AGS can't do Telltale-like games, like Sam&Max. Or 2.5D games, like the original Alone in the Dark. Well, it can, but it would require A LOT of work. Plugins exist, but as soon as they're released, they get obsolete, because they're often unfinished or badly documented or the technology has already moved forward.
But with Lua, the binding with DirectX and such would be much simpler, not only for the rendering part but also for all the stupid 2.5D calculations (for example, when the player clicks on an object in a 3D scene). All the libraries are out there somewhere.
There is a serious problem with Lua C modules (like a DirectX binding) in AGS, unfortunately. There is no reasonable way for the plugin's Lua state serialization system to know how to save an external C function. All the standard built-in C modules ('math', 'string' etc.) are carefully processed when the game starts up, but once you load your own one the next time the game tries to save it is likely to not be able to. There are ways to get around this (like removing the loaded module when you save the game and restoring it after you load), and hopefully in the future features could be added to make it easier to deal with, but I think it is impossible to ever make it completely seamless.
So if I wanted to start using AGS this year (probably within the next couple of months or so), would I be okay using it as an opportunity to learn Lua and dispense with learning AGS Script? Or are there things that can't be done in Lua that can in AGS Script, and are there still tutorials for Lua in AGS?
To be honest, the way things are now, it is likely to be confusing to jump straight to Lua. The plugin does not completely replace AGS-Script. Instead, it adds special functions to AGS-Script's standard set of functions, and these functions can run Lua scripts and call Lua functions, etc. So it's still AGS-Script running the show, handling game-events and so on, but it can choose to pass control over to Lua.
For example, in AGS-Script, if you want to do something whenever a mouse button is clicked, you would add an
on_mouse_click() handler in AGS-Script:
function on_mouse_click(int button)
{
Display("You clicked mouse button %d at co-ordinates (%d,%d)", button, mouse.x, mouse.y);
}...and that's it, that's all you need to do.
But to do the same thing with Lua, you could first create a Lua script - let's call it
mousehandler.lua - that defines the function:
-- mousehandler.lua
function on_mouse_click(button)
ags.Display("You clicked mouse button %d at co-ordinates (%d,%d)", button, ags.mouse.x, ags.mouse.y)
end...and then you also need to set up AGS-Script to run
mousehandler.lua when the game starts up, and then call the function when it should be called:
function game_start()
{
Lua.RunScript("mousehandler.lua");
}
function on_mouse_click(int button)
{
Lua.Call("on_mouse_click", Lua.IntValue(button));
}Quoteare there things that can't be done in Lua that can in AGS Script
Well, you can only call standard built-in AGS functions, so you can't use any other plugins from Lua, and you can't directly use AGS-Script modules (you'd have to convert them to Lua). You also can't do bitwise operations very easily at the moment (but if you don't happen to already know what those are, it probably isn't going to be something you need).
My brain just melted. I'll stick with AGS Script in the first instance then....
Just thought it'd be a good way to help me learn Lua. I'll go back to my plan for Space Invaders in Love2D!