Improving The AGS Scripting Language

[RickJ]

The big advantage I see with AGS is that it's relatively easy for someone with little programming experience to create a game. I think the goal should be to make it easier for those people, not add more complex language structures or more languages (unless they are necessary or cause things to be obscure today).

The ironic perversion is that lack of support for function and structure pointers and many of the other language features conspire to make things more difficult for inexperienced programmers.  For example, would make it possible for a predefined module to call later/user defined functions, for predefined modules to be dynamically/programtically bound to gui controls, to have call back functions, to create event handling modules, as well as jump tables and other higher level, easier scripting gadgets as Crimson describes.   The kinds of things we are talking about here would allow more functionality to be encapsulated into predefined modules that hide the underlying complexity from the module user. 

[SpeechCenter]

The big advantage I see with AGS is that it's relatively easy for someone with little programming experience to create a game. I think the goal should be to make it easier for those people, not add more complex language structures or more languages (unless they are necessary or cause things to be obscure today).

The ironic perversion is that lack of support for function and structure pointers and many of the other language features conspire to make things more difficult for inexperienced programmers.  For example, would make it possible for a predefined module to call later/user defined functions, for predefined modules to be dynamically/programtically bound to gui controls, to have call back functions, to create event handling modules, as well as jump tables and other higher level, easier scripting gadgets as Crimson describes.   The kinds of things we are talking about here would allow more functionality to be encapsulated into predefined modules that hide the underlying complexity from the module user. 

Ok, if the main users of these language features are module developers then this makes a lot of sense. Thanks for clarifying.

[Monsieur OUXX]

ArrayList.

I think the goal should be to create an environment in which you can effectively code your own array list rather than just exposing one from the layer below.

Calin, you're right, but until this miracle happens, a set of Array* HashMap* Tree* objects would be great. I'm currently working on a Visual Studio integration that will automate the creation of AGS C++ Engine plugins. Once I'm done, I'll start to (and encourage others to) massively produce engine plugins -- and even turn existing modules into plugins--, for out-of-the-box performance gains, and for convenience. My dream is to encapsulate many of the utility classes of boost into Engine plugins. Then again, all of that being a temporary workaround until the scripting langage frees itself from its current constraints.
I've come to the point where the mere idea of coding (again) a search function in a stupid one-dimensional array makes me sick.

[tzachs]

A bit late to the party..
I totally support moving to a fully featured language. The fact that Unity games are written with C#/JS is one of their biggest sell points.
Assuming we're sticking to AGS script, I support Calin's idea of seperating class with struct and removing the pointer syntax, and obviously that passing struct/class as a parameter is a must.

Other than that, I think we also need:
* Delegates (function pointers)
* Nested structs/classes
* Events - not just from the designer, but being able to define custom events and having multiple subscribers. And also the ability to subscribe to the designer events from the code, so that you can select in which script file you want the event and avoid the massive global script.
* Inheritance/Interfaces, and also changing the AGS objects to inherit from base objects/interfaces (Character, Object, Hotspot and GUI should all be "Moveables"- this can make the Tween Module be a lot shorter and easy for maintenance, for example)
* Creating objects at run-time
* Generics (Templates)
* Removing the constraint of scripts and functions ordering.

[monkey0506]

AGScript does have its shortcomings, but replacing it with a mainstream language with custom commands could very potentially increase the learning curve for newcomers. I think we should consider an integrated interface in addition to switching out the language, if at all.

But, does AGS even need that? I agree with most of what Calin and tzachs have said, but it shouldn't come as a burden to those who aren't programming saavy. I'd actually advocate doing something like what SupSuper began, but unfortunately never completed, to give a way to design the game without having to actually edit the scripts directly.

They are there, which is great for users like myself, but pulling things a step back for others would be beneficial too IMO.

[Calin Leafshade]

it occurs to me now actually that we dont really need a new construct for managed structs since there is already a construct for just that purpose. Namely "managed struct". If we could simply make the managed keyword mean something and implement the new keyword to instantiate them we dont need to invent anything new.

EDIT: Oh, also, we should definitely stick with AGS Script in my opinion since everyone knows it and changing it seems somewhat counter productive.

[monkey0506]

Simple polymorphic classes are also possible in AGS, it's just casting between them and lack of user type pointers that make it limited in usefulness.

Also, I'll assume that anyone who knows anything about AGScript already knew this, so I'm stating this redundantly.

[Snarky]

EDIT: Oh, also, we should definitely stick with AGS Script in my opinion since everyone knows it and changing it seems somewhat counter productive.

I don't necessarily disagree that we should stick with it (there are more important issues to deal with), but "everyone knows it" is just selection bias. Everyone knows it around here because this is the AGS Forums, and people who want to code AGS games have to learn it. And still we frequently get questions about various "features" of AGS Script, like just today about the old "dialogues will not be run until after the end of the script call" pitfall.

One potential benefit of using a scripting language, that we're not getting with AGS Script, is not having to recompile the source each time you make an edit. With another scripting language it might even be possible to edit it live, i.e. when running a game in the debugger, being able to pause it, edit some code, and resume it with the edited version taking effect immediately. That's the sort of thing I think could really improve a game-maker's productivity.

