Page 5 of 7

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 06:57
by Chris
drakovyrn wrote:
16 Sep 2018, 04:10
I meant in general. opendf has been mentioned a few other times in previous posts, and that's honestly the only reason I know it exists.
I guess it's because it's the closest OpenMW-like project for Daggerfall, free/libre and open source, utilizing similar low-level libraries.
Still, yes, Unity isn't Open Source. I don't even like it as an engine in general. Nonetheless, Open Source is about Open Source, and no matter what happens to Unity (lost support, deprecation, etc.), the source code and logic contained in the DFUnity project will still be openly available to any who wishes to port the logic to another (open) engine (such as Godot), or to more in-depth methods of implementation.
DFUnity's code, by itself, isn't enough to do anything. A working executable for DFUnity requires non-FOSS code. If a working executable for OpenMW or any other of the listed projects in this thread relied on non-FOSS code, it wouldn't be suitable for this list either. Again, that's not to downplay the work Interkarma has done, or to say it's not a project worth checking out, but if you're asking for game engine replacements that are FOSS, it would be disingenuous to list projects that require non-FOSS code.

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 18:51
by wareya
Unity is basically a very elaborate platform library or VM or whatever you want to pretend it is. Using it as a target doesn't make the project itself stop being FOSS. Same with things like game maker. Likewise, any FOSS projects that run on proprietary gaming hardware don't suddenly become "true FOSS" just because a FOSS emulator for that hardware becomes available, they were FOSS all along.

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 21:02
by AnyOldName3
I think the general consensus is pretty much in line with whether or not the GPL's system library exemption applies. It does with the API of an OS or the actual hardware, but it doesn't with middleware like Unity.

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 21:17
by wareya
That's about the GPL's system library exception, not whether a non-GPL project is FOSS or not. FOSS is not defined by the GPL.

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 22:06
by AnyOldName3
That's why I said it was in line with the GPL's opinion.

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 22:43
by wareya
Yeah, some people think that way about FOSS because of the GPL, but the GPL shouldn't have that kind of influence on how people think about FOSS. The GPL is absolutely not a good standard for what kinds of dependencies should render something no longer FOSS.

Game maker is proprietary. Let's say someone makes a FOSS game maker clone that has some level of compatibility with games made for game maker. Do all those open source games made for game maker in the past suddenly become FOSS retroactively? What about just the compatible ones? No! They were FOSS the entire time! (PS: this is a real example.)

Re: List of (other) FOSS game engine replacement projects

Posted: 16 Sep 2018, 23:10
by Chris
wareya wrote:
16 Sep 2018, 18:51
Unity is basically a very elaborate platform library or VM or whatever you want to pretend it is. Using it as a target doesn't make the project itself stop being FOSS.
But along that vein, is a FOSS project that requires a non-FOSS component to be complete, actually FOSS? The DFUnity code on its own is not an engine replacement, it doesn't do anything on its own without a specific "platform library" to function.

Put another way, can I take a working DFUnity executable, get the full source code needed to rebuild it, and treat the whole of the code as a FOSS project (change, redistribute, etc, as I see fit)? For OpenMW and the like, the answer is yes. Every component required in making an executable is FOSS. The fact that it can run on a non-FOSS platform is irrelevant; it can equally run on FOSS platforms, which are officially supported. This is not the case for DFUnity, which is designed for and only supported on Unity, which has proprietary restrictions. There is no officially supported way to use it that doesn't rely on proprietary code, as there is no Unity-compatible FOSS alternative.

It'd be like claiming Doom3 was open source upon release, because the game code (for controlling the game behavior and AI) was available and redistributable. The idTech4 engine was just a very elaborate (closed, proprietary) platform library, but the source code controlling the game was still available and could be ported to another (FOSS) engine if someone had the inclination. Of course such a claim would be silly... the available code isn't designed to be used elsewhere and nothing properly interfaces with it; the original proprietary engine/"platform library"/whatever was still necessary to make a complete executable for a functioning game, despite the state of the core game code.

EDIT:
wareya wrote:
16 Sep 2018, 22:43
Game maker is proprietary. Let's say someone makes a FOSS game maker clone that has some level of compatibility with games made for game maker. Do all those open source games made for game maker in the past suddenly become FOSS retroactively? What about just the compatible ones? No! They were FOSS the entire time! (PS: this is a real example.)
I would take it a step further and say they still aren't fully FOSS until the individual projects officially support said clone, and do whatever work necessary to keep them working. Otherwise, using that logic you could just as easily claim Skyrim and Dishonored 2 are Linux games, because a Windows compatibility layer lets Windows games work on Linux. Doesn't matter that one of them might not actually run right now (Dishonored 2), or that the developers/publisher never guarantee they will work, but the entire time they weren't doing anything Linux couldn't do and were just missing a Linux compatibility layer.

