About merging with ScummVM, open-source and AGS

Started by johnadv, Sun 02/12/2007 22:27:54

Previous topic - Next topic

johnadv

Hello.

There are people on ScummVM forums asking a lot about ScummVM supporting AGS. Just want to make people on the AGS community say their opinions about this, and if the developer of AGS say his opinion related to this long question by user from both communities (ScummVM and AGS).

I see ScummVM Team has nothing against a future merge of AGS into ScummVM if the author agrees. They just not want to try to "catch in" the official AGS implementation all time

Quote from: sev
First thing you need to do is talk to AGS author. We do not want to do anything in this regard without his permission. Then, it would be much easier if he would hand his source code and allow it to use under GPL.

Quote from: eriktorbjorn
Neither of which is likely to happen, according to the aforementioned AGS FAQ.

Quote from: md5
If you get permission from the author of AGS then that's great, but on the other hand he distributes AGS as closed source for his own reasons, and I'm not sure how his work could be tied into an open source project, unless he wants to open some parts of the AGS source code to the public (which he is reluctant to do).

Quote from: sev
Quote from: SSH
I can look the FAQ up in the wayback machine and find it identical in 2002
That's understandable. But since he did not update it, we just assume that those statements are still valid.

Quote from: sev
Quote from: SSH
I guess there must be some kind of grudge against AGS people or something here.
Not at all. We point to AGS on a regular basis as to a reliable and most up-to-date way to create adventure games without paying any kind of royalty. From the other hand we regularly, perhaps each other month receive a request about adding AGS to our engines collection. Whereas we ourselves do not see any problems with it from technical side, our policy is not to merge maintained projects without author's permission and if possible, collaboration. That is, we got FOTAQ, Reinherit, Gob, Sarien, TrollVM, CinE, CruisE, Igor engines only after they were either completely abandoned by their authors or their authors joined our team. And even in case of abandoned projects we always contact their authors beforehand.

So, take a look at AGS situation now. We have their FAQ. We see requests about merge with ScummVM both on our forms and on AGS forums as well. Still we saw no reply from the AGS author. This leads us to conclusion that he does not want it. Simple as that.

Again, we have nothing against if Chris will switch to our infrastructure and join our project. It will make great number of excellent games available to bigger masses and I am sure will make AGS even more popular. (Consider iPhone ;) ). Of course, it will require some tweaks, as, for instance, current AGS implementation supports external modules via precompiled DLLs which is not portable, but all those questions could be resolved. So talk to Chris :)


Eugene

Quote from: sev
Quote from: fingolfin
Still, to once more reiterate: You will have to fork ScummVM if you want to make a AGS engine, as we won't accept one, unless the AGS author explicitly gives written permission to do so. Even then, personally, I would be very reluctant to accept such an engine unless the AGS author goes even further and starts to collarborate himself. The problem being that AGS is actively developed, so if we tried to implement a second version of the engine from scratch, we'd always play "catch me" with him while trying to achieve compatibility.

Seconded. I.e. as I told above, we would not object if Chris himself will decide to switch development to the new platform. He will definitely benefit from that, and even I think he will get more engine developers from AGS community. But the on-going efforts of a second runner following AGS development is not an option.

Eugene


Here is the forum thread in ScummVM:
http://forums.scummvm.org/viewtopic.php?t=4294&start=60#29373

Here are others forum posts like this:
http://forums.scummvm.org/viewtopic.php?t=4458&highlight=ags


You can see conversation from devs (it seems everything was said before, but to proving they have nothing against AGS becoming part of ScummVM) : http://sand.enderboi.com/scummvm/log.php?log=scummvm.log.02Dec2007


Regards.

Rui 'Trovatore' Pires

QuoteThe problem being that AGS is actively developed, so if we tried to implement a second version of the engine from scratch, we'd always play "catch me" with him while trying to achieve compatibility.

Not even going into open-source/closed-source stuff, this quote alone suffices as an argument.

Regardless, you might find it more productive if you did as good a search in these forums as you did over at ScummVM - this is by no means a new issue, and I'm sure there's been lots of discussion already.
Reach for the moon. Even if you miss, you'll land among the stars.

