[Scummvm-devel] Adding Frotz engine to ScummVM

[John Willis]

Just my 2p on this ;-), usual caveat that my views tend to count for naught.

> > I have my reservations about adding an Infocom engine, too.
> Although being one of the proponents for adding new engines to ScummVM,
> and that adding IF to the project would seemingly "complete" cycle of
> supporting all "old-style" adventures, I would say no in this case.

I tend to agree with that but as Eugene alludes to later, ScummVM has many
many good points and some of the major technical ones are oSystem and
portability. 

That can be quite compelling to a developer and as we have experienced in
the past (looking back to the Another World engine for instance) it is very
flexible and that flexibility is the very thing that makes these forks from
the core project ethos so easy to do (and so easy for someone to
contemplate). I'll confess to having used oSystem for things it was not
designed for just so I could quickly test something on a load of platforms.

I can personally (on some level) see the attraction of adding IF to ScummVM
to complete the cannon of adventure games but really, it's not what the
project is about.

> > Of course Paul already spent a lot of time on this engine, and it's
> > not nice to get that work rejected. However, that's why it's always
> > a good idea to ask before starting work on any patch whether that
> > patch has any chance of being accepted... ;)
> Yes, that's a pity, and if Paul would at least give hints about his
> plans, I would give my answer right away.

Agreed, working on anything that may or may not get a good reception can be
heart breaking but there is no reason any of this work need be lost. I think
this could well be a catalyst for the project to consider that it has now
grown to the point that it has a number of highly valuable software (and
community) artefacts that it should look to make the most of. 

After all it's a pretty unique project in a fairly unique position.

> Still I understand the benefits of having an Infocom engine based on
> OSystem, as it brings tons of portability and hardware abstraction. So,
> thus perhaps it is a good time to work a bit on our open task"Improve
> the ScummVM build system" and particularly "Modify ScummVM build system
> to add ability to build engines ourside of the main source tree." In
> this case Paul's effort could continue to evolve as a spin-off project
> based on OSystem. Also I know that there are at least some
> non-adventure projects which are based on OSystem, and I myself would
> gladly port my puzzle game to OSystem for portability.

This was going to be the thrust of my mail before I read your reply :). 

I could not agree more on this. It tends to tie up with a lot of the recent
background work that has been undertaken over the last few years on the
plugin model, recent 16bit support, more 'hardware' and codec support,
better and more platform backend support etc., even the talks about DVCS
source control - It all adds to the attractiveness of oSystem and ScummVM
for all manner of things loosely attached to 'adventure gaming'.

If you take this further you could have several component parts. 

ScummVM, this stays as a pure 'point and click' project and has all the
restrictions and conventions we have right now in place. The same rules and
discussions around core engines apply.

Secondly you would have any number unofficial and totally unsupported (by
the project) engines that 'use ScummVM technology' to provide the backend
infrastructure to their core engine logic.

It would seem reasonable, assuming these engines are indeed built out of
tree, for these engines to be whatever the person who is doing the coding
wishes. It would also cut down on the proliferation of forks of the entire
codebase to support these engines (and could make engine development on the
whole easier anyway, especially in the incubation stages). 

I am not sure how the details of all this would/could work out in real terms
(after all we are not really discussing anything that different from the
concept of the Linux kernel and modules). 

The plugin architecture puts the technical groundwork there already but you
would still have to consider all the evil things like static/dynamic etc.
(do we 'taint' ScummVM if it has unofficial engines statically linked ;-))
but I really do strongly think it's the way to go to help us find a middle
ground. 

Not sure what I can do to help this but I am willing to sink time into it if
there is support for the idea.

Still, as I said above, just my 2pence on the issue.

Regards,

John