[Scummvm-devel] Yet another proposal for engine merge procedure.

[Arnaud Boutonné]

I also don't understand why we should make a specific rule for the games
using hardcoded logic.
Working on reducing the number of unknown variables, documenting, ... is
something which already has to be done for other engines. Can't we simplify
things and only set general rules?

If we stack more and more rules, I'm afraid we'll end with something
completely discouraging for new developers.

And concerning rules...: shouldn't we specify 2D point&click adventure
games, instead of 2D adventure games?

Best regards,
Arnaud



On Fri, Nov 18, 2011 at 6:09 PM, Willem Jan Palenstijn <wjp at usecode.org>wrote:

> On Fri, Nov 18, 2011 at 06:47:51PM +0200, Filippos Karapetis wrote:
> > On Fri, Nov 18, 2011 at 6:32 AM, Johannes Schickel <lordhoto at scummvm.org
> >wrote:
> >
> > > * Your engine must target an 2D adventure game.
> > >
> >
> > This is a bit ambiguous. For example, Myst/Riven and the 7th Guest are
> not
> > considered adventure games (at least not "classic" adventure games) -
> > they're puzzle games, really. Also, this still does not cover two cases,
> > which I would like to have covered as well:
> > - Non-adventure games, developed with an adventure game engine. I suppose
> > these should be the only exceptions to the rule above, thus they should
> be
> > mentioned as well, IMHO (e.g. scripted games, like Quest for Glory or
> games
> > requiring some changes to their engines, such as Elvira, Living Books,
> > Humongous games and Lands of Lore)
>
> Didn't we say earlier that in those cases the initial engine merge should
> at
> least target an adventure game? (And this discussion is about merges.)
>
>
> Also, please don't try to over-define things. There's room for some
> ambiguity.
>
>
> -Willem Jan
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20111118/9e265e4d/attachment.html>