[Scummvm-devel] TsAGE engine and Geekwad

[Filippos Karapetis]

Some thoughts from me on this:

We have another case where a non-adventure game was developed using an
adventure game engine. As mentioned already, there are several other cases
where this occurs, such as:
- Hoyle card games (SCI)
- The Quest for Glory series (SCI)
- The Elvira series (AGOS)
- Waxworks (AGOS)
- Lands of Lore (KYRA)
- Rodney's Funscreen (MADE)
- The backyard series games (SCUMM)
- Living Books games (MOHAWK)
.... and more - these are just examples.

So, in essence, we got a lot of non-adventure games games in several
different engines. The question that arises here is: what is the fine line
that must be drawn for such games to be added in ScummVM?

To be perfectly honest, the details of this are fuzzy at the moment. The
metric we are using right now is the amount of hardcoded logic used in each
game... but this again is not always clear.

There are some games (such as the Quest for Glory ones), where everything
is scripted from the game scripts themselves. However, there are also some
cases where additional changes to the engine itself are needed (such as the
non-adventure AGOS games, the backyard games, and the Living Books games).
So again, we can either say that no non-adventure games are added to
adventure game engines (which is a bit harsh), or that only non-adventure
games where there is no additional functionality needed will be added
(which we haven't honored up to now, e.g. with the AGOS, the KYRA and the
SCUMM games). Another option is to specify that any non-adventure games can
be added to adventure game engines... which reflects what we have been
doing up to now. In any case, ScummVM nowadays does include a lot non
point'n'click adventure games, so perhaps it's time we reflect that in the
description, saying that we also support games that were created with
engines that were originally used for adventure games.

Regarding Faerie Tale Adventures: the only thing that has been kept the
same with the other SAGA games is some rudimentary resource management and
the scripting system. The rest is a highly hardcoded engine, rewritten from
the ground up to handle things such as monster encounters, equipment
generation and combat handling. The additional logic added is a lot, to the
point that Faery Tale Adventures used a SAGA-based engine, with only parts
of the VM reminiscent of SAGA1. IMHO, this is a fairly big change, in this
case, and requires a lot of additional coding which I'm not willing to do
at this point. But if someone came up and wrote this logic, would it make
sense to include it along with the rest of the SAGA code? Again, the answer
is a bit fuzzy here... :( With the current code bloat metric, the answer
would be no, but there is no set standard of what will be accepted and what
won't, judging by the code size alone.

So what would constitute a "small" footprint for an additional
non-adventure oriented sub-engine, originally implemented as an adventure
engine? 100KB? 300KB? 500KB? More?

Also, concerning sev's plugin suggestion: at first, I agreed with him, but
after reading fuzzie's thoughts, it seems a plugin system won't be as easy
to implement as we originally thought :(

Regards
Filippos

On Mon, Oct 31, 2011 at 2:06 PM, A. Milburn <fuzzie at users.sourceforge.net>wrote:

> On Mon, Oct 31, 2011 at 11:36:47AM +0000, Eugene Sandulenko wrote:
> > What I would like to encourage is to work on support for external
> > plugins for ScummVM. Thus projects like scummvm-misc, or scummvm-rpg
> > could be easily integrated at run-time. I even would vote for
>
> Two thoughts about external plugins in particular:
>
> * Many of the games people are interested in are implemented as a
>  subengine of tsage/mohawk/kyra/whatever, so anyone implementing a *plugin*
>  for such a game would realistically have to keep a second copy of all the
>  engine code around, I guess - one copy in the main ScummVM tree and
> another
>  second copy in their external tree?
>
> * The external plugin model doesn't seem particularly viable to me. The
>  attraction of scummvm is how portable it is, but porters already find it
>  difficult to find enough time to build the core tree, buildbot is quite
>  overloaded enough so I assume we can't really lend support there, and
>  trying to build plugins independently of the porters is presumably a
>  nightmare of ABI issues etc.
>
> - fuzzie
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>



-- 
"Experience is the name every one gives to their mistakes" - Oscar Wilde
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20111031/fa9398dd/attachment.html>