About merging with ScummVM, open-source and AGS

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

Previous topic - Next topic

RickJ

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 ...

subspark

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.

Radiant

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.

subspark

#23
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.

SSH

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.

12

Radiant

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.

subspark

#26
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.

Radiant

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".

Time to grow up, dude.

Electroshokker

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.)

Pumaman

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.

subspark

Fair enough.  :) Although running our AGS 3.0 games in a platform independent environment is certainly a lucrative idea.

Cheers,
Paul.

eriktorbjorn

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.

rivadolmo

 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

johnadv

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.

Rocco

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  :)

SSH

What is the most portable backend, I wonder? Perhaps Java?
12

Joseph DiPerla

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.
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

subspark

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.

RickJ

#38
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.. 

SSH

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?
12

SMF spam blocked by CleanTalk