Epsilon is a SEVERELY OUTDATED version of Darkplaces. Also, you may want to check the definition of fidelity. 

Epsilon is a superior version of Darkplaces that lets you play Quake at higher fidelity closer to modern games.

https://youtu.be/1wiz0UsBPac 

That is what you call fishing for responses, though it does look very shiny. -_-

Basically, the curiosity of id2 is how unexplored it is in comparison to every other retro engine. The Quake engine, despite all that has been done with it, has never truly been pushed to the full extent of what it can do as well as taking from successor engines as far as I can tell. A project that pushes the engine as far as it can go would be an interesting prospect. Something like a tech demo... 

FTE also simulates Quake like Quakespasm, has multiplayer support, and has a lot to offer to mods or total conversions just like Darkplaces (or even more)... but FTE should come with "vanilla look" as default for newcomers (i know there's some premade configs that show up when you run the engine for the first time, but it's confusing to newcomers, because they don't know what that is or how the game will look with each premade config)... Another thing that is confusing, is that some things you have to write on the console to turn it on/off (i have a txt file with a lot of console commands, so i don't forget). All the customizations should be on the menu/options (like in rain, snow, turn on/off effect.info...)

And if, for some reason, a mod/TC needs some of the effects turned on (like realtime shadows or something) just make an autoexec.cfg and pack with the mod.

And, of couse, people need tutorials and examples to learn how to mod for it... FTE could be the ultimate quake engine for all we need, but most of the times it seems too advanced for my little understanding :P 

The answer is to diversify the engines

This causes problems as well. You have something like GZDoom, which is the Emacs of Doom source ports - at this point, it's more like a separate engine that just happens to run Doom. It inadvertently pushes its own format by offering un-Doomlike features such as true room over room, slopes, and much more. A chunk of the GZDoom camp is incredulous that anyone would want to use Boom or Doom format when mapping. If you prefer PrBoom, you're out of luck if someone used features specific to GZDoom. If you have a large, detailed map i.e. Frozen Time, you're out of luck if you want to use GZDoom due to its abysmal performance compared to PrBoom.

Incompatibilities aside, you end up with a lot of talented coders single-handedly keeping their project afloat. I don't think that PrBoom+ has been updated in years, and that's the problem when the single developer gets bored and moves on. There's a case to be made for developers consolidating their efforts into fewer source ports to make it the best that it can be and providing a fallback if one decides to quit the project.

It's good that different developers who have different ideas about where they want to take the project are doing their own thing but there are still a lot of drawbacks to consider. 

I agree 100% about FTE. I literally was just tweaking a new install of FTE to my liking and even with the presets I needed to fiddle around for quite a while (and I sort of know what I am doing!) But I agree with the power under the hood there. If FTE defaulted to a Quakespasm look and didn't default configs to the Home directory I think it would be very good competition for QS for casual users.

As it is now, there are almost too many options. 

And the most impressive thing about FTE is that Spike is always fixing things and adding even more features as you can see here:

https://sourceforge.net/p/fteqw/activity/?page=0&limit=100#5cef13cef0d347678db86202 

It's better than having engines/source ports locked bytheir creators and not giving the source code for public use. And knowing how things usually go, something will replace PrBoom+ once it becomes a problem. In practice, Doom players use specific ports, but there aren't any serious hang-ups against making maps for something like Chocolate Doom for example.

Branching out doesn't hurt when it calls for it, but you're right that there doesn't need to be massive forking at the moment. 

Good point. Doom engines can either use the GPL, or the non-commercial closed source id licence. For developers who wants to do extremely innovative stuff, the closed source may be more attractive since they can finish implementing their vision and still get open beta testing feedback before releasing their code.

I wonder how many active Doom engine projects still uses the closed source licence, though. It's hard to say that the closed source option has any significant weight on Doom engine diversity. 

is not a version of Darkplaces. It is a collection of mods and assets that work in Darkplaces that someone gathered from Quakeone´s and became popular because it was advertised around. 

 

IMO, all these replies with big ambitious suggestions are missing the point of "making Quake engine coding enjoyable".

That's like someone asking how to make gameplay coders interested in doing Quake mods, and you telling them to create something like Arcane Dimensions. For people who are beginners in Quake modding, that's overwhelming and leads to burnout.

Back then when the Quake source was released, several new engine features were developed by one-shot programmers. People who just wanted to try doing small things. And then other coders merged those small things into their own forks.

That's how open source collaboration works. It doesn't need big projects. It doesn't need an unified vision. It just needs lots and lots of people trying out different ideas, and a very few of them merging the best ideas into a few different forks. It's an organic process.

And what the Quake engine scene is missing out is the lots and lots of people trying out different ideas. People to merge those ideas we still have, though the loss of Baker is very significant.

People begin by trying out small things, and a few of them eventually starts merging things out. Without beginners, we won't have mergers. 

How is it up to us then to attract more people? Either you're interested in coding or you're not. Either you're curious about trying new ideas or you're not. It's not up to any of us to entice people to modify the engine. It's a game engine like any other and no random person is gonna hack on it just because we asked them to do it. They'll do it if they're attracted to maps, mods, or Quake engine projects.

I can agree that it's good if people are always testing the waters and trying to take the engine to new heights but I also understand the complaints about additions that completely clash with Quake's aesthetics. Again, you're probably only going to find complaints about most of those additions if they're enabled by default or tedious to disable. They can also be a problem if they slow the engine down. 

FWIW I think that any generalization about what coders like to work on is going to be wrong. Generalizations are almost never correct and are very often turbowrong.