Kneel. Now.

Never throw chicken at a Leprechaun.

johnadv

Quote from: Rui "Trovatore" Pires on Sun 02/12/2007 23:32:35
Regardless, you might find it more productive if you did as good a search in these forums as you did over at ScummVM - this is by no means a new issue, and I'm sure there's been lots of discussion already.

I tried but found a lot of threads about SummVM on PocketPC and posts of uninformed people thinking ScummVM was like an universal adventure game emulator, or just references to ScummVM but not directly related to this idea/concept.

It could be fine if you find some interesting thread about this and putting in this thread the URL.

scotch

This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

johnadv

Quote from: scotch on Mon 03/12/2007 00:21:55
This makes a lot of assumptions about how the AGS source code works and how well AGS would fit into the SCUMMVM scheme.

Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none. You couldn't take a snapshot of the code and support even 20% of AGS games with it. A widely compatible AGS engine would require months of dedicated work and lots of reverse engineering, even if the AGS source code was released.

It's mainly for that reason I don't think SCUMMVM compatability is a good idea. Users would expect most AGS games to run, when they probably wouldn't.

That's not to say I think open sourcing the engine would be a bad idea, if CJ wanted to do it. It would make the existing ports easier to maintain for a start, as well as allow people to make their own if they're desperate for that.

But I'm sure the source code of all AGS versions are stored by CJ, so maybe it's possible to support all AGS versions in some way after doing research analyzing the differences between different AGS versions.

I'm sure this is a task os some months as minimum, but I personally consider the final result quite interesting. It would allow to play AGS games on a lot different platforms, with the actual platform maintainers of ScummVM doing the work and maybe having a few new devs for the AGS engine like others said.

RickJ

#5
Boy, I hope something can be worked out.  I would really like to see this happen. 
[edit]
Btw johnadv, thanks for comming here and engaging us in this discussion.   I hope CJ will consider cooperating with you in some way that would allow SCUMMVM to support games made with AGS.  I would think that if the effort succeeded that many of our portability issues would simply vanish.   Anyway, it's something I would certainly support. 

I wonder has anybody ever considered defining an intermediate XMLish game language?  Game development systems, such as AGS, could export to this language and runtime engines such as yours could either run intermediate language directly or have a compiler that converts the intermediate language to a native form? 

SSH

After discussing this with scotch on IRC, it seems to me that a Flash backend for AGS would be a much better idea...
12

johnadv

#7
Quote from: RickJ on Mon 03/12/2007 08:36:15
Boy, I hope something can be worked out.  I would really like to see this happen. 
[edit]
Btw johnadv, thanks for comming here and engaging us in this discussion.   I hope CJ will consider cooperating with you in some way that would allow SCUMMVM to support games made with AGS.

Well, I think you are a bit confused. I'm not a developer, just found an interesting topic and created a forum thread to debate it.

About finding help for this possible thing, it's just a matter of ask to the community. I'm sure as AGS being one of the most popular tools for creating adventure games, there will be some volunteers out there for help with the effort of porting to the ScummVM infrastructure.

SSH: I don't understand your decision of a "Flash backend". Can you explain it a bit more? I inform you Adobe Flash is not supported by all devices and there could be certain feature and performance limitations (limited versions of Adobe Flash for slow devices, old versions, not enough CPU...). Compiling AGS to Flash could be a difficult task, there are certain Flash generators but those are open-source and being unsure of the flexibility of them.

EnterTheStory (aka tolworthy)

What about a two speed AGS? Kind of like Linux has a stable kernel plus all kinds of extras. Each AGS function could be flagged as either 'core' or 'non-core.' Non-core has the latest changes plus Windows bells and whistles, Core is the essentials.

Has anyone contacted Shawn Walker about this? He made a player that works in Linux, without sacrificing either CJ's time or secret codes. Could he be persuaded to use this port as the basis of "AGS-lite"? This would ensure compatibility with at least one generation of existing games.

Imagine it! AGS games that work on Windows and Linux and the Mac and Palm and DS and WinCE and PSP and Dreamcast and Solaris and BeOS and Amiga and...


.... Wow!!!!!!!!!!

Radiant

