Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - snover

#1
Hi all, ScummVM team developer here. I was notified about this thread and figured that I might offer some feedback and be available to answer any other questions you might have. There is a lot of great productive discussion occurring here already, so in this initial message I am going to just try to address some of the broader concerns I see raised, instead of trying to quote-reply to every thought. I will do my best to get more specific in response to any questions you target at me, since there are some good specific questions which have been raised but maybe not satisfactorily answered, so let me know which of those you would like me to address.

ScummVM's core system is designed to be pluggable with different graphics backends. Right now SDL and OpenGL are the two which are available, and I know a couple of people have been working on creating another one using Qt. I would not rate these APIs as being perfect or immutable. There is definitely room and reason to make improvements. I and a couple other active team members have been working on getting rid of some of the worst brokenness of the core graphics system, and having more interest and engagement from others would be a huge plus here. I would really like to make OpenGL the default renderer, which means doing some more work to bring it up to feature parity with SDL, and, I don't have the time or energy to do it myself.

One of my medium-term (3-6 month?) aspirational goals is to merge ResidualVM (the 3D game counterpart of ScummVM) into ScummVM proper. Assuming that this happens (informal feedback I've requested from team members on both sides has been all positive so far), there will be more feature availability for 3D games, and we do already have platform restrictions (as noted in one of the last posts) so there is no concern in my mind in that regard. It is obvious to me that the present and future state of games computing involves GPU programming, so ScummVM is going to need to be able to facilitate this sooner or later anyway or else never be able to support anything after the early 2000s. Having more developers on board with this vision and desire will make it easier to realise such changes.

ScummVM contains portions of code licensed under less restrictive licenses than GPL, so alternative licensing for some features is probably fine so long as the chosen license is GPL-compatible. I am not very familiar with Artistic License, but what I have read seems to indicate that version 2.0 is both GPL-compatible and also includes a relicensing clause which should allow for little trouble with any older code carried over (assuming AGS is using AL 2.0). I don't know what this would look like for an entire engine, I am at least not opposed to exploring reasonable solutions.

With regards to the non-library code and ports baggage, these are points of contention for me already and I plan on making a serious proposal to try to get some better goals in place which prioritise improving the end-user experience for the majority of our users, and improving the developer experience by offering more modern features to engage and retain developers, over choosing to have the absolute largest number of ports. When I look at our latest 2.0 release statistics and see we have 9787 Windows downloads against 30 Dreamcast downloads, it's pretty obvious to me that we are not serving anybody with the current approach. Having a new group of developers saying that they really want to help make ScummVM better, and are quite reluctant do so if they must be saddled with such legacy baggage, does help to strengthen the argument that the project needs to reorient.

I am personally also not opposed to the idea of using ScummVM as a base for some newer engine developments. I don't see this as being any different than development of brand new engines or enhancements to existing engines, as they all involve the same amount of risk in terms of adopting technical debt. So long as there is a reasonable process for change management, and the engine doesn't get into another state where old games become broken due to backwards-incompatible changes (= bad user experience), I'm willing to support such an initiative, especially if it means we'll get some more folks willing to put in the work to maintain the core system.

With all of these things, caveats apply: I am not the one in charge of ScummVM, so I cannot make any guarantees. I can only state my own desires and goals for the project direction, and express my openness in working with you to figure out if this idea makes sense, and if so, how to move forward.

Thanks for reading, and I look forward to your feedback.
SMF spam blocked by CleanTalk