First I would like so see LZDoom added as it is a fork of GZDoom that aims to have lower required specs and can run on more systems, even older ones, this can go well on either rock or rome, as it will give users with crappier PCs and laptops a better experience with doom.
Another thing that is definitely needed is a launcher for doom mods like either QZDL and DoomRunner (graphical), or twad (TUI), which makes launching doom with many mods way more easy and user friendly.
a few optional things to add, but not as important is Zandronum, QZandronum, and DoomSeeker, which zandronum is a skulltag based source port centered around mutliplayer modded doom, and doomseeker allows players to find doom games that are open like Master of Puppets, Mega man 8 bit deathmatch and so on.
(it is also worth noting that the main fork GZDoom is nowadays horribly optimized and can barely run above 35FPS even on lowest possible scale. The community around GZDoom from what I could gather has also been known to be to some degree toxic and will even lie and say GZDoom IS optimized and it’s the mods that run on it that are not, but running those same mods on LZDoom prove otherwise.)
Everything has to be tested in Cooker first. Then the stable version of Cooker becomes ROME. After ROME is good for a while, we bring it down to Rock.
Are you going to be able to spin up an install of Cooker or some other method to test the results of the packaging? Do you have any experience with compiling these engine mods? Would you be willing to package it?
I could download cooker and compile LZDoom, which I kind of know how to compile to some extent, but right now I am tired… and I am usually too lazy.
I could also compile twad, but yeah…
As for how it works, I am aware on how it all works, I am saying for the future, LZDoom is a good choice especially for more stable OSes as it has a slower release schedule.
Hopefully you can. Someone is going to have to own the wad files or there won’t be a good way to test it.
It depends on how slow. We tend to package things that are actively developed. There are packages that release slower that we have (i.e. awesome and nheko) but we tend to expect they are at least making some progress on it as we don’t want to hold back libraries if we can absolutely help it.
Another option is flatpak or appimage with the caveat that support will have to be requested from the authors because they are self contained.