ScummVM game creation studio?

[sev]

I think to write a programm which can edit the files which are in the games to replace some musics voices or animations and backgrounds.

The problem with this approach is that for all games except BASS and FOTAQ you will not be able to distribute it. However there is a workaround, i.e. you may distribute is a patches applicable on original files. Otherwise it would be a copyright violation.


Eugene

[FeebleFiles1]

Oh sorry i forgotten the Copyright Violence, yes you have been right if you see that on the other hand you have copyrights, and the Autors of the games which have worked very hardl for make the game as we know it, good and culty.

[fingolfin]

I think this idea is a lot better. There's no reason to create the new games in the Scumm format, really. You'd also have a lot better control of the features and any bugs or unclear parts of the format would a lot easier to sort out when you're creating the design yourself.

Precisely. In particular, progress didn't stop since SCUMM was originally created. They made a major overhaul to the system with v6 (used in DOTT, etc.), and extended it to 32bit with COMI, but it still shows it's age... You'd have to extend and modify it a lot to get access to modern features anyway (like the HE folks did), so IMO, it's easier and more flexible to just develop a new engine based on LUA, Python, Scheme, whatever (each of those has already been used to develop game scripting systems, BTW).

Moreover, I don't feel it of particular relevance to implement this via a SCUMM module. IMO a modern adventure would nicely benefit from 16/24/32 bit colors, and should take advantage of modern audio capabilities, too. Which just isn't possible with ScummVM at this time. Of course, the ScummVM *framework* has the advantage of being ported to many systems. That's a one point why it might be nice to use it for that hypothetical system... But frankly, if *I* was to develop such a adventure game system, I'd definitely *not* base it on ScummVM.

[visy]

Also don't forget about AGS, but that's Windows-specific and is not supported by ScummVM. From the other hand you may learn from it, i.e. first lesson is amount of years which AGS creator spent on it. That's not that easy task.

Being somewhat a seasoned AGS user (I've been with the "community" since the beginnings) I know, that there is a Linux port of the engine, but not of the editor.

Works fine, too.

Of course, this doesn't solve the problem of porting it to ScummVM because it too is closed source.

Hopefully, the developer of AGS (Chris Jones) will someday open source the editor and the engine. In a way, I still do understand his decision on this matter, because I know he has worked on the engine practically _alone_ all these numerous years now.

My comment on the editor bit is, that I myself wouldn't spend my time with SCUMM. It is, after all, a very old engine, and somewhat difficult and unflexible to develop for.

IMO, Ags is the way to go (closed source 'n all).

[sev]

there is a Linux port of the engine, but not of the editor.

Works fine, too.

Unfortunately AGS has one (mis)feature. Plugins. At the time being those are Win32-only, so any game which uses them will not work on other systems.

My comment on the editor bit is, that I myself wouldn't spend my time with SCUMM. It is, after all, a very old engine, and somewhat difficult and unflexible to develop for.

Not to say that practically each time SCUMM engine was tweaked to run some particular game. I.e. it is somewhat inconsistent and has numerous hacks and shortcuts.


Eugene

[jumpjack]

wanna create a graphical adventure compatible with (almost) ANY platform around?
I found this. Dated 2001, but...hey!
http://www.geocities.com/SiliconValley/ ... /indyjava/

[paradigm]

I thought about developing new games for use with scummvm too, until I read up on it, in any case This really isn't the way to go.

Ideally, for me, a new 2D scumm'alike engine would be based around a Python extension and use PyQt or PyGTK for the graphics side of things. Easy to use classes to set up scenes, AI, etc, so that you could just include the extension and build the entire game using Python.

There are good reasons for this, since there are loads of development tools and editors for these technologies, which (with correctly engineered classes and functions) would act very much like the proposed studio or at least be more helpful than nothing at all.

Ideally graphics would be based around the SVG format (again, multiplatform editors exist along with implementations for python/qt) since its completely scalable and you could take objects in and out of the image, as well as define layers (for walking behind objects). And sound system based on OGG for its openness.

Hey.. when do we start?

[timofonic]

I think the wide experience of ScummVM team on a lot of different adventure game engines, could be very useful for helping others in designing a powerful and consistent engine suitable for mostly all needs, without for future important limitations.

AGS could be interesting in some weay but as others said, the project is too closed source, so I think a open-source adventure engine must be created some day....

[clem]

AGS could be interesting in some weay but as others said, the project is too closed source, so I think a open-source adventure engine must be created some day....

Afaik AGS is closed source and the author doesn't want it reverse engineered - but what would keep anybody from writing a compiler which converts the AGS adventure source files to non-AGS compatible data files, then write an interpreter for that? But then again I've never used AGS so I have no idea how much work that would be.

[sev]

but what would keep anybody from writing a compiler which converts the AGS adventure source files to non-AGS compatible data files

clem, that's much more difficult task than writing that very non-AGS interpretator. Imagine automatic C->Basic translator. Not that easy task. And such convertor will be very thing which scares AGS developer: he doesn't want to opensource his engine because he doesn't want people to rip gfx and scripts from AGS games. Quite weird reason in my opinion, as it would be not very difficult to RE at least gfx/sound bits. I.e. your convertor will do exactly this task.


Eugene

[LOGAN]

AGS FAQ states that this will never happen.

Actually he goes on explaining why it isn't open source: because an earlier tool from him was released by someone claiming he wrote the tool. That's the reason the AGS author would not release his source to the public.

But did anyone ever ask if he maybe wanted to share his code for this particular reason with a SCUMMVM developer? I guess most developers are busy.

The reason why AGS would be nice to be supported is that Scummvm can offer a new range of games on 'other platforms'.

And AGS would be very hard to implement due to the different versions it has gone through (and will go through).

This is a big reason why to choose not even try to support it, I guess.

[glokidd]

i guess the best option would be for someone to work with Chris Jones on an "agsVM" or something that could run all the different versions of the engine frome one executable. the unfortuneate down side of making games in ags right now is that two or three years from now the game that you worked so hard on may be completley unplayable due to uprades to the engine or the OS you run it on. A good interpreter for ags could open up hundreds of excellent games (and hundreds of not so excellent games as well ) but i think for such a progect to really be sucessful, the team that created it would really need to focus solely on the many different ags engines

[sev]

something that could run all the different versions of the engine

...

but i think for such a progect to really be sucessful, the team that created it would really need to focus solely on the many different ags engines

In fact, it is not that difficult if he has all sources for older versions.


Eugene

PS. Now, when AGS is clearly belongs to him, who can "claim" his rights if he will open sources? That's not a sound reason.

[eriktorbjorn]

i guess the best option would be for someone to work with Chris Jones on an "agsVM" or something that could run all the different versions of the engine frome one executable.

Even if you could convince him (and judging by the AGS FAQ that's a pretty big if), I doubt many ScummVM developers would be interested. AGS is a closed source project in active development. We, on the other hand, use open source for building a better tomorrow by cloning obsolete engines. I don't see much common ground there.

[glokidd]

to clarify, i meant a completly new team working with chris jones on a simiar project, and not the scummvm team.
You guys all work hard enough on this project without needing to worry about th omni-hundreds of games and gui interfaces that ags support would bring to ScummVM.
I guess what i was trying to say is that if such an interpreter was made, that the team doing it should strive towards doing a ScummVM like interface where you can add many different games from one launcher.

then, who knows, maybe the project will get defunct, and ScummVM could absorb it
(just kidding )