News | Forum | People | FAQ | Links | Search | Register | Log in
How To Attract Coders To The Quake Scene
From this thread (see it for full context):

There's little reason left for anyone to implement graphical advancements in Q1. [...] Q1 engine coding seems to be dead.

The constructive question in my comment is: How will you attract new talented engine coders?

Talented coders likes to do crazy stuff. It's a waste of their time not to do it. Programmers are fuelled more by challenges than by artistic visions. They are primarily driven to make things work, not to make things look good. Making things look good is the most boring part of their work, often being a chore because of how subjective things can get.

How do you expect programmers to feel compelled to work in Q1 engines if you keep telling them that doing crazy stuff is wrong?

Baker was one of the most amazing coders here because he did lots of crazy stuff. There's lots of stuff in his work I don't agree with, like hacking the QC code behavior to shoehorn the fish count fix through the engine. But despite not agreeing with his methods, lots of stuff can be learned from them. He contributed a lot.

People hates Darkplaces because it does lots of crazy stuff. But that's exactly why it's one of the best engines for any Quake modder who wants to make wholly new games: almost any crazy shit you throw at it will work. Engine coders doesn't think only of the mappers, they also tries to improve things to 2D artists, modelers, texture artists, musicians, gameplay programmers, and so on.

How do you expect engine programmers to enjoy working in Quake engines?

Mankrip, I'm presuming you're drunk posting with the "community rejects any graphical advances in Quake rendering these days" gibberish.

Years ago the community was more receptive. Nowadays, it isn't.

Just because some rendering things that look completely out of place with the rest of the game aesthetic are rejected doesn't mean that people reject advancements

Some maps in some map jams are very poor, yet people don't reject maps jams because of them. Nobody says "this jam is bad because of that map", but they say "this engine is bad because of that feature". It's sad to see lots of good work being ignored because of small stuff.

The quake scene on here should be mature enough to use stuff subtly... [...] And the more people do that, [...] the more the advancements can progress overall

there's so many areas that remain to be advanced harmoniously and appropriately...


Guess what, the skills to do such things comes from the same place of "pissing around with disco lights". Programming is not art direction. If you want a good programmer, you must let him exercise his programming skills, instead of forcing him to develop artistic skills.

The question remains: How to make engine coders enjoy working with the Quake engine?
Yarps 

#14 posted by Kinn on 2019/05/30 17:44:08

It's been well over 20 years since quake was released. We're the faithfuls, the ones that stuck around because we like quake for what it is, rather than what crazy stuff you can do with the engine, and anyway, there are so many better starting points for "crazy stuff" than the quake engine.

The people who want to turn quake into a "Disney's Pocahontas"-themed dating-sim slash 2D-fighter with QWOP controls are long gone. They left for the Q2 engine when Q2 (sorry, Wor) came out, then left for the Q3 engine when Q3 came out, and so on. Now they just cock about in the latest Unreal or Unity oh shit the engine just updated for the twelfth time this week and broke all my boob animation physics and nipple-erection blend shapes.

All of the designers here have made tons of posts in the past where they state what things they would like in the engine. There has NOT been a lack of communication in this regard. The programmers only do the bits that they personally like the sound of, and feel are worth doing, and I guess they don't really want to spend their time just working through the bullet-points of some random mapper's wish list.

From a selfish-mapper point of view, I wouldn't be coming at this from a "how do I make a programmer enjoy working with the quake engine" angle, but more of a "how do I make a programmer implement this very specific set of features that I want to build a mod around (a mod that may or may not ever be finished and released)". You can see why they probably wouldn't be queuing up at my door, unless the exchange of money is involved.


 
That's Not How You Improve Things 
Posted by "8657"....


#15 posted by 8657 on 2019/05/30 19:16:34

If you want programmers to help you with what you want, you have to let them do what THEY want so they come to enjoy the engine. There's plenty of shit that is out there that's just ignored because it doesn't fit with the vision certain people think the engine should be. That's never been how this shit works.

Programmers come in because they like a certain something about what they see. It's like a hook for them to put their skills to the test. It's a challenge that they're looking for. That does benefit everyone else if it can be used in the future/built off of. Things get easier if you don't have to build from scratch.

