rather than the designer having to add loads of nodes everywhere.

I'd rather have control over it though - as no matter how good the implementation is there will be issues. 

what I'd like to see would be engines to FINALLY start supporting tracebox, so that this stuff can actually be implemented...
without that, good luck with this ai stuff... you'll need it...

but yeah, without this being some map-specific thing, you're going to drastically change the balance of various maps. 

Breadcrumbs is the only AI "enhancement" that should be considered.

The direct-path, omniscient AI is actually quite good and varied due to the way Quake handles AI states.

AI in Quake is handled on a per frame basis, allowing perfect coupling of the animation with the movement and movements to match the model. This prevents monsters feeling too floaty when walking. The simplistic AI lets the player be smarter, gives smart players a way to control monsters and make in-fights, and gives some monsters character. I always love it wgen shamblers wander off for a bit becahse they don't see me.

Getting caught on lips is bad though. 

Reading the DLL rant made me lose a few IQ points.

Something I'd like to see is an engine which focuses on a modern tool-chain with modern formats. No one is considering Quake engines for bigger TC projects because every project also seems to aim for compatibility and misrepresents itself and its capabilities.

When you look for ways to get started for mapping/modelling for modern Quake engines you still mostly get results for .MDL and Quake 1 BSP creation. I highly doubt most people (unless they are trying to cash in on the whole 90s FPS revival...) would want to work with their limitations. Most noobs stop when they realize that you can't crouch due to hull size limits. I GUESS EVERYONE JUST WANTS TO MAKE SIMPLE QUAKE MODS.

Engines just seem to do a little too much overall with their builtin HUDs, menus and scoreboards. If they don't support CSQC then mods have a harder time customizing the look and feel. Overall all the advanced engines are bloated hogs with an identity crisis.

Thoughts on currently relevant engines:
QuakeSpasm
To me was always a solid GL engine that just did NetQuake stuff well. I'd never consider it for development. Just for playing old NetQuake mods. Extending it to do more complex things might harm it in the long run, because it'll just be another FTE/Darkplaces.

Darkplaces
While it somewhat supports CSQC and somewhat supports Quake 3's material/shader system, doesn't do any of it well. It's only half QuakeWorld compatible as well. So as a developer I've run into a few problems.

FTE
Does everything and _most_ of it works. Sadly the engine just does way too much. 16 year old code sticks out and things regress more often, because it's all cobbled together in one giant binary, I often have run into bugs/features that hadn't been tested recently or at all. It's like the emacs of Quake engines. But probably more reliable than any GNU project...

ezQuake
Does anyone even consider this for development? I guess if you run a custom QW server you use it to test because there's this invisible community of QW players who seem to use it. I don't know anyone personally who does, but a bunch that have focus on retaining compat with those clients because half their player-base uses it.

Overall, all of the above aim to be Quake 1 compatible. Those who care about Quake and don't need obnoxious high-res texture-packs just usually stick with QuakeSpasm. Why? Because it focuses on one thing well. Technically, FTE is the most complex engine but it has less of an adoption than say Darkplaces because it's mostly competing with ezQuake in the QuakeWorld space. That's because everyone has a hard-time at comprehending what it actually is. The name suggests it's just another ezQuake alternative. That's where it's kinda stuck.

I don't follow QuakeSpasms development (I don't even use it), but I hope that those who maintain it know what they are doing. Don't give in to requests of adding support for non Quake file formats and conventions. Just stick to being a good NetQuake client that offers the feel of the original. Otherwise you're just a few inches away of supporting rtlights and giving little kids the keys to using their Rygel pk3s. It'll be like Darkplaces but with less features.

Having been busy in recent years, I just occasionally take note of what's happening in the engine world. So what I might be talking about is not relevant anymore. 

Does support colored lights.

I can agree on FTE. Not really sure where it fits in, no offense to Spike or anything. 

@Qmaster

FTE is a perfect engine for people like me who wants to play Quake with the classic look (pixelated textures and particles) but also can't live without realtime light and shadow.

Now, answering the question "What Do You Want To See In Quake In 2018?"

I just want to see mappers and players noticing how important realtime lights and shadows are for quake.

Seriously, it makes the ambience so much more gloomy and terrifying. Just look how this little and simple old map looks awesome with realtime L&S: https://www.youtube.com/watch?v=WmcXLNzan48

