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. 

attract people who [...] aren’t sure how could they help

The main way for a programmer to figure this out is by reading the code, not by reading to-do lists.

The main thing I work on in Quake is the software renderer. But if I was going to modify a Doom engine, I would start by working on the GUI.

Why? Because that's the easiest starting point for me to figure out how that god damn engine works. To-do lists doesn't teach anything about how the tech works.

If I was going to do something on the Build engine, I would start from its gameplay scripting interpreter.

Each tech has a different optimal starting point for each programmer. It's about the learning curve.

For example, there's no way to expect a talented network programmer to use Quake's BSP rendering as a starting point for learning the engine. It may happen, but the odds are that he'll tackle the networking code first.

Lists are useful, sure. But you can't expect others to follow them. You can't expect to dictate the programmers' priorities. You can't expect to dictate what others will get excited to work on.

It's kinda uneven to tell others what they should work on, when nobody tells mappers how their maps should be. 

The point of a "what mappers would like" list is not to dictate what programmers should do - of course the programmers can do whatever the hell they want to do. The list does not interfere with that in any way.

The point of a "what mappers would like" list is - believe it or not - to make it a lot clearer what mappers would like, because no-one really knows right now, because all the requests and wish-lists are long buried in random threads here, and no-one knows if a random request is something only one mapper is interested in working with - or whether it might have the endorsement of two dozen currently active mappers.

There might be some programmers - even if it's just one or two - who may be interested in knowing what the content creators would like to be able to do. A nice visible record of this is worth having I think. 

Each tech has a different optimal starting point for each programmer. It's about the learning curve.
No two programmers are alike. Sure, rendering is interesting, that's why I spent 6 years at a GPU company. But it also showed me that there are people much more capable than I am in the rendering dept so I tend to stick to what I do best which is "cleanups nobody wants to do". But I'm lazy and I want someone to show me what's there to do. Simple as that. Lists don't hurt, there's no liability in them. But lists are useful to some. 

One of these days you'll be able to distinguish between MAPS - which last for a few minutes and are then are easily forgettable if they're not to taste, and ENGINES - which will have constant duration and have players putting up with any unwanted features throughout their usage. Hopefully today will be that day.

And fwiw, the same quality standards apply. People DO tell mappers what to make, in a subtle background sort of way - there's an implicit expectation for people to release something that is well themed, creative, reasonably polished / refined, has some aesthetic interest, balanced gameplay etc etc (which thankfully covers a broad spectrum in quake whether it's Lost Tomb or 37 Relics). If someone releases dung, their release is going to get criticised. Same with engines and mods and whatever. It's all meritocratic here.

Hopefully engine coders will be able to tell the difference between, oh I dunno Ersgan-style slightly enhanced but Quake-faithful textures and gently undulating water or something, versus sticking in a neon crosshair for the sake of it or shoehorning in 2019-level volumetric fog weapon effects into a 96-era game. But if they can't (how? Why?) then it might be useful for them to get some ideas what would work with Quake, surely?? 

Having re-read your starting post, I get what you're saying, in a way. Tbh, if coders really want to do crazy stuff without artistic vision, then sure they can do that. Doesn't mean a player / mapper / Quake fan like me either has to like it nor pretend that I like it - nor for that matter care about encouraging them to work with the Quake engine. I want to see great end results that enhance and build on (not override nor clash with) the base game, and I'm not too bothered about attracting stuff that isn't going to focus on that. Otoh if they dick around with crazy stuff behind the scenes and that eventually gets transmogrified (by them or others) into a great end result, that will be very welcome. 

feathub.com looks nice but I agree it's problematic to have to associate it with a particular github project.

All we need is just a record of mapper-requested features that are very easily visible and don't just disappear into a black hole like func posts.

Maybe we just need something more like a standard threaded discussion board, external to func, which is simple to sign up to (i.e. doesn't require you to make a github account).

It would need to be moderated to make sure that the only allowed thread topics are feature requests.

To get an idea of how popular a feature request is, a "vote" system could help visibility, and we could look at the rest of the comments to get an idea of who else is endorsing it.

There's a risk that it gets out of hand and fills up with dozens of stupid little requests that only one person cares about, so the format of the board would need to keep popular requests always visible, and not allow them to get buried by a slew of crappy requests.

And I must stress for the Nth time that I'm not trying to create an environment where it looks like we are dictating what programmers should do, I'm just trying to solve the problem we have currently where it's not terribly clear what things mappers would like. Programmers might not visit the site at all, but the next time the "well, what do you want then?" question comes up, at least we can go "have a look at this, my good sir" 

New features are good and all. But I think better tooling for coding goes a long(er) way. Mapping has beautiful tools (even if sometimes hard to use by a complete beginer such as compilers and so on, how to gather all programs and wads and etc to figure out how to actually do a map).
-- Kudos for all those that make that easier with tutorials and tools --
But the tooling for coders is actually very limited and the pace to get along with the code, compile and test is still very primitive and slow, and it feels like the 90s or 2000s in some regards. For example Doom coding tools are way better streamlined.
Well thats my opinion. The first step would definitely be to make the coding/QC/CSQC (and a huge shoutout to CSQC support for extending the looks of Quake) tooling better. Mapping is great and has a lot of things to go around with compared to coding and modding.
Feel free to ignore though. 

External forum still needs people to register to participate and doesn't benefit from someone already having an account (like GH does). Once you have bulletin board it's also tempting to create threads for general chat... and suddenly you dilute small community even more. Feathub does one thing well and it's hard to misuse it.

And it's not about dictating anything to anyone, IMO. It's about organizing knowledge. If one creates GH organization (func_msgboard or whatever) and assemble interesting projects around it, one of two things will happen: it will be ignored or people will start paying attention. Either way you'll have a single, well groomed place for stuff func finds valuable.

You could put it on some wiki or on another forum or whatever but I don't see extra value in that over GH. And I don't even like GH. :-S