Little Big Adventure (patch included)

[SuperDre]

The people who are in charge of ScummVM care.

Using that argumentation I could request a DOOM engine to be put into the Linux kernel because "people want it" and "the scope has changed over the years"

well, if it works as a simple plugin, why not.. hehe..
but according to your own words, then games like goblins shouldn't also be playable in Scummvm, as those aren't real adventuregames, LBA is more of an adventuregame as goblins is (it's also in the name, LOL)..

[Collector]

The people who are in charge of ScummVM care.

Using that argumentation I could request a DOOM engine to be put into the Linux kernel because "people want it" and "the scope has changed over the years"

well, if it works as a simple plugin, why not.. hehe..
but according to your own words, then games like goblins shouldn't also be playable in Scummvm, as those aren't real adventuregames, LBA is more of an adventuregame as goblins is (it's also in the name, LOL)..

Have you even ever played the Gobliiins games? yes they are more puzzle based than some adventures, but they are adventures. They are also most assuredly 2D and "Point & Click". LBA is more of an arcade game than adventure, even if it has more of a story than most arcade games.

As far as a plugin system, I don't know how likely this would be, the devs would know better. I suspect that it would not be easy, if it is even possible/practical. It would be nice, though. I won't be holding my breath.

[Dark-Star]

...There's nothing better than having one 'frontend/engine' for all your (old) games for almost any platform you can think of...

I completely agree with you there. Having all kinds of engines in one place would be the "best" solution for users (and probably for developers, because the OSystem takes away a lot of the burden of writing a complete game engine by themselves).

However, the ScummVM devteam has the last word here, and they made their position rather clear.

My point was that instead of letting all those "out of scope" engines bitrot, they could find a permanent home in some other project based on ScummVM. If you can't have chocolate ice cream, vanilla is better than no ice at all IMHO

And who says that these two separate projects couldn't be merged again in a few years, if the devteam's viewpoint changed over time...

[Longcat]

In the beginning, ScummVM was only intended for use with LucasArts games. Besides, adding engines means someone will have to make the commitment to mantain and work on them continually. Games like LBA are far more likely to be supported by developers like gog.com than ScummVM. Plus, there are a lot of p^c adventure games I would rather see supported before arcade games make it into the mix:)

[Gucek001]

Strangely - I agree with ScummVMdevs here. Not only because LBA is adventure-ish rather than adventure - mostly, because it's 3D. Period. BTW - such genre cross-over became quite common since then - even to the point where many people nowadays consider games being clearly action-adventure as just "adventure". (like Tomb Raider or Beyond Good and Evil). Sad.
All in all - 3D is enough reason to put LBA in separate program - maybe together with abovementioned residual and Free in the Dark?!

[Reckless]

The ScummVM team certainly have strong views on project content. I would agree that LBA doesn't fit the 2D Point & Click adventure game shape that defines [most] of the supported ScummVM games.

I've no idea of the exact details (who is?) but FreeSCI is being added in the shape of a plug-in (bridge, thing, widget, whatever) as part of this years Google Summer of Code. Depending on the design of said 'thing' maybe it'll lead to a more flexible approach for contributions such as this. Re-using the ScummVM infrastructure [without having to generate/maintain a local branch] is surely a good thing!

[Dark-Star]

...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.

[Lostech]

You can compile plugins at least I know this for Windows and WinCE. But I don´t know if this is supported for other platforms, too.

[KevinW]

I would agree that it makes sense to pick up abandoned RE projects and give them new life. But I don't think that the plug-in system is the right solution. There are many users, who don't know how to compile anything.

Adding LBA to a project like Residual sounds best to me, since it would be more in scope and you could make use of an existing OpenGL subsystem to render the 3D-Portions. I hope that this will happen one day, still it can't be forced and we should let the developers decide, it's their project after all.

[fingolfin]

The problem with abandoned RE projects is that they are abandoned -- nobody is working on them, nobody knows how they work exactly. Reviving them is cool, but it's a hard task. Porting the abandoned project to ScummVM is another, different, hard task. Combining the two tasks is not making things easier on the short term . Thought it might on the long term -- but the key problem is that you still need 1-N individuals who dedicate the time to reviving the abandoned project. This is an invariant, and exists, regardless of whether you mention/involve ScummVM in the equation or not.

Working on and adding to ScummVM is not magic. It's a lot of hard work.

[Dark-Star]

I completely agree with Fingolfin here. "Porting" to ScummVM will not make dead projects magically alive again

However, having those project based on a common engine (be it ScummVM or something else) would ease the task for people who might want to take over and/or revive the project again later, because they are already familiar with the internal API, the event handling and so on. And moving from an old branch/copy of the ScummVM engine is easier than from a completely custom game engine (because the OSystem API, event system etc. are already well-known).
And of course we all know that one of the hardest parts of creating a game (no matter if it's an RE'd game or a original one) is creating a working engine on which to build upon

-Darkstar

[Yuruka]

I don't think ScummVM should support any other type of game than Point'n'Click.

That's my opinion though.

I also think they should make a little button which brings up a nicely coded menu which tells you what games it supports.

And maybe another menu that quick-finds all the extras folders (broken sword) and all the ROLAND-MT32 drivers...

For lazy people.



Offtopic - Dark-Star your avatar is nostalgic to me.

[iPwnzorz]

Support button = Bloat

[Yuruka]

It was a joke. About the lazy support thingy. Because so many people ask for so many simple things.

=]