The dark atmosphere, the monster's shadows moving on the walls... reminds me of Severance:Blade of Darkness. That game blew my mind, the gameplay was slow, hard and boring, but I played it just for the lights and shadows, it was awesome runing around the map with a torch on my hand, moving shadows... it makes the place look real. And I wished so bad that quake had it too... And now we have, and looks like nobody care for it. It's awesome when you see a shadow walking at the wall before you see the monster, the shadow grows and shrinks, so you know when he is close or far away, or when you see a rotating shadow from a weapon that you can't reach... these little details add so much to the game. Imagine how mappers could create suspense, paranoia and horror if they think about RT shadows when they are making a map...


Sorry for the long post :P 

 

Well...I would have a leg to stand on by arguing that Quake needs point lights sprinkled throughout a space as fill lights, but...

ericw already made this method of lighting obsolete with his bounce lighting.

With too many point lights comes dozens of overlapoing shadows = ugly and distracting and poor performance...on older maps that are much more evenly lit. 

Something I'd like to see is an engine which focuses on a modern tool-chain with modern formats. No one is considering Quake engines for bigger TC projects because every project also seems to aim for compatibility and misrepresents itself and its capabilities.

So, you want an engine that works with modern asset formats, but you're also knocking points off engines for being compatible with the original Quake.

Ummm... maybe just do whatever in UE4 or Unity? Not sure I understand why anyone would even want a Quake engine in this situation... 

I've noticed just how out-of-place and incongruous real time lighting looks with Quake's old textures and models, especially with pixel mode on, hope that helps. 

I think it fits perfectly with them =D

but it's ok, let's agree to disagree ;)

i'm not here trying to change anyone's minds, i'm just answering the question of what i would want to see in quake in 2018. But nobody has to agree with me, it's just my two cents ;) 

These engines run on certain ranges of modern hardware, Unity struggles heavily on integrated chips and even dedicated cards from 5+ years ago, also have all sorts of licensing issues and do not contain the same workflow that everyone is used to in the Quake community.

There is a lot of tech in between QuakeOne-level-tech and something like UE4. When it comes to 3D Gaming engines it's probably as big of a gap as there can be. You never have to take full advantage of such things. I am sure that anyone would welcome a Quake engine where the audio, physics and rendering API was on par with something like the Source engine (because no one has $25000 to pay to Havok and RAD Game Tools)

But seeing as only one current Quake 1 engine fork (being FTE) even attempts to take advtantage of things such as a Bullet physics implementation or supporting OpenAL Reverb setups, that's not really happening. So that's what I'm talking about.

Of course, what I named above is an example. People love Quake modding, they are familar with it. Everyone here takes advantage of the GPL all the time and are able to build fantastically open things - but all everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts. 

aal everyone cares about is making it so that Quake 1's playable in 1000 new ways instead of opening it up to new concepts.

Yes, and? 

For what it's worth, engines probably typically want to react to what the community is actually doing, rather than create a brand new content creation paradigm and then hope that some modders pick it up and start doing something worthwhile with it.

DP, FTE have md3 and Q3 bsp, amongst all manner of other things, and have done for a long time. When we start seeing good projects based around those features, we might start seeing support in other engines. 

this thread title is like a legal contract - realistically. Its such a relative term :D I'll try.

