AGS Is Going Open-Source!

[maximus]

Indeed, the license is not a problem.
The main issues currently are 'who' and 'when'

I'll create a branch in my fork, but i promise nothing From a cursory examination, it looks like the author began this as a dos-based project, then slowly ported it to windows (and hacked in linux/osx support), so the codebase is messy (as CJ indicates in his disclaimer on the ags forums).

I personally think that AGS would be an excellent engine candidate (as it has multiple games, and fits the point-and-click adventure category). As Strangerke indicates though, "who" and "when" are still deciding factors (me having an empty branch means very, very little )

[LordHoto]

I personally think that AGS would be an excellent engine candidate (as it has multiple games, and fits the point-and-click adventure category). As Strangerke indicates though, "who" and "when" are still deciding factors (me having an empty branch means very, very little :P)

I am not into AGS news myself, but isn't AGS still actively developed? Having a engine in our tree which is still actively developed somewhere else is really annoying, since we need to stay in sync with the upstream code and of course in case the upstream code breaks compatibility we would need to decide whether we try to keep compatibility with old versions and integrate the new code in a way which doesn't break compatibility. This will make it a really big project though, since maintaing such a codebase is really a lot of work.

As long as AGS still actively developed I am rather reculant to include it in the official ScummVM source tree for the above mentioned reasons. Of course everyone is free to have its own fork of ScummVM.

[maximus]

As long as AGS still actively developed I am rather reculant to include it in the official ScummVM source tree for the above mentioned reasons. Of course everyone is free to have its own fork of ScummVM.

It seems that AGS breaks functionality constantly, but games that are compiled with a certain interpreter would still run. This would put AGS in a similar position as SCI, which means we'd be able to support a subset of games until newer features are implemented.

I don't necessarily see this as being a bad thing. It just means that ScummVM would likely be a version behind (once the "official" AGS engine is updated, we have to source and can implement changes).

If the engine is unlikely to be accepted though for the reason you indicated, then there's little incentive to do anything with this.

[LordHoto]

As long as AGS still actively developed I am rather reculant to include it in the official ScummVM source tree for the above mentioned reasons. Of course everyone is free to have its own fork of ScummVM.

It seems that AGS breaks functionality constantly, but games that are compiled with a certain interpreter would still run. This would put AGS in a similar position as SCI, which means we'd be able to support a subset of games until newer features are implemented.

In fact SCI is fundamentally different here. SCI is an engine which is not actively developed anymore. Thus there is no upstream development ongoing, which we need to merge into our codebase. Seeing that SCI suffers from regressions quite often due to the fact that some slightly different handling is discovered in different engine versions, that makes me think that with AGS this would be a lot worse. Since AGS is steadily improved/worked on, thus aiming at supporting all versions out there is even more work than with SCI.

I don't necessarily see this as being a bad thing. It just means that ScummVM would likely be a version behind (once the "official" AGS engine is updated, we have to source and can implement changes).

Then again what's the point in having a ScummVM AGS engine, when you could just play the most recent AGS games with a up to date interpreter built from their open source base?

Having an AGS engine in ScummVM does not automatically mean it will run on all of our ports either. Some ports require memory alignment etc. which the AGS source code might neglect, endian issues, which newer AGS versions might not care about anymore, etc. Implementing this properly is a quite a bit of work and might change the engine source code in a fundamental way, which might make it harder to merge upstream changes. If someone worked on a ScummVM engine of AGS we might have more knowledge about that though.

Last but not least AGS might have different requirements on the graphics functionallity etc. which we do not support in ScummVM. I saw some D3D9 shaders in the AGS source after a quick look through it, I am not sure whether they are required or are just for special eye candy. But features like that would never be supported by a ScummVM AGS engine, at least not as hardware shaders, if it's done by a software implementation it might be.

Anyway to get some real knowledge about the AGS requirements and whether ScummVM fullfills those it would be required that someone tries to read himself into the AGS source code and/or tries to create some ScummVM engine out of it.

If the engine is unlikely to be accepted though for the reason you indicated, then there's little incentive to do anything with this.

I don't want to say that there's no chance of an AGS engine getting accepted. But seeing that AGS is also different to all of the other engines we support, since it's actively developed, I am not sure how good the chances of it being accepted are.

Another point is would the original AGS author be fine with it? I know it's released under a open license, but actually I wouldn't feel good if we support it when the original author is strictly against it.

[maximus]

Another point is would the original AGS author be fine with it? I know it's released under a open license, but actually I wouldn't feel good if we support it when the original author is strictly against it.

I think that is probably the most important point to consider before anything else is considered. Chris Jones does indicate that the engine source should be taken as an example of bad programming practice and he's aware it's extremely messy, so maybe a re-implementation could be useful as an exercise in refactoring if nothing else

