<div dir="ltr"><div>Hi all,</div><div><br></div>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.<div><br></div><div>Paul.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 3:39 PM, Eugene Sandulenko <span dir="ltr"><<a href="mailto:sev@scummvm.org" target="_blank">sev@scummvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Team,<div><br></div><div>This is the second letter which I am sending to you after discussion with wjp.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The current rules for the engines to be included are becoming the following:</div><div><ol><li>Any ScummVM developer or person vouched by at least one ScummVM developer is welcomed to develop their engines in-tree.<br></li><li>That means, that even the half-baked engines or starting ones are OK to be merged or even started right in the tree.<br></li><li>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.</li><li>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.</li></ol><div>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.</div></div><div><br></div><div>Which also leads to another topic. The project scope.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>To sum up:</div><div><ul><li>Now the engine development is welcomed to be in-tree as early as the engine author wants (with the requirement to be active).</li><li>The ScummVM scope includes RPGs.</li></ul>As a side note, the official scope description of the project will be adjusted once we announce support for our first RPG engine.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Eugene Sandulenko</div><div>ScummVM Team Lead</div><div><br></div></font></span></div>
<br>------------------------------------------------------------------------------<br>
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic<br>
patterns at an interface-level. Reveals which users, apps, and protocols are<br>
consuming the most bandwidth. Provides multi-vendor support for NetFlow,<br>
J-Flow, sFlow and other flows. Make informed decisions using capacity planning<br>
reports.<a href="http://sdm.link/zohodev2dev" rel="noreferrer" target="_blank">http://sdm.link/zohodev2dev</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" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
<br></blockquote></div><br></div>