[Scummvm-devel] Adjustments to the ScummVM engine development and the project scope

[Paul Gilbert]

Hi all,

Both myself and Strangerke are very happy about the move, as most everyone
will already know. I'll probably hold off creating a merge request for
Xeen, though, until I've time to work on it more regularly, since right now
all my time is being spent on my Starship Titanic engine.  But I'll create
a pull request that now. What Sev said is something I've felt myself - back
in the early days when I first worked on the Lure engine, it felt good to
have had what was initially just a glorified introduction sequence player
accepted into the main codebase, and having it visible like that meant I
was able to get help and encouragement from others constantly. Hopefully,
this new policy will mean likewise for future engine developers again.

Paul.


On Mon, Jul 18, 2016 at 3:39 PM, Eugene Sandulenko <sev at scummvm.org> wrote:

> Hi Team,
>
> This is the second letter which I am sending to you after discussion with
> wjp.
>
> In the last years, since we moved to the GitHub, we gradually changed our
> development model. The major difference was that we raised our bar for the
> new engines significantly. In short, only the practically finished engines
> were accepted.
>
> As a result, it diverged the development outside of the tree, often
> leaving the engine authors one-on-one with a colossal work of implementing
> a fully functional engine.
>
> Now we would like to bring it back to the times when we were developing
> SCUMM, Simon (AGOS), FOTAQ, Sky, Sword1/2 and other relatively early
> engines.
>
> The current rules for the engines to be included are becoming the
> following:
>
>    1. Any ScummVM developer or person vouched by at least one ScummVM
>    developer is welcomed to develop their engines in-tree.
>    2. That means, that even the half-baked engines or starting ones are
>    OK to be merged or even started right in the tree.
>    3. The engine inclusion is announced on the scummvm-devel (if
>    developed from the scratch) or passed as a PR with 2 weeks provided for any
>    objections or comments.
>    4. However, if the engine is not yet complete, and the author is not
>    active for 6 months or more, or when the engine is not being developed for
>    12 months or more, the engine could be removed from the tree. Most probably
>    we will create 'scummvm-attic' repository, which will be synced with the
>    main tree right before the removal of such engine.
>
> This hopefully will make the ScummVM development more vivid and
> pronounced, the engines will benefit from the buildbot, and the porters
> could try the new engines earlier on their platforms.
>
> Which also leads to another topic. The project scope.
>
> ScummVM started as a reimplementation of the SCUMM engine, but by the
> 0.2.0 it has been including the AGOS engine as well. In the years of
> development we gradually faced with the engines which embrace non-adventure
> genres, and those games were accepted. By these days we have 56 game
> engines in-tree which support the vast majority of the most popular 2d
> point-and-click adventures. This lead to the point that most of the ScummVM
> developers have their best adventures supported and their interest got
> diminished. With the same time, there is a big interest in the developing
> of games from the adjacent genre, which is RPG.
>
> Thus, I would like to announce that the scope of ScummVM now embraces both
> 2d point-and-click adventure engines, as well as 2d RPG engines.
>
> That means that the Dungeon Master GSoC task could be merged right
> in-tree, and also the current work of Paul Gilbert aka dreammaster with the
> Xeen engine could also be merged. However, the fully 3d games are out of
> scope due to the technical reasons and completely different requirements
> for the backends and infrastructure.
>
> To sum up:
>
>    - Now the engine development is welcomed to be in-tree as early as the
>    engine author wants (with the requirement to be active).
>    - The ScummVM scope includes RPGs.
>
> As a side note, the official scope description of the project will be
> adjusted once we announce support for our first RPG engine.
>
>
> Eugene Sandulenko
> ScummVM Team Lead
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning
> reports.http://sdm.link/zohodev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20160718/bd6e0c33/attachment.html>