[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[55130] scummvm/trunk/configure

[Johannes Schickel]

On Fri, Jan 7, 2011 at 3:43 AM, Paul Gilbert <paulfgilbert at gmail.com> wrote:
>
> For me at least, as I mentioned at an earlier date on my blog, the engine is
> more or less working, so I figured my time was better spent, and more
> enjoyably for me, on working on the RE of the new games, and leaving further
> work to any other interested party.

I think that is a definitely legit personal decision on what to spend
your time on. On the other hand for ScummVM as a project, this
decision might not be optional. But then again ScummVM is a free-time
project, so I do not say you should feel bad about it now, it is still
mostly about what you consider as fun.

> If all the other developers have other
> priorities at the moment, I don't think there's any major problem with it
> 'idling' for a bit, so to speak.
>

>From an engine developer point of view I agree that I do not think
there is too much of a problem here. On the other hand for a common
code developer there might be some problems, especially if people who
used to work on engines are not contactable anymore, since then
adapting the engine to changes might be really annoying. From a user
point of view it is not ideal either, it might be in a pretty solid
state, but some users might be disappointed why it is still not
finished (or why there is not even progress towards that goal).

> In recent years, perhaps in part due to the fact that several of our engines
> were based on original sources provided, and thus had to be kept secret
> until they were reasonably refactored, it seems like, more and more, there's
> an implication that an engine shouldn't be added until it's
> semi-completable. And this I think is a pity.
>

Personally I was always in favor of merging in development engines.
Nowadays I am not even sure whether we should really merge
"semi-completable" engines....

Let us take a look at some (regardless of their state when they were
merged) engines we merged:

I will start with M4 as an example now:

The engine was added 2 years ago and from what I heard it was under
development by then. Then again shortly after it was merged the
progress decayed till there was virtually no progress anymore. Of
course you are working on it now and then, but I am not sure how much
progress there really is. To me it actually looks like overall it was
a failure to add it, since we had no real advantage of the engine so
far. Means we do not have any newly supported games.

On the other hand when we did not get any advantage out of the M4
engine addition we got disadvantages:

 - When we change common APIs we have another engine we have to adapt.
This is sometimes not much work, sometimes more, and sometimes
annoying work. And personally I see no reason why I should spent my
time on a rotten engine. I personally would mostly only do that
because it is in the development tree and thus it might affect
buildbot builds.
 - On a less technical side we had certain users interested in games
possibly supported by M4 and who where curious on how it turns out,
but we rather disappointed them so far, which is not really nice IMHO.

There are other examples of (sub)engines/games which are rotting: Cine
(Operation Stealth), Groovie2, SAGA2, maybe some Gob games Strangerke
worked on (not really sure about this). They pretty much suffer from
the same disadvantages, then again they are embedded in a working
engine and (hopefully) code base wise not totally unrelated to the
engines which they are embedded in. This rather weakens the technical
disadvantage.

On more recent engine additions:

The Last Express and Toonstruck. Both are in a pretty solid state (I
think, at least when playing around a bit I got that impression), one
might even want to go as far as compare them to BS25's state, but
there is no progress on those either.

I think Littleboy took a pause from TLE to work on some other engine
right now, since he was tired from all the hardcodednes of TLE, which
is I think a pretty legit personal reason not to work on it anymore
right now.

Sylvain probably got caught up by real-life, which is also a perfectly
legit personal reason not to spend time on working on Toonstruck.

Both these engines suffer from the same problems as the one mentioned
above, except that they seem more playable, thus maybe even enjoyable
for some brave users, who do not care about certain glitches / missing
features.


Going a bit further:

It seems to me that for all the "semi-completable" engines we added so
far we have a pretty good success rate, so maybe it is totally fine to
add those.

On the other hand I am not sure what engines were not added
"semi-completable", but I will try to make a list here (I will not
include work on games of later versions of engines already in the
source tree, which was done in tree exclusively):

SCUMM: Looks like a success I guess ;-).

SIMON1/2 (nowadays AGOS): Success, though I am not sure whether they
started as separate project and if how evolved it was when it was
added. So this might not count.

One might be able to count KYRA as one of these engines too. The real
start off of this engine, 1 year and 5 months after it was initially
"added" as a stub, was done by cyx, when he imported his Kyrandia 1
Intro player code and his (partly) further REing of the original
executable. Of course this was all off-trunk by him, though I would
not consider this "semi-completable". Vinterstum and me took over the
development then. I initially made some patches off trunk (or rather
CVS main line back then ;-), which I committed pretty early after,
after Eugene asked me to work completely in the development tree,
since it is easier to review etc. After that most of my work on KYRA
was exclusively in source tree.

LURE (as you mentioned): Success.

M4: A (more or less total) failure IMHO.

Engines I have totally no clue of (and I am too lazy to check the
development history right now): SKY, QUEEN.

