Improving The AGS Scripting Language

[Joseph DiPerla]

I can see your point and reasoning Snarky, but then let it evolve slowly rather than replacing everything at once.

But Ryan, I also understand your reasoning, but sometimes, if you take time to develop something, it becomes something more. I think we are losing sight of the fact that AGS is not a Programming language, but rather a Game Engine. I agree there is a lot thats missing from AGS Script, but if WE work on it, it can become something more than we can immagine. How do you think some of these other projects started? LUA, AngelScript, or even others? They evolved from something Smaller into what they are now. Thats why its called HTML 5 or PHP 5 or Python 2(Or whatever version its at). It evolves. I believe that eventually, with the work the team puts into it, it can evolve into something more. Atleast then the team is at the mercy of themselves when they want to implement something, rather than at the mercy of the LUA or AngelScript team. I dont know. Its just the way I see it personally.

To tell you the Truth Ryan, I do feel there are more important things that AGS needs to work on at the moment. The scripting engine, while not perfect, nor allowing us to script something quickly, does do the trick and allows for a really impressive game making experience. I mean, just look at Resonance or the other Wadjet Eye games or even Games like Minds Eye or Yahtzee games. AGS can do what we need it to do with the current scripting engine.

[monkey0506]

Ryan, I will personally fight you to the death if you try and replace AGScript with Java. Just giving fair warning.

I tend to side with Joseph here. I honestly don't feel that AGScript needs to be replaced. If a few good men were willing to put the time and effort into it, then we could actually make it into something better than Java. Just because the task is large doesn't mean we should just throw it out the window and buy a new one. The caveats of AGScript are very, very much a programmer's issue rather than the average Joe Game Developer's issue. If we plugged in Java in place of AGScript, sure we could just replace our "RTFM"s with a "GO FS#@KING LEARN JAVA" (a "GFLJ" if you will), but I honestly feel that it would have a greater impact on the little man than the perceived benefit of the programmers in the class.

One point where I somewhat shy away from Joseph is his apparent fear that AGS is changing too big and too soon. Replacing Allegro with SDL would be a great move, IMO, because from everything I've seen/heard/read, SDL is being more actively developed, and tends to be more readily available on other platforms. This would be one change that would not take away from the non-programmer developers, but would serve to benefit everyone. These are the types of changes I would like to see.

Later, once the issues with the engine's code base and compiler have been cleaned up (JJS and Crimson Wizard are doing a lot of good here, and I'm still trying to find a way to actually get in the door on this), then we can look at abstracting the scripting language itself out away from the core of the engine. From there, we could provide an interface with which it would be possible to plug in languages like Java, LUA, etc., without having to completely get rid of AGScript. Giving the end-user a choice of language would be better than forcing Java on anyone. Trust me.

[Joseph DiPerla]

One point where I somewhat shy away from Joseph is his apparent fear that AGS is changing too big and too soon. Replacing Allegro with SDL would be a great move, IMO, because from everything I've seen/heard/read, SDL is being more actively developed, and tends to be more readily available on other platforms. This would be one change that would not take away from the non-programmer developers, but would serve to benefit everyone. These are the types of changes I would like to see.

Later, once the issues with the engine's code base and compiler have been cleaned up (JJS and Crimson Wizard are doing a lot of good here, and I'm still trying to find a way to actually get in the door on this), then we can look at abstracting the scripting language itself out away from the core of the engine. From there, we could provide an interface with which it would be possible to plug in languages like Java, LUA, etc., without having to completely get rid of AGScript. Giving the end-user a choice of language would be better than forcing Java on anyone. Trust me.

What about then an SDL Wrapper for Allegro for future ports? Also, do you mean something like : Extern C {} type of thing?

[Ryan Timothy B]

I'm just trying to save time in the long run. And I always figured you Monkey, being a programmer that's always testing the limits of AGS, would prefer something more robust to script with.