When people say there's a lack of communication, they mean there's a lack of LISTENING. If you just talk at each other, nothing will get done. Rejecting everything out of hand also leads to alienation. That helps nobody.

I know I harp on this when this topic comes up but look at the Doom modding community and all the things they've done. It's vibrant and alive partly because there's a strong programming base. They do their own thing which helps make things better for mappers in the long run.

This isn't a business; things are going to have to evolve naturally to open new roads. Otherwise, there won't be a community worth calling it in 20 years more than likely.

 
Indeed 
That's Not How You Improve Things

Yeah, I know it's not. My point is that programmers just "doing whatever" might not exactly yield anything that modders and mappers are interested in doing anything with.

I am really struggling to think of ways to get new programmers excited about "just doing stuff" in the quake engine. By "new programmers" I mean programmers who aren't already doing stuff in the quake engine.

Surely, it should be about coming up with a great mod/game idea (that for some reason has to be based off the quake engine) and then trying to get coder(s) excited about working with that game/mod idea?

Someone has to come up with an inspirational concept first and then try to get a team assembled, where artists and designers and programmers are generally all on the same page and working to realise a particular vision.

This is incredibly difficult and rarely happens in the quake community, but I think that is the most noble thing to aim for, with the best chance of producing something good at the end of it.

I know I am being incredibly idealistic and naive, but I believe this approach has yielded results before - e.g. Nehahra, RMQ (even though unreleased, we got some tech from it), AD I think too... 
I'd Like To See A Team Effort 
It seems like engine coders are lone wolves but take TrenchBroom. ericw and Sleep are doing some amazing things as a team. If egos can be put aside and focus maintained, we could see some great things.

But what features? I dunno what everyone wants. We have some great improvements in ericw's tools. A survey and a wishlist from the ppl who create content.

For my part, I am interested in ease of use for new users, future proofing (with things like Vulkan) and adding map discovery and downloads - the sort of non-graphical things only Spike and Baker focused on recently. I think those could help keep the game relevant. 
An Idea I’ve Been Entertaining 
for a while, and which I just started working on, is to have a version of the engine (both software and GL) with all its caps entirely removed - that is, all MAX_***** limitations, and the whole idea of a static memory pool, gone from it.
I already talked about it a few days ago. These limitations were very useful 22 years ago, but they simply make no sense whatsoever with modern computers and devices.

By doing this my hope is to inspire map tool creators / mappers to realize the old ways are no longer something they should be subjecting themselves to, and to start bringing big, really really BIG things into the scene.

(I already removed the need for MAX_MODELS server-side in the engine - going for client-side, and whatever comes next). 
Keep Going 
I would love to see an uncapped software version of the engine in action. 
Do It Izhido/Other Things 
Things like this are what's been needed for years, but AD's highlighted that point in particular by being close to if not the limit of what can be done on the mapping end with current limits. What Q1 modding needs now are gameplay and technological improvements to work in the current sandbox. Q15, while divisive, is a step in the right direction in that regard.

What could also be done is to build on the TCs and other id2 games that have been made with the Quake engine. Like I said before, it's easier to build on things that already exist rather than try to build everything from scratch. What id2 offers that the other retro engines don't is the ability to make viable TCs that won't be erased by an update. To make this point, I want to post this:

https://www.youtube.com/watch?v=8sMYBYy3BQo

This is Brutal Quake. Now you might be thinking: why have I never heard of this? Well it's not on the Quake engine. It is, in fact, on the Doom engine. Yes the engine that is a generation behind this one has gone so far ahead that it can simulate the id2 almost perfectly.

And then there's this as a parallel project of sorts (skip to 1:10):

https://www.youtube.com/watch?v=gAkwzB9fJdw

ShadesMan is working a project for YPOD called Eternal that will help update it to the modern day. Things like this should be encouraged as well as improvements on the base game. There are other things, but I don't want to flood this too much. 
 
a version of the engine (both software and GL) with all its caps entirely removed - that is, all MAX_***** limitations, and the whole idea of a static memory pool, gone from it.
I already talked about it a few days ago. These limitations were very useful 22 years ago, but they simply make no sense whatsoever with modern computers and devices.


