Future AGS development

[Wyz]

or atleast accept donations to help pay for programmers?

You don't even need to charge for that. A lot of programmer are willing to help out for free; I know I would. Surely many of them don't have a lot of spare time, but then they could still do bug fixes or adding small features, or when the engine can be divided into modules: even that. That is exactly where rainy Sundays are good for.

But back on topic, I guess Sslaxx summed it up quite good. Those are the possibilities and it is really up to CJ to decide what he thinks is best.
When opening the code: have a look at the PHP license or when opening it up completely the MIT license.

[edmundito]

As a hippie (or hipster?), I'm all about fully openness... that is the MIT license and Git SCM/GitHub the project. I know. Crazy. Not really suggesting that route, but I'd dig it if it went that way.

[xenogia]

Does this mean Linux in the future? Dum Dum Duuuuuuuum.

[deadsuperhero]

I would also like to go along and point to the really important aspect of native editors for the top three platforms:

For once, rather than just trying to write code to replace Windows plugins, we could end up using native libraries of each platform to create plugins that extend the functionality of the game itself. Hypothetically, what do I mean?

Let's take a look at the Gnome Zeitgeist project. It's a file-logging daemon that, when applied to an app such as Gnome-Activity-Journal, will list what you did and when. A hypothetical AGS plugin that pipes into Zeitgeist APIs could set flags throughout a game that would count as achievements of some sort. This isn't in and of itself important to the game itself, but functionality could be extended across platforms to enhance what a native AGS game could do using API's already present in the desktop itself.

Of course, porting would take a little longer, but think about what else could be done. Rather than waiting for Chris to put in OpenGL support to be on par with AGS' DirectX video acceleration, suppose a Mac version of the game could plug into the CoreVideo suite to manage Coca-native 3D app acceleration.

If AGS were to go open source, many, many things could be achieved provided that a dedicated community could get behind it. I think if the engine itself were kept fairly stable and slow in development, and the rapid-development stuff would be mainly plugins that could be swapped in and out, you would nicely sidestep a fragmentation issue overall. After all, once you include a major feature change in the master repository, what would anyone that tries to fork the engine be able to do to get your features? If the break were big enough, they couldn't contribute upstream enough to break the overall implementation of AGS in and of itself, but perhaps their meddling might have at least turned up an unexpected bug.

Those are just some of my thoughts. It's really your engine, but really the FOSS community could use these kinds of tools, and the oncoming wave of many of the very ambitious game developers here.

[Spummy]

Whoa. This is big news.

I personally would love to see the Editor opened. Mainly because Linux + Mac could do with a good Adventure Game tool, even though a port would probably take a while before showing up...


