Topic: Improving The AGS Scripting Language

[Joseph DiPerla]

@timofonic, CW and all those who agree: +999999 I like that idea. I actually wanted that implemented, but realized that the amount of work involved for that can be a bit tricky and time consuming so I didn't suggest it. But I think that personally, this implementation can make everyone happy, keep AGS the same but make it more powerful at the same time. +999999.


EDIT: Progz, check your PM and also your PP acct so to give me an answer on whats going on please.

[Ryan Timothy]

If you're going to keep the AGS script (which I've already expressed is a terribly time consuming idea), the main goal should be to go full OO. I know, that's already the plan. But I mean especially with simple stuff like Room Elements, GuiControls, etc.

Code: Adventure Game Studio

1. gGui.lLabel.Text = "etc";

Instead of the terrible way it is now:

Code: Adventure Game Studio

1. lLabel.Text = "etc";

The way it is now, you have no idea what label belongs to what when you're reading code. You can't even right click on it, or hover over the text to find what GUI it belongs to. The best method is to just include the GUI name within the GUI controls' name.

[Joseph DiPerla]

I agree with that as well. OO could be a little improved. My question now is this, if we decided to use another scripting or embedded engine, would that break the engine's backwards compatibility? I mean, JJS ports can support games all the way to 2.5x. Will that break with a new scripting engine?

[Crimson Wizard]

My question now is this, if we decided to use another scripting or embedded engine, would that break the engine's backwards compatibility? I mean, JJS ports can support games all the way to 2.5x. Will that break with a new scripting engine?

Exactly my thoughts. If we just plain put any change, like something mentioned above by Ryan, into script system, older scripts, even 3.2 scripts, will not work.

This surely will require some workaround. The two most simple options that come to my mind are:
1) introducing some "preprocessor command", that would switch compilation to newer version, e.g.:

Code: Adventure Game Studio

1. // the script module start
2. #enable_new_compiler
3.  
4. // rest of script
5.  

2) doing the similar thing but via script properties.

[Joseph DiPerla]

I say a setting in the general properties which will allow us to choose which scripting language we would be using, eg: Legacy AGS Script 3.2 and below or New AGS Script 3.3.

[Crimson Wizard]

I say a setting in the general properties which will allow us to choose which scripting language we would be using, eg: Legacy AGS Script 3.2 and below or New AGS Script 3.3.

Unfortunately this won't always work. What if you are going to use script module written for older version of AGS?
Global setting may define default mode, but there's still should be way to set this for each separate script, I think.

[Joseph DiPerla]

I just thought of something. Generally speaking, the script OO can change without too much to affect the developer. All you would need to do to the engine is detect which version of AGS is being used and adapt the scripting language to that version so it can play the game. Isn't that what JJS ports do since they can play games up to 2.5x? I am pretty sure that AGS up to 2.6 and then 2.72 and 3.0 have completely modified scripting engines. So, its possible then to update the scripting language without breaking anything, right?

[Ryan Timothy]

Exactly my thoughts. If we just plain put any change, like something mentioned above by Ryan, into script system, older scripts, even 3.2 scripts, will not work.

Is the backwards compatibility really something that needs to be held onto when it's a change this drastic and important for AGS? I'd personally ditch it.

Then once this new scripting language is added, you can start adding backwards compatibility for any new changes. BUT if you properly plan ahead and talk things through with everyone, you ultimately shouldn't need backwards compatibility for the new versions. With proper planning we shouldn't ever have a function that becomes obsolete.

Just like I'm confused why CJ made two functions called: GetTextWidth(..)  and  GetTextHeight(..)
They should be what he mentioned:  Font.GetStringWidth(string text)  etc

There are tons of those non-OO functions we should must ultimately remove.

[JJS]

The script engine seems completely agnostic to the AGS version. Remember that the scripts are compiled into code for a virtual processor so you can add new features to the language and just output the appropriate low-level code in the compiler. Like your computer can run compiled C++ and C code because for the CPU it is just a stream of the same instructions in a different order.

Breaking backward compatibility might not sound like a big deal until you remember that it will invalidate all existing modules. What does a new game developer care more about: Fancy language features or a big library of ready-to-use code?

[Crimson Wizard]

Is the backwards compatibility really something that needs to be held onto when it's a change this drastic and important for AGS? I'd personally ditch it.

This is a question of version planning. In my opinion it all depends on what do you expect of future versions of AGS. So far I see people here wanted to have a development branch which is fully backwards-compatible with previous releases of AGS, then, after some time, cut the ties and develop something totally new. At least that is what I heard (read).

There are tons of those non-OO functions we should must ultimately remove.

What's wrong with the function if it simply exists?
It is pretty possible to hide the obsolete functions: switch them on and off depending on the compiler setting.

EDIT: Wait... I missed the word "ultimately".
Well, if we are speaking of some future version with no backwards compatibility, then it's true

[Uhfgood]

Could you maybe... implement lua or javascript while still leaving in AGS script, and when you've finished implementing said scripting language, make an interface that uses said scripting language internally while still acting like ags script... eventually you could maybe have it running off of said scripting language when no one really knew that you changed out the scripting language at all?

-Keith

ps. a switch/case command will be pretty helpful to me right about now

[Ryan Timothy]

One reason I was suggesting Java is because of the super awesome Eclipse IDE, which I'm pretty certain is open source. If it is, it would definitely make improving the AGS editor much easier. Most importantly: having real-time error checking. No idea what the conditions of its use are though.

[suicidal pencil]

I'm here just to say one thing the scripting language needs:
A ternary operator...and regular expressions =)

Keeping backwards compatibility should definitely be a goal. Invalidating all of useful modules kicking around (Pixel Perfect Collision as an example) is probably the best reason I can see for not breaking backwards compatibility. Still, what's stopping someone from just forking the project? On one side, a version of AGS that supports 2.5x which only gets updated for bug fixes, and on the other the version of AGS that we nonstop add bells and whistles to in an attempt to make it fully OO

[dbuske]

How about adapting AGS scripting like in Blocky.
It might be a good way to handle character movement.
 

[Crimson Wizard]

I have this thought about this for some time already. I can't say it's very urgent thing to consider, but we are approaching the moment when engine development branches are joined, and refactored code is pushed to master branch. Probably people would like to improve engine more intensively and add new features, including new script commands.

I strongly believe there should be some kind of group, whatever you call it (e.g. comitee), that would work on defining AGS scripting standart. I do not think that coders should do that. This has to be done by people very experienced in using AGS and developing games. These people should determine the general way the AGS should involve, scripts in particular.
While it is technically very easy to add new script commands, this should not be done without a plan in mind. Since AGS allows to write your own extension functions and script modules there must be a criteria to distinct script commands that should be incorporated into engine and which to be rather left for user modules.

[Wyz]

I guess there are two separate matters: the script language (semantics) and the script interface (objects and functions). The latter should be treated with great care as it will define the feel of AGS; something that CJ imho always has upheld. Argument order, naming conventions, use of case, coherence with documentation the list is rather long Yes a committee or maybe even a single person who guards this consistency would be needed. The less people involved the better generally. Still they should not be blind for good ideas.

About the language itself: I guess that is something for the next major version as it would be save then to break backwards compatibility.