Skwirl wrote:I know I don't have a lot of weight here in the community, let alone any engine-related programming skill, but having only used the Zdoom derivatives as a base for my work in a little over a year, my only real suggestion would be to start a roundtable discussion with all the developer heads on all these zdoom-based sourceports, towards unifying everything these sourceports have to offer, into one ultra-capable, all-purpose, no-bs, maybe even totally overhauled, system.
Sorry, that won't happen, some explanations below.
The way I see it, Zdoom was designed on a pre-1999 codebase, and ever since then had to stay that way. As I learned it, it wasn't meant to make games on, but to keep the game itself, and mods for the same game alive, 20 years later. This is noble. But it brought up what I believe may be an issue: age, and bloat.
Changing this will change the soul of the game. So, clearly no. All that old code is absolutely necessary to play Doom the way it was designed.
To get GL support, it had to be forked.
No, it had to be forked because I was unwilling to deal with a release schedule that was decided by random decisions and because I wanted to have control over my own releases.
To get multiplayer support, it had to be forked.
And the reasons for that are still valid. A multiplayer-centered port needs an entirely different development strategy that will always be at odds with the mainline so it's best to be kept separate.
To have all the licenses removed so it can be applicable for commercial use, it had to be forked.
It had to be forked because the code base needed to be compromised to change the license. And to allow something completely free of potential issues it also had to change some of the base resources in gzdoom.pk3 which we are unwilling to do for the base engine.
Other sourceports use even older versions of it entirely. Now we have a whole bunch of sourceports that have different features so you would have to swap between one and another.
So? What does that have to do with ZDoom?
To remedy this, I say consolidate absolutely everything and keep these new features focused to make the same system better...
... and destroy what most people use the engine for. I have absolutely no interest in making an engine that deviates too much from the original game.
If you want to take it to an unnecessary but damn useful extreme, consider rewriting the entire codebase like OpenRA did. The entire thing was done from the ground up in C# and uses absolutely none of the original code. Download the content because it's free, and you are up and running with a whole slew of new and old features from the original game. This would be great, but I realize how insanely large a project this would be. Still, it makes for a continually-updating highly-moddable platform.
Good luck finding people who would undertake such a thing. And it wouldn't really solve anything. The old code needs to remain because it's what makes Doom. It may be translated into another language but the bad decisions that cause all the quirks cannot be removed without destroying everything.
I also highly support purging all of the non-libre materials. Both GLOOME and GZdoom-GPL have proven that the game can still run and beautifully without that code. In the new age of FOSS, it's silly to hold on to the 1997 DSL when people are making completely out-of-this-world mod projects that aren't even remotely similar to the Doom experience and could probably be great commercial titles.
Of the 3 things that still pose a problem:
- FMod may be refactored into a plugin, this is certainly something I'll investigate, now that Randi is no longer calling the shots.
- the OPL player may need to be replaced, but this will require some investigation because I do not know much about MIDI programming.
- some resources in gzdoom.pk3 will have to be replaced - and this is where it gets problematic. I am entirely unwilling to do this because some of these are essential for making GZDoom look and feel right - like the font being used for level names.
So, I think the engine can be GPL'ed, but the whole package would have to be split up, so that there's one version for playing Doom et.al and another one for making free games.
Finally, slap in the multiplayer code bases of both Zandronum and ZDoom. One offers having a lot of players, one offers better network logic/speed, as I understand it. I would definitely say make it so it's entirely inside runtime, so you don't have to rely on launcher settings or scripted batch files to do something as straightforward as setting up lobbies or whatnot.
[/quote][/quote]
This will most definitely never happen.