Morning gents,
So AGS.Native has been around for a few weeks now and I've spent a few hours going through the compiler.
I'll be honest and say i don't really understand a lot of it due to all the assembly required but I think we should make a conscious effort now to improve the scripting language.
I think we should start by adding the ability to reference custom structs and pass them as parameters. This addition would essentially make AGS capable of creating full (read useful) OOP constructs.
Does anyone have any insight on how hard this would be? AGS can already create managed objects and already has a pool for them since they can be created using plugins so it seems like there isnt that much more to do.
Any thoughts?
I don't have enough time to help but I'll cheer you on.
- Alan
The biggest reason that CJ ever stated for not doing this was simply that the save game files could possibly become invalidated...but I see no difference between custom struct pointers and managed struct pointers in this case when save games can reference static custom struct instances just fine...
I think it simply was never enough of a priority, because there are SEVERAL ways of accomplishing the same end-result. It would certainly make design-time better for programmers though (rewrite half my modules? here I come!).
Just make sure we can create dynamic arrays of pointers to custom structs. Coz, y'know, we need those.
Also, dynamic arrays within structs.
Also, dynamic array length members.
Get busy dude!! :P
Also, the 'const' keyword:
struct foo { int data; };
int a = 10, b = 30;
const int c = a * b; // const would be sooo handy, or at least let 'readonly' act the same as const
foo arr1[c];
foo arr2[a * b];
Instead of having to use #define (could not use #define if we did not yet know the value of a and/or b before declaring the arrays).
AND everything that monkey said. All of it.
Cheers :tongue:
ArrayList.
That would be the ultimate addition along side the ability to pass custom structs as pointers.
Quote from: Ryan Timothy on Wed 06/06/2012 21:53:07
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.
Three extensions on existing code that would be particularly handy:
Read/Write .Name properties- String Room.Name; - Example: player.ChangeRoom(rForestGarden, x, y);
- String Hostpot.Name; - Example: hBlockedEntrance.Name("uncovered exit");
- String Object.Name; - Example: oMug.Name("?");
Hotspot.Name and Object.Name already exist but they are read-only at run-time. I don't think it was ever thoroughly explained to me why this couldn't be changed, although perhaps it was something to do with only one room being loaded into memory at any given time and save game stuff...
Named rooms are technically possible by using an enum:
enum RoomNames
{
rForestEntrance = 1,
rForestGarden = 2,
rForestLake = 3,
rForestWhyNotAnotherRoomInTheForest = 4,
// ...
};
It might actually cause some confusion to have AGS built-in names like that (especially if they represented script objects and not just enumerated values) unless the whole "only one room loaded into memory at any given time" bit was changed.
Edit: What? Ugh, typing posts 5 mins before I go to sleep... (laugh)
Quote from: Calin Leafshade on Wed 06/06/2012 22:48:43
Quote from: Ryan Timothy on Wed 06/06/2012 21:53:07
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.
I looked at the code, I don't think that adding a struct as pointer parameter is that complex, just a matter of loading the address to SREG_MAR. However, that's far from being able to do an ArrayList because you'll quickly need the ability to create a new object in the heap. Then of course you run into the question of deleting the object.
Furthermore, should the syntax have struct* and if so how do you pass the address of struct as parameter? (and do we really want the C notion of pointers in scripts?)
I believe language changes like that require careful planning, otherwise it will create backwards/forwards compatibility problems.
Quote from: monkey_05_06 on Thu 07/06/2012 05:17:56
It might actually cause some confusion to have AGS built-in names like that (especially if they represented script objects and not just enumerated values) unless the whole "only one room loaded into memory at any given time" bit was loaded.
Agreed, things like this are not changes to the scripting language. They are just additions to the environment. This is something we want to avoid really.
Quote from: SpeechCenter on Thu 07/06/2012 07:07:35
I looked at the code, I don't think that adding a struct as pointer parameter is that complex, just a matter of loading the address to SREG_MAR. However, that's far from being able to do an ArrayList because you'll quickly need the ability to create a new object in the heap. Then of course you run into the question of deleting the object.
Creating objects on the heap was also my concern. As I said, AGS already has the mechanisms to handle an object pool in a managed way and has a suitable garbage collector.
Quote from: SpeechCenter on Thu 07/06/2012 07:07:35
Furthermore, should the syntax have struct* and if so how do you pass the address of struct as parameter? (and do we really want the C notion of pointers in scripts?)
I agree here. Pointers dont make a lot of sense in a scripting environment like this. I am of the opinion that all structs should be reference types and the idea of pointers should be abstracted away. There's no real reason to make a distinction between a ref type and a value type.
Alternatively we could make an entirely new construct and call it a class. Then we leave structs as value types and classes as reference types. This avoids any backward compatibility issues.
like this:
class MyClass
{
int LOL;
};
struct MyStruct
{
int LOL;
}
function foo()
{
MyClass classRef; // this would now be null
MyStruct structVal; // this would not.
MyClass classRef = new MyClass; // classRef is now not null and a new object has been created on the heap.
//classRef will now go out of scope and will be garbage collected just like a DynamicSprite would be.
}
Quote from: SpeechCenter on Thu 07/06/2012 07:07:35
I believe language changes like that require careful planning, otherwise it will create backwards/forwards compatibility problems.
Planning, yes. Hesitance, no.
Would be great to have some higher order datatypes built in, like perl or python does: lists, hashes, etc. as well as the ability to build your own. Pre-made ones would be easier for those with less of a programming background. Ideally, if you could access all the namespaces themselves as a dictionary like python can, it would also provide a way for people to make their own savegame mechanisms that didn't get broken for compatibility every time the game is recompiled.
QuoteNamed rooms are technically possible by using an enum
You missed my point slighty so I'll elaborate. ;)
I remember being able once AGS 2.8? to call cEgo.ChangeRoom("Room Description"). This was helpful when I wanted to re-order rooms into a much more logical list.
I don't see the drastic difference between that and what I did. I mean, if you changed the room numbers then you'd be responsible for updating your list...but...how often do you change room numbers?
Regarding the whole bit about about list types and the like...we'd really need templates to make that truly useful. I've pondered on the idea of trying to have an editor plugin to auto-generate specialized structs based on usage of a pseudo-template. The template struct itself would be commented out immediately before saving the game, and then uncommented after compilation. Never really did get around to implementing it, obviously. Of course now that the compiler is available, we could look at just doing it the "right" way.
As for the proposed reference class type, that sounds like a good solution to me. I haven't really looked into it, but AGS already has garbage collection for things like DynamicSprites, dynamic arrays, ViewFrames, DrawingSurfaces, and other on-the-fly types that are cleaned up if there's no more pointers to them lying around. Would it be terribly difficult to extend this to user-defined reference classes?
Quote from: Calin Leafshade on Thu 07/06/2012 08:11:20
Quote from: SpeechCenter on Thu 07/06/2012 07:07:35
I believe language changes like that require careful planning, otherwise it will create backwards/forwards compatibility problems.
Planning, yes. Hesitance, no.
Not advocating hesitance, but don't want to pay the price of easily avoidable mistakes. If you create a 'new' keyword for objects, constructors and destructors easily come to mind, which of course further complicate things.
As for garbage collection, I didn't check, but does the current garbage collector handle loop reference? For example object A references object B and object B references object A (or something more elaborate)? I didn't check, but maybe this wasn't a concern for the current use case and if we start adding data structure library (which is a good idea) this has to be handled. The template option (or generics) is also an important subject. Anyway, all this is much more work than simply sending a struct as a function parameter, essentially all these things drive the script language to C#-like language. Most importantly, this has to remain optional for advanced developers, it's best that most AGS users can just start without knowing too much programming.
I thought a bit about the pointer thing, in AGS '*' actually acts as a reference & in C++ and not pointer, so it might be ok, as long as you can simply assign struct instance to struct reference. Another possibility is to define that this operator is optional for parameters, because objects are always passed by reference.
Since there is effort to separate editor-compiler-runtime, one has to wonder if it wouldn't be easier and better to just move to an existing high level OO script language such as python, angel script, etc, etc, ...? We would end up with a full featured language complete with compiler/runtime and wouldn't need to expend any effort on compiler and related issues.
Yea, i've thought about that. The problem is that you would need to find a way of saving the state of the VM and I'm not sure how you do that with a 3rd party scripting language,
I'm not sure what you mean by that. Unless we are not talking about some esoteric scripting language, you can save the state of any VM by saving its cache (ie. stack) and memory contents, doesn't matter if it is AngelScript, PHP or Python.
I still don't fully understand what problems are we trying to solve here. Can anyone provide the use cases that are not possible or difficult with today's scripting language? Meaning, not in the language itself, which is obvious, but for game developers, actual use cases.
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).
I agree that AGS's strength is its simplicity and I think that keeping that simplicity intact is vital.
However, there are a few holes in the scripting language that prevent more experienced coders doing things more elegantly. This is not a problem in itself but it means that we cant make certain kinds of modules for the less experienced to use without jumping through hoops.
Ok I'll list the things that AGS cant currently do that i think it should
Important:
Passing structs as parameters either as a reference or value type. (easily the most important thing that ags lacks)
More flexible dynamic arrays and a way to find an array's length at runtime.
Forward declaration of some kind. Currently its impossible for modules to talk to each other in a bilateral fashion.
Sugar:
For loops,
Switch/Case,
implicit casting,
function overrides
To be honest, even if just the first one was implemented i'd be happy. The rest can be fudged in various ways.
Quote from: SpeechCenter on Sat 09/06/2012 13:49:21
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).
Quote from: Calin Leafshade on Sun 10/06/2012 12:48:18
I agree that AGS's strength is its simplicity and I think that keeping that simplicity intact is vital.
Just two add my two cents, there's always an option to have both low-level and high-level language features, with latter serving as user-friendly wrappers over low-level functionality.
And, by the way, there's always an option to create GUI wrappers over scripts. I haven't had much experience with AGS 2.72 but I remember there was some sort of "interactions" dialog. I recall some people mentioned it was easier to work with for newbies. Personally, I may also mention such examples (known to myself) as Warcraft 3 and Starcraft 2 scripting module that allowed people to make scripts both by using GUI and by directly writing script texts.
Quote
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.
Quote from: RickJ on Mon 11/06/2012 05:05:08
Quote
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.
Quote from: Calin Leafshade on Wed 06/06/2012 22:48:43
Quote from: Ryan Timothy on Wed 06/06/2012 21:53:07
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.
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.
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.
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.
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.
Quote from: Calin Leafshade on Sun 17/06/2012 21:49:33
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 (http://haxe.org/)? (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.)
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.
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.
Quote from: Calin Leafshade on Sun 17/06/2012 21:49:33
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.
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.
Quote
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.
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
There are a million differences between java and AGS Script.
Go on, dare me to name them all.
Calin, I dare you to name every one of them. :D
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.
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.
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.
Quote from: Joseph DiPerla on Sat 23/06/2012 14:36:22
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.
Quote from: Snarky on Sat 23/06/2012 16:23:01
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.
QuoteBut 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.
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.
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.
Quote from: monkey_05_06 on Sat 23/06/2012 17:12:39
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?
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?
Quote from: Ryan Timothy on Sat 23/06/2012 17:37:31Are 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. :P
Quote from: Ryan Timothy on Sat 23/06/2012 17:37:31I'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. :P 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.
Quote from: Ryan Timothy on Sat 23/06/2012 17:37:31Yes, 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 :P), 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.
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).
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 ;)).
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.
Quote from: monkey_05_06 on Sat 23/06/2012 20:39:02Methods 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). ;)
Quote"@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? ;) ;)
QuoteThe 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.
Quote from: Ryan Timothy on Sat 23/06/2012 20:18:18
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 :))
Quote from: Ryan Timothy on Sat 23/06/2012 20:18:18
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.
Quote from: Ryan Timothy on Sat 23/06/2012 20:54:41Quote"@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]
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.
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.
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 :)
Quote from: ProgZmax
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.
Quote from: ProgZmax
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.
Quote from: Crimson Wizard on Sun 24/06/2012 18:10:21Quote from: ProgZmaxAbility 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. :P The scripting language itself is one of those things that transcends the two forums, but I think what ProgZ was getting at is this:
Quote from: ProgZmax on Sun 24/06/2012 17:55:49Improve 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.
Quote from: Crimson Wizard on Sun 24/06/2012 18:10:21I believe monkey_05_06 will do that eventually.
The keyword here being "eventually". :P 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).
@Joseph: What language is the following written in?
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
Looks a lot like AGS script doesn't it. They (http://www.angelcode.com/angelscript/sdk/docs/manual/index.html) have an army of contributors (http://www.angelcode.com/angelscript/credits.html) and even more users (http://www.angelcode.com/angelscript/users.html). 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.
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?
Quote from: timofonic on Mon 25/06/2012 14:55:06
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.
Quote from: RickJ on Mon 25/06/2012 04:34:14Honestly, if you people were running the show back then it would have never happened.
I would literally have preferred it that way. :D
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 (laugh)).
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?
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.
@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.
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.
gGui.lLabel.Text = "etc";
Instead of the terrible way it is now:
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.
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?
Quote from: Joseph DiPerla on Wed 04/07/2012 21:49:46
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.:
// the script module start
#enable_new_compiler
// rest of script
2) doing the similar thing but via script properties.
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.
Quote from: Joseph DiPerla on Wed 04/07/2012 22:30:37
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.
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?
Quote from: Crimson Wizard on Wed 04/07/2012 22:23:14
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 (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=25967.msg327751#msg327751) 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.
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?
Quote from: Ryan Timothy on Thu 05/07/2012 00:13:26
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).
Quote from: Ryan Timothy on Thu 05/07/2012 00:13:26
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 ;)
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
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.
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 :P
How about adapting AGS scripting like in Blocky.
It might be a good way to handle character movement.
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.
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 :D 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.
// i would like:
int counter=10;
while (counter--){}
//to be valid source code.
//i would like to have functions that can return other data types than just int, maybe i am just missing how to set a function to return a string or any type. not well documented.
Quote from: ollj on Wed 24/06/2015 11:34:46i would like to have functions that can return other data types than just int, maybe i am just missing how to set a function to return a string or any type. not well documented.
This is quite possible:
String GetString()
{
return "MyString";
}
Character *GetCharacter()
{
return character[0];
}