> These sort of projects tend to be pretty large and also fairly binary: either it's complete, useful, and playable, or it's not (yet) complete and it's unplayable and useless.

Everything is "binary" if you choose an arbitrary cutoff point.

Your example of ScummVM is a bad one: in ScummVM there are games that show nothing but a title screen, games where about half of the game works, games that are completeable but are lacking some aspect (e.g. music/sound effects/animations), games that are perfectly playable and completeable, and even games that have improvements upon the original games. The whole spectrum is present in ScummVM's engines at almost any point in time, as there are new engines constantly being added and others perfected. A game that's completeable but lacks music, for example, is certainly not "useless".

The fact that many of these engines are not (yet) complete is certainly not exclusive to game reimplementations. There's hardly any open-source project or game that declares itself "complete"

Eh, you are getting in wrong. There are lots of complete game engine reimplementations with most of the bugs fixed. They run far better than the original game engine on any new OS.

If any, it's good to have working WIP projects and reimplementations for games such as Resident Evil so they don't require emulation any more and thus they could run fast as hell on an Atom netbook.

> There are lots of complete game engine reimplementations with most of the bugs fixed. They run far better than the original game engine on any new OS.

I never said that's not the case.

> I don't think that requiring the original game files is a huge hurdle

It can be, because unless the game comes with all its own assets, it can't be a friction-free install for the end-users.

You can't expect to get the success of OpenTTD if you're unable to put the game on steam, and you cannot put it on steam if it won't run without the original game (which won't be on steam).

There other question of successfully cloning a game is "Will we ever be able to replace the requirement of needing the original game's files?"

With 2D games the answer is almost always "Yes, we can sooner or later have replacement 2D assets".

With 3D games you can forget about it; the effort and skill level is too high for volunteers to make it happen.

> With 3D games you can forget about it; the effort and skill level is too high for volunteers to make it happen.

Not necessarily true. I can churn out game-ready 3D assets pretty quickly and I can't draw anything 2D at all. There's a lot of tools for 3D modelling and texturing that can provide some sort of automation to a degree (e.g. Houdini or even Blender's geometry nodes for procedural stuff [landscapes, mechanical stuff], Substance Designer for procedural materials, Mixamo for premade animations for virtually any scenario that you can simply attach to your models etc.). AFAIK there's nothing like that for 2D.

2D, while maybe fun to draw on a piece of paper, requires a lot of painful manual labor when working with games, e.g. you need to draw all animation frames separately instead of simply keyframing some skeleton as in 3D. Just imagine the process of changing a simple thing like a piece of clothing on a character.

> With 2D games the answer is almost always "Yes, we can sooner or later have replacement 2D assets".

This is really not true for most 2D games. For something like OpenTDD where the art is mostly functional and replacting it will still give you about the same experience as TDD, sure. For something like a Point & Click adventure? Nah, the art and scripting is the game, you might as well create a completely new game at that point. The distinction really has nothing to do with 2D vs. 3D.

That just means that you need twice the programing effort. Part one is a game play engine, part two is a game content creator engine. Then of course your need to attract people who want to create a game but are not programmers. Of course to create a game of that type needs some programming skills, but the level is - or should be - a lot less than writing the engine.

A good game engine with good tools can save users who want to write that type of game a lot of effort. You shouldn't have to write collision detection algorithms to give the user a sword/gun/magic spell.

I honestly don't see a point to creating "replacement 2D assets" for old LucasArts and Sierra adventure games. As far as I know, every single one of those classic adventure games runs great inside SCUMMVM. So why not just buy any of the games you want to play (from GOG) and run it through SCUMMVM? I bought Quest for Glory I-V for like $10. Indiana Jones and the Fate of Atlantis is $5.

Looks like some of the original Monkey Island games were taken off the site and replaced with remakes, much to fans' dismay. I suppose there are other ways of tracking down the originals.

> I suppose there are other ways of tracking down the originals.

Har, har!

> some of the original Monkey Island games were taken off the site and replaced with remakes

MI and MI2, replaced with a 'Special Edition' which does include 'classic mode'.

Industry is not ready for leasing the assets to the end-users. Yet, I hope.

> For something like OpenTDD where the art is mostly functional and replacting it will still give you about the same experience as TDD, sure. For something like a Point & Click adventure?

I think the reason for this is something you haven't considered: OpenTTD is extremely repayable, long-term fans of this game put thousands of hours into it. An old Point & Click adventure? Long-term fans might replay the game a few times every few years, but I don't think those sort of games will ever inspire the amount of invested effort that OpenTTD can.

Or consider Morrowind, closer to a Point & Click in concept (the art and scripting is a big part of the draw), but known to be a huge time sink that people can easily put thousands of hours into. And again, you see a very high level of investment from the community. Lots of total graphics replacement mods, mods that add huge new levels dwarfing the original game, etc.

The Steam release of openttd is incredibly late in the life of the project. I don't know how much it affected the users, but it was certainly well known and established before it was on Steam

OpenTTD was well known and popular for it's genre. Placing it on Steam, GoG and Microsoft Store was more about just making it more accessible and convenient for players to download and update, as users were already providing simple installs for the various Linux distributions, Docker, Flatpack etc.

    These sort of projects tend to be pretty large and also fairly binary: either it's complete, useful, and playable, or it's not (yet) complete and it's unplayable and useless. There's a bit of grey area, but a lot less than many other projects.

Kinda hard disagree there, I guess. I’m following both Dethrace which is source port of Carmageddon, and OpenGothic2 which is source port of Gothic 2. And both of those projects were massive fun to play before even reaching feature parity. You just need to get your project to the point where game can be completed and there is no crash every 5 minutes.

"Full feature parity" is probably a bit too much, yeah, but to get to a "game can be completed" stage often requires a lot of effort, and it's hard (not impossible, just hard) to attract a community before you get to this stage.

Getting to this stage is often the biggest hurdle for these projects, not the lack of free resources.

> I don't think that requiring the original game files is a huge hurdle, unless the game is very esoteric and hard to find. There are many widely-used game engines that require the game files, such as ScummVM, Rollercoaster tycoon, etc.

But then the question is: Why not use the original game with ScummVM, DosBox or a VM (with whatever OS necessary)?

Running a VM is hard-ish, and in a reimplementation will usually run better on modern systems, may have additional features, support for things like modern resolutions, bugfixes, etc.