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 (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.
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.
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.
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.
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.
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?
After discussing this with scotch on IRC, it seems to me that a Flash backend for AGS would be a much better idea...
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.
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!!!!!!!!!!
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?
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?
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.
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.
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.
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.
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.
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.
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. :|
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.
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.
I agree with a lot of what Electroshokker says. The real goal is to give developers the choice of releasing their games to other platforms. I would think that it's not too difficult to do as Electroshokker suggests and be able to target either a proprietary or an open version of the runtime engine. The only things that would necessarily be different are the data structures used to read and write the game file(s). Isn't that all we're really talking about, just having two different file formats?
Just my 2 cents ...
Why don't we call a MASS developer vote. If the majority agrees then fair game, open source it is. If not, then we continue down the path we always have.
Cheers,
Paul.
Quote from: subspark on Tue 04/12/2007 07:54:15
Why don't we call a MASS developer vote. If the majority agrees then fair game, open source it is.
Because that is CJ's decision, and he is in no way bound by any democratic vote on the subject? Frankly I find this voting suggestion a little silly.
We're a community aren't we? I never said it wasn't CJ's decision, Radiant. Quite frankly, my suggestion was not silly and it was directed at Chris anyway. If Chris wants to hold a vote then I'm in.
AGS is a tool for the developers. As a community, Chris relies on our feedback in order to progress forward. If you feel that this is not the way things should be done then I'm afraid your in the wrong forum.
Anyhow, I feel comfortable with risks that lie with an Open Source engine. My personal opinion is that if people choose to take apart my game and rip graphics so be it. If a rip off version draws attention away from my game, it wasn't that good of a game in the first place and neither was it's advertising. I openly welcome an open source engine knowing the platform independant release options it would give developers. That of course is how I feel and I don't speak for everybody else...Which naturally, is why I suggest Chris holds a mass vote.
Paul.
Specifically for a GP2X version, I would think that since it runs Linux and Allegro has been ported to the GP2X then it wouldn't be too hard to move the Linux engine to the GP2X anyway.
Quote from: subspark on Tue 04/12/2007 09:28:05
AGS is a tool for the developers. As a community, Chris relies on our feedback in order to progress forward. If you feel that this is not the way things should be done then I'm afraid your in the wrong forum.
"Relying on feedback" is a far cry from "being bound by a popular vote". Given that you don't seem to have contributed to any games, it is quite easy for
you to demand that it be open sourced (you're demanding a sacrifice of others that you are unable and unwilling to make yourself), but that doesn't mean anybody is going to comply with your demands. Neither am I going to comply with your completely idiotic suggestion that I shouldn't be here.
QuoteGiven that you don't seem to have contributed to any games
Well you can start with Tribes Vengence, Bioshock and Monster Madness.
I may not have published any AGS games yet but I do believe I know what I am talking about when it comes to development.
Regardless of how many games I have published here I am as valuable as any other member. I'm sorry but I choose to ignore your petty backchat Radiant. Your starting to bother me and I have little time for children's games. Demanding is a far cry from suggesting that AGS should be open sourced. I don't remember demanding anything here. Might I finally suggest that you use a little more respect when posting to people you've had no previous encounter with. You can never know what is going on in peoples lives, Radiant and I'll admit that I am just that little bit sensitive to overactive criticism and pompus attitudes.
This rude little squarrel of ours is over.
Paul.
EDIT: Apology to the members of this forum. This argument was started by me and I'm sorry I let myself become angry over such a minor thing. I have apologized to Radiant and will try to keep thicker skin next time.
Quote from: subspark on Tue 04/12/2007 11:39:18
Well you can start with Tribes Vengence, Bioshock and Monster Madness.
I may not have published any AGS games yet but I do believe I know what I am talking about when it comes to development.
Be that as it may, you obviously do not know what you're talking about when it comes to civility. Or, for that matter, spelling.
Here's a thought: stop suggesting that people leave the forum because they disagree with you, and you won't have a "squarrel (http://www.urbandictionary.com/define.php?term=squarrel)".
Time to grow up, dude.
on the XML subject:Quote from: scotch on Tue 04/12/2007 07:07:04
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?
No. That's not quite what I meant. Let me clarify:
AGS (so Chris) writes a simple xml game exporter, which puts all the game resources in a pre-defined xml schematic (he is provided with an xsd, XML Schema Definition)
all the game scripts are put in this xml "as-is", so basically copy-paste into the proper node. a node marks the script as being AGS-type script.
Now, that's as far as Chris would have to go. No further work required.
...on his behalf, that is; The ScummVM community, using their own (custom) engine, takes the exported xml, and compiles it in their own game language.
To get all the specific AGS script functions across, the ScummVM community uses the AGS help file as a reference to build their "converter" API, which converts the AGS scripts to their native game engine language.
Now, this means the ScummVM team's got a lot of work to do implementing such a thing, but like I said, if they take a look at SLAGE and have a chat with it's developers it might not be all THAT much work.
Using the help file's description of what each function does will help them a lot, and I think it would be a hell of a lot easier when you know what it does then to try and partly reverse engineer old game engines. So I'm sure the ScummVM team is upto the task, if they're willing.
To summarize:- adventure game engine developers would only have to build a light-weight xml exporter and provide proper documentation of their script functions
- the ScummVM team would have their own run-time engine which takes the exported xml and through the use of a converter API they write using provided documentation, they compile the exported xml.
- this allows the ScummVM team to decide for themselves which functions to support or not (for AGS I suggest only bothering with the new object-oriented functions and leave out the legacy code, but that's something they'd have to discuss.)
on the proprietary - open source subject:whilest many of the community wouldn't mind if others "ransacked" their games to build new ones, AGS also has hard working commercial projects;
It is unfair and unacceptable to allow people to "rip" stuff from commercial games to use in other (possibly also commercial) games.
Sure, we don't mind if it's, say LucasArts or some big giant company, but what about those small independent developers, who worked really hard to produce this absolute gem of a game with all new sorts of crazy fun stuff? Would you deny them their livelyhood? They can't afford to go after every crazy fan with a bunch of high-priced lawyers, you know. And they are more likely then not the target commercial developers who will actually use AGS. (Big companies tend to use their own proprietary game engine, anyways.)
And although you might mean well, and say this won't affect their livelyhood, it will. Even worse, it will make every just-starting-out commercial developer make a big wide pass around the AGS engine. (which can't be what we want)
I suggest you read up on the subject, if you're interested; I know I did.
So, anyways, this is why AGS needs to have a proprietary format.
Now if the above makes you think I'm against open source, rest assured, I am not. I however do believe that one must balance open source and closed source, as both CAN co-exist peacefully together. (that's what the whole GPLv2 is all about)
It's a mistake to think everything has to be open source. I know you can have parts open source and parts closed source working harmoniously together.
...right, let me just rush along and go to the summary before I got off on an even longer talking spree. (did somebody say, "too late?")
To summarize:- IF you want to make AGS open source, only make it open source in part. Leave a closed source part, a "special" compile option, if you will, with a proprietary game format. Commercial developers will use it, amateur developers do whatever they want with it.
- if you go with this, only the open source variant could be used by ScummVM and have cross-compatibility
- I believe for AGS, it is better to stay on the current course and go with the XML exporter if the ScummVM team decides to work on an universal game engine thing
Anyways, I hope this has all been somewhat enlightening (and that I don't get a whole bunch of angry amateur developers on my back who disagree with me for sentimental reasons, not knowing the facts, like always tends to happen if you mention "you can't steal someone's stuff or break their copyright". Seriously, the commercial AGS developers aren't the big companies. They need to be left alone legally. Give them a break.)
(legal disclaimer: Oh, and this doesn't mean I condone stealing/breaking copyright from big companies either.)
As far as the "universal game format" goes, I would still maintain that it's an impossible task. But, if anyone did manage to actually create something like this, then we could certainly consider an export feature from AGS ;)
On the more general open source question, one possibility would indeed be to open source most of the engine except the code that reads in the data files. But then you'd have a pretty useless open source game engine that couldn't play any games, and it'd be unlikely that anyone would go to the effort of writing a separate data importer and compiler to use with it.
The other argument against open-sourcing the engine code is, well, the current state of it. The design of the code was reasonable back in 1999 when AGS 2.0 was created, but now it has got into such a state that I really wouldn't wish trying to decipher it on anyone. Put simply, it wouldn't be easy to understand and therefore trying to merge it into something like ScummVM would be a nightmare.
Fair enough. :) Although running our AGS 3.0 games in a platform independent environment is certainly a lucrative idea.
Cheers,
Paul.
Quote from: Electroshokker on Tue 04/12/2007 18:25:33
...on his behalf, that is; The ScummVM community, using their own (custom) engine, takes the exported xml, and compiles it in their own game language.
To get all the specific AGS script functions across, the ScummVM community uses the AGS help file as a reference to build their "converter" API, which converts the AGS scripts to their native game engine language.
Sometimes, it might not be enough to know
what an opcode does. You'll need to know exactly
how it does it. Something as simple as "walk actor X from point A to point B" could get hairy if the actor is supposed to interact with other objects on its way there.
For instance, for the past several years ScummVM has had to "cheat" in the "get distance between two actors/objects" opcode to keep
Monkey Island 2 from hanging. From what I remember, a script is waiting for an actor to move close enough to something but it never happens. It could be because of tiny differences in how actors walk, compared to the original implementation, but no one knows. (It could even have been fixed, without anyone noticing.)
If that kind of jiggery-pokery is needed to get a game to work on an engine that's written to be compatible with the original, I imagine the problems could be much worse when trying to make the same game work on two independently designed game engines. The author would probably end up targetting just one of them, which - to my mind - would defeat some of the purpose of this interchange format.
I'm one of the persons that thinks your tools and the SCUMMVM crossplatform player could increase the number of the potential adventure makers instead of fearing the action of some code or artwork stealers.
Instead of thinking a complete compatibility with older version of AGS which would take so much time why it may be supposed to start from the actual version and see ?
I know that we do not have anything in exchange to offer for so much time spent on coding exept new wonderful adventures coming up which is the main reason (I think) of the creation of AGS
Quote from: Pumaman on Tue 04/12/2007 20:36:05
As far as the "universal game format" goes, I would still maintain that it's an impossible task. But, if anyone did manage to actually create something like this, then we could certainly consider an export feature from AGS ;)
On the more general open source question, one possibility would indeed be to open source most of the engine except the code that reads in the data files. But then you'd have a pretty useless open source game engine that couldn't play any games, and it'd be unlikely that anyone would go to the effort of writing a separate data importer and compiler to use with it.
The other argument against open-sourcing the engine code is, well, the current state of it. The design of the code was reasonable back in 1999 when AGS 2.0 was created, but now it has got into such a state that I really wouldn't wish trying to decipher it on anyone. Put simply, it wouldn't be easy to understand and therefore trying to merge it into something like ScummVM would be a nightmare.
What about having two kind of different game formats?
- open format: it will be compatible with the open-source one. This can be used in the AGS version of ScummVM, but the "second runner" thing can be a problem here (maybe the solution could be a fork with AGS on it).
- closed format: only compatible with the closed-source AGS implementation.
Of course both engines will be 100% compatible. If developers prefer the open format, then maybe the closed-source version could be canceled in the future.
About source code: maybe the ScummVM Team already had to deal with certain spaghetti code from some game that their main devs gave them the source code for easier support. I think messed code could be easier than reverse engineering.
Quote from: subspark on Tue 04/12/2007 21:46:19
Fair enough. :) Although running our AGS 3.0 games in a platform independent environment is certainly a lucrative idea.
Quote from: RickJ on Tue 04/12/2007 07:24:03
The real goal is to give developers the choice of releasing their games to other platforms.
i dont care about merging the engine with scummvm or not,
the interesting point in my opinion would be to make the engine work on other platforms as well.
would be great, if there is a possibility to achieve this :)
What is the most portable backend, I wonder? Perhaps Java?
In my opinion I really think AGS should be closed-source. It doesn't need to be on ScummVM. AGS is doing a good job of updating it. Lets let him focus on the bugfixes, user operability and features. Besides, ScummVM is to be able to play games on different platforms. AGS is playable on three main ones. Maybe someone will port the engine to other OS's as well. But why would you need to anyway? Why play it in DOS, or Amiga? It would be nice, sure. But Mac, Linux and Windows are good enough for now.
Stay on your own Chris. Don't open source AGS. Thats my opinion anyway.
Well as long as Chris or somebody will eventually get round to porting AGS to windows mobile then I'm as happy as a fly on a poo.
Paul.
QuoteWhat is the most portable backend, I wonder? Perhaps Java?
Perhaps Java is a bit more portable, but isn't it much easier to encapsulate C/C++ within Python? If so maybe Python would be a better choice.
And with regard to the open and closed runtime? This doesn't really need to be two separate programs. It could be one program that knows how to read two different file formats. The code that reads the proprietary format could be linked into the open source runtime via a binary library which would not be distributed. Put in a #define and a couple of #ifdefs so it can compile without the binary lib and Bob's you uncle..
Quote from: RickJ on Thu 06/12/2007 04:51:29
QuoteWhat is the most portable backend, I wonder? Perhaps Java?
Perhaps Java is a bit more portable, but isn't it much easier to encapsulate C/C++ within Python? If so maybe Python would be a better choice.
Or even Jython?
QuoteOr even Jython?
Or perhaps Pava? :o
No one implementation is going to be portable to all systems whatever language it's in, and Python is far too slow for most handhelds, Java is too slow for many, or unsupported. Python running on a JVM is right out. Most Python games rely on specific C libraries like SDL which have their own platform requirements, and there is no standard Java graphics system (MIDlets on phones are a completely different world to desktop Java games, or games that use one of the Java 3D APIs).
Standard C with a sensibly designed interface for porting is the best approach if you want widest support. Like SCUMMVM. Anyone doing a port to a new device will have to write a bit of C but I don't think it's avoidable.
A C engine effectively rules out J2ME only phones, but you can't please everyone (without a lot of different implementations).
None of this matters of course. Unless someone documents the AGS file formats nobody could produce a compatible engine, be it compatible with exes or sources, and since (although I think they're shooting themselves in the foot) people don't want the file formats to be public, no compatible engine is going to be made.
I almost want to make a game ripper just to get this imaginary barrier out of the way. But of course I wouldn't do that :P
???
If I want to spend my time to make a good adventure I would be pleased that it could be played by the wider audiance possible.
So If I trust on my story I'll choose a tool that give me the possibility to play it in PDA, DS, PSP....
AGS could have been the choice but it preferes to stay under a "warmy" cristall bowl.
That force me and everyone that wants a space around the idea and not an island to move to another tool.
Too bad :'(
I know you won't worry about but it's a leak on your perfect world that someday may crack. Think about it ;)
(Still my admiration about the works on AGS and to the persons that spend time to give a creative opportunity to others! :)
QuoteI almost want to make a game ripper just to get this imaginary barrier out of the way.
But it's not an imaginery barrier -- I've been asked in PMs by different people who have been working on large and/or commercial games whether their work is "safe" from being decompiled when they use AGS. If I changed my mind now and made it open source, I'd be letting these people down and going back on my word.
But that's not the only reason. I don't think I'd be comfortable with AGS being open source anyway, regardless of that. What I would seriously consider would be giving a copy of the source code to somebody to write a port to a particular system (as I have done with the Linux and Mac ports), but I wouldn't want it publicly available.
And since ScummVM is GPL, that basically rules it out.
Well fair enough then! If you'd rather it wasn't then that's reason enough for me.
Would you consider tasking someone with a private copy of the source code for a Windows Mobile port Chris?
That would be one step closer to an internal and closed group support for other platforms.
Paul.
CJ, would you consider making the formats of the editor's files public, so that someone else could read in the XML, scripts and sprite files etc to compile their own back-end?
Quote from: Pumaman on Thu 06/12/2007 21:29:29
QuoteI almost want to make a game ripper just to get this imaginary barrier out of the way.
But it's not an imaginery barrier -- I've been asked in PMs by different people who have been working on large and/or commercial games whether their work is "safe" from being decompiled when they use AGS. If I changed my mind now and made it open source, I'd be letting these people down and going back on my word.
But that's not the only reason. I don't think I'd be comfortable with AGS being open source anyway, regardless of that. What I would seriously consider would be giving a copy of the source code to somebody to write a port to a particular system (as I have done with the Linux and Mac ports), but I wouldn't want it publicly available.
And since ScummVM is GPL, that basically rules it out.
Thank you for your answer and if you decide to release a light version for scummvm ....it's Xmas time.......! ;)
Hope will surprise you with a new adventure ! :P
QuoteCJ, would you consider making the formats of the editor's files public, so that someone else could read in the XML, scripts and sprite files etc to compile their own back-end?
Well, apart from the sprites this is pretty much already self-documenting; I'm not sure how much more 'public' you could want?
QuoteWould you consider tasking someone with a private copy of the source code for a Windows Mobile port Chris?
That would be one step closer to an internal and closed group support for other platforms.
If somebody with the necessary skills and dedication was to offer to do this, I would consider it.
Quote from: Pumaman on Fri 07/12/2007 20:14:35
QuoteWould you consider tasking someone with a private copy of the source code for a Windows Mobile port Chris?
That would be one step closer to an internal and closed group support for other platforms.
If somebody with the necessary skills and dedication was to offer to do this, I would consider it.
Chris, does AGS still use Allegro for graphics? And it uses wxwindows as well? WXwindows can be ported to a portable Windows OS. Look here: http://www.wxwidgets.org/wiki/index.php/Developers_Notebook-WxWinCECompiling
Seems like a dauting thing to do though.
As far as Allegro, there is no port for another platform. If it were to be ported to Windows Mobile, it would have to start using the SDL graphics library or some other graphics library.
I think that would be the other problem with merging AGS with ScummVM. ScummVM uses SDL and AGS uses Allegro(I think). I think for now AGS would stay with Mac, Ubuntu Linux and windows. If the dos port came back, we can use Dos virtual machines on practically any other system to run the games. But I think thats the limits AGS could reach in portability honestly.
Although I really hope I am wrong... But I do not see it being ported to Windows Mobile or merging with ScummVM without A LOT OF WORK. I rather much see Chris keep updating the greatest adventure game engine of all time...
Just saying, that "someone will write a ripper" isn't the best arguement against Open Sourcing the engine.
QuoteWell, apart from the sprites this is pretty much already self-documenting; I'm not sure how much more 'public' you could want?
The XML and script files are very handy, but yeah being able to get the sprites from the .spr file reliably, as well as the room masks from the .crms, that's the main difficulty currently.
I was only ever nosing around because my interest was in porting an AGS game to DS, and I haven't looked into it much recently since I broke my DS, so I'm not desperate to work it out.
Alliance: yeah I've tried to explain to people how easy it is to take content out of a game, and how it doesn't matter in the slightest, but that issue is done really. CJ doesn't want to open up the engine for his own reasons, and that's up to him.
Just to throw in my two cents, as a commercial developer I can definitely see the upsides of an open source engine. The lack of portability has always been a problem for me, and would be the primary reason for me switching to another engine if I ever wanted to expand. The benefits of being able to port (and sell!) my games on other platforms would be a huge boon, and would far outweigh the downsides.
;D
Are a relative of Ron Gilbert..... ;)
Yes.
He's four years old and my cousin's son. :)