(background: I'm a Gameplay Programmer i.e. I work with things like interface, controls and camera as opposed to engine code like loading, rendering, etc.)
Yep, I can confirm that the code for controls is hard to get right, and often features a lot of hacks and special cases - making controls that are easiest to learn for the player doesn't result in simple code. Check this out for someone overanalyzing "simple" jump controls.
Some common reasons for making your controls non-simple
The game lags, so by the time the game gets the player's input, some time may have passed, and a good game may want to "pretend" the player did his action in a past state (this is tricky to get right, and totally transparent to the player).
The graphics don't match the simplest representation in the game engine - code for boxes colliding is much simpler than code that looks at pixels or casts ray etc. but the latter may be what the player expects.
Player's intuitive representation of physics doesn't really match Newtonian physics - if your character is on a moving train and you're shooting cannonballs at fixed targets, you don't expect the train's momentum to apply to the cannonball (though it's not clear whether this is because of natural human instincts, or because a cannon-shooting game that took proper account of Newton and Galileo would just be less fun, so players are willing to suspend disbelief). "Naively" applying the laws of physics in a game engine is a common pitfall.
One bit that's particularly hard to get right in 3D third person games is the camera: if you give the player full control of it it may often end up pointing in an awkward direction and he'll fall in a hole because he was looking at the sky; so you want it to reposition itself magically when the player is near a wall, or being attacked, or there's a special plot-relevant thing going on; you may want the camera distance and angle to depend on what the player is doing (sometimes he needs to see his own character well, sometimes he needs to see the environment or where he's going); you have different needs for say shooting and melee combat, which is a hassle for games that mix both.
By the way, Mario 3 doesn't really change the "jumping" rules, but rather the "walking off the edge of a platform" rules. In levels without slopes, you can inch your way over the edge of a platform and Mario won't fall as long as even the slightest bit of his foot is on the edge. In levels with slopes, however, Mario will be allowed to fall as soon as his midpoint passes the edge of the platform. Without this change, he'd "hover" over the edge of every slope you'd try to have him walk down.
Good player handling code doesn't just translate the player's inputs into action, it tries to discern the player's intent.
Headshot the entire enemy team with my sniper rifle without using the scope. How could it not be able to discern that? I mean, I had the gun and pointed it in their direction and pressed the trigger. Clearly I'm not trying to lose.
Good player handling code deduces intent to the extent and in a manner that will ensure the players experience only the addictive kinds of frustration.
The player means to try to win the game, and means to walk a bit to the left. A player who means to win the game stares at a "You win" screen. A player who means to try to walk a bit to the left is me struggling with the tutorial levels of a platformer.
Good player handling code doesn't just translate the player's inputs into action, it tries to discern the player's intent.
Well put. This is what separates the good user interfaces from the bad.
For example, you're building a mouse-based or touch-based interface for editing a Bezier spline for a a program like Flash, Illustrator or Corel Draw. A bad interface would have the user precisely hit the control points with the mouse or finger. A good interface would expand the hit testing zone of each control point to a circle several pixels wide. A great interface will detect situations when the user hits multiple hitzones, and select the nearest control point (so the hitzone pattern for a set of points close to each other becomes a Voronoi diagram).
Another example of this is the angle of escape in pulldown menus:
http://thomaspark.me/2011/10/making-menus-escapable/
This makes a lot of sense; not many people make games that accurately model reality (with a few notable exceptions) because, quite frankly, video games are supposed to be escapist. Most gamers spend quite enough time dealing with reality without dealing with it during relaxation/fantasy time too, especially if it makes the game a lot harder to play.
Besides, having your game accurately model reality tends to make you look uncreative (and usually like a bad game designer, as mentioned above), which cuts into sales. Games are a business, after all!
"Friendly AI doesn't just translate humanities inputs into action, it tries to discern humanities intent. Once the intended action has been identified, if the rules of the game allow it, friendly AI makes the action happen–even if it means breaking the rules of the simulation a little."
A possible solution to the fermi paradox, friendly AIs in general holodeck their originating species.
Chris Pruett writes on the Robot Invader blog:
Good player handling code is often smoke and mirrors; the player presses buttons and sees a reasonable result, but in between those two operations a whole lot of code is working to ensure that the result is the best of many potential results. For example, my friend Greggman discovered that Mario 3's jumping rules change depending on whether or not a level has slopes in it. Halo's targeting reticle famously slows as it passes over an enemy to make it easier to target with an analog stick without using an auto-aim system. When Spider-Man swings, he certainly does not orient about the spot where his web connects to a building (at least, he didn't in the swinging system I wrote).
Good player handling code doesn't just translate the player's inputs into action, it tries to discern the player's intent. Once the intended action has been identified, if the rules of the game allow it, good player handling code makes the action happen–even if it means breaking the rules of the simulation a little. The goal of good handling code isn't to maintain a "correct" simulation, it's to provide a fun game. It sucks to miss a jump by three centimeters. It sucks to take the full force of a hit from a blow that visually missed. It sucks to swing into a brick wall at 80 miles per hour instead of continuing down the street. To the extent that the code can understand the player's intent, it should act on that intent rather than on the raw input. Do what I mean, not what I say.
I suppose this explains why I am better at arcade bowling games than I am at actual bowling. More seriously, while I had some vague awareness of this, I am slightly surprised at the breadth (Mario 3!?) and depth to which this "control re-interpretation" takes place.