When using modern Quakespasm, FTE etc, what limits do mappers/modders brush up against in practice?

I'd be interested to know what limits people are actually still hitting. 
Holy Shit YPOD Revival 
Never in a million years would I have ever seen that coming and I'll bet that I'm not the only one.

What's next, someone springs a surprise Navy Seals episode? 
 
There are already a lot of coders doing amazing work. If you're talking strictly the Quake engine, then dumptruck is right. EricW continues to do great work and he has worked directly with mappers to implement features, such as for Orl's Ter Shib maps. Spike did cool stuff with QSS and continues to push forward with FTE. R00k is also actively developing his port last time I checked. Aside from directly modifying the engine, several people are making awesome mods and doing cool stuff with quakec like khreathor and snaut.

When it comes to people complaining about adding "crazy stuff," keep in mind that it could just be a vocal minority. The people who are the angriest about something are often the loudest. I also doubt that people who have a problem with new additions would care so much if they were off by default or easily disabled.

I'm not sure if the challenge of improving the engine is enough to attract anyone. I think that any talented developer coming in would have a love for the game. If people continue making great mods and maps, then maybe interest will continue to grow and eventually a talented newcomer will show up.

In spite of the naysayers, stuff like AD has done a lot to generate interest in the game and Wrath will surely foster even more interest. Hopefully potential newcomers have thick skin and don't take the perpetual complainers too seriously. 
 
Wrath trailer got me back into the scene, back in the 90's I only made maps and assets for myself.

Currently I'm working on a refactor of the 1.06 QuakeC files to make it more comprehensible for new joiners. In the end I plan to provide a fully sanitized codebase with clear and flexible API functions for each aspect available. 
Replies: 
Years ago the community was more receptive. Nowadays, it isn't.

Dunno. The community seems just as receptive of high quality additions that enhance the game, fit in with it's style, etc.

Some maps in some map jams are very poor, yet people don't reject maps jams because of them. Nobody says "this jam is bad because of that map", but they say "this engine is bad because of that feature". It's sad to see lots of good work being ignored because of small stuff.

That's different. A bad map in a jam pack is a 5 minute experience you never repeat, or just skip over entirely. And yes, some people don't enjoy jam packs as much because there can be some low quality "filler" in them. A bad feature in an engine, unless it's easily turned off, will be a nuisance every time you try to play in that engine.

In spite of the naysayers, stuff like AD has done a lot to generate interest in the game and Wrath will surely foster even more interest. Hopefully potential newcomers have thick skin and don't take the perpetual complainers too seriously.

You been on the booze along with mankrip, matching him shot for shot?? I dunno who these imaginary "perpetual complainers" are, but your very examples of AD and the promise of Wrath are things that have been almost universally welcomed as great enhancements / advancements on Quake - prime examples of well-themed high quality. You've disproved your own point there.

The question remains: How to make engine coders enjoy working with the Quake engine?

Trickier one. How many engine coders would enjoy working with the Quake engine to produce great, Quake-themed, harmonious end results that will be enjoyable for players, mappers and modders?? Rather than say, tinkering with the code for their own pleasure or experimenting around to see how far they can push things?? (FWIW it seems the vast majority of mappers do it for the former aim).

I guess the ideal will be when a coder's desires / ideas and what works great in the Quake style both coincide. This is pretty easy to visualise - just look at stuff like AD, or the examples I gave in an earlier post (coloured lighting, fog, skyboxes, particles, transparency, increased limits, props, high quality model replacements etc etc). To what extent it will happen in reality is less certain - maybe just ask the coders "what can you bring to this to enhance it further??" 
Let's Talk About The Elephant In The Room 
Mappers, modders and players alike, all have a favourite engine.

For many reasons, Quakespasm is that favourite engine for a lot of us.

Let's say I have an idea for a cool feature I'd like to use in a map - volumetric fog. Suddenly volumetric fog appears in Darkplaces. Will I suddenly start mapping for Darkplaces? No. Because it's not Quakespasm, and I have to now put up with all the stuff I don't like about Darkplaces, and I no longer get to enjoy all the stuff I do like about Quakespasm.

