[Scummvm-devel] TsAGE engine and Geekwad

[Willem Jan Palenstijn]

On Mon, Oct 31, 2011 at 02:51:12AM +0100, Johannes Schickel wrote:
> On 10/31/2011 02:23 AM, Paul Gilbert wrote:
> > As part of the further investigation and implementation of TsAGE 
> > games, I spent a bit of time looking at the game Geekwad. I did a 
> > commit of a game skeleton, but it's been pointed out that since this 
> > isn't an adventure game, it should really have been discussed on the 
> > mailing list first.
> >
> 
> Yes that's right. This should have never been added to the ScummVM 
> master line without any prior discussion. Anyway it's good that you 
> still pointed it out on -devel now. Thanks for that.
> 
> > The game itself isn't very big, consisting of 13 game scenes, which 
> > represent the scenes for the minigames as well as the introduction, 
> > title screen, etc.. I haven't looked much into the mini-games yet, but 
> > from what I can tell so far they also use standard TsAGE visual 
> > objects and actions to implement the gameplay logic.
> >
> > Based on the prior precedents, I'm hoping that there won't be an issue 
> > with allowing for support of the game as well in trunk. The only 
> > disadvantage, as far I can see, is that as with the other TsAGE games, 
> > Geekwad also uses hardcoded logic, so there will be some size bloat. 
> > Luckily, given the simplicity of the individual mini-games, I don't 
> > anticipate it would be very much.
> >
> > Opinions? If it's considered a problem, I could always undo the commit 
> > and maintain it in a separate branch. It just seems more effective 
> > IMHO, to keep support for all the TsAGE games together.
> 
> Personally I would say since it's all hardcoded logic, we shouldn't 
> really have that in the tree. Then again maybe it's really not that much 
> overhead. But frankly speaking I wouldn't like that to be experimented 
> in the ScummVM master line. I would suggest you develop the whole game 
> in your personal fork, if you want to work on it, and when it's done we 
> might compare the changes and discuss it again.
>
> But being totally honest, I think it's kinda odd if we would allow this 
> game and then again deny EoB 1+2 support, which might maybe be a similar 
> amount of overhead. So right now I am rather in favor of Geekwad being 
> not included in ScummVM.

I agree with Johannes on this. I wouldn't be a happy with a ton of hardcoded
logic specifically for arcade games.

There is the occasional exception to the "no adventure games" rule I know, but
I don't think this should be or become an automatic acceptance for new
non-adventure games.

I think we're already spread pretty thinly over the amount of games we
currently support, and broadening our scope is likely to make this worse.



-Willem Jan