When a FOSS clone layer comes up, the open source games made for the original proprietary version don't automatically become fully FOSS, either. They become fully FOSS at the point that the maintainers say the FOSS clone is a supported way to use it. If the maintainers want to say older versions made before the FOSS clone was released are officially supported, then yeah, those versions retroactively become FOSS. Similarly, a Windows game working in Wine or Proton in the future doesn't make it a Linux game; however, it would become a Linux game when a developer/publisher releases a working Wine-wrapped version and says it's officially supported.

Re: List of (other) FOSS game engine replacement projects

Posted: 17 Sep 2018, 09:52
by psi29a
drakovyrn wrote:
16 Sep 2018, 01:56
For me, and many other people that actually play and love DF, we know that DFUnity is where it's at, even if most of the openmw team still tends to shy away from it.
Please don't paint us with your brush, you're doing us a great disservice and we can speak for ourselves.

I for one, love DFUnity and talk with Interkarma regularly. There are others here who have worked on OpenMW that also commit/contribute to DFUnity.

Re: List of (other) FOSS game engine replacement projects

Posted: 17 Sep 2018, 16:47
by silentthief
Chris wrote:
16 Sep 2018, 23:10
But along that vein, is a FOSS project that requires a non-FOSS component to be complete, actually FOSS? The DFUnity code on its own is not an engine replacement, it doesn't do anything on its own without a specific "platform library" to function.

Put another way, can I take a working DFUnity executable, get the full source code needed to rebuild it, and treat the whole of the code as a FOSS project (change, redistribute, etc, as I see fit)? For OpenMW and the like, the answer is yes. Every component required in making an executable is FOSS. The fact that it can run on a non-FOSS platform is irrelevant; it can equally run on FOSS platforms, which are officially supported. This is not the case for DFUnity, which is designed for and only supported on Unity, which has proprietary restrictions. There is no officially supported way to use it that doesn't rely on proprietary code, as there is no Unity-compatible FOSS alternative.

It'd be like claiming Doom3 was open source upon release, because the game code (for controlling the game behavior and AI) was available and redistributable. The idTech4 engine was just a very elaborate (closed, proprietary) platform library, but the source code controlling the game was still available and could be ported to another (FOSS) engine if someone had the inclination. Of course such a claim would be silly... the available code isn't designed to be used elsewhere and nothing properly interfaces with it; the original proprietary engine/"platform library"/whatever was still necessary to make a complete executable for a functioning game, despite the state of the core game code.

...

I would take it a step further and say they still aren't fully FOSS until the individual projects officially support said clone, and do whatever work necessary to keep them working. Otherwise, using that logic you could just as easily claim Skyrim and Dishonored 2 are Linux games, because a Windows compatibility layer lets Windows games work on Linux. Doesn't matter that one of them might not actually run right now (Dishonored 2), or that the developers/publisher never guarantee they will work, but the entire time they weren't doing anything Linux couldn't do and were just missing a Linux compatibility layer.

When a FOSS clone layer comes up, the open source games made for the original proprietary version don't automatically become fully FOSS, either. They become fully FOSS at the point that the maintainers say the FOSS clone is a supported way to use it. If the maintainers want to say older versions made before the FOSS clone was released are officially supported, then yeah, those versions retroactively become FOSS. Similarly, a Windows game working in Wine or Proton in the future doesn't make it a Linux game; however, it would become a Linux game when a developer/publisher releases a working Wine-wrapped version and says it's officially supported.
Just to clarify - because I am still a little fuzzy on this definition. I follow another project, called 'Dungeoncraft' and you can find information on them here -> http://uaf.sourceforge.net/ - but this program only compiles/runs in windows because its currently built using the windows MFC. This then means that even though you can download the code and modify it, it is not FOSS because of that requirement? I am not arguing, I am asking to better understand what makes FOSS versus not.

ST the clarifier

Re: List of (other) FOSS game engine replacement projects

Posted: 18 Sep 2018, 00:16
by Chris
silentthief wrote:
17 Sep 2018, 16:47
Just to clarify - because I am still a little fuzzy on this definition. I follow another project, called 'Dungeoncraft' and you can find information on them here -> http://uaf.sourceforge.net/ - but this program only compiles/runs in windows because its currently built using the windows MFC. This then means that even though you can download the code and modify it, it is not FOSS because of that requirement? I am not arguing, I am asking to better understand what makes FOSS versus not.
If it requires Windows MFC to build and there's no supported FOSS alternative, then it would not be a FOSS engine. The project's code can be FOSS, but if you can only build a working executable by including non-FOSS components, then the thing people would actually play is not FOSS.