The Problem of Quake's Player Base Size

[r00k]

In terms of making Quake be visually appealing under the same expectations we have of modern titles, or even scaling it back a few generations and settling for something a bit more on the level of WoW, I think the only possible solution (and it's a vague possible solution) is stylization. At least, given the artistic resource constraints that any such project is bound to face. This is the general cop-out that's also used in the commercial arena, when the art resources just don't match the scope/goals of the project.

Retro modernize it for the iphone

[Rich]

NQ doesn't have master servers, otherwise it would have been done a long time ago.

Oh, I see. When I mentioned "technical reasons", I was thinking more along the lines of, perhaps people want to maintain the old qspy/gamespy protocol and no one knows what the hell to communicate between the master and client. If it's just one of those NQ vs. QW things, I don't think that ought to stop anyone. Just respect the master cvars for NQ as well, and either track the protocol version on the master or let the client poll the server to discern its protocol version, so that the client can filter servers by supported protocol(s) appropriately.

How is the list at http://quakeone.com/servers/ populated? It's not completely manual, is it?

[Spike]

gameaholic has a list of forgotten servers in ip-only form, served up via tcp. FTE already parses that but I doubt anyone uses it.
In both cases the list is added to manually, as far as I'm aware, so half the entries are probably dead.

In all seriousness, just use the dpmaster protocol for NQ. Its like the QW protocol ones, but you can steal.. err... use some existing ones... urm, for redundancy... yup...

[qbism]

Thoughts on what it would take for a successful multiplayer base engine(s)-

A lot of Q1 dev is done in silos as each project focuses on specific areas. The ability for a single person or small team to prototype quickly is a feature of Quake. Many recent tutorials and other documentation have emerged to promote 'bridges' between these projects.

"The Engine" may not come down to a single perfect codebase with all others falling by the wayside. But it is beneficial to regroup and raise the bar. The standards should include 'official' client-server and master server protocols, a long list of known fixes, and a lowest-common-denominator target (LCD).

One benefit of all the existing engine branches is the huge variety of devices supported. Some vintage or portable platforms may have specs lower than the LCD. Unsupported features should drop-out gracefully. (Skyboxes and png textures are examples of peeves in this area.)

Observe newbies whenever possible as they run the game. Changing the defaults of a few settings for 'modern' conditions could get them up-and-running quicker.

2010 kicked-off with the Quake Standards Base discussion. How does that fit-in with practical multiplayer implementation moving into 2011?

Coop and team modes are a strong point for Q1. Engines and protocols should be supportive of that, such as entity only-to-client or all-except-client type DP extensions.

[r00k]

Hmm, I guess it REALLY depends on what you want your MultiPlayer game to be. I like the idea of Quake the SDK for an entry level game dev starter kit.

{tangent}

Imagine back in the day early 90s, before the internet. Most of us did this forum chit chat on BBSs. And taking a look at that for a moment.
There were door games. Most BBS had only 1-4 line simultaneous connections. Quake can support 16,(dp = 64?). Imagine a single DarkPlaces server hosting 64slot, realtime "BBS", in 3d. Imagine each connecting client able to host a backend 64slot server, all interconnecting with 64 more "clients", whoa that would be a crazy social network. WoW meets FaceBook

ok its after 4am I'm talking in my sleep again...

[frag.machine]

"The Engine" may not come down to a single perfect codebase with all others falling by the wayside. But it is beneficial to regroup and raise the bar. The standards should include 'official' client-server and master server protocols, a long list of known fixes, and a lowest-common-denominator target (LCD).

One benefit of all the existing engine branches is the huge variety of devices supported. Some vintage or portable platforms may have specs lower than the LCD. Unsupported features should drop-out gracefully. (Skyboxes and png textures are examples of peeves in this area.)

In this case, LCD should be interpreted as "largest common denominator" instead. And actually I think is better to accept that such engine or standard won't fit for very low end/ancient hardware (sorry leileilol) and not hinder the platform evolution. The cut point is what could be under discussion, not if it will happen.

Observe newbies whenever possible as they run the game. Changing the defaults of a few settings for 'modern' conditions could get them up-and-running quicker.

*cough*consolititis*cough*

2010 kicked-off with the Quake Standards Base discussion.

I wouldn't hold my breath for QSB. It's something that the community already feels it's badly required, but looks like nobody really cares to make it happen for some obscure reason to me.

[Baker]

I wouldn't hold my breath for QSB. It's something that the community already feels it's badly required, but looks like nobody really cares to make it happen for some obscure reason to me.

I think it has already happened and is continuing to occur. FitzQuake 666 protocol (how many engines have this now? 6?), alpha support, rotation, other miscellaneous bells and whistles.

re: Quake

Quake in some ways is a colossal failure of a game two degrees removed from perfection where the sum of the parts adds up to so much less than it should.

Such a place is the breeding ground of daemons. Past, present and future.

(Cube engines, Nexuiz, 100 different engines including ones running on exceptionally weird devices, Open Arena, CSQC, Quaddicted, this place, QuakeOne, miscellaneous map editors/converters/experiments, NQuake -- hate it or grudgingly accept it -- ad infinitem plus all the dead sites of ages gone by. Unlike other games, these things attract far more brains instead of the masses).

Perfect places inspire no such thing.

[frag.machine]

Don't get me wrong, Baker. I am sure that you do fully support the idea, not only by words but by actions. But the fact is, any QSB specs are so far fuzzy at best - and something that intends to be a "standard" cannot be ambiguous. You cited some no brainers like protocol 666, but there is far more than build a list of features to create a true standard. We need reference implementations, we need a test mod to validate every required aspect of QSB (test maps using external textures, higher limits, QuakeC required extensions, etc) we need some abstract documentation about each feature (for example: among the several ways to implement fog in OpenGL, which could be considered "QSB compliant" ? What if engine XYZ uses a software renderer and has a funky/hacky fog based in obscure color pallete mumbojumbo ? Can it be considered "compliant" ?). How about CSQC ? Does QSB will support something from this at least as "optional" ? Which will be the RI ? FTEQW ? Darkplaces ? Anything else ?

There is a LOT of things that were already discussed, another big bunch that wasn't even touched, but very few was actually defined. From time to time, the discussion comes back to life when someone think about modernizing Quake. And everything always falls in a frustrating silence again a few messages later. And I'm afraid this time won't be different.

Ok guys, sorry about the bitter rant. But the fact is, I really would like to see Quake rise from the muddy waters of the past and shine once more in all its glory, like a quad powered rocket launcher (lol!). And seems to me the only way is to add efforts around a common collaborative project, and the start point is QSB.

[Spike]

Tbh, the only way I can see a QSB work is if its along the lines of:
If project supports $FEATURE
$FILENAME is supported and loaded (reason must be given as to why its not prefered over other alternatives if its not favoured).
$STUFFCMD args are supported.
If project doesn't support $FEATURE
don't complain when clients get stuffcmds.
If project supports $NONQSBFEATURE
$QSBFEATURE is not broken, even if a cvar unbreaks it (can have cvars that break it, just their default value must be QSB-compatible)

to be fair, that's not too different from the current extension system, except that the current extension system doesn't give a damn about network compatibility.

[mh]

To my mind the key barriers are:

• The split between NQ and QW.
• Quake clients often failing to work on modern software and hardware.
• An insistent almost religious belief in some quarters that - in the age of the PS3 and XBOX 360 - requiring command-line args and console commands (not to mention case-sensitivity) is somehow a good thing.
• Lack of sensible defaults that meet modern gaming expectations (mouselooking, crosshair, you know).

Fix these, and then maybe start talking about QSB...

[revelator]

not to mention

"stoneage opengl support (i kinda understand mh's reluctance with the opengl api).

but... direct3d is in no way more powerfull nor better than opengl in fact the d3d api only recently aquired hardware tesselation. opengl had that 3 years before the ms guys even thought of it, it may be easier to code in but i kinda suspect coders today of being more used to the c++ syntax in the d3d api.

the sad thing is most only use a small part of the possibilities of modern opengl"

"besides there being numerous api's availiable for letting the user decide to mod there favorite quake engine without destroying its basic functionality. like reading in ent scripts to do map based workarounds, or basic shader or script support (both avaliable).

i believe fragmachine made one of them ? (Qdq2k) the other one is as old as topaz quake and needs some reworking but it allready back then supported a large number of Q3 shaders in Q1 and used vertex arrays. None of these (and more like vis file support) made it into a standard which is kinda sad if you take the development timeline into account"

[mh]

but... direct3d is in no way more powerfull nor better than opengl in fact the d3d api only recently aquired hardware tesselation. opengl had that 3 years before the ms guys even thought of it

*cough* vertex buffers *cough*

Ahem, moving on...

Yeah, the usage of OpenGL in Quake sucks and is a huge barrier to uptake too. At the very least it needs to be updated to OpenGL 1.1, for crying out loud.

[Baker]

Don't get me wrong, Baker. I am sure that you do fully support the idea, not only by words but by actions. But the fact is, any QSB specs are so far fuzzy at best - and something that intends to be a "standard" cannot be ambiguous. You cited some no brainers like protocol 666, but there is far more than build a list of features to create a true standard. We need reference implementations, we need a test mod to validate every required aspect of QSB (test maps using external textures, higher limits, QuakeC required extensions, etc) we need some abstract documentation about each feature

Well, I am a believer in both the roles of "pure science" and "applied science".

Pure science. The discussion of abstract ideas. Possibilities. How they would work. Much of the discussion that occurs here. It shapes the future. Fluid.

Applied science. The actual implementation of abstract ideas and a body of work using them. Debugging. Discovering unforeseen issues. Defining limitations. Solid.

Engines can't inherently define standards in Quake because it is a pre-existing game, only mods and games can define standards as a result because you must have a body of work to support it and to create demand.

1. Texture sets created a demand for a texture set standard.
2. Single player maps using fog, lit files and skyboxes created a demand for those as a standard.
3. Limit busting maps created a demand for enhanced limits.

Engines support a game generally speaking, not define it. You still need supporting QuakeC, mapping definition files, etc. and like you said test implementations.

My opinion of change is that "change is always slower than what you want, but far deeper than you imagined."

I'm confident things are moving in the right direction, there just isn't a visible fireworks display for people who aren't as confident. The QSB discussions, HUD discussions and all the other discussions will eventually be discovered in retrospect to have had quite a bit of impact.

[leileilol]

The truth is, QSB doesn't mean jack shit when the multiplayer scene is 24/7 Aerowalk/DM3. It's much like Doom's problem where the majority are a bunch of Dwango5 Map01 scrubs, disregard for all the ports that extend the game.

[qbism]

Maybe "baseline" is a better term than LCD. For example, 4000 maxvertexedges is a good practical limit as compared to QSB's 60,000+ ideal. I'm biased, but the baseline should include a software-renderer build.

Fitzquake protocol is great, relatively easy to implement, but some gaps for multiplayer. #1 potential improvment is support of additional TE_ and DP_ extensions, needed for mods like OrionTF. DP_SV_DRAWONLYTOCLIENT, DP_SV_NODRAWTOCLIENT, DP_SV_MODELFLAGS_AS_EFFECTS, DP_ENT_EXTERIORMODELTOCLIENT come to mind. Fairly easy to implement. Protocol must pass long rather than byte ent->effects for starters. ent->baseline could be used to only send updates when effects change.

Other protocols to look at- FTEQW, DP, bjp. However, I doubt that backporting DP protocol to a software engine would be fun.

An irony of the NQ/QW split is that both FTEQW and EZquake support NQ and QW, and already include many features of an ideal engine for newbies (in-game server browsing, mouse menus, easy installer)