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

James Lacey jamlacey at gmail.com
Wed Aug 14 00:29:53 CEST 2013

As someone on the outside looking in, I support this. I am working on an
engine for an old RPG. It is a hobby project, life has gotten in the way
and long stretches of time have passed without me being able to work on it.
Maybe I won't ever finish it. But, it was because of all of those things
that I was attracted to extending ScummVM with another engine instead of
starting a game engine remake totally from scratch.

I think having a core OSystem library, or even just a better way of
building engines out-of-tree, will attract developers and be beneficial to
ScummVM. I was told that my engine would not be eligible for inclusion in
ScummVM, but some developers expressed interest in seeing something like an
RPGVM project. This move would allow that to grow organically over time and
in a way that would potentially benefit both projects. ResidualVM is a
special case because they are doing 3D and a fork really does make sense
there, where it wouldn't for other 2D genres. Right now, to start an RPGVM
project, someone would have to fork ScummVM and maintain that when, the
effort to maintain such a fork could be avoided to the benefit of both
projects. In a library situation, contributors from both projects could
much more easily improve OSystem. And genres that some would like to see
work done on, could be maintained separately and, at least initially,
installed on top of ScummVM, until there was a movement to organize a
project around them.

Matt said he saw no benefit having a core library. In the strictest sense,
that might be true, since the benefits are hypothetical right now. But I
also think that view is a little short-sighted. I wasn't present for the
discussion, but IMO it would have been a shame to use the same argument to
block the inclusion of non-SCUMM adventure games way back when. Making it
easier for people to contribute and easier for people to work on the games
they want to work on, even if not adventure games, could pay dividends.
ScummVM could stay strictly about 2D adventure games, but get the benefit
of more people working on a variety of projects contributing back to its


On Tue, Aug 13, 2013 at 5:18 PM, Johannes Schickel <lordhoto at gmail.com>wrote:

> On 08/13/2013 09:57 AM, Arnaud Boutonné wrote:
> > If the plan is to tell to people "fork and do whatever you want, we
> > don't give a shit", then we could spare a lot of time and potential
> > regressions if we just keep what we currently have, as it's precisely
> > how we proceed currently. People are forking, implementing things,
> > which rot forever as we explicitly don't care.
> >
> I am not sure where I claimed we will say "fork and do whatever you
> want, we don't give a shit". But I think it might be worth to point out
> how the current situation is for anybody who wants to use our core code:
> Right now they would create their own copy of the ScummVM repo. Then
> they have to strip out all the ScummVM specific bits, that is logos,
> engines, engine credits, README etc. Finally they will have to add
> substitutes for these bits with their own bits. This means they have all
> sorts of changes to files which are also in the ScummVM repo.
>      Then consider the point where we make a change in the core and they
> want to benefit from it. They would try to do a merge from our
> upstream's master. This will result in them having a ton of possible
> conflicts in case some files have changed in master which they had to
> replace to make use of our core. Then they have to resolve all these
> changes everytime that happens.
>      Alternatively, they can do what Residual seems to do which seems to
> be copy over all the changes by hand and worry about it with even more
> manual effort.
> These are all very tiresome and pretty annoying bits. My suggestion was
> trying to have a core where people would not need to replace anything.
> Then if there's changes to our core code they can simply do a merge and
> only need to adapt their code if there's any API or smiliar changes.
> This way it should be much *easier* for them (yes, easier for
> outsiders!). The creation of forks of a core repo for starting a project
> is a *technical* bit. It is in no way connected to whether they want to
> be a ScummVM sub-project or not.
> This is an *improvement* over the current situation. That is, instead of
> "we don't give a shit" I want to make life easier. Thus, I completely
> fail to see your point here. I started this discussion to make life
> *easier* for everybody and I'm get complained about for that. That is
> pretty hypocritical in my eyes.
> > Even worst, at some point we may be tempted to ask developers to
> > choose their camp and leave one of the projects, after some dispute
> > between the two projects
> I am not sure but I have the feeling you want to make people make this
> decision when they want to take advantage of our core code. That is
> either they join ScummVM or "you don't want to be one of us, so go away,
> but we hate you and don't want you to have an easy life". I'm really
> against such a policy.
> My idea would have been to encourage people using our core by making
> things *easier* for *them*. This way we have people working with our
> core, which in turn might make them have great ideas of improvements for
> it or even making actual improvements. Thus, we open a new door to gain
> developers who help us improve our code. These developers might not have
> a background of being interested in ScummVM itself. If they then realize
> ScummVM is a cool thing let's help there too, then that's great and we
> should of course welcome them. Opening such a door makes much more sense
> than treating people only interested about our core as second-class
> citizens. It is important to realize that if our core improves we also
> benefit from that.Thus, I see no reason to force them into joining a boat.
> >
> > At the opposite, I see essentially positive points in organizing the
> > efforts around the core code, under a ScummVM hat. sub-projects key
> > users would be identified and could be informed of changes by the core
> > team, could suggest new functionalities without getting flamed, and
> > they could ask for resources on punctual issues already handled by
> > ScummVM team: hosting, forum configuration, buildbot, whatever. The
> > other way round, I'm convinced that a new developer of such a sub
> > project would have better chances to contribute to ScummVM if he feels
> > he's part of the family.
> >
> I think I didn't talk about how we organize core development so far. But
> yes, having, for example, a mailing list to notify core users about
> changes and for them to bring in suggestions, is a good thing.I think we
> can talk about that again when we are ready for the actualy step. Thanks
> for these suggestions.
> > The way we act currently, such a developer would feel completely out
> > of the game and wouldn't mind about ScummVM, except maybe for its core
> > changes.
> >
> If a developer using our core helps in making our core better, he *is*
> helping (and also contributing to) ScummVM and also himself. I have a
> feeling you make that sound like a bad thing simply because he isn't
> interested about ScummVM itself. In fact, I completely fail to see why
> it should be a bad thing that someone isn't interested in our adventure
> game engines (and thus ScummVM) and *still* helping the project.Making
> people feel bad about this definitly is not going to help us get any new
> contributors.
> Greetings,
> Johannes
> ------------------------------------------------------------------------------
> 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/20130813/f684cbf7/attachment.html>

More information about the Scummvm-devel mailing list