Probably because most people dont use a controller to control their PC, so it doesnt make sense to optimize the interface for a controller - you want to optimize it to be fun with a keyboard and mouse, and if youve done that already, is there much value in adding polished controller support anyways?

Adding some basic support might be easy enough (its better than nothing), but 'deeper' compatibility with the control scheme probably isnt the highest priority feature. Its more of an extra.

If the feature is not polished or even broken, its very easy for people to just switch back to keyboard and mouse (which the game likely was designed to work best with anyways), so maybe there are not enough complaints to create pressure for devs to work on it.

Doesnt apply for the cases where the game was designed to be played on a console or with a controller, in that case one would of course expect proper support.

I've found a mixed bag in this situation, where some games don't let you even use gamepads all the way to games doing it automatically, and that includes the menus and in-game text. I've made it a point that any engine I use, if not already done, will have nice custom inputs for the game players. I like the idea of the player simply hitting what button they want for the controls. I also like the "modifier/shift" kind of setup, even for gamepads, where you choose a button, and pressing it makes all the other buttons different, a lot like the shift key. This allows a more complex game without having to have 20 different buttons in order to control things.

There's a lot of reasons, some of them which I bump into whenever I try to implement it myself.

First, historically GamePad support was pretty bad. Ignoring DOS games, back in Windows 9x the default setup wouldn't let you support more than 4 buttons.

You had to install special drivers to support 6 button pads or higher. I never understood why, though at some point I began suspecting that it could have been a limitation of the Game Port and the drivers would workaround the limitation via special encoding (hacks) or using signals that were reserved for other uses (extra axes, etc)

Because of this, interfaces coming from the OS and DirectInput were rather very basic (let's not even joke about rumble support, or stuff like that)

This problem more or less went away when USB gamepads arrived. However we are now left with HW problems: lots of non-standard input layouts. Even if all gamepads now look like either a PS3 or XBox controller; you still have the problem that one assigns button 0 to square, and the other assigns button 0 to circle. There's no standardization at all.

Therefore, you have to dedicate time to include an easy to use interface to map you controllers to actions. Also, the user now can't just hook in any controller and start playing.

Then there's the analog sticks. Even though the basics are the same and fortunately all vendors seem to agree in which axes map to the left stick and which axes map to the right stick; they do not agree in the scale/space they use.

In one controller you move your thumb halfway through it and the gamepad will report 50%, while another gamepad will report 80%, another 99%, and another will report 10% and if you move the thumb a millimeter more then suddenly reports 100%.

This problem can be alleviated via deadzones and a user defined exponent factor as an attempt to linearize the signal coming from the stick. But it has to be manually configured by the user and is not as easy to setup as the button mapping. And he may not be able to set it up "right" the way the designer meant it to be played.

Carefully designed stick-gesture experiences such as in Zelda Ocarina of Time in the original Nintendo 64 (walk, run, quick spin attack; all depending on how you moved the stick) are completely ruined unless everyone uses the same gamepad. How can you implement walk/run gestures when a gamepad goes from 10 to 100 in a heartbeat?

The Xbox360 controller simplified some things. Microsoft made an API specifically designed to only work with their xbox controller (XInput) and all their gamepads are standardized. Meaning you get the same experience in all of them and good support. Therefore some games chose to only support this interface and screw everything else.

Ironically, I find games running on XInput with x360ce (an XInput to DirectInput wrapper) much better than games that directly support all sort of gamepads, thanks to this standardization layer and the fact that I can configure/calibrate my gamepad to closely resemble a real Xbox360 controller after a long time of tweaking around the same tool that works on all XInput games.

Then there's gamepads joystick that don't resemble the PS3/Xbox controller at all. Their button layout doesn't map too well to in-game icons or layouts. Also reading "tap button 5" isn't too helpful either unless the manufacturer pasted a '5' sticker on the button #5 (which doesn't happen very often because they prefer to resemble a PS3 controller and use square, triangle circle, etc as if somehow that would fool me into thinking it's not a cheap imitation).

Sadly the USB drivers don't expect the controller to send a few bitmaps for each button #, that we could display and show a circle, a smiley or "L1" instead of saying "button 5".

Finally, a game designer aiming to support a PC has to make peace with the fact that there's a chance the user doesn't own a gamepad, and design their game for a mouse/keyboard, which has no analog interfaces, and different buttons combinations that are easier/harder to execute (try a 360° barrel roll with the left, down, right, up keys! Easy to do with a stick)