Quote from: scotch on Mon 03/12/2007 00:21:55
Each version of AGS engine can only run games made with a narrow window of previous engines, sometimes a few releases, sometimes none.

I don't think that this statement is actually true. It is obviously the case that each newer version has more options (and less bugs) than each earlier, but overall the backwards compatibility is pretty good (barring a few huge paradigm shifts like 2.72 -> 3.0). So I do believe that writing an emulator for 2.72 would be able to play nearly every AGS game released to date. But perhaps Chris could shed some light on this?

LimpingFish

It seems an awful lot of work for (imho) little benefit. ScummVM is an excellent program, but surely taking the time and effort to try to incorporate every version of the AGS engine would be counter-productive.

Wouldn't it be easier to figure out a way for the newer AGS engine to interpret older (dos engine versions, etc) games?

Or, similar to what SSH said, some sort of "universal" frontend/backend type deal, that could emulate, for want of a better word, the earlier versions of the engine?
Steam: LimpingFish
PSN: LFishRoller
XB: TheActualLimpingFish
Spotify: LimpingFish

FSi++

Quote from: LimpingFish on Mon 03/12/2007 19:07:25
Wouldn't it be easier to figure out a way for the newer AGS engine to interpret older (dos engine versions, etc) games?
The reason of going ScummVM is not to have one program to play ALL and EVERY AGS game; but rather - to be able to play at least some AGS games on more platforms (linux, windows and mac are ok - but ScummVM has many other frontends, including handheld devices, to quote the developers,
Quote from: ScummVM
Windows, Linux, Mac OS X, Dreamcast, PocketPC, PalmOS, AmigaOS, BeOS, OS/2, PSP, PS2, SymbianOS/EPOC
)


Quote from: LimpingFish on Mon 03/12/2007 19:07:25
Or, similar to what SSH said, some sort of "universal" frontend/backend type deal, that could emulate, for want of a better word, the earlier versions of the engine?
Which will become an utter and complete rip off* ScummVM, set in AGS world.

* Oh, come on, that's classical Anselmo quote.

Pumaman

#12
ScummVM is an open-source project, AGS is not. Therefore, it wouldn't really be possible to incorporate the AGS code into ScummVM, since it's all open source.

Why don't I make AGS open source? Well, one good reason is this from the FAQ page:
(2) The AGS file formats are proprietary to make it harder for people to "hack" other people's games. If the source code was available, it would be easy for someone to write some sort of de-compiler for use with other peoples games.

I may make the AGS 3 editor source code available at some point if it would be beneficial, but currently I have no plans to release the engine code.

Quotedon't think that this statement is actually true. It is obviously the case that each newer version has more options (and less bugs) than each earlier, but overall the backwards compatibility is pretty good (barring a few huge paradigm shifts like 2.72 -> 3.0).

The usual reason why the engine stops supporting old versions is when the game file format changes significantly. To keep the EXE size manageable, the engine only includes the code to load the current file format; whereas the editor has all the code to load previous versions of the game files as well.

Electroshokker

Quote from: RickJ on Mon 03/12/2007 08:36:15I wonder has anybody ever considered defining an intermediate XMLish game language?  Game development systems, such as AGS, could export to this language and runtime engines such as yours could either run intermediate language directly or have a compiler that converts the intermediate language to a native form? 

Actually, this seems like a reasonable option. Let's consider:

- SCUMMVM defines a universal XML game language (In which case I urge them to take a good hard look at the SLAGE engine, which allows developers to make games in pure XML, and is pure open source. (java) Downside of the SLAGE engine is it's still in development and a lot of work before their game editor hit beta stage. However, the actual engine pretty much works, according to the developers.)

(so if those friendly folks at SCUMMVM would be willing to spend some time helping out their development team, I'm sure they can get a win-win situation there.)

...ehum, anyways, while they are off doing that, Chris does what he does best, that is improve the AGS engine, bring tons of new dazzling features, solve bugs, and make AGS better then ever  ;D

With me so far? Ok, now when this universal XML game language (slage-based or not) is developed by SCUMMVM, they can (nicely, of course) ask the developers of game engines (such as AGS) if they would be so kind to create an export function which exported their game to this new universal XML game language.

So at that point in time, Chris can still decide to build such an exporter or not.

The result:

- SCUMMVM can offer a universal XML game language (open source) to game engine developers and offer their multi-platform and other benefits as a "selling" point, so they build an export function

- AGS keeps getting better without being bothered with this stuff for a while (seriously, I like cross-platform, but I REALLY, REALLY like the new features and bugfixing a whole-of-a-lot more.), and keeps it's options open.


...so anyhoo, just my 2 cents.

scotch

I did mean the engine, yes, I'm actually not sure if it's more compatible these days but certainly when I've wanted to run an old DOS game I've had problems matching Windows engine versions unless the version was very close.

An intermediate XML format for adventure games sounds unworkable to me, without strictly limiting what games are able to do. It's fine if you can define a standard adventure game API, a standard graphics system, audio systems, as well as a standard scripting language. Can't see that happening. It's hard enough to standardise web page development even when the browsers are all implementing the same specs. Game engines have entirely different capabilities, and that's a good thing for games.

CJ, is that really the only reason now for the engine being closed source? It seems like the number of people who would care about their game being decompiled is much smaller than those that'd like to be able to have more ports or to compile in plugin functionality for other OSes and stuff. Any determined person can rip graphics and audio out of a game without a decompiler, and the scripts are irretrievable anyway, iirc. If it's also that you'd rather work on your own project by yourself that's perfectly reasonable.

Pumaman

QuoteWith me so far? Ok, now when this universal XML game language (slage-based or not) is developed by SCUMMVM, they can (nicely, of course) ask the developers of game engines (such as AGS) if they would be so kind to create an export function which exported their game to this new universal XML game language.

That's all well and good for defining inventory items, characters, etc ... but what about the game scripts? Chances are that this "universal language" would have a different set of script commands to existing systems like AGS, and probably a different scripting language as well; converting that all over would be a mammoth task and probably impossible in several places.

As scotch says, it's pretty much an impossible task.

QuoteCJ, is that really the only reason now for the engine being closed source? It seems like the number of people who would care about their game being decompiled is much smaller than those that'd like to be able to have more ports or to compile in plugin functionality for other OSes and stuff.

Well, the number of people argument doesn't really work here because there are of course a smaller number of people making games than playing them. And if releasing the AGS source code meant that people stopped using AGS to make games because they didn't want people to be able to easily rip the resources, then you end up with an open source game interpreter with no games for it.

Of course a determined person will be able to rip anything they like, but as we've said before it's all a matter of effort. As long as it's reasonably difficult, it should stop random kids ripping a room and some characters and making unauthorized sequels/parodies/etc.

This may not sound like a major issue, but actually it is. I remember last time we had a discussion about this, there was an almost unanimous feeling that AGS games should not be decompilable; and that if the code was open source then people would be likely to move away from using AGS.

You've got to remember that ScummVM is largely used to run classic games from the good old days, which is a different kettle of fish to running brand new games like those made with AGS.

scotch

Hm, I had not come across all these developers worrying about protecting their assets that much. I'm sure most would rather it was harder than easier to rip out content, if that's considered in isolation, yeah... but I'd question if they have seriously weighed up the issue.

A lot of modern commercial downloadable games I have store their data files in jpegs, pngs, xml files other easily readable formats. If it's not a big problem for them, why is it for any of us? Would any developer of a decent AGS game seriously consider not using AGS if there was a potential risk of an automatic graphics/audio ripper being made?

This is what I can think of:

Downsides:
    Would make unauthorised fan games somewhat easier to make, if someone used the source to make a ripper.
     A tiny minority of players might use the ripper to look at the later parts of the game without playing it.
    The engine source could get forked or otherwise confused with bad contributions.

Upsides:
    People can port the engine, and maintain the current ports.
    Plugins could be compiled in to the engine for other operating systems.
    This whole potential scummvm emulator deal is more possible.

The downsides seem pretty small to me, and two are dependent on someone actually making a ripper. The third is not a major issue as long as sensible controls are in place.

Shane 'ProgZmax' Stevens

QuoteWould any developer of a decent AGS game seriously consider not using AGS if there was a potential risk of an automatic graphics/audio ripper being made?

Hmm, tough call.  On the one hand I would say I'm greatly against someone having easy access to all my work, but on the other I'd like to see AGS running on a GP2X and open to outside improvements/tweaks.  I don't think making the engine open source would hurt commercial developers since they will naturally need to copyright and protect themselves like any other developer, but freeware authors who might take pride in their work and demand a little respect for their effort?

I'm not really sure.  I like the idea of being able to contribute to builds by making bug fixes and additions and let a wider audience play my games, but then I also like the idea of a secure platform.  I definitely think I would be more for open source if CJ wasn't so committed to improving his engine.  :| 

Electroshokker

Quote from: Pumaman on Mon 03/12/2007 22:35:47
That's all well and good for defining inventory items, characters, etc ... but what about the game scripts? Chances are that this "universal language" would have a different set of script commands to existing systems like AGS, and probably a different scripting language as well; converting that all over would be a mammoth task and probably impossible in several places.

ah, but here's the genius, you DON'T convert scripts. You just pass them over. An API then handles the script. (all other stuff should be easy enough to export)

so you would get something like: (oversimplified)

<game="A great adventure">
    <character/>
    <room/>
    <room>
         <object/>
         <hotspot/>
         <script>
              <script-type="AGS">
              <content> Character.Say("Something smart"); </content>
    </room>
</game>

Quote from: Pumaman on Mon 03/12/2007 22:35:47As scotch says, it's pretty much an impossible task.

a bit difficult, yes, but impossible, no;

It mainly depends on the way the "universal" XML game language is built, and on how much functionality is put in the API.

Note: The conversion would have to happen in the editor (no converting a compiled game), so it'll be the game developer's responsibility to choose whether to convert it or not and if he/she's using extra plug-ins, module code and what not, the conversion might not even be possible.

The developer would still have to check after the conversion if everything still worked as intended.

The only open source bit for the game engine developer to write here is the game script API, of which the most obvious functionality could be written by others (who get the information of what does what from the AGS help file, their own experience and just plain asking you, Chris)

Quote from: Pumaman on Mon 03/12/2007 22:35:47Well, the number of people argument doesn't really work here because there are of course a smaller number of people making games than playing them. And if releasing the AGS source code meant that people stopped using AGS to make games because they didn't want people to be able to easily rip the resources, then you end up with an open source game interpreter with no games for it.

Of course a determined person will be able to rip anything they like, but as we've said before it's all a matter of effort. As long as it's reasonably difficult, it should stop random kids ripping a room and some characters and making unauthorized sequels/parodies/etc.

This may not sound like a major issue, but actually it is. I remember last time we had a discussion about this, there was an almost unanimous feeling that AGS games should not be decompilable; and that if the code was open source then people would be likely to move away from using AGS.

You've got to remember that ScummVM is largely used to run classic games from the good old days, which is a different kettle of fish to running brand new games like those made with AGS.


In that regard, you could have a "proprietary" game format which is compiled/stored differently then the regular "open-source" format. (I recommend keeping the current format as "proprietary", so all games to date remain closed, and you'll get no complaints from commercial AGS game developers)


Anyways, I'm NOT advocating you should spend a lot of time on this, Chris, in fact, I'm saying you shouldn't.

While many would want ScummVM to be able to run all AGS games to date, I don't think that's an achievable goal, or even a desired one.

AGS runs just fine on windows, and if you want to play an old DOS version, use a DOS emulator or something;

The ONLY reason why you should even consider allowing SOME games to run under ScummVM, games where their own developer chooses to do so, is it's cross-portability.

scotch

So the idea is to have an standard description of rooms and characters, like what already exists in game.agf, but with all the remaining binary information in it too, so some rewritten engine could load this data easily. And this other engine implements the entire AGS script engine, and AGS API?

I'm not saying it wouldn't help things along a little, but it seems like if you're reimplementing the entire AGS engine, loading the AGS file formats is one of the less complicated things on your list. If I was doing it I'd want to go that extra mile because loading the original formats means compiled games can be made to run too.

SMF spam blocked by CleanTalk