Yes, AGS script could be changed and made better than it is, but in the end you're only copying what is already out there. Only because that's the model AGS already uses. Its syntax is based off of C and making any improvements will, in the end, just have an identical model to that or anything on that level.

Are you looking at AGS with rose tinted glasses or am I blind in seeing where it could be taken in terms of scripting. I personally can't see any changes made to AGS that would completely differ from something like Java or C#. That's why I argue it's a waste of time remodeling something to be a lesser or equal version of something else already out there (I can't see it surpassing anything). Please help me see how you could make AGS better than something like Java? How would the future enhanced AGS script be any different?

[monkey0506]

Are you looking at AGS with rose tinted glasses

I absolutely am, and always will. I don't care if I'm blinded by my love affair with AGS.

I'm just trying to save time in the long run. And I always figured you Monkey, being a programmer that's always testing the limits of AGS, would prefer something more robust to script with.

I love programming in other languages. It's fun. But, at the same time, so is being one of the few who knows (the ins and outs, ups and downs, quirks and kinks, etc. of) AGScript as well as I do. I test the limits of AGS not because I want to show off how limited it is, but to exemplify how powerful it is. Very few programs that I'm aware of that use proprietary languages can stake claim to being as robust and versatile as AGScript.

Yes, AGS script could be changed and made better than it is, but in the end you're only copying what is already out there. Only because that's the model AGS already uses. Its syntax is based off of C and making any improvements will, in the end, just have an identical model to that or anything on that level.

I personally can't see any changes made to AGS that would completely differ from something like Java or C#. That's why I argue it's a waste of time remodeling something to be a lesser or equal version of something else already out there (I can't see it surpassing anything). Please help me see how you could make AGS better than something like Java? How would the future enhanced AGS script be any different?

I didn't even strictly mean that AGScript would become so powerful as to take over the world and overthrow your Javas and C#s and PHPs and Pythons and LUAs. When I said that we could end up with something "better", what I specifically meant was "better for AGS". For most, I would say that it's within a reasonable margin to say AGScript has a lower learning curve than Java. Your basic programming concepts and conventions can carry over to most any language. AGScript is lacking in that area, to some degree (no switch statement, no for loops, etc.). However, it is still a very well defined language, that was specifically designed with programmers and non-programmers alike in mind.

If the scripting language were entirely stripped out and replaced (again, if it's Java, I'm coming for you ), then there's a lot of things that would have to be taken into careful consideration. One good example that comes to mind is memory leaks. It's something that's easy to overlook in a lot of cases, but near impossible to track down. AGS handles this brilliantly, and its garbage collection stays very much on top of things.

I'm not trying to say AGS is perfect or that nothing about it should be changed, I just don't see any burning imminent reason why the scripting language should be replaced, while I do see what I consider fair reasons for it not to be.

[Ryan Timothy B]

The only way I could see AGS being better is to have it more organized and easier to work with. Any fully OOP language would definitely improve this along with more organized scripts (separate scripts for classes, interface, etc).

One thing I still want to see is the ability to have a script for every GUI, Character, Object, Inventory Item, etc. With a master script for each type. When I say ability, I mean you'll need to manually create one or it'll default on the master script of that type for the interaction methods.

That way GUI's (and everything) would have a master script instead of using the GlobalScript. Then if you wanted to make a more modular GUI (easily exported and imported into new projects - I'm looking at Abs' verb GUI here instead of it being a clusterfuck in the GlobalScript), or just separate it for organization. Basically leaving the GlobalScript as the master for these methods:  repeatedly_execute, repeatedly_execute_always, on_event, game_start, etc. But this conversation doesn't belong in this thread.

