On Sat, Aug 2, 2008 at 8:46 AM, Max Horn <email@example.com> wrote:
And because it was mentioned on the tracker item: People keep quoting
Simon's Puzzle Pack as a justification for adding arbitrary things.
Well, my reply to that is: If you can support a full new game by
adding only a few hundred lines of code in total (like it seems to be
the case for the puzzle pack), fine by me. Somehow, though, i doubt
that this will be the case with LoL, so the comparison is invalid :)
My bad there - I'd never actually looked at exactly how much code comprised the changes to support the Puzzle Pack, so it seemed like a valid comparison to make, since the Lands of Lore patch was using the Kyra engine as well.
On the topic of joining, my first thought is that your first question is an important one (adding LOL support).. what are Lordhoto's plans? Does he particularly intend/want to complete the entire Lands of Lore game, or is the patch more in the nature of an experiment with the game's file formats and/or sounds and animations? If he doesn't want to do the whole game, then there's no immediate need to make any firm decisions on the subject.
In any case, I'd be interested too to hear what others think on the topic.. if someone really wants to implement a RPG using the ScummVM framework, should it be allowed into the SVN, or would they be required, for example, to do a fork and maybe start up a separate 'SCUMMVM-RPG' project. :). But of course it might get complicated when you start considering 'adventures' whose genre is harder to define exactly, like "Another World".. maybe they'd need just a general SCUMMVM-NonAdventures project instead. :)
My 2 cents - I think clueless newbies are always going to ask for support for particular games on the forums, and that fact shouldn't discourage people from implementing a game they really love. There could, for example, be a policy of allowing RPG engines into the SVN, but not enabling them in the official releases, or utilising the evolving plugin capacity and providing them as downloads in a separate download area that's clearly marked as 'non-adventure games that ScummVM happens to support'. That could provide a compromise for maintaining the 'adventure' focus of ScummVM, yet still allowing a common repository source of game engines that use the ScummVM framework.
In the case of a sister website & SVN for non-adventure games using ScummVM, it would be difficult to keep the core of ScummVM up to date in both, particularly if the sister project wants to take advantage of new GSOC features (for example) in the future. But if the concensus is to keep the main ScummVM website/SVN completely for only adventures only, I'm sure no-one would mind someone forking ScummVM and starting up a separate project.