On usage of reverse engineering for creating open-source game engines #264
Replies: 9 comments 7 replies
-
One of the main things with this was to avoid projects that use decompiled code directly, so reverse engineering the game is ok, but not just using the decompiled code directly, which alot of these projects do. I realize it's difficult to have a perfect rule for this. One of the things that I've looked at in the past is longevity, mainly that if the project has been around for quite a few years, without getting DCMA, like with what happened with re3. Games with leaked source code can also be tricky. One of the things that helps with Dominatrix is that I'm not actually hosting it, just providing a link to a download, although i wasn't aware of how it was created. I've thought about having another repository for certain decompiled games, at the moment that'd mainly add a bunch of maintenance costs, in terms of duplicated workflows and the like. The other problem with alot of those projects is they don't really have a clear license, like MIT or GPL, so it makes it alot harder to determine if I can actually distribute. That's only mostly related to it being a decompiled project, but shows another issue with those sort of projects. What sort of engines in this manner are appealing to you? |
Beta Was this translation helpful? Give feedback.
-
It makes sense to avoid duplicating the workflow with another repository, and on top of that, I will also suggest to avoid Rockstar games (e.g. GTA) and Nintendo (e.g. Mario 64 or Zelda) reimplementations, since the companies are too litigious to risk all the project. In any case, this is preliminary list of engines that could be nice to add is:
There are a few more, I can update this list later. |
Beta Was this translation helpful? Give feedback.
-
Games from Sega should be fine. They are very tolerant of fan projects and often encourage them, like when they hired the author of Retro Engine, originally a fan game engine recreation for Sonic 1-3, to make Sonic Mania.
|
Beta Was this translation helpful? Give feedback.
-
I'm just curious, do you know anything about this source code? https://github.com/NightDive-Studio/sin-ex-game |
Beta Was this translation helpful? Give feedback.
-
I'm not an expert, but I think that's only part of it, not the complete game. |
Beta Was this translation helpful? Give feedback.
-
Just converting this to a discussion, from an issue, to continue the thread. Thinking about the different repo idea, I could create re-usable workflows for the actions that are being run today, and a new repo could output a completely new json structure. I'm not 100% sure how that would manifest for use by the client yet, one option could be is that the new re json would have to be manually or automatically synced with the normal, or I could add to the client the ability to have multiple packagesjson and merge them. Then that repo could have re engines that aren't really applicable to the mainline, and users of the client could optin by adding it to their config. What do you all think of that? And would either of you be interested in being maintainers of a repo like that? |
Beta Was this translation helpful? Give feedback.
-
I like the idea of supporting multiple packagesjson, feels similar to the way it works now with user-packages.json. Separating the parts could also make Luxtorpeda more easy to adapt to different use cases out of the scope of normal Luxtorpeda; like applying patches or mods to games.
Sounds great. I've actually been thinking about making this for a while already :) If you're interested @neuromancer we could maintain it together. |
Beta Was this translation helpful? Give feedback.
-
I put up an organization with repositories here: https://github.com/decolux/ |
Beta Was this translation helpful? Give feedback.
-
I created #270 to track a new feature to be able to pass new packages.json sources alongside the default official one. Then that repo could be used accordingly. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I wanted to create an issue to discuss in detail the following statement:
If you are not interested in this discussion, feel free to close it.
The idea here is simple: most, if not all the reimplementations are based on reverse engineering (with the notable exception of source ports such the Doom ones). A few notable examples:
And there are many many others.
Some other engines relied on leaked source code, which is, IMHO, more legally questionable:
If you are looking to avoid reimplementations that rely on the usage of decompiled code directly (e.g. where they directly recompiled part of the source code, which end in the final executable), then it will be good know specify that. In particular how much original assembly code is acceptable (most of the projects will state how much original code is still left to replace, such as dethrace). On the other hand, there is the question of the legality of replacing every assembly line, similar to the Ship of Theseus.
If you still want to allow projects with decompiled assembly, but avoid compromising the legality of the other packages, one option is to use a different package repository (e.g.
github.com/luxtorpeda-dev/packages-re
). In that case, if GitHub decides to take down the certain game engine, it will not affect other packages.Beta Was this translation helpful? Give feedback.
All reactions