We should catalog all the failed attempts so far. Perhaps on this website. A couple of things they all had in common is that
1. With I think
one exception, everyone skipped middleware and tried to
make their own engine. So a lot of work got duplicated.
2. They were all closed source. Some intentional. Others due to
data loss. (I can't speak for what happened to Cyberion's No Hope project though. He had some collaborators, so someone has the source code?)
So no one could continue where any of them left off, even with documentation. I am hoping that a Doom Total Conversion will solve that problem as it is open source, widely documented, and has a large community of modders with 30+ years worth of banked resources. So trivial things like co-op/multiplayer maps will get automatically made once the basic building blocks are assembled. I for one will be borrowing heavily from P.Rex's work on CrusaDoom once I start think about making a class inheritance structure for every entity in the game.
The development journey needs to be modular, with definite break points where it is easy for someone else to pick up. For example, I can leave this project after making sure that an isometric mode is available in GZDoom, is well documented on the wiki, and has project templates on open source repositories. Another good break point will be after porting all the textures and maps, or porting some maps and documenting how it was done. A third one might be importing all entities of a certain class (say non-interactable but destructable objects, or all missile weapons) into zscript code. At every stage, even if a Crusader project doesn't happen, all the work will get used in other projects easily.
Judging by how the Doom mod scene works, popular things get enhancement packs made all the time. Upscaled textures with PBR material shaders, dynamic lighting additions to level maps, weapon packs, improved monster AI, voxels, and so on. You can just look up these things for existing doom mods, including OG doom.
The biggest downside to GZDoom (and by extension, VKDoom) that I think will never have a solution to is the physics engine. All actor collision boxes need to be cuboids with a square base, even if they are rendered as complex 3D models that get accurately lit by the renderer. And these cuboids can't rotate. They are eternally oriented to the global axis. But hey, if Selaco made it work ...
Another minor snag will be the lack of path nodes for monster AI. A dev actually made a PR to the main code with an actor-based path node system but it got rejected by the maintainers, as they want a surface-mesh based navigation eventually. But it is possible to implement that from the mod side of things. P.Rex used basic doom built-in AI and got the droids in CrusaDoom to behave pretty well. The zombie reskins for the basic soldier looked off because they didn't put too much work into it. They were using custom publicly shared actors from realm667 (the stabby labcoat scientists).
