New Age "Quake" Engines Specs

[Baker]

This is a list of things I think matter to modern "Quake" engines. Quake engines don't seek to be Quake 3, they don't seek to be the CryEngine engine and they don't seek to be on the bleeding edge.

They need enough features for a mapper to tell a good story, for a user to enjoyable play without seeking outside setup assistance and to provide the mapper/modder reasonable limits to allow this to succeed.

Here is my list:

1. HUD markup language a la Frag Machine's concept. CSQC requires near-engine coder levels of expertise; proper modding tools should allow trivial access to such things.

2. Intermap travel, via the specification by Spike. No custom QuakeC required. Map travel should not be mandated as linear.

3. Camera control a la Frag Machine's contribution in addition to either MH or R00k's camera fix (each with their own merit's ... MH's is comprehensive at the expense of being speedy, R00k's is speedy at the expense of being comprehensive).

4. On-screen diagnostics. The first thing that F1 should bring up in Quake is similar to what About:Help brings up in competent Windows applications ..... Operating system, version, video card, current video mode, memory and utilization, major settings, gamedir, path.

5. Achievements system. Is this important? Yes it is. This definition is intentionally vague, but the implications are significant.

6. Vwep for stock model formats, in this case certainly at least q1model (regardless of implementation method, like Error's work). This flexibility in design is imperative.

7. File access via QuakeC. Specifically: FrikFile.

8. Magic ear. The DarkPlaces extension that allows triggers based on the spoke chatword. Opens the door for non-linear plots and immersive environments.

9. Rotating brush model support.

10. Dynamic splash screen and console support. One example: some of the Nehe demos offer examples of effects that various engine should be able to easily support upon launch and during console display. ezQuake to some degree is an illustration of such.

11. User Accounts. Primarily for the purpose of whitelisting, but also for the purpose of stats. Current administration controls are not enough.

12. Friends lists. Especially when combined with #5. Compete against your buds.

13. Error reporting of the client. In the age of libcurl, there is little reason to not collect feedback.

12. Clipboard support. Even on Linux if internally. Windows and OS X have a clipboard. Even if Linux doesn't, it should still internally support an internal engine clipboard reservoir that can be text exported.

13. Client and server entity browser.

14. Full video mode switching.

15. ROQ format style cut-scenes.

16. 8-bit Software only: the ability to convert 24-bit/32-bit TGA on the fly to the current palette for display.

17. Built-in Quaddicted style mod launcher. It shouldn't be separate.

18. Extra hull support. I won't define this. But an enhanced q1 BSP format is approaching a "must-have".

19. Enhanced particle support. Won't completely bother to define this completely. Sprite 32 comes across as a minimum. Maybe some version of effectsinfo.txt

20. Intermission transition screen control. Won't define this either.

21. Document viewer. Seriously. I mean textfile scroll window with scrollbar, not something more complicated.

22. Prediction.

[Team Xlink]

I agree with you, Baker, this seems like the QSB standard idea as well.

[Spike]

2: clarification: my code requires a modified trigger_changelevel.

6: recommendation: setattachment.

7: concern: file access is not always desirable... be very cautious about this.

10: complaint: ezquake's console is like a christmas tree in march. Tacky, without even being festive. A regular user shouldn't be expected to look at the console for anything other than chat/death messages.

12: correction: X11 has _two_ sorts of clipboard!

23: an awareness of other engines (ie: a readable message when an nq client tries to connect to a qw server).

24: rewritten NQ net code...

[Team Xlink]

[mh]

[leileilol]

As a super experienced person who actually does produce custom shit in quake I will have my opinion shared among this:

1. wrong. csqc requires beyond-engine coder expertise but for making custom huds in csqc, it isn't difficult at all. having partial csqc support JUST FOR THE VIEWPORT ALONE is enough for this.
2. hexen2/quake2
3. potential cheat and wouldn't go well with sv_playerphysics/calcrefdef
4. unneccessity
5. forget it, it would be quickly gamed and uneconomical faster than you can say 'achievement_idle'
6. isn't an engine feature. movetype_follow + drawonlytoclient is the proper term for the quake2 method. the more modern 'right' method would be to attach a weapon model to a tag on a md3 or a bone of a skeletal format
7. welcome to 2000
8. it was annoying in excessiveplus "Ass! Ass! Ass!" and it would be now. a csqc unneccessity
9. done a thousand times already
10. why
11. not client-code ; just implement a nickserv on the serverside and have the client 'tell' the server somehow to authorize
12. "add non-steam game to list" done. also qtracker has extensive stalking features
13. -condebug's enough
12. lots of engines do this, even QIP quake does it (qip quake is often forgotten of its existence since it doesn't do interpolation)
13. pointless
14. ...it's the only video mode switching quake allows
15. quake2 calls this .cin
16. pointless as such textures would even be out of the resolution necessary for the spans leading to a worse appearance if sampled down
17. to menuqc
18. Unneccessary. just support q2bsp/q3bsp and forget about adding hulls
19. effectsinfo.txt is the only decent implementation of this idea and this should even be done in software engines (without the texturing of course). sorry fte and tenesuck
20. Too vague. What, no idlescale? or v_intersway?
21. to menuqc
22. Implement the Quakeworld / DP protocol stuff

tl;dr version: quake2. fteqw. We've had all these features for years but who's going to use them really? NOBODY. This thread is no better than that one guy bugging for halflife formats because it'll somehow solve the quake creativity stagnancy (FTEQW supported HLBSP, SPR32, HL Sprites, and HLMDL since 2003. How many times were those used together since?)

The QSB spec has enough of what I want anyway and then some, but some of it is badly contrived and it's been all talk and no do. the only thing that wants to 'do it' is RMQ and i still have bad impressions from that old alpha i'm not sure if i have faith in that one anymore. it's just hype right now

[frag.machine]

Items 5, 11 and 12 are the kind of questions an embedded database (read: SQLite) could answer just fine. Another use would be support for RPG-like and/or persistent world mods. Finally, it could also work as a sandboxed replacement for the frikfile API.

[dreadlorde]

The day a database (like sqlite) is needed for quake is the day it dies.

[Sajt]

Concerning vweps and, well, general engine gooderization:

I'm making a MDL format extension that adds higher quality vertex coords to the end of the file, where they'll be ignored by engines that don't support them (they will just use the old crappier vertex coords).

Due to the transparent backwards compatibility this feature isn't necessary for anything, but it would be nice to propagate it into some kind of standard, so modders (Quoth?) might actually bother to use it.

The other thing I'm considering is an external tags file which will specify per-frame tag positions for any model. The tags would then be accessible using the standard 'setattachment' et al QuakeC interface, as if they were md3 tags. Qwalk2 is going to have some features for easily and visually creating tags in existing MDLs (based on relative positions of existing vertices).

[leileilol]

do it

and for that .tag idea you could doll up the MDL exporter for Blender to output empties as tags like the MD3 exporter does

I'm probably going to be the only one that uses your technology in the end anyway.

[mh]

I like the idea of adding extra data to the end of a file like that. Potential to do similar with the BSP format too.

[frag.machine]

[Spirit]

[mh]

[leileilol]