[Scummvm-devel] KYRA - Eye of the Beholder extension

[Johannes Schickel]

On Fri, Dec 2, 2011 at 12:10 PM, Eugene Sandulenko <sev at scummvm.org> wrote:.
> If it is so, then another approach would be to refactor those specific
> format readers and put them into common code, then base eob engine on
> that and have it as external one. How does it sound now?
>

I can't say I like that, it would be basically code in common code
parts which is just used by one in-tree engine and has no real use for
any other in-tree engine.

> The main fears over here is the maintenance overhead. So let me put a
> simple question: 'Will supporting of 2 forks of code be easier for
> athrxx, or it will basically suck out the developer out of the team?'
>

In fact _athrxx working on it outside the team is definitely quite
much overhead for him, that's one reason why he wants to merge it now,
when I got it correctly ;-).

> There were thoughts about additional burden during refactoring. Well,
> I consider OSystem interface as quite stable, and let me point out,
> that the game-specific code is exceptionally rare if ever touched by
> the refactorings. The engine interface to outside world is shared
> between all subengines. No additional work here. Really. Come back
> with specific examples.
>

In fact I have no fears about that and I didn't really talk about it.
I merely said we add code really specific to an RPG, which is built up
on a common framework with Kyra1-3 and not on a common engine. If
that's fine with everybody then it's good, if people don't like that
then it's bad. And this is *not* a point about code maintainability,
but *what* kind of engine code we accept, i.e. non-trivial code not
targeting adventures.

> Thus again, we are talking (and always been talked for these 10
> years), that we are supporting adventure engines. And I would really
> like the project to stay so, despite the attempts to bring in RPG
> engines.
>

This is directly related to my point that EoB code addition is
non-trivial code (which might even be considered a whole engine) only
to target RPGs. If in the case of subengines, we do not really care
about that much, then it's fine.

> The only disputable area here is those /few/ games which were
> developed on top of adventure engines.
>

This is exactly my point, calling EoB 1+2 being developed on top of an
adventure engine doesn't really fit the reality IMHO. We of course
have it in the same code base, since we share the framework
functionality by doing so. Then again also here applies my question:
Is that enough? If it is then it's fine. There is no reason to start a
whole discussion about maintainability to answer that right now IMHO.
We all know Florian isn't the guy to suddenly disappear and lets us
with code we can't work with, so maintainability isn't really a
problem to me. Rather it would be good to focus on the question at
hand.


So once again: If we think the reason that EoB 1+2 shares framework
code with Kyra games is enough to accept it as "subengine", then it's
fine to add it. That's for me the sole remaining question to be
answered, but it seems people try to avoid to answer that. So please
give a clear "yes" or "no" answer to this (and maybe some *short*
explanation why). Until I hear anything about that I'm against merging
this code and to clarify this is *not* because I don't want to include
it, but rather because I want this point clarified clearly visible,
i.e. without "interpreting" people's vague statements about it.

// Johannes