I'm not sure how tightly integrated the engine is with the AGS editor (if you can debug games while building them that is), or if it's standalone only. I'm going to inquire further with the author (just to at least follow up on whether he'd even want something like this), but I'll leave this issue alone otherwise

[LordHoto]

Another point is would the original AGS author be fine with it? I know it's released under a open license, but actually I wouldn't feel good if we support it when the original author is strictly against it.

I think that is probably the most important point to consider before anything else is considered. Chris Jones does indicate that the engine source should be taken as an example of bad programming practice and he's aware it's extremely messy, so maybe a re-implementation could be useful as an exercise in refactoring if nothing else ;)

I am not sure, but as far as I know there's a fundamental difference between reimplementing and refactoring. Maybe you mean the engine should be refactored first?

[maximus]

I am not sure, but as far as I know there's a fundamental difference between reimplementing and refactoring. Maybe you mean the engine should be refactored first?

The engine "should" be refactored, but according to the author, he'd rather you didn't.

So just to be clear, YES I KNOW that the code is in a bad state. You don't need to tell me that.
I also know that AGS is used by thousands of games with thousands of combinations of game settings and script functions, and that any attempt to refactor the code into a better state is likely to inadvertently break something in someone's game, which is why I haven't attempted to do it yet.

I may have used reimplementation and refactoring a bit ambiguously before, but what I meant was reimplementing AGS as a ScummVM engine would be an opportunity to clean up the current engine code.

I've sent Chris Jones a message, but i'm starting to lean towards LordHoto's conclusion that this may not be the best direction for any development effort atm.

[fingolfin]

