I think it's pretty much universally agreed that simply mapping the analog stick to rotational speed of the character is not good enough to make console first person shooter feel good.
So what are some input paradigms that make a modern FPS on the console work well?
I went to a GDC session this year presented by the guys at sucker punch, discussing how they handled assisted aim and movement for inFamous. My understanding is that Halo uses a very similar system for assisted aiming, and here's the basics:
There are two things that make aiming "feel good": You need to feel like you're in control, and you need to feel like the game is not lying to you. Adjusting the game's perception of input direction and button timing within tolerances is a great way to do this, as it NEVER results in an impossible situation where the auto aiming is actually performing better than a theoretically perfect controller. If you try to solve it ad-hoc after the input processing is complete you're going to end up with some sketchy situations where the player feels like they have lost control.
There are good answers here. I had to figure it out for myself on the project I'm on, but came to the same conclusions as the Sucker Punch guys (and I had thought I came up with something novel. Baww :( ).
I find it useful to consider your entire first person 360x180 degree "panorama" as an "acceleration field". All valid targets create gravity wells which bend the player's input (only subtley) such that macro motion (turning to face targets) feels as though it's a "greased" path. However, this is not affecting the crosshair all of the time - only when the player's turn delta is pointed with the slope of the well (as it were). That's really key though - you're only giving this extra turn speed when the player is turning roughly toward a target. That's about the only inference you can make from the player's input.
Much more, and you get too much of a noticeable "ouija effect". You want the exact opposite of ouija: Where a ouija board is moving unintelligently due to a user, without their conscious knowledge, you want a player's crosshair to move in an intelligent way without the user realizing that it's NOT purely their input. It really is a bit of a magic trick.
Use the dot product of the player's pitch/yaw turning delta vs. the pitch/yaw delta from the crosshair to each target. Clamp the value between 0 and max speed (so you ignore the input while pushing away from the target), then use a function of distance as a falloff modifier.
I found that increasing this "macro movement" bonus when the crosshair vs. target angular delta is large (i.e. when an enemy is behind you) really helps with the classic console controller problem of not being able to turn-to-face quick enough. In terms of "targetting choices", if you're being attacked from behind, and there's no targets infront of you, that panorama ahead of you is "dead space", and you might as well give the player the ability to fly across it at great speed with their cursor. And if there ARE targets ahead, well, they're probably higher in the player's mind and due to dampening/sticky aim, aren't unduely affected by the weak macro force.
There's not much need for you to dampen sensitivity when the player tries to turn away from an object (this will result in a feeling of trying to "escape" a target's orbit). Dampening is used more for precision aiming, and also to stop players' aim overshooting when moving from macro to micro precision - It's the darnest thing: players (especially novices) have a tendancy to only use the extremes of a stick's deflection, so you have to do a lot of finessing for them.
Sticky aim is a relative movement compensator. Watch the difference between the angle to your target (from the camera, not from the entity origin), this frame, and last frame. See how closely you are aiming to the target. To avoid the ouija effect when there is no user input, check both sticks' deflection: See if you have physically moved (left stick actuation) OR if there is active aiming "with" the direction of the target. Add the yaw/pitch delta step * aim closeness * Max( move.length , aim.length ) for rudimentary sticky aim.
Where the issue of target confusion comes in (i.e. a target strafes across your view while you were aiming at something behind, "stealing" your focus), simply keep track of your targets, and "heat" a single one while it is being actively aimed at. Then, multiply the dampening and sticky components by this heat parameter so that unheated targets get ignored. If the player WANTS the help on that other target, they'll manually aim toward it, and very quickly, that becomes the most prominently heated target while the previous one is forgotten.
We also create "phantom" aim assitance targets to help you turn away from uninteresting things (i.e. facing a wall - no need to hang around looking at a close up blank surface if it's not usefully interactive), but it's probably more than I can talk about - you can apply this stuff to anything that's interesting for the player to point at, be it explosive barrels, interactive objects (bioshock uses dampening when aiming over interactable objects at close range... but doesn't do sticky aim on them, I don't think). Once you realize that this is all just to compliment the core concept of aiming, you realize it's not just about aiming shots, but a general useability improvement which feeds into any mechanics reliant on aiming. And in an FPS, really, movement and aiming are the fundamental core concepts you need to nail before developing onward.
The improtant thing with all this is tuning. Takes a long time to just get right, and to deal with target interference, and issues with targets being so close range that their "targetting zones" swamp the player's panorama, slowing 60 degrees of rotation down to a crawl.
Oh man, I should get to bed. Sorry if some of the maths is not to clear. It's really late, but I was excited reading this post.
For input to feel good on consoles you will want to have some processing done to it.
First we converted the linear input that comes from the analogue sticks into a curve that gives us more sensitivity around the stick center and less sensitivity at the borders. This can be done with small tools that help you create and visualize these curves and spit out code. (http://www.arachnoid.com/polysolve/)
As a second step we implemented some kind of accelleration. It kicks in after a short amount of time when the stick input is at least 97%, and ramps up the camera rotation over time. We handled the X and Y axis independently. That allows you to somehow artificially enhance the stick input range. The first 97% can be used for relatively fine adjustments, but due to acceleration you can have fast movements too.
If you have different camera FOVs (e.g. when aiming/ zooming) then there needs to be a factor that adjusts the cam rotation speed by the FOV currently in use.
Some other nifty tricks that make the players life easier is "auto centering". This levels the camera pitch slowly back to the horizon when no input is given. It helps to keep oriented.
Another thing to take care of on consoles is the dead zone. When a controller gets older the analogue sticks start to loose precision and tend to give "false" input. To prevent this you have to disregard the first few pct (up to 20%) of stick input.
We also had done some experiments with friction based aiming help as mentioned before (accel input when moving towards enemy on screen, slow down input when moving away) but we had the feeling that this is very noticable to the player. Also the downside is that you dont have smooth cam movement anymore when there is a row of enemies. We opted for a "magnetic bullet" effect, where the bullets itself tend to gravitate towards the enemy within a certain range. However you have to be careful here too.
For console games, you will have to work with an analog stick. While analog sticks feels intuitive for 3D games, it's horrible during intense moments where you need to actually aim. The best solution is to make the stick become accurate during these moments.
Here's a simple solution: As the crosshair moves closer to an enemy, the sensitivity goes down. This would allow the player be more accurate with his shots.
You can also implement a "sticky aim". This becomes very satisfying if there are multiple enemies and the player needs to kill the one immediately in front of them.
I personally like the "lock on" paradigm for console shooters. I.e. hold a button to lock onto an enemy roughly in front of you (press multiple times to cycle through multiple enemies) and then your aim just automatically follows them. The first FPS to use it that I can think of (I'm sure there were others before it) was Metroid Prime on GC. Makes the sluggish inaccuracy of the analogue stick not matter. ...not sure how it would translate to multi-player though.
While we're on Metroid Prime, I also liked the technique they used for platformy bits where the view would automatically angle down slightly when you jumped. It was subtle, but it made the controls feel much more natural.
