A new standardised protocol?

[Spirit]

Hi Engineers!

I am clueless about network stuff, protocols, code etc. But I had the urge to post this. Surely I forgot to write down this or that and some things might sound stupid. Well, it's basically just an attempt to invoke a discussion.

Maps are getting bigger and bigger in terms of pure size, details, monsters and probably other things. The problem is that the common engines are not able to load those maps. Of course you can say "well, these are Quake's limits, if you break them I could not care less if my engine breaks". I totally understand this and actually I feel a bit like that myself (meaning I somehow like being limited).

However, people are making these maps, some of them are simply great and the players expect any map to work in any engine. Unless I overlooked some there are only 2 (3-4) engines that have introduced support by using an optional less limited network protocol so far.

supports "QUAKE, QUAKEDP, NEHAHRAMOVIE, DP1 and up (DP2, DP3 etc)" via sv_protocolname.
support "15 (std Q1) and 10000-10002" via sv_protocol.
is going to have a protocol for such maps in the upcoming release and it's another proprietary one.
might be getting one too, at least it would not surprise me when I look at the to-do list.

As I briefly talked to metlslime (Fitzquake) about it, the probably biggest problem quickly came up:
<Spirit> it would be pretty cool if you engine coders could get together and decide on a common protocol
<metlslime> every engine coder agrees with you, and furthermore every engine coders thinks it should be their own protocol that becomes standard

While the internal limits (lightmaps, clipnodes etc I think) don't really affect anything "outside" your engine, the protocol limits (such as entities) surely do. It wouldn't be that much of a problem if we were talking about singleplayer only, it sure is a mess if you take multiplayer (obviously different protocols do not talk to each other) and demo recording/playback (obvious to coders, not so much to a player) in mind.

It's sad enough that things like fog, full- and overbrights or skybox loading are so differently supported, but those are faults made in the past I guess. These protocols are a pretty current thing so right now is the chance to set a common standard to benefit everyone:

The coders can brainstorm and create a truly kickass protocol.
The mappers and modders can let their creativity float more freely.
The players just see it work.

As a "benchmark" the would be perfect I guess.

PS: I am not sure about Nehahra but I guess if there was a standarised protocol with "higher limits" (and whatever else has to be changed) then Nehahra would be supported?

PPS: MH currently seems to be working on exterminating/increasing the internal limits, maybe he can put this into a nice tutorial/guide/article so others can catch up?

So to conclude:
How to create a protocol that more engines could adopt?
How to name it?
How to use it (variablename)?

[FrikaC]

Quick way to make a standard = make a good tutorial.

[mh]

[frag.machine]

Ok, let's start from the begin.

Let's put the problems properly pointed out by MH and metslime apart and try to define a clear goal to achieve with this new protocol - namely, to support bigger, far more populated and detailed maps.

So, in order to support this new protocol, an engine must also:

1) supports a bigger number of dynamic entities (at least how many ? 1024 ? 2048 ? as many as the available memory allows, like Darkplaces ?);
2) supports a bigger number of precached models (again, at least how many ? the current limit is 256) and sounds (same limit as models);
3) obviously, stretchs the internal engine limits for vertices, faces, leafs, possibly number of textures, dimensions, etc;
4) and of course, all this limit breaking eats up a lot more of memory, specially stack memory space, and depending of how many of this the engine already consumes we can start to bumping the head on the floor, requiring a major rewrite of some parts of the code to compensate this;

And so on...

As you see, the problem goes far beyond just defining a new protocol: there is a lot f work to do in the plumbing department to reach the point where one can say: "now, let me think about a new protocol". And of course, even if we manage to define a minimal set of messages to expand the current protocol or simply create a new one from scratch, there will always someone whinning like "waaaahh engine XYZ suxx0r cos doesnt support <insert non-trivial feature here> and cant run map blah".

However, that said I agree: we shouldn't be limiting ourselves by standards defined 13 or more years ago, when bandwidth, memory and CPU raw power were far more scarce. And if enough people agree to "sit" and define a minimal message set to this goal - running bigger maps like warpc.bsp - I surely would try to implement it in my engine.

[Spirit]

[frag.machine]

[LordHavoc]

[Baker]

[LordHavoc]

[Baker]

[frag.machine]

[Baker]

[frag.machine]

[mh]

I've two ideas coming right up!

Gonna create a new thread for them though, which seems a sensible thing, so as not to clutter up one discussion with another and end up with a confusing mess of cross-posting.

[metlslime]