Some thoughts from me on this:<br><br>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:<br>- Hoyle card games (SCI)<br>
- The Quest for Glory series (SCI)<br>- The Elvira series (AGOS)<br>- Waxworks (AGOS)<br>- Lands of Lore (KYRA)<br>- Rodney's Funscreen (MADE)<br>- The backyard series games (SCUMM)<br>- Living Books games (MOHAWK)<br>
.... and more - these are just examples.<br><br>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?<br>
<br>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.<br><br>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.<br>
<br>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.<br>
<br>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?<br><br>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 :(<br>
<br>Regards<br>Filippos<br><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 2:06 PM, A. Milburn <span dir="ltr"><<a href="mailto:fuzzie@users.sourceforge.net">fuzzie@users.sourceforge.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Oct 31, 2011 at 11:36:47AM +0000, Eugene Sandulenko wrote:<br>
> What I would like to encourage is to work on support for external<br>
> plugins for ScummVM. Thus projects like scummvm-misc, or scummvm-rpg<br>
> could be easily integrated at run-time. I even would vote for<br>
<br>
</div>Two thoughts about external plugins in particular:<br>
<br>
* Many of the games people are interested in are implemented as a<br>
subengine of tsage/mohawk/kyra/whatever, so anyone implementing a *plugin*<br>
for such a game would realistically have to keep a second copy of all the<br>
engine code around, I guess - one copy in the main ScummVM tree and another<br>
second copy in their external tree?<br>
<br>
* The external plugin model doesn't seem particularly viable to me. The<br>
attraction of scummvm is how portable it is, but porters already find it<br>
difficult to find enough time to build the core tree, buildbot is quite<br>
overloaded enough so I assume we can't really lend support there, and<br>
trying to build plugins independently of the porters is presumably a<br>
nightmare of ABI issues etc.<br>
<br>
- fuzzie<br>
<div><div></div><div class="h5"><br>
------------------------------------------------------------------------------<br>
Get your Android app more play: Bring it to the BlackBerry PlayBook<br>
in minutes. BlackBerry App World™ now supports Android™ Apps<br>
for the BlackBerry® PlayBook™. Discover just how easy and simple<br>
it is! <a href="http://p.sf.net/sfu/android-dev2dev" target="_blank">http://p.sf.net/sfu/android-dev2dev</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"Experience is the name every one gives to their mistakes" - Oscar Wilde <br>