Some Technical Concerns Regarding Use of New Player Models

by SteQve, 3/12/98 I have some concerns with the proliferation of new player models that I don't feel have been fully addressed yet in "idsoftware's code. These concerns, while they may be relatively minor, can have an effect on Quake gameplay, especially in some mods. Some of these issues also affect Quake II "as is." Please correct me if I have erred in my analysis.

Note to non-technical people: following is a fairly technical description. Modders can make an intelligent guess as to why idsoftware made the design choices that they did, so this should not be thought of as any criticism of idsoftware's programming efforts.

Deciding what gender a model is

id's code makes a simple assumption of assigning gender based on the first letter of the skin name ("male/WHATEVER" or "female/WHATEVER"). This is very efficient but yields incorrect results when there are male models which happen to go into folders that start with "f". In addition, new female models are "assumed" to be male by default if they aren't in a folder that starts with "f". Even the new Crack Whore model by Paul Steed is called a "he" in any gender-specific obituary, and the Crack Whore *as originally distributed* had a male voice due to the defaults specified by the code. ;-)

I think that there is, therefore, a need to be "cleaner" about specifying and handling gender in the game. Some "gender value" could be specified by the client, then used to determine gender for obituaries as well as default sounds. For models which are "gender-free" and/or without sounds (such as the Snork), the gender value could assign an appropriate set of sounds depending on the user's selection. It would be nice to allow flexibility for different "genders" as well, e.g. a "neuter" for all the Snorks or machines out there, or some other notion of "gender" depending on what is being modeled.

Perhaps the way to address this problem is to specify the gender value in the userinfo string (and filter out obvious attempts for a male player to set a female sound, for example). BEGIN WHINY SOAPBOX: Oh, and this gets into another minor issue I have with the game - if a female skin doesn't exist on the server but it's known to be female, why not select some default female skin? I hate hearing that grunt screaming in a high-pitched voice ;-) END WHINY SOAPBOX.

A different way to handle the gender specification problem might be to provide a generic "gender" command or variable to be settable by the player, but that's probably problematic too.

Yet another way would be to encode the gender into the model itself (allowing for flexibility to account for things like machines, Snorks, etc.) but there are lots of reasons to discourage this approach ;-)

Varying sizes of models

Players can use new models that have a decidedly different size and shape than the normal player models. The code appears to assume a uniform player size. But then there is a discrepancy between the size of the model as the human sees it vs. how the server sees it.

What this presently means is that there are parts of larger models that can't actually be hit by another player, and there are parts of smaller models that you can miss entirely but still hit. If you want to see this for yourself, use the great Cartman model from South Park, which is both short and wide. Turn on your crosshair. Shoot him in the left elbow or hand and you won't hit him. Shoot 2 feet over his head and you will.

Should this size difference be accounted for on the server side? What impact should this new variation of player sizes have on the game? If the server maintains a uniform internal model size, then players should be notified about this discrepancy and adjust, since there will be parts of larger models that an attacker will miss, and there will also be empty spaces around a smaller model that will be hit (and not just because of auto-aim ;-) I imagine that some players already know this.

If the server DOES take this size difference into account, a smaller or larger player shouldn't get an unfair advantage because they use a differently-sized model (Uh-oh, sounds like I'm starting to get PC here, first I talk about gender, then this "differently-sized" term!) With varying model size there are obvious applications for cheating (albeit the issues are probably the same as with "skin cheating"), and besides, how would a server know what the model size is if the model being used isn't on the server?

Using color "shells" with models

Some differently-sized models do not glow properly with a color "shell" such as Quad damage or invulnerability; only parts of them glow. Look at the mek or tentacle models, for example. In the mek model especially, only a portion of its arms glows. This may be less of a problem for people using GL since the color shells glow so brightly, but it is harder to distinguish with software rendering. This problem has an even stronger impact on mods such as Keys2 or TagYerIt which use color shells extensively.

You can see this picture for an example of the Mek model with a yellow "shell" and without. I'm not a modeler, so I don't know if this is a modeling or skinning problem, or a Quake II problem.

The mod authors do not have control over how the shell is to be drawn, therefore a solution to this problem may require modification of the Q2 client.

A Simple Conclusion

I love the idea of the flexibility of all the different models, but these are some technical issues whose solution I think would further enhance game play, especially for those people who use mods.

If you have comments on these concerns, please email me.

Go back to SteQve's No Frills Quake Mods Page