Realistically I would love quake's palette restrictions lifted. I understand that its all comes down to the fact that old wads and bsps can't store truecolor images, but (correct me if I'm wrong) you're converting them to truecolor anyway when loading into memory?

So bsp can store palette.lmp. So what if, upon loading said bsp, engine detects it has palette.lmp and uses it for textures from that bsp, instead of default one? Obviously items and weapons would still use original palette.

From my ignorant perspective it sounds very realistic. But then again I have no idea about inner workings of Quake engine, let alone source ports.

Point is - using colors from original palette is very limiting. It might be a good thing to keep things coherent and 'in-style', but from what I've seen so far, people would rather create awfully translated to quake's palette textures than adjust their design decisions. The idea of creating a new mod just so I can change color palette is absurd and discouraging. 

Whoa, you can totally remove all palette restrictions right now by just using external textures! Works in every custom quake engine I know.

You can even keep your new fancy coloured textures looking all limited-palette and pixel arty, but that's an artistic decision now. 

If you're using external textures, you can still have crappy Q1-paletted versions "baked" into the bsp to allow backwards compatibility for any wierdos somehow not using an external-texture-compatible engine, but if you aren't interested in backwards compatibility, you can even tell ericw's qbsp to strip the Q1 textures out of the .bsp and rely only on the externals. 

way to make a bear feel stupid :D oh well, ignore me :P 

What some popular engines doesn't support are special textures like bumpmaps, normalmaps and so on. Regular 24-bit color images are fine. 

@#198
The word 'good' is incredibly subjective.

In this community, 'good' means 'like quake', which in turn means 'low res', which to most people from outside the quake community means 'crap'.
That is the problem.


@#199
While its true that most engines support high res textures...
1) filenames for those textures is pretty much pot-luck - on a per-engine basis. And good luck with fullbright naming too.
2) supporting all the possible paths results in horrible horrible load times on windows, so expect only one, and for it to not match any other engine.
3) you can't be sure about file types either, for instance, QuakeSpasm pretty much only supports tgas (unless you count pcx as a 24-bit image format - I don't, although per-texture palettes can still be useful). Good luck when it comes to fullbright channels - additive, blended, premultiplied, etc...
4) pk3s(read: zips) are not supported by eg QS, so you'll have to use some large paks instead, along with needing to use annoying tools that have not been updated since q2 era and were never that friendly anyway...
5) except that quakespasm doesn't support miscellaneous pak file names, so they'd have to be numbered exactly and probably break...
6) so instead you'll have to distribute all those files loose which makes it really messy...
7) and they'll get confused with all the other maps because quakespasm lacks per-map replacement textures (even though you need that even for replacement textures with the vanilla quake maps).
8) so you need to create an entirely new gamedir.
9) which requires command-line arguments or console commands that vary in every single engine
10) and you can't use multiple gamedirs so if its an AD mod you have to distribute the ENTIRE ad (the alternative is installation instructions that 'no-one' would bother to follow).

so yes, 24-bit textures work... But you'll screw up every other maps, and you STILL need a wad for your map editor and so the qbsp can get the texture wraps/lightmap correct.

And in writing this post, I remembered that per-map replacement textures is something I overlooked in QSS, so it's still kinda screwed with conflicts despite the png+pk3+naming stuff that I added to it.

And now I'm wondering about tweaking ericw's tools to spit out a hlbsp with its per-texture palettes.


@Kinn
Hopefully you should understand Eukara's stance a little better now.

Additionally, note that while ericw's tools support writing a bsp with no mipmap data, ericw's engine (read: quakespasm) will just give you corruption if you actually try using it. That was my change (and probably only got merged because it was in the same patch as the phong stuff). Both FTE+QSS support it, but apparently no-one else gives a shit about stuff like that. The same is true of embedding the lits inside the bsp (although ezquake supports that one too, but not QS).


@Qmaster
FTE is intended mostly for modders (note that the one tool that shares fte's name is a quakec compiler). For it to be useful to modders, it has to cater to users too (like OPTIONAL realtime lights, or its 8bit rendering stuff, its better networking, raised map limits, etc).

At the end of the day, there's a fine balance between compatibility and sanity. The only way to avoid needing to balance is adding lots of extra cvars. Hence the presets, in an attempt to get it configured how people want without them fleeing in terror and bewilderment. 

@Spike

First, i love your engine.

Second, You sir, are a genius =D

Third, thank you for your awesome work =D 

Where would I find info on how to add real time lights to my map for FTE? I'll be honest I am not a big fan of those BUT I would rather place them myself than have FTE do it automagically. 

In this community, 'good' means 'like quake', which in turn means 'low res', which to most people from outside the quake community means 'crap'.
That is the problem.

For me, 'good' means 'fitting in with quake via gradual enhancements' which in turn means 'a resolution harmonious with the level of models, typical map brushwork, and general graphical effects'. 

We are talking about Quake so I can agree with making it fit with Quake's style.

I would like to have a CSQC HUD template that matches the original HUD so that people could use it as a base to tweak or add things rather than reinvent the whole wheel.

Heck I might make one myself someday. 

Quakespasm inherited per-map external textures from Fitzquake 0.85; they go in /textures/mapname/ (docs: http://celephais.net/fitzquake/files/fitzquake085.txt ).