What I, as a programmer, am missing to start is a single "upstream", engine that has everything (even if it lacks polish). QuakeSpasm seems to be "the engine" but as much as I respect Dumptruck's opinion, it's just an opinion. I'd love to see an up to date writeup on different engines and what they have to offer. This would help me decide where and if I want to add something.

In general it's good to keep public laundry lists. TrenchBroom has a list of interesting things to add but, TBH, the only one appealing to me (smart layers) seems like something I wouldn't want to take away from the maintainers. Like, it sounds so cool I want Kristian to enjoy working on it. :/

Which leads me to a question:

A survey and a wishlist from the ppl who create content.

Is there such a thing? I'm sure I could read gazillion posts on Func_ and figure it out myself but is there a list of things map makers want? 

How is it up to us then to attract more people? Either you're interested in coding or you're not. Either you're curious about trying new ideas or you're not. It's not up to any of us to entice people to modify the engine. It's a game engine like any other and no random person is gonna hack on it just because we asked them to do it. They'll do it if they're attracted to maps, mods, or Quake engine projects.

I can agree that it's good if people are always testing the waters and trying to take the engine to new heights but I also understand the complaints about additions that completely clash with Quake's aesthetics. Again, you're probably only going to find complaints about most of those additions if they're enabled by default or tedious to disable. They can also be a problem if they slow the engine down.

Poorchop clearly sobered up as that is spot on. 

Is there such a thing? I'm sure I could read gazillion posts on Func_ and figure it out myself but is there a list of things map makers want?

No, and we need one.

I have often thought that there needs to be some sort of "feature request" website thingy somewhere, set up to allow quake mappers and modders to submit general engine requests. These requests can then be commented upon and embellished and upvoted and whatnot by other people and you would in theory build a consensus of what engine features would be the most useful to the quake community at large, not just useful to one particular goon.

This should NOT be about specific tweaks, fixes and things for one particular engine, this should be about features that we would like to see in quake in general, and the ideal scenario would be for multiple engines to adopt them.

So - can anyone recommend a good, existing, web-based, feature request solution that we could use for something like this? 

There's https://feathub.com/ with the only drawback being that it requires GitHub account. On the flip side pretty much any developer interested in helping out would have one.

There's also a question of what the upstream would be. Any existing engine has primary developer behind it and it would be unkind (to say the least) to ask them to take the change just because there's a majority vote that this feature would be a great addition to the engine.

So you probably need a fork that will accumulate these changes as they are being prototyped so that individual maintainers can decide on which features they are interested in (or can support - some graphical stuff that's a small addition in GL-backed renderer would require a lot of work to implement in the software rasterizer).

Keep in mind that some (if not all) features would require tools to support them but I guess TB being multiengine could support quake with stuff without much controversy. 

I was going to write a different post, but as it would have involved words such as 'faecal matter' and 'letterbox', so lets try again but a little less ranty.

Give up on engines catering to the mapping community. Its a lost cause. The instant you add something that might cause them a little more work they'll start shit-talking about you behind your back (yes, discord shows chat history from before you join) and your changes will never get up-streamed (see QSS).
Any extra features you try to add are doomed to disuse unless you can achieve a high critical mass so good luck with that (eg QS still has the +/- 4k limit despite it being fixable from the console).

Tools don't have the critical mass issue so focus on those, its much less toxic and much overlooked (wads? still? really?!?). 

It's a chicken-egg problem. If you have a mapmaker-oriented engine and something awesome gets created for it, other engines will either implement this feature of people will switch. There's a fine line to tread so one doesn't cross from "Quake engine" to "no longer Quake engine". But that can be solved through consensus (probably).

And sure, engine XYZ developer may not want to implement this particular feature and may not care about the number of users. But who cares if engine XYZ gets forgotten? Programmers love to masturbate with technology but what really matters is content. And users move where the content is. 

Give up on engines catering to the mapping community

So who would you consider the most important user base for new quake engine stuff? I take it you'd rather be targeting stuff at players then, and not the content creators? 

Give up on the people who actually enjoy Quake just fine the way it is, start catering to the Brutal Doom UHD Texture Pack Metal Soundtrack user base. 

and your changes will never get up-streamed (see QSS)

I'm curious as to why at least some QoL changes never made it into upstream, particularly with regard to networking. If I do co-op, I use QSS. It's also a great example of how fancy additions should be handled: content creators can make use of the extra features as they see fit but the defaults are pretty vanilla. However, some of the extra features cause one of the problems that I mentioned in that performance tanks for me in some AD maps like busy moments in Leptis Magna.

The only complaints I've seen about QSS stem from a lack of documentation, not from actual problems with the engine or its new features. 

AFAIK, QuakeSpasm doesn't have enough active coders either. EricW said he'll look into implementing lightmapped water support, but he also has the mapping compilers to maintain, and is also helping out with Trenchbroom.

QSS is a wonderful engine that already has an userbase, and it's what I'm using to develop stuff. It also got some love from mods like Arcane Dimensions, that uses some of its extra effects.

Anyway, there's no point in making lists of requests if there aren't enough coders available. 

On the contrary.
Having a publicly available list of things that need to be done, will attract people who want to participate but aren’t sure how could they help and, maybe, who knows, can work on *that* particular feature they always wanted to get a shot at - or is already an expert on it and hey, didn’t know they were missing that, *cracks fingers* and get going with it... 

I have an account and can pass on mapper's requests if they don't want to make one.