(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.

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.