The AGS code is indeed a bit messy *cough* (no insult intended, though, I just agree with Chris Jones . Indeed, there is no way this could get included as-is. But since the source is open and available, it would indeed be a good opportunity to refactor it, clean it up and rewrite some of the worst parts.

Comparing this with SCI is off the mark in various ways. As LordHoto already pointed out, AGS is a moving target, SCI is not. On the other hand, for AGS the source is available, maybe even containing some useful comments (I haven't really looked at it yet, so I don't know).

If only Chris Jones would bless a team effort to actually rework and refactor the engine... Then the refactored engine could be part of ScummVM and part of the official AGS, and new development be based on it... and all could benefit.

But if the author's stance really is that he'd rather not want you to refactor the engine (citation needed), then you would have to work *against* him, and in that case I'd rather not touch that code with a long pole. And in that case I really wonder why he bothered to put it under a GPL compatible license in the first place. "Just look, don't touch", really? But maybe / hopefully I am doing him wrong here, this is just based on hearsay.

[grim107]

The AGS code is indeed a bit messy *cough* (no insult intended, though, I just agree with Chris Jones . Indeed, there is no way this could get included as-is. But since the source is open and available, it would indeed be a good opportunity to refactor it, clean it up and rewrite some of the worst parts.

Comparing this with SCI is off the mark in various ways. As LordHoto already pointed out, AGS is a moving target, SCI is not. On the other hand, for AGS the source is available, maybe even containing some useful comments (I haven't really looked at it yet, so I don't know).

If only Chris Jones would bless a team effort to actually rework and refactor the engine... Then the refactored engine could be part of ScummVM and part of the official AGS, and new development be based on it... and all could benefit.

But if the author's stance really is that he'd rather not want you to refactor the engine (citation needed), then you would have to work *against* him, and in that case I'd rather not touch that code with a long pole. And in that case I really wonder why he bothered to put it under a GPL compatible license in the first place. "Just look, don't touch", really? But maybe / hopefully I am doing him wrong here, this is just based on hearsay.

If I recall from the link I supplied in my opening post of this thread, Chris Jones says that he was making it open-source because he doesn't have enough time to work on it as he once did. Rather than let it die, he wanted to give others the opportunity to improve it. He stated on his website that the only reason it was ever closed-source was because he'd once written an open-source program that someone else took credit for. If this is all true, I doubt he'd have any problems with the ScummVM team doing what they want with it.

[maximus]

Just to clarify, my comparison with SCI seems to have been misunderstood (which is likely my fault for not providing enough information). All I meant is that there are variations of the interpreter, and for each major variation, there are minor variations as well. If AGS were implemented, there are (currently) 3 major versions, and each contains minor versions.

I agree with all the points raised by LordHoto and fingolfin as well

I think the ideal (my point of view only here) situation would be as follows:

1. The current version (3.2.1) is reimplemented under the ScummVM framework
2. Chris can provide diffs of the previous versions so that backwards compatibility can be established (assuming that 3.2.1 currently does not contain backwards compatibility)
3. Moving forwards, the ScummVM engine would be the defacto place for engine development (both by the ScummVM team and AGS team)

This would provide a standardized platform for AGS moving forwards. The only issue I foresee (and I think I've mentioned this) is I'm not sure how tightly bound the editor is to the engine. If the editor doesn't rely on the engine, then this proposal may not be all that far fetched ...

[timofonic]

Just to notify there's a forum thread in AGS forums about a wishlist for the AGS runtime and some effort coordination.

http://www.bigbluecup.com/yabb/index.php?topic=43407.0

It could be interesting if interested developers here explain their ideas and impressions in that forum and invite them to participate in this forum too

[monkey_05_06]

I'm not sure why the general consensus here is that AGS is constantly breaking backwards-compatibility with older versions of the engine. As noted in the post in which he opened up the engine source, much of what has been done has been in the effort of maintaining backwards-compatibility. Granted, it's not perfect, but it's a far cry from nonexistant.

Something that should be considered for those unfamiliar with AGS who are looking at it is that a lot of the functions or properties that have been replaced in newer versions still exist, but they are just disabled for use by default. The AGS language supplies the constant STRICT which if defined removes the older functions/properties entirely; otherwise they can still be used just fine. This is actually defined by an editor setting, and is utilized in built-in script headers.

In any case, as has been said both here and in the AGS forums many, many times, porting the engine would not be a simple task. Despite the backwards-compatibility that does exist, there's still the likelihood that certain aspects are just totally broken in newer versions of the engine; a factor which might be exacerbated by refactoring/reimplementation of existing engine code.

I'm not a strong C++ programmer (most of my programming endeavours over the past 8 or so years has taken place within the context of AGS, via modules and such), but I have done some work with it. My programming knowledge is primarily based on the concept of "rip this code apart and see what does what", so the engine source might not be the greatest example for me to do learning from, but I would certainly do research and see how else the same things could be accomplished. In any case, I'm a supporter of both the AGS and ScummVM projects (the latter just by word-of-mouth primarily ), so whatever can be worked out would certainly be great I think.

As for the ties between the editor and engine which was brought up, the way that AGS games are compiled is such that the compiled game resources are appended to the existing engine EXE, which creates the executable game file. The AGS compiler itself is still closed-source, but that's the only real dependency the editor has on the engine. The compiler is written in native C++ which the editor accesses in C# via proxy classes. So, I imagine that wouldn't cause (too many/severe) problems in trying to make the AGS engine ScummVM compatible.

Good luck!

-monkey

[CJ-AGS]

If only Chris Jones would bless a team effort to actually rework and refactor the engine... Then the refactored engine could be part of ScummVM and part of the official AGS, and new development be based on it... and all could benefit.

But if the author's stance really is that he'd rather not want you to refactor the engine (citation needed), then you would have to work *against* him, and in that case I'd rather not touch that code with a long pole. And in that case I really wonder why he bothered to put it under a GPL compatible license in the first place. "Just look, don't touch", really? But maybe / hopefully I am doing him wrong here, this is just based on hearsay.

At this stage, I don't think it's appropriate to try and assimilate AGS into ScummVM. AGS is a separate project that it constantly evolving, and I wouldn't want it to be tied into the scummvm development process.

I would have no objection if the ScummVM team wanted to implement support for running AGS games (but this would obviously be a huge task), but for now I would like to keep ongoing development of AGS as its own thing.

FYI, the only tight coupling between the editor and engine is the debugger, which communicates over Named Pipes. Obviously this would not be required if scummvm simply wanted to run AGS games, since that doesn't require the debugger.

[aryah]

hm, I guess that settles it, negatively.

I would have liked to be able not to depend on (possibly fragile) wine to run AGS games, and perhaps to pull their graphics through the hq3x filters etc, so I think its a shame ...

[Barky]

Well, that assumes that the goal is to make the current and upcoming versions of AGS ScummVM-compatible. (AGS includes HQ3X, btw.)

On the AGS forums, on the other hand, the discussion has focused on getting ScummVM support for the older versions of the engine (2.6 and 2.7), since they are a stable target and since it's actually hard to get older games to run on many new machines. That might make hundreds of games playable with ScummVM (even excluding the relatively small number that use various plugins), some of them quite professional.

The AGS developers who are likely to contribute to the engine have talked about the need for a major rewrite of the engine, and about possibly breaking backwards compatibility. CJ has not in fact said that he's against refactoring, just that he hasn't done it because it's a big and difficult task when trying to maintain that compatibility - which he would apparently prefer. If the engine is refactored, would it make sense to design it with a "ScummVM-friendly" architecture, even if it's not actually merged with ScummVM? That way compatibility would be easier to achieve going forward.