[Scummvm-devel] Bringing our Core Code to another Level?
bluegr at gmail.com
Mon Aug 12 20:52:59 CEST 2013
Also, will changes to OSystem still be discussed among all ScummVM
developers? Or will they be discussed among the "core team" members only?
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?
> 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
> 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.
> 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).
> 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
> >>>> name on it except for credits to its origins) project would be a
> >>>> nice thing to do in the long run.
> >>> Now I completely fail to understand why we should not brand it as
> >>> Library or ScummVM OSystem Library. Removing "ScummVM" brand from the
> >>> library title would diminish invaluable volunteer efforts of hundreds
> >>> developers who made it exist in the first place.
> >> The branding isn't the name, though. If we leave it branded "ScummVM",
> >> third-party projects would ship their binaries with "ScummVM" branding
> >> over it. I don't think we want that (for support reasons if nothing
> >> 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
> >>> 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
> "Experience is the name every one gives to their mistakes" - Oscar Wilde
"Experience is the name every one gives to their mistakes" - Oscar Wilde
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scummvm-devel