[Scummvm-devel] Bringing our Core Code to another Level?

Arnaud Boutonné strangerke at scummvm.org
Mon Aug 12 21:04:11 CEST 2013

Thus the idea of an umbrella, in which ScummVM core team and the people
responsible of sub-projects would synchronize and work in good cooperation.
If we don't structure the way we work together, the result will typically
be a core team working only with ScummVM and orphan sub-projects, just like
we would have today if someone fork the project to support some other type
of games.


On Mon, Aug 12, 2013 at 8:52 PM, Filippos Karapetis <bluegr at gmail.com>wrote:

> Also, will changes to OSystem still be discussed among all ScummVM
> developers? Or will they be discussed among the "core team" members only?
> Regards
> Filippos
> On Monday, August 12, 2013, Filippos Karapetis wrote:
>> I find this a very good idea as well. We could separate the core OSystem
>> from the engines themselves, and extend its usage to other, non-adventure
>> 2d/3d games.
>> I assume that the plan is to split the project into two separate ones,
>> possibly with different maintainers per project. Thus, engine developers
>> will not have write access to OSystem itself, right? Again, I assume that
>> only the "core team" (LordHoto, wjp, fuzzie, possibly others too?) will
>> maintain the OSystem project? Or will all developers have write permissions
>> to the OSystem core?
>> Regards
>> Filippos
>> On Monday, August 12, 2013, Paul Gilbert wrote:
>> I'd certain be in favour of a scheme like that, speaking from experience
>> as someone who's also interested in re-developing non '2D point and click
>> adventure games', as well as other genres. I think we'd all agree that
>> ScummVM has a pretty sophisticated and mature core, and would love to see
>> it made more accessible to people planning their own reimplementation
>> projects.
>> As I see it, there are two parts of the discussion. The technical and
>> managerial. For the technical, as already discussed, some separation of
>> ScummVM into the core library that could be easily shared would be ideal.
>> As for the managerial, I haven't been involved in any discussions with
>> companies as Arnaud has, but his argument makes sense to me. There have
>> been offerings from certain companies in the past other than the 2-D
>> adventures, and having that option open still in the future, would IMHO, be
>> a good thing. As Arnaud says, we could have authorised ScummVM micro groups
>> for things outside ScummVM perview. So, for example, if we get more RPGs in
>> the future, we'd have the option to smoothly implement support and provide
>> executables for them without having to have them as part of the main binary
>> engine list.
>> This may even have some side benefits for the main project, in that game
>> companies that have seen our track record with any of their games may be
>> more inclined to release other suitable adventure games for the main
>> project later on.
>> Paul.
>> On Mon, Aug 12, 2013 at 12:50 PM, Arnaud Boutonné <strangerke at scummvm.org
>> > wrote:
>> Hi everybody
>> Concerning the branding, I can tell you that the name 'ScummVM' is very
>> well known and is a real help when you contact people. In my case, it's
>> essentially in order to discuss about legal rights, sources and
>> distributing games.
>> So, wouldn't it be possible to imagine some kind of umbrella
>> organization, with micro-orgs lying under , and try to structure something
>> based on that? the micro-orgs would benefit the aura of ScummVM and it's
>> core, and could focus on specific engines specifcally rejected by ScummVM
>> (Arcade games, RPG games, whatever).
>> Regards,
>> Arnaud
>> On Mon, Aug 12, 2013 at 6:24 PM, Einar Johan Trøan Sømåen <
>> einarjohants at gmail.com> wrote:
>> The various sub components are somewhat interdependent, i.e., surface
>> is used a lot in video/, and almost anything in Common/ is used more
>> or less everywhere.
>> Den 12.8.2013 kl. 18:14 skrev Adrian Astley <adastley at gmail.com>:
>> > What if we were to create individual libraries for different subsets
>> > of the core? Aka, have one .lib for graphics, one for audio, etc. That
>> > would allow third parties to choose which parts they want and which
>> > they don't.
>> >
>> > RichieSams
>> >
>> >
>> > On Mon, Aug 12, 2013 at 11:05 AM, A. Milburn
>> > <fuzzie at users.sourceforge.net> wrote:
>> >> On Mon, Aug 12, 2013 at 06:52:00PM +0300, Eugene Sandulenko wrote:
>> >>>> I think such a split off core resulting in an unbranded (i.e. no
>> ScummVM
>> >>>> name on it except for credits to its origins) project would be a
>> really
>> >>>> nice thing to do in the long run.
>> >>>
>> >>> Now I completely fail to understand why we should not brand it as
>> ScummVM
>> >>> Library or ScummVM OSystem Library. Removing "ScummVM" brand from the
>> >>> library title would diminish invaluable volunteer efforts of hundreds
>> of
>> >>> developers who made it exist in the first place.
>> >>
>> >> The branding isn't the name, though. If we leave it branded "ScummVM",
>> then
>> >> third-party projects would ship their binaries with "ScummVM" branding
>> all
>> >> over it. I don't think we want that (for support reasons if nothing
>> else).
>> >>
>> >> Obviously it would be pointless to remove the ScummVM name from e.g.
>> the
>> >> credits or the source code or whatever; as Johannes said, we'd want to
>> >> make sure that the origins of the code was clear and credited in any
>> case.
>> >>
>> >>> I agree that it is a good idea to put OSystem and Common code into a
>> >>> library, but it should stay within main scummvm github repository and
>> be
>> >>>
>> --
>> "Experience is the name every one gives to their mistakes" - Oscar Wilde
> --
> "Experience is the name every one gives to their mistakes" - Oscar Wilde
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20130812/e33c1afa/attachment.html>

More information about the Scummvm-devel mailing list