[Scummvm-devel] Little Big Adventure
max at quendi.de
Tue Aug 19 13:41:44 CEST 2008
Am 18.08.2008 um 15:03 schrieb Filippos K:
> Hello everyone, sorry for the late reply to this, just got back from
> I'll try and list my thoughts on this, and general similar efforts,
> as I do believe it's a very interesting discussion.
> Some of the engines used in certain supported adventure games were
> used to create non-adventure games as well. Examples that come to
> mind are:
> - Many humongous games
> - Elvira 1/2, Waxworks (RPG games)
> - Simon's Puzzle Pack
> - Lands of Lore: The throne of Chaos
> - Several fan made AGI games
> - Inca 2 (the simulator part)
That's true. Note in particular the this is the *only* reason those
games are supported: They are "byproducts" of our work on supporting
adventure games. Sure, some extra work was invested, but note that
none of those is featured in an engine of its own.
This is a major difference compared to LBA or Another World.
> The facts of this project are:
> - ScummVM's portability is outstanding, and it can run under a wide
> variety of platforms
> - There is a lot of shared code for all engines (OSystem, plus
> common code)
> - The focus of the project is on 2D point'n'click adventure games
> This has been mentioned in the past as well, but I'd like to raise
> the question again: currently, the project supports far more games
> that the LucasArts SCUMM games that it originally supported. Perhaps
> it would be more fitting to rename it to a more appropriate name,
> e.g. "GameVM", as an example,
I don't think so. Our name is a brand, and well-established. That's
worth a *lot*, these days. So, why change it? Microsoft is producing
and selling hardware these days, too, yet they still don't change
their name to "MicroHardNSoft" :). Everybody would call them nuts if
they did, too :).
> and provide engines of 2D games to download as dynamic plugins -
> this way, users will be able to play the games they want.
> As a hypothetic scenario, there could be:
> - an "adventure game plugin pack" with the adventure games currently
> supported - and of course, the FreeSCI engine as well (integration
> of FreeSCI into ScummVM is currently being worked as a GSoC project)
Wrong. The GSoC project is roughly about adding a FreeSCI backend
based on the OSystem core, but *not* about integrating FreeSCI into
> - an "RPG game plugin pack", with plugins for games like Elvira/
> Waxworks and Lands of Lore (when/if the engine is expanded to
> accomodate this). The exult project comes to mind, as well as the
> AESOP engine for EOB
> - a "puzzle game plugin pack", with plugins for games like The 7th
> Guest, Myst, Riven etc
> - an "arcade game plugin pack", with plugins for games like Simon's
> Puzzle Pack and the ones cyx wrote (check http://cyxdown.free.fr/)
> - an "isometric 3D game plugin pack" for Residual (which could
> include plugins for games like Grim Fandango, Little Big Adventure,
> Alone in the Dark etc)
Here I disagree, strongly. We are about adventures. If other projects
want to use our code, they are free to do so, as long as they adhere
to the GPL. If they even want to work in close collaboration with us
on enhancing OSystem, we'll be happy to do so, too.
But I disagree with the notion of trying to get the whole "retro game"
world to use ScummVM / Osystem as a basis. It's both unrealistic and
not as big a win as you try to paint it here.
Let me assume for a moment here that I would not think adding more non-
adventure games was a bad idea (unless there are *very* good reasons
for it). Well, even then, the following issues are apparent immediately:
* First off, it would dilute our focus. Focus is essential, in my
eyes. OSystem works so great precisely because it focus on some
specific things, and does those well. For example, ScummVM/OSystem
focuses on 256 color games. While some people here are hoping for
16bit support, well, even if we did it, it would always be a tack-on.
If we truly tried to support arbitrary color modes, then we'd
essentially become a cheap SDL rip-off. No, I'd rather point people to
use SDL directly, instead of our code, if they truly want to support
16/32bit games, or 3D, or whatever (BTW, SDL is getting NDA and
iPhones ports as part of GSoC).
* "Porting" existing codebases like FreeSCI, Exult, Pentagram, AESOP
or whatever is a *major* task. Being involved in Exult and Pentagram,
I just don't see this happen, unless somebody who was intimately
familiar with the projects would spend weeks of work -- and I am not
even discussing the acceptance of the involved developers, without
whose consent and collaboration the whole thing would be rendered moot.
* Having multiple "packs": As a user, I find it much nice if I just
have to download "ScummVM", and not worry about which "pack" I need.
That said, it certainly would be OK to have other code/projects use
OSystem, as long as OSystem provides exactly what they need; but I am
not willing to extend OSystem beyond what it needs to do to support
point and click adventures (and I'd prefer if we only supported
palette mode adventures, too, no 16/32 bit support). The regularly
changing OSystem API shouldn't be a problem for 3rd party projects,
either, BTW: They can either base themselves on the fixed point
releases of ScummVM (like 0.11.1), and only update when new major revs
come out; or they would actively follow the changes we make just like
our existing porters & engine authors do.
Distribution: If, say (hypothetically), Pentagram was "ported" to use
OSystem, or somebody wanted to releases a Myst/Riven engine
based on OSystem: no problem at all! Register an SF.net project,
import our code, and then base it on OSystem 0.12; track changes at
point releases. Or ues DVCS tools like git and mercurial, to track our
changes actively. Or use direct checkouts of the relevant ScummVM
source dirs (using the svn:external property) inside your Subversion
repository, if you prefer SVN.
> Of course, this is all highly hypothetical and very radical, and a
> scenario like this would lead to a very different path for the
> project than it originally started. Still, it could provide a
> "segmentation" of the project into other kinds of games as well. In
> the end of the day, OSystem would be the "umbrella" that would
> include all these engines, and each developer would be responsible
> for his/her game engine - something which works for projects like
> MAME. The only real difference is that engines for non-adventure 2D
> games could be accepted as well, as separate "packs".
The problem is: This would only work if we started to make separate
"point releases" for the new OSystem project, with a well-defined
binary API. "We" would have to manage two releases cycles instead of
one now. As one of the persons who works most on OSystem these days, I
can say that I wouldn't want to spend that extra time -- I already
have far too little spare time to work on this.
Sure, *other* coders/projects might benefit from this, but would
*we* ? I don't think so.
> I'm not advocating any change of direction to the ScummVM project,
Actually, if you weren't, what else was your email about? :)
> but I do believe that the fact that game engines can be included as
> plugins leads to all sorts of interesting results.
> What are your thoughts? Could this ever become a reality or am I
> just daydreaming? :)
My interpretation: You have a vision; I have a totally different vision.
More information about the Scummvm-devel