The engine being opened would also be cool (Do both of them use C#?)

If people are concerned about the ability to obtain content, then you could have that section of AGS still closed. I think the GPL is the only license that disallows that. Licenses like LGPL/ZLIB/MIT/BSD would allow for it.


I think some people here are thinking that it being open means that any random can make their own contribution and it has to show up in the official version on the main website. Which it doesn't.


But anyway. I look forward to seeing some Editor code sometime soon! If you decide to go for a small team of programmers instead, cool too!

[GarageGothic]

To be honest, when I look at the changes I hope for, or even consider more or less necessary for AGS' continual growth as a tool and the engine's expansion onto other platforms, I'm beginning to wonder if that product would still be AGS in anything but name. The core design of the program is so firmly grounded in the adventure games of a certain era with rooms, characters, objects, hotspots, walkbehinds and so on, each with (sometimes arbitrary) limitations specific to their type. Of course stuff like this can be kept part of the default declarations to make transition easier, much like the current default GUI setup, but it would be shortsighted to treat them as anything but genre specific abstractions of a much more generalized system, and more importantly, to not allow user access to that base system.

My main reason for hanging on to a (hypothetical) future AGS rather than Wintermute 2.0 (whenever that comes out), or switching to a non-adventure specific engine, would be that I already know the scripting language. Yet thinking objectively, if the whole engine was rewritten wouldn't it make more sense to switch to an existing language like Lua or Python? Not only would it be easier for new user who already knew that language, but the skills learned while working in AGS could be transferred to professional game scripting. That kind of "universality" would also make it more attractive to use AGS in an education environment.

So I'm really on the fence here - on one hand I'm truly excited about the future of AGS as a community developed engine, and yet I'm in favor of changing pretty much every feature of it. At the same time can't help I wonder if there's any real consensus on a "vision", and I'mcurious what directions of development people have in mind.

In short, what do you perceive as the core of what makes AGS what it is?  And how elastic are the boundaries of that identity?

[Calin Leafshade]

I do understand what you mean here and I have thought something similar.

However there is alot of room to expand AGS, whilst keeping it an adventure game engine.

Let's think about this. The 'Adventure Game' hasn't changed that much in format over the years.
Monkey Island is not that much different to Vampyre Story or The Longest Journey.

They all have rooms, characters, objects, guis generated in much the same fashion but I'm sure we can agree that the feature sets of the SCUMM engine and the... modern ones, whatever they are.. are completely different.

so here is my list of things that could be improved.

2.5D support - this is a realistic way for indie games to be produced. You get the advantages of 3d lighting on characters without the need to model a full world

A Gui overhaul - The GUI system is *very* dated. I would suggest a more modular system which allows users (via the plugin system) to create their own user controls in the same way that WPF or WinForms works.

An updated sound system - The new audio system is a good start but there is so much more you could do. DSP on channels for instance

A pixel shader system - This could be implemented almost overnight if the source was open.

Updated font support - unicode support has been a long time coming.

More complete scripting language - Alot of things are missing which irk me on a daily basis. Classes, accessor functions, template classes, ternary statements, for loops, events.

Blending modes damnit: Alpha and Additiveplease

Dynamic Classes - What i mean here is being able to create characters and objects on the fly. The new object would then be added to the room's collection. something like:

Code: ags

Object obj = new Object([constructor values])

Polymorphism: This really fits in with a more complete scripting function but how cool would it be if you could make your own classes that derive from other classes like this:

Code: ags

Class Monster : Character
{
    public Monster()
   {
       //constructor stuff
       base();
    }

    public override Say(String what){

      base.Say("ROOOARR!");
    }
}

Being able to override functions like this would turn AGS in something really powerful.

Now I know what your thinking. All this sounds super complicated for the less techy users but its not really.

You could still maintain the current features of AGS with some kind of main entry point 'Game' class. So besides a few format changes everything should be basically the same if you didnt want to use all this advanced stuff.

Meh, theres probably more but i'm bored of writing now.

[Wyz]

I have to agree with Calin, with a few augmentations on the existing scripting language it should stand to time without problems (I know that these augmentation require the lexer to be completely rewritten; add testing and implementation; they are HUGE tasks.)
I don't think AGS would ever need a functional programming language. Simple polymorphism like Calin proposes will do just as good. I would also add: passing structs as function parameters. (I can only assume this means big rewrites for the engine too) I'm just throwing it out there.

As for the other features: it would be really great if we could do stuff like that with just the plugin interface. Well, the sound system proposed by Calin and unicode support can already be done with plugins right now. So chop chop!

About the cross platform thing: I want to state for any plugins I've made so far and all I will make in the future: I will guarantee they can be available for each platform AGS gets ported to if that were to happen. I will either port them myself or open it up to people so they can port it. If other plugin developers will make this guarantee I hope this takes away some of the worries people have about using plugins.

[Dave Gilbert]

I really don't have much to add here, since I'm just a user and I am not much of a programmer per se.  I've used AGS for almost 10 years now (!) and I've grown so used to it that I always hesitate before using something else.  But, if I ever *do* use something else, the lack of portability would be the biggest one.  The ability to natively run an AGS game on a Mac, or any other platform for that matter, would be a huge boon.

That said, I owe my livelihood to this little engine and no matter what happens I'm eternally grateful to CJ and the community here that made it happen.  As someone in this thread said, AGS is currently near perfection already and I'll continue to use it for the time being.

-Dave

[deadsuperhero]

As another random, unrelated-but-sort-of-related snippet:

PyGame was ported to AmigaOS4 recently. Yes, the operating system still exists and is in active development. A recent computer with comparatively powerful specs is almost on the edge of coming to market.

This is all purely hypothetical, but the Amiga at one point was the hub for some of the best indie games around. Think about it. AGS games on the Amiga. 

[monkey0506]

A pixel shader system - This could be implemented almost overnight if the source was open.

Yes, so long as it isn't required. It might sound ridiculous, but my computer which was given to me by my old roommate does not have a graphics card that supports pixel shader 2.0. I don't know if it even supports such a graphics card as I..haven't really done anything enough that would force me to try and upgrade it.

More complete scripting language - Alot of things are missing which irk me on a daily basis. Classes, accessor functions, template classes, ternary statements, for loops, events.

I never really understood why there necessarily needed to be a distinction between a class and a struct. If structs were limited to POD types then that might be a different case, but AGS's struct type is a bit more flexible than that (I am completely disregarding the supported functionality here in favor of what it can actually do..). I do agree that template classes would be AWESOME. I actually started to write an editor plugin to iterate the scripts in a pre-compile state and replace template definitions with appropriate struct types based on implementation..which..clearly, never got released.

For loops are nice as they allow their iterators to have their own scope. Ternary statements too can be very useful. These are fairly simple implementations which would make scripting a bit easier.

Events already exist within AGS though. AGS doesn't offer any form of delegates for dynamic linking of events (in that fashion) which is what I assume you mean, but we have events like game_start, on_event (the events therein), on_mouse_click, etc., as well as character-, object-, inventory-, hotspot-, GUI-, etc.-based events which can be used to call the functions you'd want to call at that time. Perhaps not as elegant as a delegate, but still the same end result ultimately.

As far as accessor functions go (WARNING: More disregard of what is supported as possible in favor of what is possible), they're entirely possible in AGS. Using this example that I hijacked from Wikipedia:

Code: ags

// C#
public class Student
{
    private string name;

    public string Name
    {
        get
        {
            return name;
        }

        set
        {
            name = value;
        }
    }
}

Translates in AGS to:

Code: ags

// AGS
struct Student {
  protected String name; // field
  import attribute String Name; // property
};

// NOTE: The following can appear in any script you want, however, the Name property cannot be used before these are defined
// AND the Name property cannot be used in THIS script

String get_Name(this Student*) { // getter
  return this.name;
}

void set_Name(this Student*, String name) { // setter
  this.name = name;
}

// NOTE: The getter and setter functions can be called in this script in lieu of accessing the property directly

For indexers (arrays) the syntax is a bit different:

Code: ags

struct Student {
  protected String name;
  protected int classIDs[10]; // unique ID number for the student's registered classes; max 10 classes per student
  import attribute String Name;
  import attribute int ClassIDs[]; // note we CANNOT set a static size here, though AGS does not yet support dynamic arrays within structs
};

// ...

int geti_ClassIDs(this Student*, int index) { // getter with an array index
  if ((index < 0) || (index >= 10)) AbortGame("Student.ClassIDs: specified index %d out of range, valid range 0..9", index);
  return this.classIDs[index];
}

void seti_ClassIDs(this Student*, int index, int classID) { // setter with an array index; index comes before classID in parameter list
  if ((index < 0) || (index >= 10)) AbortGame("Student.ClassIDs: specified index %d out of range, valid range 0..9", index);
  this.classIDs[index] = classID;
}

Of course this is not in any way supported but due to its excessive internal use (every single property of every single built-in type is defined as an attribute), I'd say it's probably safe for use..for those who know what they're doing with it (though of course CJ would probably have to say to stop giving away trade secrets..).

Blending modes damnit: Alpha and Additiveplease

Dynamic Classes - What i mean here is being able to create characters and objects on the fly. The new object would then be added to the room's collection. something like:

Code: ags

Object obj = new Object([constructor values])

I can appreciate these two, though dynamic object creation is actually pretty complicated when you consider how much actually goes into an object's definition. In particular, for this we would need some type of delegate in order to be able to create event functions for dynamically created objects.

Polymorphism: This really fits in with a more complete scripting function but how cool would it be if you could make your own classes that derive from other classes like this:

Code: ags

Class Monster : Character
{
    public Monster()
   {
       //constructor stuff
       base();
    }

    public override Say(String what){

      base.Say("ROOOARR!");
    }
}

Being able to override functions like this would turn AGS in something really powerful.

Which is also completely unsupported yet completely and totally possible! :

Code: ags

struct Monster extends Character {};

function Say(this Monster*, String what) {
  Character *c = this;
  c.Say("ROOOARR!");
}

The problem with this is simply that none of the existing Character objects (cEgo, etc.) are defined as instances of the Monster type, and AGS does not provide a way to cast between types..except..as I showed when casting a derived type into a pointer of a base type. Since AGS doesn't allow pointers to custom struct types, this means that short of writing some sort of serialization and deserialization functions for your struct (I'm thinking along the lines of the Stack and List modules here), it is impossible to create polymorphic types derived from a custom type (that reference the base type's functions). (Edit: By the way, this above example would actually cause "object not in managed pool" errors (derivate of "pointer cast failure" errors) if you ever called Monster::Say due to the fact that the internal Character object is not a managed character. You'd actually have to add the AsCharacter pointer I talk about below and use it in the polymorphically overridden function instead of casting a new pointer..and it would of course have to be initialized at some point or else you'd get a "null pointer reference".)

However, if you included some sort of AsCharacter pointer as part of your Monster struct definition then you could create an array (sadly due to AGS's limitations it must be statically sized ) of Monsters and use those instances anywhere you would use a Character (using the AsCharacter property when necessary).

Now I know what your thinking. All this sounds super complicated for the less techy users but its not really.

You could still maintain the current features of AGS with some kind of main entry point 'Game' class. So besides a few format changes everything should be basically the same if you didnt want to use all this advanced stuff.

Meh, theres probably more but i'm bored of writing now.

I wasn't planning on critiquing your entire post..ah well. 8) Anyway, this final point sounds to me like you're suggesting to move the AGScript language more toward a full OO language, which I'm fine with..though I know others find it more intuitive to state what they're doing before what they're doing it to.

In closing..don't any of you ever read the wiki? :

Enough talking though..more arguing how bad open source is. It makes me laugh.

[Wyz]

Well I also have to agree with that, if only AGS had dynamic allocation of structs and arrays, and the ability to pass structs to functions then I could do everything I want for OO. Add ternary operators, for statement, switch statement and I'm a happy coder.

But let's continue making monkey laugh.

[Snarky]

I just want to say that CJ has done a great job with AGS, obviously. If he can't devote the same time and energy to it any more, that's unfortunate, but I think his proposal is a good one to ensure it continues to exist and move forward. I'd be in favor of ideally open-sourcing both the editor, compiler and engine, but that doesn't need to happen all at once, and the most important thing is to find a solution CJ and the community are comfortable with.

Keeping it all closed-source and handing it over to some new person/group doesn't sound like such a good idea to me, since it's impossible to guarantee in advance that whoever takes over will have what it takes (including spare time) to successfully maintain and develop the system. I would worry that some of the most talented candidates might be tempted to aim for a really ambitious update (viz. some of the suggestions in this thread) that takes years to develop -- like e.g. AGX and XAGE -- and eventually peters out without ever being delivered. This is the only scenario where I can realistically imagine AGS ceasing to exist.

Of the "big tasks" that handing over some of the AGS development to others might make easier to achieve, cross-platform support is obviously the most important one, and one I think is pretty realistic to hope for. To Calin's list of other desirables, I'd add better translation support (which relies on Unicode support to ever be particularly useful), and perhaps the resurrection of the "zero coding" point-and-click event creation system.

[Calin Leafshade]

I would have bet diamonds on a response to my post from Monkey.

I was fully aware that some of what I said is technically possible but rather inelegant.

The implementation of accessor functions for example is, while functional, a code dump.

But yea, you summed it up in that I'd like AGS to be a full OO language.

It's already kind of halfway there and observes alot of the conventions of OO programming.

And like I said if you basically changed the GlobalScript to an entry point class then most average users would be none the wiser.

The main reason I think these changes would be beneficial is not due to what could be done for ones own game but rather due to the way it would make AGS much more expandable.

I think AGS should be more like a framework rather than just a program.

The editor then simply converts all the stuff defined there (characters, guis and stuff) into the necessary code to generate the classes. In fact I imagine this is already how its done.

And dynamic events could be simulated pretty effectively by essentially allowing the scripter to tie an event to an extender function like this:

Code: ags

Character C = new Character("Bob");
C.OnInteract += CharInteract;


void CharInteract(this Character*){


}

[monkey0506]

  IMO the accessor functions aren't really that different than the C# variants with the exception that they're actually defined outside of the function. If you cut the commentation out altogether it's actually fewer lines than the C# example..if you don't count the braces then it's pretty comparable. But that's really semantics.

As for your ideas on dynamic event linking, I wouldn't mind using extenders as event functions, but like I said, it would require some type of delegate to be defined, which AGS doesn't currently have.

I didn't mean to contest what you were saying, but rather I was just providing examples of existing methodology in AGS that could be utilized to make the transition easier. Basically, why reinvent the wheel? Just create ties to the existing methods (i.e., adding formal support for custom attributes) and then we're good to go. I don't think AGS strictly needs C#-style encapsulation if attribute-encapsulation were formally supported.

I also think that perhaps a base keyword would improve the functionality of polymorphism on custom types (were it to become officially supported).

Beyond that, casting methods would not necessarily be a bad thing. For most non-basic types the cast would just return null anyway. The only point at which I can think of that it wouldn't return null is if you're casting, for example, a Character* back into a Monster instance where the Character* is in fact pointing to the Character object defined within a Monster instance.

Given those two things I think we'd have fully functional polymorphism. It would be very loosely defined in the sense that all functions would be essentially overrideable, but that could be addressed once polymorphism was fully implemented I think.

There's also a million other things that could be done to improve AGS on the scripting side that CJ simply hasn't had the time or resources to do himself. This is why I believe OS would be so beneficial. Even if it wasn't formally adopted into the official version, if I needed a specific functionality (say just for one particular game project) I could just write a custom engine for that game.

Doing this via the plugin API is something I also support, but I think that both the engine and editor APIs could be improved a lot by the move to OS, for exactly the same reasons.

[Knox]

The more I read this thread the more I hope it DOES go open source...people like Khris, Monkey, Calin, GarageGothic, Wyz, Tzachs, Abstauber, RyanTimothy (and many others) etc...could reaaally make AGS even more pwerful, which, in turn, would make better, more awesomer* games!

*awesome + awesome = awesomer:
http://www.youtube.com/watch?v=w355PoLomwE

[Clarvalon]

I would worry that some of the most talented candidates might be tempted to aim for a really ambitious update (viz. some of the suggestions in this thread) that takes years to develop -- like e.g. AGX and XAGE -- and eventually peters out without ever being delivered.

Consider me sufficiently shamed into updating the neglected XAGE development blog.  Progress is slower than I'd like, due to work and family commitments, but I'm still ploughing most of my free time into it.

From a purely selfish perspective, pure ports of the AGS engine to new platforms doesn't help me at all.  But for the AGS userbase it would likely be the best possible outcome from opening up the source.  Exciting times, regardless.

[Snarky]

That's great clarvalon! I didn't mean to imply that XAGE (or AGX) will never be released, just that they're the kind of ambitious undertaking that will unavoidably take a pretty long time to complete.

[Pumaman]

Thanks for all your feedback, guys!

Just to be clear, AGS will NOT be going commercial; the target market for a tool such as AGS is simply too small to make it a profitable business -- which is probably why there is no equivalent commercial product.

Based on the anonymous usage stats, I can tell you that AGS currently has 2260 active users. If AGS went commercial and charged $30, if we work with a generous assumption that 10% of people would buy it, that would bring in $6780. As a lump sum that would be enough to fund development for a few months, but the number of new registrations each month would be nowhere near enough to fund it as a business.

So let's just say, if I went on Dragon's Den and pitched BigBlueCup LTD, there would be only one response -- "I'm out"!!

So, what are we going to do? Well, from your feedback it sounds like people are generally in favour of opening up the source code in some way, so I will prepare a release of the AGS Editor Source Code.

AGS as open-development (not open source) - Inform 7 broadly follows this model. It is still, ultimately, under the control of Graham Nelson (and the code for the compiler is closed source), but there are also a team of developers, working on the UIs (which are open source), standard libraries etc. This might be the best compromise concerning Chris's mistrust of open source licenses and loss of control. This would allow the community to be more broadly involved with the project.

Yes, this sounds good and is probably the license model I will choose.

[Sslaxx]

AGS as open-development (not open source) - Inform 7 broadly follows this model. It is still, ultimately, under the control of Graham Nelson (and the code for the compiler is closed source), but there are also a team of developers, working on the UIs (which are open source), standard libraries etc. This might be the best compromise concerning Chris's mistrust of open source licenses and loss of control. This would allow the community to be more broadly involved with the project.

Yes, this sounds good and is probably the license model I will choose.

Would you decouple the compiler from the editor, in this case?