The other thing I want to see is Class, fully working pointers, public keyword (instead of import/export - basically eliminating the useless header script (don't argue, the header script is useless and time consuming)). Then of course the other things I've mentioned above. But once this is done, you've already got yourself a language you claim to not want for AGS.

The advantages of just adding a fully OOP scripting language (I like Java, Monkey! And C#, but I've used Java more) is that you could then extend the automatic types that AGS makes. But of course once you do this, you'll need to modify it so that when you Add a character in AGS (using the editor) you can select if they're using the super class Character or an extension of that class (in the case below, you'd select the NewCharacter class).

Code: AGS

public class NewCharacter extends Character {
    @Override
    public void say(String text) {
        //your new custom Say method that will now override the default Say method (only if the character is an instance of NewCharacter)
    }
}

Notice how I made "say" a lowercase? Isn't that the programming standard? That's always confused me when I started with AGS. Classes, Interfaces, etc should be first letter uppercase, with methods and variables being first letter lowercase.

With AGS we currently have Character.x, Object.X, GUI.X, Button.X, label.X, etc. Why is it that Character is the only one that complies with this standard? If the coding script were to switched over to a different language, things like this should to be corrected.

Anyway, back to the subject, that's why I'm so confused with anyone wanting to spend anytime enhancing the current AGS script when it's going to end up like something else anyway (like Java ).

[monkey0506]

Methods and properties shouldn't start with a lower case letter, now you're just going out of your way to piss me off.

Character.x/y/z are only lowercase for legacy reasons.

"@Override" is stupid, it should just be implemented as a keyword.

public is implied for AGS, which is fine. The header isn't useless, and I will argue that point. It gives you greater control over how functions and objects are linked. If we did away with it, a lot of crap would start colliding unnecessarily.

[Ryan Timothy B]

Methods and properties shouldn't start with a lower case letter, now you're just going out of your way to piss me off.

Hmm. I believe you're right. I've read both a Java and C# book and I could've sworn C# also said first letter being lowercase. Alright, so my Java is showing (and I personally prefer it, but I don't want to piss you off).

"@Override" is stupid, it should just be implemented as a keyword.

You don't need to create your own programming language just because it "looks" stupid, do you?

The header isn't useless, and I will argue that point. It gives you greater control over how functions and objects are linked. If we did away with it, a lot of crap would start colliding unnecessarily.

I'm not speaking in today's AGS, so you'll have to explain this "colliding" thing. I'm talking in more of a future version with a fully working public keyword, forward/backward declaration, etc.

[Crimson Wizard]

One thing I still want to see is the ability to have a script for every GUI, Character, Object, Inventory Item, etc. With a master script for each type.

I give you my full support on that wish! (morale support for now )

Notice how I made "say" a lowercase? Isn't that the programming standard? That's always confused me when I started with AGS. Classes, Interfaces, etc should be first letter uppercase, with methods and variables being first letter lowercase.

I guess this is an "endian" question.
All Microsoft libraries (WinAPI, MFC, .NET), as well as Borland Delphi (VCL) follow "capital letter" policy.
Meanwhile unix and cross-platform libraries show tendency to "small letter" policy.

[monkey0506]

"@Override" is stupid, it should just be implemented as a keyword.

You don't need to create your own programming language just because it "looks" stupid, do you?

Like hell I don't.

P.S.

Spoiler

[/sarcasm]

[close]

[SpeechCenter]

I agree with Monkey on the simplicity. The fact that the framework is OO (events and predefined types) but doesn't force a user to learn OOP is a plus. Based on the previous discussion, I think we need to separate features for game developers and features for module writers. The former (usually) need the language to remain simple and the later may need improvements and can work with them. I don't think this means a full new language, but we need to agree which minimum constructs will help.

I think the language is closer to C# than Java (despite their own similarities), the element that really seems redundant in the language is the '*' for object reference, not sure why it's needed (did anyone intend to pass structure by value?). The biggest advantage of other languages is their existing libraries, but I don't see it likely that AGS will run JVM or .Net IL in the near future, so it doesn't matter. The only thing is what syntax we'd like to  borrow from those languages to AGS.

As for imports, the ability to deduce the function without the 'import' directive would simplify the work of game developer. It's not a simple task for the code interpreter and compiler because it would mean adding a linking stage, but I don't see the use case that 'import' helps to develop a game if this can be done automatically. In fact, it's very likely that this change can be done without touching the engine, just need to create the correct import reference in the compiled code.

[Shane 'ProgZmax' Stevens]

Here are just a few ideas people have tossed around over the years that would likely be more useful now than redesigning the ags script in java/whatever.

In no specific order:
1.  Reformatting game saves so that they continue functioning after game re-compiles, patches, and work regardless of resolution.
2.  Faster rendering of sprites (this becomes more of a problem for 800x600 and up people).
3.  Switching between windowed mode and fullscreen at will/changing video resolution in-game.
4.  Ability to export views and any other resources not currently supported, adjust current exports to export relevant views with them (in the .chm, etc).
5.  Better portability.
6.  Walkable area/hotspot/region overlapping with support for any character to respond to (not just the player).
7.  More dynamic limits, eventually phasing out static resource limits entirely.
8.  Test and modify game code while game is running.

Improve the existing scripting language, sure, but as far as starting over there are loads of other things we could do to make a much greater impact on the utility of the engine.

[Crimson Wizard]

Btw, that reminds, me, I am totally sure some time (months? years?) earlier I've seen ProgZmax proposed to make every game object (Character, Room Object, Inventory Item, etc) inherit from some base parent "entity" class and support dynamic creation. I remember that because it is what I would like to see in AGS some day too.

"Some day" is a key word here

Ability to export views and any other resources not currently supported, adjust current exports to export relevant views with them (in the .chm, etc).

That is rather an Editor feature.

More dynamic limits, eventually phasing out static resource limits entirely.

This is not difficult to make right away, just need to put normal utility classes into use. I believe monkey_05_06 will do that eventually.

[monkey0506]

Ability to export views and any other resources not currently supported, adjust current exports to export relevant views with them (in the .chm, etc).

That is rather an Editor feature.

And this is rather the Editor development forum. The scripting language itself is one of those things that transcends the two forums, but I think what ProgZ was getting at is this:

Improve the existing scripting language, sure, but as far as starting over there are loads of other things we could do to make a much greater impact on the utility of the engine.

He was just saying that this thread is useful and purposeful, but we shouldn't ignore/reject/forget about other features that would highly improve the state of the engine.

I believe monkey_05_06 will do that eventually.

The keyword here being "eventually". Actually, this is exactly the type of situation where I feel I could be useful, but I do need to take some time to really gather more information about what should be considered "best practice" for our purposes (i.e., should we use std::vector, or should we write our own "normal utility classes", or even just look for a compatible existing non-STL library?).

I think one thing that it would be good to lay out before we start getting too deep into changing things is that we need some well-defined and well-structured Coding Conventions. Nothing bothers me more when opening up other people's code (especially if it's been authored by several people) than finding inconsistencies and so forth with regard to formatting, methodology, etc. I've actually read through Google and ScummVM's Coding Conventions, and while they both raise some very good points, I don't think we should just directly adopt either. As a matter of fact, I think I'll start a new thread for this topic (in the engine forum as that's where most of this is going).

[RickJ]

@Joseph:  What language is the following written in?

Code: ...

  if( condition ) 
  {
    // Do something if condition is true
  }

  if( value < 10 ) 
  {
    // Do something if value is less than 10
  }
  else
  {
    // Do something else if value is greater than or equal to 10
  }

  :
  :

  // Loop, where the condition is checked before the logic is executed
  int i = 0;
  while( i < 10 )
  {
    // Do something
    i++;
  }

  // Loop, where the logic is executed before the condition is checked
  int j = 0;
  do 
  {
    // Do something
    j++;
  } while( j < 10 );

Spoiler

http://www.angelcode.com/angelscript/sdk/docs/manual/doc_script_statements.html

[close]

Looks a lot like AGS script doesn't it.  They have an army of contributors and even more users.  It seems foolish to reject such options out of hand without even taking a look or having a discussion about it.  Heaven forbid if we happen to learn something along the way.  Imagine that...a group of humans getting together and making an informed and objective decision...the world would probably come to and end.  

How do you think AGS's fabulous script editor came about?  It was an off the cuff comment to CJ similar to "You may want to have a look at this  scintilla.org".  Honestly, if you people were running the show back then it would have never happened.

[timofonic]

What about accepting different scripting systems providing different computer programming approachs? This way, game developers would choose one of them based on their experience or personal preferences.

Here is some examples about what scripting languages would be good to include...

- One for non-programmers but poweful enough for complex games too, being scalable with additional features for more advanced users. This would be the default one
- A Python/C#/Java alike for people used to to Object-Oriented Programming.
- A JavaScript/ECMAScript alike for people used to web programming. This is currently done by the Wintermute engine, for different reasons.

If the scripting system can be hooked up to produce an AGS bytecode compilation, then there would be no problem at all to give it as an option.

After all, those scripts are going to be converted to bytecode by the AGS compiler. You can't include big external dependencies like a full blown JVM but provide a common infrauestructure to execute the game logic, the "AGS VM". This way it can be ported easily to all kind of devices because of portability and lightweight design in mind. If you require an external interpreter or embedding a script interpreter, you ruin all the portability and/or lightweight advantages

As two possible negative points, maybe this would make code maintaining of both the AGS compiler and editor more complex in certain way.

Am I right?

[Crimson Wizard]

What about accepting different scripting systems providing different computer programming approachs? This way, game developers would choose one of them based on their experience or personal preferences.
<...>
If the scripting system can be hooked up to produce an AGS bytecode compilation, then there would be no problem to give it as an option at all.
<...>
After all, those scripts are going to be converted to bytecode by the AGS compiler.

Personally I like this concept in general, although at the moment I have little idea how scripts are compiled and run in AGS and what would it take to allow something like that; I haven't had much chance to investigate this in detail.
What is being proposed here is very similar to how MSIL works.
However, there are two questions:
a) should we actually care about making such a wide variety?
b) who actually is supposed to be responsible for making and maintaining various compilers? I don't think it should be AGS team, at least not the core team.

If the internal language specifications are made open (they are open already de facto, since source code is open), literally anyone can make his own compiler and programming language for AGS.

[monkey0506]

Honestly, if you people were running the show back then it would have never happened.

I would literally have preferred it that way.

Dang, I've got to stop being such a troll.

There's a lot of languages that are similar to AGScript, but it doesn't mean we should throw out years of dedicated work...I mean, CJ could have done that. There was a reason he didn't. It's not like he was ignorant to the existence of other languages.

@CW: +1'd.

P.S. Per my last post, I'm working on drafting up a formal proposal for some coding conventions. I'm actually putting some thought into it though, so it might be a little bit before I get around to clicking that "Post" button (the wiki would have been easier on formatting, but apparently everyone around this place hates the wiki, or maybe they just hate reading what I've put in it ).

[Calin Leafshade]

I like the idea of modularising the whole thing and allowing people to use whatever scripting language they want providing there are bindings for it.

Thats not as crazy an idea as it sounds. All the base functions are already defined in the engine source so we just need to expose a few more things in the API and have a base system for saving the game. Then you can have as many languages as you want just by writing the bindings for them. Feasible?

[Shane 'ProgZmax' Stevens]

It's certainly possible to adapt the engine to support custom/multiple scripting languages but I think it would be quite a job, especially with reworking saves (which I think is pretty important).  I don't have any substantive objections if someone wants to do this, but if it comes to priorities I think most of us can agree that there are more pressing improvements/corrections to be made.