Jonatan wrote:...Plus, there are a lot of p^c adventure games I would rather see supported before arcade games make it into the mix:)
I fully agree with you there. I, too, still have some fond memories of other good adventure games that have not been reverse engineered yet.
However, this is not a question of "wanting" but a question of what people have fun working on. If someone wants to reverse engineer an "arcade game" (if you can call LBA that), why should all his work rot in some obscure and hard to find corner of some old webpage where it will be list and forgotten...
There are actually people out there who feel that all their adventure gaming needs have been fulfilled by ScummVM now, and they turn to other games. One can hardly blame them for that. And you can't force them to work on yet another obscure point and click adventure when they'd rather hack on something else...
My guess is that sooner or later, there will be a handful of other projects which all use the ScummVM core to implement one or two games each. And then some time later, someone will step up and unite these projects. Whether that will be the ScummVM team or some other team remains to be seen.
I'd certainly prefer it if this "unification" was done sooner rather than later (i.e.: now, or in the near future). But since you can't force anyone in Open Source, I'll just wait patiently
And about the plugin system: I'm not entirely sure (my last SVN checkout is now some months old), but isn't there a flexible run-time extendable plug-in system already in place for ScummVM? IIRC it was once discussed because it was needed for the smaller ports (Dreamcast?) to free up some much needed memory. I remember a discussion on the ML about a dynamic library based plugin system. Was this ever implemented? If yes, why isn't it enabled per default on Win32? Maybe it just needs some tweaking/fixing here and there to be usable.
However, this would not fix the problem that each engine would need to be updated to stay in sync. The OSystem changes so often, and in a binary-incompatible way, that everyone would have to patch his plugin maybe once a month. Taking a fixed snapshot of ScummVM and developing against that would push the need to migrate to the new API forward to the (hypothetical) merge point with the main ScummVM tree or with other subsystems, thus removing the need to release new plugin-DLL's every few weeks/months.