Multiplayer FPS Model Strategy

This post is regarding a first person shooter that will be online multiplayer.

I want to have a model of arms that will be what the local player will see when they play. The local client will not render the entire body of the player, simply the arms of the player.

The local client WILL render the full body of all other players. So, just a recap, the local client will render the full body models of all other clients, and the arms of the local player. This allows me to have cool animations with switching weapons, reloading, etc.

Does that sound like a good plan? Does anybody know what big companies like Valve do for that sort of stuff?

In addition, how do those companies make their models grab the correct parts of new gun models?

Is there a book I could read on the general theory behind this kind of stuff? Every book I find doesn't want to discuss the general theory–they're all about promoting this tool or that tool or this engine or that engine…

My best advice would be that you try to mod a game. From all the things that are needed for a modded player model and weapon model to work, you can figure out what and how the game makes it work.

I had the fortune to mod a game which was moddable trough plain text files. So it was easy to figure out how the code interpreted those text files, and what it was doing.

I don't remember all the things, but basically it worked like this:

The main components were:

  1. Model description
  2. Animation description
  3. Weapon description
  4. Ammo description

    The model description contained the model names of alive and dead (destroyed) model. As well as pointers to the animations and sound files. The hit points, speed, etc. It also contained the name of the handler class of the model, like "player", "AI bot", "4 wheeled vehicle", etc.

    The parts of the actual 3D models were named. Every model was required to follow a rigorous naming standard. For example a player model had to have: "eye point", "eye direction", "weapon attachment point", "weapon direction" (these points behave like bones in animations). Every vehicle had to have its wheels named (so those could be properly turned and rotated), attachment points where players could sit in the vehicle, etc. When a part of a vehicle was named, it also meant, that the physics engine could separate those parts when the vehicle exploded. I'd like to emphasize this part, since it is a misconception that the coder has to make all the models work. All the free models on the net are pretty much useless in this respect, those models are either made for a specific game engine, or lack the information needed for the models to work. The coder should make a kind of "modelling interface". There should be a standard (documentation) for modellers, how they should build the models. Custom modelling tools (plugins, model importing tools) should help the modellers too.

    The weapon description contained references to two models. One for weapon model when seen in another players hand, and one when the weapon is viewed in the players own hands. If i remember correctly Valve uses three: on the ground, in someone's hands, and in players hands. The rendering of first-person view of the weapon was probably done in a separate rendering pass, with different near-far frustum planes than the main view. It also contained the reference to the image file used as overlay HUD (iron-sights) when the weapon was used in aiming mode.

    The ammo description contained data on the damage, trajectory, spread, impact effect/explosion of the weapon/ammo combination.

    The developers concept (IMO) was that basically every behaviour should be coded into different classes. Then if two models (weapons, ammo) behaved similarly, then a moddable text file was used for parameters.

In addition, how do those companies make their models grab the correct parts of new gun models?

If i understand your question correctly, you are asking how to make a single model hold different weapons, and to look natural. When viewing other models, a specific animation file is associated with the given model and given weapon (with hierarchical animations its possible to affect only the arms+hands). When the player is viewing its own weapon and hands, the hands are also part of the model itself (weapon+hands). Or are separate models, but the hands have an animation file specific to the weapon. I could imagine an IK algorithm, which given the attachment points on the weapon and character model, could calculate the correct position of hands, but that again does not solve complex animations, like reloading a weapon. So i would just go with hands and weapon modelled together. Since you want a multiplayer game, with probably different hand models, that would require a specific animation for each different model with each of the weapons (if weapon/hand models are similar, then those animation files can be reused, hence the text files to define these). Think about "holding a weapon" like "playing the idle animation of hands".