Let's be honest, when a mapper wants feature X, what he wants is feature X in his favourite engine. 
 
...and as Bal just pointed out in #tf, the mapper also wants that feature X in all the engines people are going to be playing his map in.

Oh shit son... 
 
So, we want a solution that concilliates what I want (or bother) to do, with what the rest of humanity needs me to do, if I want my work to be known and played for that precise instance of humanity.

Man, if you find the answer for that, you’d find the solution for all of the problems humanity has right now.

For now, the only thing we can do, if we want segment X of the market to enjoy our work, is to step up of our confort zone, find out what segment X uses, learn about it, and do whatever it takes to implement our work on it and give them what they need to see it. I see no two ways about it. Sorry. 
The Doom Community Already Solved This Problem 
The answer is to diversify the engines so that each engine does a certain thing others don't so it's worth playing them. Quakespasm's worth is that it simulates Quake in a better quality than the base game, but it struggles with simulating other builds that don't fit in the neat little bow.

In contrast, Darkplaces and its forks are the TC engine in the sense that it's more flexible than QS when it comes to these things. This is why Quake 1.5 (Q15) started on that engine in the first place. Epsilon is a superior version of Darkplaces that lets you play Quake at higher fidelity closer to modern games. Mark V tries to go to the real experience of the original Quake using many different parts of past engines. And that's not counting the MP engines.

QS can still be the main favored engine, but it also doesn't have to be the only one. 
Ummm, 
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 
:P 
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. 
@tribal 
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. 
@dumptruck_ds 
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 
@Poorchop 
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. 
#24 
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. 
Epsilon 
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. 
That Was Aimed To #16 
 
 
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? 
/End Thread 
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. 
Features 
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? 
@Kinn 
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? 
Yup 
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. 
#39 
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... 
+1 For A GitHub List 
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. 
Good Lord 
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. 
Mankrip. 
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?? 
Hmmmmm 
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. 
Thulsa, Dumptruck 
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" 
My 2 Cents 
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. 
@Kinn 
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 
How About A Github Issue Tracker 
For feature suggestions not specific to one engine. Only use the issue tracker bit of GitHub. I checked out Feathub and it looks good but there is a JS execution vulnerability and I was getting popups..

No downsides to, worst case is it doesn't catch on. 
 
Sure, this would work too. It may be a good idea to start GH org for that so it's easier to switch maintainers if this is needed down the line.

I'm also wondering: is there any point in updating quakewiki with more technical stuff? I want to spend some time comparing code of various engines (mostly non-rendering code) and it would probably make sense to document it somewhere. 
It Was Because Of QuakeWiki.. 
... that I could move QuakeEd from a mass of old UI code from a forgotten era, to a working product for Macs so I’d vote for adding *more* content, instead of less. 
+1 
To adding engine coding info to QuakeWiki

That place needs more love 
Does Anyone Object 
If I create a repo for this as ericw mentioned above? 
+1 
Yes to ericw's idea. 
@dumptruct_ds 
If you currently have no beef with anyone then I don't think anyone objects. ;-P Once again I suggest starting GH org for quake related stuff but this can obviously be done later. 
@thulsa 
 
Correct. 
 
I'd like to do the organization thing upfront I think. I'll make a catch-all email account for this and maybe the org can be: The Worldwide Quake Mapping Community. Something fancy like that.

I am pretty slammed with work and other Quake related obligations but I will get this cook at some point today or tomorrow. 
QuakeDads 
That'd be the best name. 
@dumptruck_ds 
+1 to that 
Github Org Is Up 
I've created this:

https://github.com/quake-mapping-community

I'll add more info and a repo later as I have time. I dropped the Worldwide from the name. 
 
Alright a repo has been created. If you'd like to post issues in the tracker I've started with one that was sent to me on Discord. If you'd prefer not to create a GitHub account email me or post suggestions here. I'll likely create a func news post about this soon. 
Anti-spam Re-bump. 
 
2 posts not shown on this page because they were spam
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.