by Preach » Sat May 19, 2007 11:39 pm
I don't think people would want one mod to do everything, it will end up with too many redundant pieces. Once you've decided to use a mod instead of stock quake then it's no more hassle to provide your own mod with a map than it is to tell people to use this unified mod. If you want to change things later you'll need to make sure you have backwards compatibility, which might be restrictive/complicated. Plus individual maps often need things tailored in ways nobody anticipates - no matter how many features you add. Adding your own unique boss to a map, for example.
What I think could be more useful would be a repository of code that does all of these things, easily available, made as modular as possible. You could have a base qc source that changes nothing at all except fixing bugs - the Quake Info Pool list of fixes for instance, along with a few things aguirRe is always fixing in mods for people - recursion in some of the search functions and the like.
Then you'd have a list of these useful things like rotating brushes, generic sound, teleportation flag. Each useful thing would come with a chunk of code, with very clear instructions on how to impliment it(for someone with absolutely no experience in QC). The various bits of code would be as modular as you could make it, all the various pieces being designed to work together in theory. You could warn of possible conflicts between pieces of code in this repository if they arise.
Then when someone is making a new map, they can just run a checklist down this set of available features and build the ones they want quickly and easily, even if they don't really understand QC. The end result is that they get a nice slimline mod that does just what they need for the map without any fat.
For my part, here are the things I'd think would be handy:
Entity Optimisations - saving ents is important for large maps, so things like culling info_teleport_destinations, storing info_player_start,coop,deathmatch as origin vectors in globals, actually removing the ammo entities in single player rather than just hiding them.
Corpse Management - related to entity optimisations is what to do once an enemy is dead. Lots of larger maps need the bodies removed, so a nice bit of code is needed to handle this job. It can be done in a "unified" way like the monster spawning, with a little ingenuity.
Customisable monsters - this one strays a little from the custom mod for each map idea, as it's a kind of generic mod feature. It's also hard to see it being a feature that's easy to impliment in a modular way. What it involves is turning lines like
setmodel(self, "progs/ogre.mdl");
into
if(self.model == "" )
self.model = "progs/ogre.mdl";
setmodel(self, self.model");
So you can customise the model/health/etc of a monster by setting the entity fields, and leaving them blank sets the defaults.
Logic gates - There are ways to set up logic gates in maps already, using spikeshooters and doors as literal gates. But obviously an entity to formalise this would be much more sensible. The logic gate entities would be statements like AND/OR/NOT with several input fields, each having a targetname. The gate would then have one "target" field that gets triggered if the logic gate test is passed. Chaining them to make more complicated decision trees would be straightforward from there.
Decision triggers - Similar to the logic gates, you would have a trigger that fires if a certain property holds, for example if the player is below x health, if the player has a certain weapon, if a monster is nearby/no monster is nearby. It would be quite hard to exhaustively list all the possible things a map might want to check for, but having customisable code here would help a lot.