AGS Is Going Open-Source!

[RickJ_Ags]

I'd like to share some thoughts I think may be helpful to this discussion.

AGS consists of a game Editor tightly intergrated with the runtime Engine. The good thing about this is that compiling a game usually takes a barely perceptible amount of time, making it easy make changes and test frequently. I think this fact is at the root of most if not all of our blathering (self and other AGSers included) about this that and the other thing.

Now suppose we were to consider the middle point; that is the output (perhaps in some other form) produced by the editor? If ScummVM were able to understand the editor's output or if the editor could export to a form ScummVM could understand, then AGS games could be run on and distributed with ScummVM without any licnese problems - right?

What if both communities were to cooperate in developing a game specification language or format that was compatible with both ScummVM and the AGS editor? Instead of porting older version of the AGS engine to ScummVM it would only be necessary to create a converter that would input the older game scripts and convert them to the new format.

Going forward it would only be necessary to collaborate on new language features rather than trying to integrate disparate codebases.

There is a related thread on AGS Forums started by Monsieur OUXX in the General Discussion section. Sorry no link - spambot don't allow it.

Does anybody else think his may be a sensible way forward for both communities that would make the best use of our combined resources?

[da1writer]

Well it seems plausible but the scumm team just doesn't seem to want to chase this pipe dream with evidence of this thread being in the junk yard portion of the forum and banning people who bother to suggest about the PSP ported model as being proof that it is possible.

Right now, AGS seems to have an android port in the making but who knows how far that is coming along, also as stated above, there is a PSP ported fully finished if you want to play stuff like Six Days a Stranger on the go...

Simple answer: No, won't happen - the scumm devs have other things to attend to...

[sev]

da1writer, thanks for speaking in behalf of ScummVM team, and no, we do not ban anyone on reasons besides Rule #0.

As of the AGS development, anyone is welcome to come with an engine ported to our framework and according to our standards. Current AGS source code is a mess and has to be refactored heavily. This will lead to two incompatible codebases and if AGS community will continue developing original AGS engine, it will turn into an endless race for the compatibility.

Thus it was told that a feasible approach would be to port 2.x branxh which will definitely not be developed anymore. So far the sources weren't published and such discussions are pointless.

And of course, once the engine is ported to ScummVM and if the community decide to develop the engine on top of our codebase, we're fine with that, however in this case development will be ruled by ScummVM's 6 months release cycle.

I personally hope that AGS 2.x sources will be published because there is number of developers interested in tackling it, and even there is an idea to turn it into a GSoC project if we be accepted this year.


Eugene

[eriktorbjorn]

Instead of porting older version of the AGS engine to ScummVM it would only be necessary to create a converter that would input the older game scripts and convert them to the new format.

