Ping in the scoreboard is one of those features where you turn over stones and things crawl out from under them. Things with far too many legs.
Now this isn't a problem with something like ProQuake which is a dedicated multiplayer client, doesn't support huge maps or alternative protocols, and can easily afford to treat special cases as the normal case as a result. For something like QRack it needs to be handled, but not so much as once again it doesn't step too far beyond supporting what ID Quake (and ProQuake) supports.
For an engine like DirectQ it is a problem that needs to be addressed. This underlines the reason why I'm normally reluctant to implement dedicated multiplayer-only features which are only of benefit when connecting to ProQuake servers: as well as the overhead of actually doing the initial implementation of the feature, there is also the overhead of making sure that it plays well with everything else, and a continuous ongoing overhead of making sure that things stay that way.
If I hadn't already announced that I was doing this, the obvious easiest solution would be to just drop the feature and say nothing at all. That might still happen, but right now it's tickling the part of me that's marked "hmmmm, interesting" well enough that I'm going to continue.
So what I'm planning on doing now is putting walls around this feature. The code required for it will only get run if you're in a multiplayer game that's using protocol 15. If I can reliably detect a ProQuake server from the client side I'll wall it off to ProQuake servers only as well.
Otherwise who's to say that adding support for this won't screw up a demo recorded using protocol 10001 for example?
This is where the ongoing absence of QuakeSrc.org is really going to be felt badly in the future. Inside3D is picking up some of the slack, and is doing a great job, but the requirement for a standards registry that everyone buys into is still badly needed. The proposed Quake Standards Base is a nice idea for sure, but I would vote for stabilising what's already there as a priority requirement before we even think about moving forward again. Unless the major engine authors start getting together and agreeing on things instead of going off in their own directions we'll end up with every engine supporting it's own mutually incompatible set of standards, and any attempt at being "all things to all men" will be doomed to failure from the start.
It was with this thought in mind that I decided to implement FitzQuake protocol 666 (and the BJP protocols) in DirectQ. I hadn't elaborated it to myself at the time, but I certainly did view it as some kind of vague requirement.
None of this is to advocate some kind of "design by committee" approach. We all know that doesn't work and produces watered down half-assed results. Throwing out ideas and getting feedback on what's good or bad about them is the name of the game here.
And so we come back to the original matter of ProQuake scoreboard ping, and the way it's implemented in the engine. Not to denigrate the original author of ProQuake, but if this feature had been properly built up with at least one eye on making it an accessible standard, it would have been far superior. The trouble with wildcards is when that wildcard becomes a de-facto standard (almost always despite itself, as it's very rare that it's the best or most elegant alternative) it always necessitates a period of pain and suffering while everything else tries to bring itself up in a compatible manner.
We've seen this happen so many times before that one would think we would have learned by now.
Sunday, March 14, 2010
More on Scoreboard Ping
Posted by
mhquake
at
1:18 PM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment