Quake Standards Base discussion

[Urre]

[dreadlorde]

[Spirit]

[Spike]

[Baker]

A QSB 0.5 would be nice.

Right now I am thinking that the ideas behind a 1.0 standard violate the 90%/10% rule (90% of the gain for 10% of the effort).

My personal philosophy is that development and standards are fueled by completed works that people enjoy playing and are popular, increasing the demand and use of the feature.

Certain features have LOW implementation costs and HIGH gains for implementation:

* Scale
* MOVETYPE_FOLLOW
* EF_NODRAW
* EF_ADDITIVE
* DRAWONLY_TO_CLIENT
* FRIK_FILE

etc.

And certain other changes have very HIGH implementation costs and LOW gains for implementation:

* Memory management systems
* Major protocol changes
* Major changes to break limits

I'd like to see a stepping stone standard as a reasonable first step towards a greater standard.

There is nothing inherently wrong with QSB 1.0, but a fast and easy to achieve QSB 0.5 with most of the easy win features that would allow better modding would be nice as a checkpoint to a 1.0.

Obviously with a protocol 15+/666+ to support it maybe even with delta compression if that isn't too difficult to achieve.[/list][/code]

[mh]

One other advantage I can see of a QSB 0.5 is that it would let us road-test the standard rather quickly. We all know that talking about great ideas is one thing, but actually doing them and seeing how they work in practice is completely different. By getting something up and running sooner rather than later we can easily identify and find solutions for potential trouble spots.

It would also greatly ease the implementation overhead for engines that have already been evolved well boyond the ID Quake baseline.

The danger of course is that the standard will become stuck at 0.5 and not go much beyond that.

[frag.machine]

We can create a QSB 1.0 standard with a really minimal list of features, I don't see the need for "< 1.0" version numbers. Actually I already told that: let's start small, a list of 10 or less features that we, the community, could consider the "minimal" to expect from a non-vanilla engine. QSB 1.0 doesn't need to be "complete" - actually, it's unlikely it will be in the first incarnation. I see QSB only reaching a "mature" state after the fourth or fifth iteration. So, I'd vote to start small, but following the "90/10" rule Baker mentioned.

Another advantage in start small is to dissipate a bit this "formal committee" image we are creating to people outside the discussions. Both dreadlorde and Urre have valid, although different, points regarding this committee image. But IMO the simpler we start the easier people will embrace the idea.

Regarding checkextensions, I share Urre's point of view: why not implement it ? It's really simple to do, a number of projects already have it (filling the "let's standardize what's common" requisite) and quite useful for modders. Having the ability to detect in a safe way if the engine can/cannot do something is useful. Unless somebody is considering another QSB-exclusive mechanism - and, TBH, I think it's not a good idea to reinvent the wheel, since checkextensions works just fine.

[mh]

[Baker]

[metlslime]

I agree. To restate my earlier posts:

- smaller, incremental standards. Multiple small versions are easier to implement, but more importantly, easier for a committee to agree upon than one "ultimate standard"

- standardize common practice, rather than inventing new features. new features are too hard to spec, existing practice is proven to be usable in the field.

- keep it modding relevant and eliminate anything that is outside of that scope. Console size, tab completeion are NOT modding relevant.

- implementation-agnostic requirements. MAX_MAP_LEAFS are inherent to the bsp file, MAX_GLTEXTURES are not, because they depend on all things the engine uses gltextures for.

[mh]

[Sajt]

[metlslime]

[mh]

[r00k]

1.> QSB 1.0 engine limits
2.> ENHANCED STRING FUNCTIONS / FRIKFILE support
3.> SKYBOX, FOG, ENTRYSPAWN world spawn fields
4.> enchanced SVCs for hud features.(teamscore, match time, flag status)
5.> 24bit texture support. atleast menu and world textures
6.> animation interpolation
7.> cvar standards