Another drawback of having our own scripting language is that there are no standard libraries, so any time you want to implement a feature, algorithm or data structure, you have to start from scratch (unless you're lucky and someone has made a module for what you need). We shouldn't have to reimplement or port stuff like drawing Bezier curves, or 2D physics engines.

Of course if we switched to another scripting language we shouldn't pick one that is harder to learn. In fact, I would hope one of the benefits would be to simplify various things that can be tricky right now, and make an easier learning curve for beginners. For example, I'm thinking of things like having to export variables from script files, order-dependent function definition, and having dialogues scripted in their own separate script hierarchy, in separate scripting language with special commands. Plus breaking up GlobalScript so it's not one huge monolithic file, though that could probably be done while sticking with the current scripting language.

It would also be beneficial to pick one that is widely known and used. Lua seems to be a popular choice among experts/professionals, but I think it's a drawback that it's not based on C-style syntax, which I believe tends to be more familiar to casual coders. Really, if there was some standard, sane/safe subset or variation of Javascript, that might be a good choice - not too much of a departure from existing AGS Script, but more widely used, with more fully-fledged features, and without some of the more dated requirements of the AGS compiler. Maybe something like Haxe? (I don't know it, I just researched JS-like languages on Wikipedia. It's compiled, though, so you wouldn't get the scripting benefits I mentioned above.)

[RickJ]

I agree with what Snarky says about his.  His comments about JS and live editing are interesting in that google has released V8 their Chrome/JS engine as open source.  One has to wonder if the game engine couldn't just be built around V8?  And if this were the case what else would have to be in place for AGS games to run on standards compliant browsers?

The upside to using a fully developed language is that there would not be a need to add new or a need to maintain a compiler.  People and resources that would otherwise be spent on language definition and compiler maintenance would be able to spend their time on other things such as editor improvements, engine portability, plugins, etc.

The downside is of course there will be a disruption in the community.  Effort would have to be spent making libraries, translators, and/or other technological measures to maintain some degree of compatibility with the current language and/or to provide an upgrade path.

I think it would be foolish not to take a look at the possibilities and objectively weigh the pros and cons.   

[Calin Leafshade]

I think thats all great and everything but you need to remember that we have very limited resources.

I mean, look how hard it was to get *anything* done. If JJS/bero hadnt saved us we would literally be in the same place now as we were 3 years ago.

Using an old-the-shelf scripting language is, in theory, the better idea but the capital cost in terms of manpower is likely to be too high for us to bear.

Having said that, if it were a possibility I would love to have JS or Lua integrated into AGS.

[Joseph DiPerla]

it occurs to me now actually that we dont really need a new construct for managed structs since there is already a construct for just that purpose. Namely "managed struct". If we could simply make the managed keyword mean something and implement the new keyword to instantiate them we dont need to invent anything new.

EDIT: Oh, also, we should definitely stick with AGS Script in my opinion since everyone knows it and changing it seems somewhat counter productive.

I agree. AGS should stick with AGS Script. After all, we do not want this project in the end to be something other than "AGS". Also, many of us "not so code at c/c++/c#" people are used to how the scripting engine works. Stick with whats there. There is a reason why Chris used his own scripting language over LUA, AngelScript or Python which were all available at the time that he rewrote the scripting engine.

As far whats proposed with this thread, lets start with the referenced structs. This seemed to have tapored off to a whole new discussion. KISS. The script engine is in place, no need to discuss more details about it. What should be done is take each idea one at a time and start working together to implement that idea. If we can put aside what we want, and just start one at a time with the idea's, development would be more productive. So, I say, leave the script engine as is and lets figure a way to reference custom structs as Calin had mentioned when he began this thread. After thats implemented, we can move on to Dynamic Array's of pointers to custom structs and go on from there. Within a few months, AGS can have quite a nice scripting language implemented. Now, wouldn't that be nice?

EDIT: Also, think of those who are in the middle of producing a large game and would want to keep using the current version of AGS. If we alter something monumental like the scripting engine, they would have a lot of hard work ahead of them.

[Shane 'ProgZmax' Stevens]

Any one of us sufficiently familiar with designing languages and parsers could just expand the scripting language to include elements it is lacking in either partial or full implementation, like fully fledged classes, for loops (why not?), and so on.

I don't honestly see a need to drop everything and move to a new language when AGS is already sufficiently c-style, has a relatively low learning curve, and we have the access to make improvements that would bring it more up to date.

One potential benefit of using a scripting language, that we're not getting with AGS Script, is not having to recompile the source each time you make an edit. With another scripting language it might even be possible to edit it live, i.e. when running a game in the debugger, being able to pause it, edit some code, and resume it with the edited version taking effect immediately.

This is probably the most compelling argument for such a change in my mind, though I believe accomplishing something like this within the current scripting language is within the realm of possibility and *could potentially be easier than reconfiguring and adapting the editor code to work with a new language, or indeed, re-writing the editor from scratch in the new language.


*I cannot verify this but based on my work designing parsers I'd say it's true.

[Ryan Timothy B]

I don't see many differences between Java or AGS-Script. Aside from Java being much more powerful and having everything AGS should have. The only real breaking part would be Object (it wouldn't be able to use that name anymore). And the enums having to call the Enum class instead of just the enum type.  Eg: eDirection.Left

[Calin Leafshade]

There are a million differences between java and AGS Script.

Go on, dare me to name them all.

[monkey0506]

Calin, I dare you to name every one of them.

[Ryan Timothy B]

No, I'm talking about everyone complaining and saying "But we already know AGS Script". Working with Java or AGS Script would be exactly the same, assuming you built the appropriate framework to match that of what Chris has already made. Then there's the additional things Java can do, that the AGS Script lover can forget about and just do what they already know if they're too afraid of something more powerful.

[Joseph DiPerla]

The thing is, even though Java may somewhat be superior to AGS Script, AGS Script does what it needs to do. Yes, there are a few things missing, however, we do not need a full blown programming language such as Java to develop adventure games. Its nice to know the features are there. It may streamline certain other things. But, despite a few missing features, AGS Script works very well. To tell you the truth, with AGS Script, if something is missing, it can be added, which makes using AGS more satisfying. Also, the language can be customized beyond the features of what other programming or embeddable languages provide with a little work, while with AngelScript, Java, Python, etc... that would be a little harder to do.

The thing I am seeing with AGS at the moment is there are so many big changes everyone wants to make that really defeat the purpose of AGS to begin with. Some want to implement it within SCUMM, others would like to swap out Allegro with SDL. Some prefer to use different languages to program the IDE. Now we want to swap out AGS Script with something else. Whats next? What was the point in having AGS become open source if we want to make all these BIG changes? Why not just get together and create a whole new engine then? Chris released AGS so that we can CONTINUE Development, not alter and change it completely. Just my two blue cups.

[Ryan Timothy B]

See that's where things get a little blurry for me. So instead of spending a one time installation of Java and removing AGS Script (or whatever the chosen language), you'd rather spend several hours each time you want to add a new feature.
    We should have a for loop : hours later.
    We should add a public keyword instead of messing around with the terrible import/export : weeks later.
    We should add a switch, interface, const, static, abstract, final, instanceof, super, proper passing of custom objects with proper extending methods : weeks and weeks later.
    Forward and backward declaration, Polymorphism, Continue, Break, etc etc (just to name a few that AGS should have)

And that's just because we have a cute little programming language we don't want to see ruined. It's like owning a car that only drives 20km/h. I could just buy a new car for $10k that'll drive faster than I'll ever need, or I could spend many months and twice the amount of money working and replacing components in this car to make it faster - just because I thought it was a cute little car.

I don't see anything AGS does "unique" with its programming language, or even anything that is worth holding onto that makes it different from any mainstream language. Instead it actually limits the programmer and confuses the hell out of them as they monkey their way into a spaghetti code of nightmare.

[Snarky]

The thing I am seeing with AGS at the moment is there are so many big changes everyone wants to make that really defeat the purpose of AGS to begin with. Some want to implement it within SCUMM, others would like to swap out Allegro with SDL. Some prefer to use different languages to program the IDE. Now we want to swap out AGS Script with something else. Whats next? What was the point in having AGS become open source if we want to make all these BIG changes? Why not just get together and create a whole new engine then? Chris released AGS so that we can CONTINUE Development, not alter and change it completely. Just my two blue cups.

Well, it's the ship of Theseus paradox, isn't it? If, a couple of years from now, AGS has a different engine, a different editor, a different scripting language and uses different libraries and runs on other platforms, is it still AGS? I think it can be, as long as it evolves with continuity, and the changes are made in the spirit of AGS. I don't think the "purpose of AGS" is that it must run on Allegro, use a C# editor, 16-bit pointers and C-style strings internally, store projects in big binary files that can't be checked into source control, compile the game and engine together in one exe, etc. AGS is about a way of making and playing adventure games. If CJ didn't want anything to change, it didn't even have to go open source.

But like I said before, I think switching to another scripting language or redesigning AGS Script (and I tend to agree with Ryan in that if what we decide we ultimately want is something very close to an existing language, it's probably easier to just hook that into the engine than it is to recreate all the features ourselves - rather than Java I would prefer an actual scripting language, though) is one of the least urgent tasks for the project at the moment, and likely to just be a distraction from more important improvements. It's just something I think we should keep in mind as a future possibility.

[Ryan Timothy B]

rather than Java I would prefer an actual scripting language

Only reason I've been suggesting Java is that it runs on nearly every platform.

But like I said before, I think switching to another scripting language or redesigning AGS Script [..] is one of the least urgent tasks for the project at the moment, and likely to just be a distraction from more important improvements.

Sorry, I must've missed a post-it or something showing the future improvements for AGS, but what are the other more important improvements aside from the editor related changes? I personally see the editor code swap as being the most important improvement at the moment.