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

Mon Aug 12 21:12:22 CEST 2013

Also, as far as I know, the Core Team is currently LordHoto, sev and wjp...
But that's a detail.
Arnaud

On Mon, Aug 12, 2013 at 8:49 PM, Filippos Karapetis <bluegr at gmail.com>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
>> >>> branded as ScummVM.
>> >>
>> >> Well, putting it in a *library* would make no sense, it's only useful
>> as
>> >> a whole integrated binary.
>> >>
>> >> Right now any third-party project is clearly a "second-class citizen":
>> >> they'd have to keep their own copy of the repository and merge ScummVM
>> >> into it manually (as ResidualVM does), and manually modify a huge
>> number
>> >> of files. Having it separated (although not necessarily in a different
>> >> repository) is the only way I can think of dealing with that.
>> >>
>> >> - Alyssa
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> 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
>> >> ________________________
>>
>>
>
> --
> "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/ae941140/attachment.html>