What happened to custom controls?

fearsomepirate

Dinosaur Hunter
Veteran
I just got a 3rd party controller for my PS3 that's basically a 360 controller. Here's the thing...the vast majority of games have maybe 2 or 3 alt controller setups, none of which swap the fire buttons to the trigger. What gives? I remember that I could remap every single button in Timesplitters and Killzone 1, and I'm pretty sure there were a few other games that let me fully customize my controls, too. This gen, it's like everyone in the development community collectively forgot how not to hard-code your button mappings into your executable. Like I'd really be able to not map "sprint" and "hold your breath" to the same button in COD, but no, they've decided that's not to be allowed. I'd like to be able to configure all FPSes to play approximately the same way, but nope, not allowed. Why? Is this a platform manufacturer policy? Is there some obscure software patent that got dredged up at the start of this gen? Or do developers feel that their chosen layouts are so great they can't allow me to ruin the experience by putting the "throw grenade" button somewhere that makes sense to me?
 
Wondered that myself. The control setup I was best with for console FPS disappeared in presets years ago, and it seems presets have been reduced over time as well. Much less specific mapping.
 
I suspect that it's something that isn't in any policy of the platform manufacturer and not all of the devs see the importance of having such a feature... A shame - I agree and maybe it's also down to lazyness - lazyness to not think about such features.

The same could be said about other missing features - like an auto function or single-button to *mute-all-not-in-my-party* feature in the call of duty (or other FPS). WTF do I need to always mute other players, even sometimes during a game when new player arrive? It's so inexusably annoying and I just can't figure why the hell since at least 4 games of the same series, this hasn't been thought of.

The answer? Lazyness or they simply don't care enough to think about such annoyances.
 
It's especially weird in Killzone, since KZ1 had fully custom controls, KZ2 had a handful of presets, and KZ3 had even fewer presets. Maybe the guys who write the interface code all left between one iteration and the next, or maybe there's a supervillain putting a mind-altering drug in the water supply where they live.

Removing features each game seems to be a GG thing. I half expect KZ4 to not even let me choose which class I want to play.
 
This has been a trend that's been going on for a while. I'd speculate it has more to do with the scale of today's title's and the rather "directed" aspect of even "open ended" games that studios or at least the critical decision makers just don't want to bother with a lot of configurability that may require more extensive QA effort.

Along similar lines, a gripe of mine was that most big team sports titles back on the PSOne days typically had support for 8-players even though it required multi-taps that few people had. By the PS2 era, it dropped to 4. Now more and more are just going 2-player…


Granted I think online play has a lot to do with this as well...
 
I think it has more to do with the fact that any complex options test incredibly badly with focus groups.
That coupled with the fact that I've never met a designer who wants any more complexity than he absolutely has to have for UX.
 
Perhaps it should be an OS level function, with an OS API for control mapping? That'd provide a uniform interface where a player could set R1 to 'X' in a given game, arbitrarily. System protocols could expose control names per title so users could see what they are changing to what, and the game would just receive the same control inputs. I suppose that wouldn't work with context sensitive controls or per action controls (eg. short-pass and tackle on X button, user wanting to map pass to A and tackle to B).
 
Sounds like a problem with focus group testing, then. Forcing a focus group to mess around with a custom control menu is different than having a custom control option in addition to the presets, which most of the people who are scared of being able to remap buttons would probably just ignore entirely.
 
I think that developers now actually can measure how many people change the controls (using PSN etc). If only 1 % change the controls, it is not worth spending the resources implementing that feature.
 
Even if it is complex for a focus group, there is no reason there cannot be an advanced button to hit and go into while the vast majority of players only ever see the presets. These options have been around so long I cannot see that programming them would be a big testing problem either.
 
Even if it is complex for a focus group, there is no reason there cannot be an advanced button to hit and go into while the vast majority of players only ever see the presets. These options have been around so long I cannot see that programming them would be a big testing problem either.

I assume you do not work with software development?
 
I've got to imagine that programming a UI that allows you to remap controls is easier than programming a deferred renderer.
 
I assume you do not work with software development?
By that I guess you mean the testing requirement? Surely remapping input to internal control identifiers doesn't pose any test problems beyond the correct mapping? My expectation would be an IO module that updates internal variables with controller responses, and then the rest of the game code would just check these internal variables instead of the system controls. It certainly shouldn't be difficult on paper, but I've no idea on the internal workings of these consoles. Still, my suggestion of shifting this to the OS still seems far and away the best option. That'd also support new interfaces more comfortably, allowing users to map new controllers to existing inputs and allowing more generalised (if sometimes ropey) alternative controls.
 
Everybody sees the deferred renderer. Only 1 % (or something) uses the UI remapping.
But it should be so easy to add. Although personally I hate writing UI stuff as it's such a lot of effort for what you get and one's constantly reinventing the wheel, but it's an easy addition that adds value. It's one of those few jobs that should be partitionable into reusable code across projects. And seeing games used to have it, not carrying control remapping across to later games is an odd choice.
 
Everybody sees the deferred renderer. Only 1 % (or something) uses the UI remapping.
The problem with thinking this way is the market is made up of lots of little groups. Shave off any feature not used by a large majority of gamers, and you're left with not much of a game. So you annoy 2% here, 3% there, another 1% over there...and soon you've annoyed 35% of your potential customers. Imagine if COD took out all the modes and features not used by at least 20% of the customers. You'd basically get Medal of Honor 2010.

I would understand if interface remapping were something disproportionately costly to write and debug. But it's not--it's been around since at least the early 90s, and software studios comprised of only a few people were able to do it.
 
A few good people ... now they have a menagerie of idiots which prove time and time again they are unable to use a single shim API for controls even when it's present (like it usually is in PC games).
 
A few good people ... now they have a menagerie of idiots which prove time and time again they are unable to use a single shim API for controls even when it's present (like it usually is in PC games).

Yes, of course, everyone who does not agree with you are idiots.
 
Back
Top