Maybe I'm misunderstanding, but wouldn't that mean having to track down the authors of the older games, ask them if they still have the game scripts, and convince them to recompile for the new format? And then do it again, if it turns out the converter had a bug in it? (And then having to explain to the ScummVM users why the old format games they downloaded don't work, though if those files are easily identified that could be automated, I guess.)

[Endres]

But doesn't the linux runtime also provides support for older AGS 2.x games? The authors would not have to compile it again for AGS 2.6 I think, I have read it in this topic. Doesn't the PSP Engine also support 2.x games?

I don't think that a "converter" is really the best thing which can be done, as it should be way more performant to only include the engine into ScummVM, because the games itself do contain the game data in a portable format, and so I don't get why this should be reformatted again? Also the converter has to be updated if there are more features in AGS and so this game format in between would extend, and so the ScummVM implementation of our format would have to worked on. So it would be actually double work for one thing. For me it is essential to support games as is, because this is what ScummVM stands for. It would be okay to put the engine into a different source code tree, while AGS is not exactly what ScummVM wants, as these games would run on current machines without any effort, the only problem is to make it compatible to many more systems than only Windows, Linux and Mac. And for this I think ScummVM is the best way to do it, because it has the essentials for a large amount of systems. And why shouldn't the complete AGS Engine then (perhaps with an optional compile option) be included in ScummVM?

One thing is, that we would need a coder who can actually do this and is experienced in ScummVM code. So why should not the Scumm devs do this, or other people who could help? Maybe we need a ScummVM fork and every skilled coder could contribute there. I think, that this may be the best solution, to work together.

If that AGS code is such mess, than we could work on it. And if there is sometimes a new AGS 4.x released, then we have to look at it again, and work again on this mess. But isn't the goal to get it working? So I think we should take this effort and simply do it.

[eriktorbjorn]

But doesn't the linux runtime also provides support for older AGS 2.x games? The authors would not have to compile it again for AGS 2.6 I think, I have read it in this topic. Doesn't the PSP Engine also support 2.x games?

My impression, admittedly based on just a few games, is that newer 2.x versions aren't always quite backwards compatible with the older ones. The games I tried were playable - even completable - with the newer runtime, but in some of them there would be some slight glitches.

I also had problems with the Linux runtime getting the colours wrong in some games. The red and blue colour components were swapped, or something like that. (I eventually got around that by compiling a custom version of the Allegro library which swapped the components back, but that was a quick and dirty hack.) I don't know if that was also related to AGS versions, or if it was just a bug in the Linux runtime, or possibly in Allegro itself.

[Endres]

I don't know if that was also related to AGS versions, or if it was just a bug in the Linux runtime, or possibly in Allegro itself.

Was a known allegro bug, I suppose. Well, in my own Allegro apps I can comprehend that.

[timofonic]

I'd like to share some thoughts I think may be helpful to this discussion.

AGS consists of a game Editor tightly intergrated with the runtime Engine. The good thing about this is that compiling a game usually takes a barely perceptible amount of time, making it easy make changes and test frequently. I think this fact is at the root of most if not all of our blathering (self and other AGSers included) about this that and the other thing.

Now suppose we were to consider the middle point; that is the output (perhaps in some other form) produced by the editor? If ScummVM were able to understand the editor's output or if the editor could export to a form ScummVM could understand, then AGS games could be run on and distributed with ScummVM without any licnese problems - right?

What if both communities were to cooperate in developing a game specification language or format that was compatible with both ScummVM and the AGS editor? Instead of porting older version of the AGS engine to ScummVM it would only be necessary to create a converter that would input the older game scripts and convert them to the new format.

Going forward it would only be necessary to collaborate on new language features rather than trying to integrate disparate codebases.

There is a related thread on AGS Forums started by Monsieur OUXX in the General Discussion section. Sorry no link - spambot don't allow it.

Does anybody else think his may be a sensible way forward for both communities that would make the best use of our combined resources?

Where are the license problems? Artistic License 2.0 can be relicensed to GPL

The standarized game file format specification idea is interesting, but not feasible to support older AGS games. There's a need to call all people doing AGS games to save them in the new format, that's not gonna happen most of the time (missing people, not able to contact, no interested on it...).

It can be a nice concept for AGS 4, so others can implement it. There can be implementations like an HTML5 player, or players for commercial releases over propietary platforms like XBLA.

I suggest to interested people over ScummVM Team to check the AGS forums thread and explain some stuff there, specially related to source code licenses and such... http://www.bigbluecup.com/yabb/index.ph ... =43383.160

[SuperDre]

The only thing this discussion should be about it reimplementing the ability to being able to support the old AGS games, there is no need to talk about creating a new game-engine as that's not the purpose of SCUMMVM (there are enough game-engines in SCUMMVM which you already can use to create new games). Also it's no use to try and get the current developers to do that, as they have their hands full with the current engines that are already in SCUMMVM. If you are so set on wanting a new engine in SCUMMVM for this purpose, then go and create it yourself and join the SCUMMVM developers circle...

[timofonic]

The only thing this discussion should be about it reimplementing the ability to being able to support the old AGS games, there is no need to talk about creating a new game-engine as that's not the purpose of SCUMMVM (there are enough game-engines in SCUMMVM which you already can use to create new games). Also it's no use to try and get the current developers to do that, as they have their hands full with the current engines that are already in SCUMMVM. If you are so set on wanting a new engine in SCUMMVM for this purpose, then go and create it yourself and join the SCUMMVM developers circle...

Well, there's important limits to those engines...

AGI engine is not as featured as later 90s adventure games, like Broken Sword and such. Some of those engines has limited interactivity or color depth. SCI has an editor but even not supporting 256 color and it uses early AGI-like versions of the engine. SCUMM had a compiler, but it got abandoned early. The engine used in the Broken Sword 2.5 authorized fan sequel can be a nice start (it uses LUA and seems to have modern features too), but it seems to need some optimizations and probably would not work on certain slow platforms too.

Also the tools for game development aren't so evolved as AGS ones too.

I think an engine supporting new indie/homebrew adventure games would be a great addition to the project, because it can make the project even more known and also promote the genre itseld. There are design similarities to classic adventure games, as you can see most of the time in new 2D point & click games

But at same time, I agree that's a task mostly targeted to newcomers. There's a need of new motivated and dedicated programmers for stuff like this.

[MusicallyInspired]

SCI has an editor but even not supporting 256 color and it uses early AGI-like versions of the engine.

Um, what?

[Endres]

Well, I don't think that it is so hard to support older games as is, as we can see clearly in the PSP Port of AGS. Tested multiple AGS 2.6 games with it and it works without problems.

[eriktorbjorn]

Tested multiple AGS 2.6 games with it and it works without problems.

If I remember correctly, the minor issues I ran into when trying to run old games with a newer 2.6 runtime were:

1) In "5 Days A Stranger", the inventory window wasn't populated correctly. I think all items were drawn in one column instead of several.

2) In "7 Days A Skeptic", the maps of the ship wouldn't show your current location correctly.

My mind could be playing tricks on me, but at the very least it was that kind of minor glitches.

[timofonic]

SCI has an editor but even not supporting 256 color and it uses early AGI-like versions of the engine.

Um, what?

I was talking about SCI Studio, that mainly supports SCI0 only.

Maybe I'm wrong, but early SCI versions seems more rudimentary compared to newer ones (so I did that comparison).

And this tool has the source code repository not updated since over 16 months ago.

[Collector]

There are significant differences between the AGI engine and that of SCI0. KQ4 is a good example to see these differences as it was released in both versions. Don't confuse the two just because SCI0 was EGA.