So in retrospect: The success rate looks quite acceptable. But then
again KYRA was total disaster for some time too and I doubt it really
helped that it was in the source tree, of course it was not actively
worked on when it was added. Also it is the minority of engines we
have (I think!).

So all in all I am not sure whether one can make a trend here, about
whether we have a higher success rate for mostly in-tree developed
engines or for engines which were merged semi-completable. To make
some real trend we have way to less completely in-tree developed
engines IMHO (or at least I am aware of) anyway.


Then again I might be one of the persons who rather look at the
project (and maybe a bit its maintainability, when it comes to
technical aspects) when looking at engine additions etc.. I can
definitely understand that some people care more about the fun they
have when working on the engines and who have the hope that if an
engine lands in trunk, there is a higher chance of someone else also
starting to work on it (and thus finishing it, in case oneself loses
the motivation).

Though in the recent years I got the feeling that people rather only
care about their own engine(s) and not about the project itself at
all. I am not saying one should care more of ScummVM than of his/her
engine, but on should definitely see and think about the greater
picture. That is something that I think is not really nice when you
work on a project like ScummVM and also a reason why I get more
skeptical about engine additions in general.

> I understand that there are those who have started work on a game engine and
> then abandoned it (or put them in indefinite hiatus), but I personally think
> any engine showing a significant development should be added to the
> repository.

I am not sure, but seeing at what actually happened with such engines
in our past, I would rather say that a current "significant"
development is not related at all to whether we will not end up with
an engine virtually nobody is working anymore. So personally I think
the disadvantages are worse than what we get out of an unfinished
engine without progress sitting in our main development tree. (And I
do not imply all of the engines we might add this way would end up
like this).

Also I am not sure what is the reason why you think we should add in
development engines (apart it might help developing the engine). Maybe
you would like to explain that a bit?

> Especially recently more so than even in the past, since we now
> have the advantages of Buildbot, helping to ensure that code is written in a
> properly system-independent manner. Plus, working on the main SVN means that
> all past commit history is already present; transferring external commit
> history from other SVN's seems to be a cumbersome process, from what I've
> seen in the past.

Yeah it is pain some with SVN, then again with Git it would be much
easier. Another reason why I hope we will make the move to Git.

I am not sure whether Buildbot is a good argument to justify addition
of engines though. It is not that hard to setup an Ubuntu in a VM
these days, which usually is good enough for most compile time
testing. Of course there are exceptions, like broken compiler versions
on some systems, less standard library support on others, certain
platform specific details etc.. But is this really a reason for adding
engines which might end up rotting for years?

>
> If I might use a concrete example, my Tsage (Ringworld) engine has already
> reached a point where you can walk around and do basic actions in the first
> scene. In people's opinions, has it reached a point where I should/could add
> it to the main repository, or it should it wait to some future date when
> it's more completable? Certainly I could have benefited from Buildbot - I've
> already had emails of problems compiling it under Linux that I then manually
> fixed - with Buildbot, such issues could have been immediately identified
> when I first wrote the offending code, and reduced the amount of code fixes
> I then needed to do later.
>

As said above, I think setting up an Ubuntu VM these days is really
easy, thus I do not think our Buildbot is much of a reason to add
in-development engines.

Apart I am rather skeptical on adding Tsage to ScummVM's trunk, mostly
for the reasons I mentioned above. Maybe my fear of having rotting
engines is irrational, but it seems worse than what we get of having
an engine development taking place in the mainline ScummVM
development.

>
> On a related topic, this also ties into an ongoing discussion about grouping
> together all the in progress, abandoned, and miscellaneous engines into a
> single centralised set. As I understand Git, it's been proposed that we
> could have all these engines in a single main separate fork from the main
> trunk, which could then be kept for the completed games. This may be an
> optimal solution for keeping them all centralised, and removing the need for
> ever transferring commit histories. It would be an excellent bonus if
> Buildbot could also handle both that as well as the main branch.
>

Actually with Git every engine could just have it is own public
development tree somewhere. If you then make some single place which
"merges" them all is up to whether you like it. I am rather against
building such 3rd party engines on buildbot though.

If we would build such 3rd party engines on buildbot we would have to
worry about additional disk space required by all the build files.
Additional computing power (buildbot is not sometimes quite slow
already, if we also add 3rd party engines it would be even worse, when
there is much development ongoing). And also we would have to think
whether we should publish those builds. And I think that is something
we definitely should not do IMHO. If we start publishing builds with
3rd party engines disabled, users will think we actually support the
games, which would be a confusion for the users IMHO.

Personally I think switching to Git is the way to go. If we have Git
everyone is free to make their own public repo where they work on the
engine and of course we can easily merge it later on (even with
keeping the history). And also I think then we should link those from
the Engines page on the wiki so they get some attention too. This is
IMHO preferable over adding in-development engines into the
development main line and maybe ending up with dead code. Furthermore
we can keep a clean mainline where only supported engines are
included.

// Johannes