|Posted by mankrip on 2019/05/30 19:31:06|
|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?
#42 posted by mankrip
on 2019/06/02 21:43:35
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.
#43 posted by Kinn
on 2019/06/02 21:53:51
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.
#44 posted by Thulsa
on 2019/06/02 23:55:06
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.
#45 posted by Shambler
on 2019/06/03 10:42:40
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??
#46 posted by Shambler
on 2019/06/03 10:59:54
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.
#47 posted by Kinn
on 2019/06/03 12:43:25
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
#48 posted by kalango
on 2019/06/03 17:10:00
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.
#49 posted by Thulsa
on 2019/06/03 17:44:24
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
#52 posted by ericw
on 2019/06/05 08:40:45
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.
#53 posted by Thulsa
on 2019/06/05 08:48:07
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..
#54 posted by Izhido
on 2019/06/05 13:09:02
... 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.
#55 posted by Kinn
on 2019/06/05 13:23:41
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?
#57 posted by Kinn
on 2019/06/05 17:44:58
Yes to ericw's idea.
#58 posted by Thulsa
on 2019/06/05 17:54:21
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.
#60 posted by Thulsa
on 2019/06/05 19:56:38
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.
#62 posted by Thulsa
on 2019/06/05 20:10:18
That'd be the best name.
+1 to that
Github Org Is Up
I've created this:
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.
#66 posted by Shambler
on 2019/06/20 20:01:48
|2 posts not shown on this page because they were spam|
You must be logged in to post in this thread.
Website copyright © 2002-2023 John Fitzgibbons. All posts are copyright their respective authors.