So, the situation is basically like this:
- if AGS engine was supported by ScummVM, AGS games would gain massive multiplatform exposure and zero worries about technical issues. Something this community has been wanting for ages.
Creating a ScummVM-based AGS engine wouldn't lead to "zero technical worries" (cf. other ScummVM engines that are not 100% perfect), although it's true that the ScummVM backend and various platform ports are of high quality and would allow us to piggyback on existing code. But this elides the crucial point that this isn't something that can happen just by saying the word. Someone has to do the work of porting the AGS engine to ScummVM, fixing any resulting bugs, etc. That's a lot of work.
Of course there's no zero worries, that's totally obvious.
OSystem's ScummVM is a framework designed to be quite portable from the practice, and even the coding guidelines in ScummVM are crafted with very high portability in mind.
The work must be done, like it happened with all the available engines in ScummVM. There's not a magical wand to get it. But the same can be said about making AGS portable and having clean code, that's A LOT of work (and maybe recreate the same level of portability can be higher than just reusing stuff like OSystem).
- in turn, ScummVM users would get authoring system that would enable creation of new games. Something that community has been wanting for ages.
Have they? Usually when I see people asking for it on the forums, the devs tend to say it's not something they're interested in. Of course, that's what they used to say about supporting Sierra games, too...
You seem to generalize the opinions of the ScummVM Team, anyway they have a pragmatic thinking. ScummVM is a project consisting of different subprojects, having subteams for each game engine developed. The monolithic thinking that can be applied to a project like AGS can't be applied to the modular ecosystem ScummVM is.
And you agree about Sierra AGI/SCI games. The things changed when people in the project or wanting to join offered their work on those engines. Usually the procedure in FOSS is "release early, release often" and that often means doing experimental forks like the early FreeSCI adaptation to OSystem's ScummVM.
There are people already interested in AGS into ScummVM for different reasons. Some want it for classic games (like DrMcCoy is interested in Yahztee games, for example) to be supported, and that seem something most people in both communities agree to support into ScummVM.
And the only thing preventing this from happening is AGS not being GPLicensed?
No. It's one reason, but not the only one. Probably the biggest reason (as stated from the ScummVM side) is that AGS is intended as an engine under ongoing development, with new features and changes in future versions. The ScummVM devs aren't interested in chasing AGS versions, so the only scenario under which they'd contemplate this is if all AGS development was brought into and taken over by the ScummVM project. Among other things, this would mean adhering to the ScummVM release cycle.
What's the point about ongoing development? That's quite subjective right now, because AGS progress is quite stalled these days...
What's so limiting about the ScummVM release cycle? They are an organized team, they release a new version each six months. I see it a quite standard way like most of the software projects out there, even better than most commercial ones with usually larger release cycles.
How would this affect the development of new features, which might require basic changes in the engine? I don't know, but it's reasonable to think it would complicate it, since you have a backend that must remain compatible against a bunch of other engines too.
I think you are forgeting how FOSS development works these days, using modern computer programming tools like distributed revision control systems like
Git and others like
Buildbot.
* Git makes development quite easier, by making operations like forking and merging easier. Forks are a common practice in most complex projects, because they make the development of experimental stuff a lot easier. When the stuff is done to include it into the main branch, you merge the results back.
* Buildbot is a great tool to constantly test if the modified code is able to be built for different platforms, so it's a great way to check the portability and basic bugs in the code.
Each porter gets sure the engines work as intended on the platform, there's testing periods in the project too.
In any case, it's not clear that the AGS community is prepared to hand over ultimate control over the process and the direction of the engine to some outside group of developers, and it's very uncertain how the two communities could work together. Compared to ScummVM, AGS has a more complicated set of interests to align, since it's made for players on one hand and game developers on the other, for people making traditional adventure games as well as people pushing the technical and genre-defining boundaries, for newbies and non-technical artists as well as experienced programmers, and for rank amateurs and newbies through experienced hobbyists to commercial developers. It also has a long-standing community and social aspect, with multiple channels of communication (forums, blogs, IRC, social networks) and regular meets.
There's the real point! The feeling of property about a project and a community...
Contrary to what it seems to certain people, that's very relaxed in FOSS due to the Copyleft philosophy of collaboration and meritocracy. That's something not well understood to most people outside FOSS. Sense of ownership is considerated as ridiculous for true FOSS developers, because anyone can fork a project to take a different direction.
About experienced developers in AGS, I disagree. I see there are very few developers on this community, but very experienced ones in ScummVM. Computer programming must be quite organized to get proper results and certain ideas that can be amazing to a graphics artist can be totally and ridiculous nonsense to a proper computer programmer because of solid and objective technical reasons.
ScummVM isn't a monolithic project as explained before, but a bunch of projects on a common ecosystem (using a framework named OSystem) and with a common interest in adventure game engines.
Let's go to speculate a bit about how AGS would live inside ScummVM, here's my ideas:
- AGS would have it's own set of developers, the AGS subteam. Those are developers focused on the progress of the AGS runtime, cooperating with the developers of the AGS authoring tools (the real deal of the AGS community, in my opinion).
- ScummVM would integrate the stable versions of the AGS runtime in each 1.x version, having experimental ones in separated forks that can be built automatically by using Buildbot.
- Forums would stay the same, having a link on the ScummVM forums redirecting to the AGS ones.
- At least the information related to the technical part of the AGS runtime would be merged into the Wiki.
Another big issue is the work involved. Converting the AGS engine to ScummVM would involve almost a top-to-bottom rewrite, and you wouldn't have a feature-complete engine until you were done. No one who's competent to do that has volunteered. The alternatives offer a less daunting path forward, since you can fix problems and refactor parts of the code bit by bit and have a fully functioning engine every step of the way. So if we decide to go with ScummVM, we have to hope that someone with the necessary skills materializes and hope they keep working on it until it's ready.
Well, ScummVM developers managed to do difficult efforts like merging tons of engines plus rewriting ones. Some examples are AGI, SCI and Tinsel. But I agree new developers are needed to take this great effort, with volunteer work to get it done.
Refactoring with AGS alone can look easier because of a more progressive way, but the rest of the effort could be less friendly in this environment. There would be needed to prepare the project with high portability in mind if AGS wants to stay relevant in these days, with lots of available platforms in the market.
Anyway, the source code of the AGS runtime is quite rusty and needs a proper refactoring. It's one of the very common mistakes of one-man projects, they lack of coding standards because that person already understands the whole codebase (but that fails in a bigger group, where someone focus more on certain parts of of the projects than others).
Why is AGS not GPL (now that it's already open source)?
Because CJ released it under the Artistic License 2.0, and requested that it be kept under a permissive license. Since it's CJ's work and he spent more than ten years making it, I'd argue that we should respect his wishes.
OK, so you are recognizing the reasons are not pragmatical at all, but dogmatical ones. I agree on this.
But a proper community must follow it's own path, and not get into a religion.
What prevents AGS from being GPL?
Only the choices of AGS developers and contributors, who will presumably be guided by the wishes of CJ and the community.
I agree about the first part, but in the rest you are talking like a preacher.
And what are the benefits and/or limitations of AGS being GPL?
The benefits are that we could integrate GPL components, such as ScummVM or certain libraries. Some also believe that under the GPL license the project would attract more contributors, under the theory that talented open-source programmers prefer strict copyleft licenses over permissive licenses.
The limitation is that GPL imposes a number of restrictions on what you can do (or have to do) with the software, and once you switch to GPL you can't change it to something else (without the permission of every individual contributor, which is usually impossible). It only allows the integration with other GPL (or GPL-compatible) software, and this excludes anyone who isn't prepared to adhere to the GPL licensing restrictions. This can be an obstacle not just for commercial developers, but also for other open-source projects (as the ScummVM-AGS issue demonstrates).
I agree about the first paragraph, there's lot of projects under GPL and that's something objetively verificable. It's quite common open source programmers prefer Copyleft over BSD/MIT style licenses, because it makes their code to be always available and not closed sourced by other individual or company/corporation (like Microsoft and Apple does most of the time, for example).
It hasn't been an obstacle to many commercial developers and publishers already using ScummVM. So what's the problem?
Even ID Software releases their games as GPL too, but the game data still being propietary and need to be bought.
Does GPL prevent commercial usage of software? Would it require open sourcing the scripts in every AGS game?
It doesn't technically prevent commercial use, but the licensing requirements are such that you'd have to provide the source code and allow people to distribute it and compile it freely, so you can't stop people from giving it away. There are business models that work under these conditions, but probably not for commercial adventure games.
Excuse me, but what's wrong with giving back the code to the community? You receive it, then give something back!
Nobody can stop giving away an unauthorized copy, even by using samizdat-like laws like SOPA and ACTA or by an extreme evolved Big Brother approach from the wet dreams of british/american/chinese/iran governments. That relies on the personal ethic of the individual, not on the software license itself.
I believe that the way AGS works now, where the engine and game logic/data are compiled together into one binary, the GPL would technically require the scripts to be open-sourced. ScummVM doesn't work that way: the engine is distributed separately from the game logic/data, so there's no question of its license covering them.
It would be possible to change the way AGS is built so that the engine code and game code are kept in completely separate files, and this would probably address the concern. Though in most cases you would probably still want to distribute the engine along with the game and have it launch the game directly on startup with a single click. In spite of what RickJ says about the absurdity of what a "binary file" is, I think the distinction matters. And I also think an expansive reading of GPL could mean that e.g. distributing an AGS game with the engine as an executable installer could require open-sourcing the game (or at least the installer), though probably no one would be likely to press this interpretation.
I'm sorry, but you and others are misinterpreting the virality of GPL. This has been talked ages and it's just theoric speculation, because commercial game development companies like ID Software already release their games as GPL and we all agree they have a lot of lawyers to check this kind of things.
It's quite possible to extract the games of the already available games from the AGS bundle, that's not a problem at all.
About using an installed or bundler, that's quite possible to do without breaking the GPL. It has been done with other projects.
What I think would be a more realistic concern would be that a game developer couldn't make changes to the engine that relied on closed-source APIs. For example, I don't think the Steam plugin that monkey and Dave made for the Blackwell games could be integrated into a GPL version of AGS. (And I believe I remember that the ScummVM team was unwilling to create a plugin API for the engine to link to separate DLLs, partly, I guess, because it's platform-dependent.)
That's something that need to be discussed, as Steam is closed source and having a strict license. I would like to know the opinion of other people on this matter, it looks a quite interesting situation to know for me.
