Why do videogame developers not allow players to remap their controller?
December 22, 2010 1:14 PM Subscribe
Help me to understand a prevalent console-based video game UI design decision : Why do so few developers allow the player to freely remap buttons on their controller?
I'm speaking specifically of actions performed in-game and tied to specific buttons ("hit X to jump", for example), often referred to as the "control scheme".
Often developers will include a handful of different control schemes to choose from, wherein the same handful of functions is performed but the buttons used to perform these actions changes (from the previous example, a second control scheme might swap the jump button from X to Y). The primary reason for this seems to be to allow players with different playing styles a control scheme that will fit into their natural tendencies/expectations, to enable them to pick up the game and play it with a minimum of "learning" how to control the game.
On rare occassions, developers will allow a player to manually assign each possible action to whichever button the player would like it to be triggered by. I would like to know why this isn't more common, from a game designer's point of view. What are the primary reasons one decides not to include this functionality?
This ability is present in some games where the developer has offered a set of preconfigured control schemes as well, so that pick-up-and-play gamers can just choose one and go if they prefer. This seems like the best possible outcome.
(I recognize that development is a complicated process and that little features hit the cutting room floor, as it were, constantly throughout the process, but the impression I have is that this is a minor piece of functionality that wouldn't noticably impact the time spent in development. Is this correct?)
I'm speaking specifically of actions performed in-game and tied to specific buttons ("hit X to jump", for example), often referred to as the "control scheme".
Often developers will include a handful of different control schemes to choose from, wherein the same handful of functions is performed but the buttons used to perform these actions changes (from the previous example, a second control scheme might swap the jump button from X to Y). The primary reason for this seems to be to allow players with different playing styles a control scheme that will fit into their natural tendencies/expectations, to enable them to pick up the game and play it with a minimum of "learning" how to control the game.
On rare occassions, developers will allow a player to manually assign each possible action to whichever button the player would like it to be triggered by. I would like to know why this isn't more common, from a game designer's point of view. What are the primary reasons one decides not to include this functionality?
This ability is present in some games where the developer has offered a set of preconfigured control schemes as well, so that pick-up-and-play gamers can just choose one and go if they prefer. This seems like the best possible outcome.
(I recognize that development is a complicated process and that little features hit the cutting room floor, as it were, constantly throughout the process, but the impression I have is that this is a minor piece of functionality that wouldn't noticably impact the time spent in development. Is this correct?)
Two reasons (1) developing, testing and maintaining a feature costs time and money, and (2) as a general principle, if a feature in a user interface isn't crucial, you should remove it.
Often following (2) takes time itself. The designer has to solve a difficult problem or make a choice in the general case, but by doing so they avoid simply punting the problem/choice on to the user. But doing this is something that is taken seriously by a lot of designers, especially on consoles and Mac.
posted by caek at 1:24 PM on December 22, 2010
Often following (2) takes time itself. The designer has to solve a difficult problem or make a choice in the general case, but by doing so they avoid simply punting the problem/choice on to the user. But doing this is something that is taken seriously by a lot of designers, especially on consoles and Mac.
posted by caek at 1:24 PM on December 22, 2010
I realize you're talking about consoles, but just so you know, it's common on PC games to allow this.
The reasons are development and testing costs, as mentioned above. Some other reasons:
* If the game is out on a console as well as PC, it's likely that a console version was the "lead SKU," meaning that all initial decisions were made with one specific console in mind. The PC port may have had a skeleton team working on it.
* The data must be stored somewhere, which opens up its own development and QA cans of works.
* On-screen prompts must change to reflect the re-mapped button. If you switch "jump" to the Y button, for example, the tutorial will have to know that and display the correct control, otherwise the tutorial will be telling you to do the wrong action.
* Perceived complexity. Some may think it better to just offer an alternate control scheme instead of a true re-mapping ability.
* Console controllers are actually pretty sweet designs themselves. They're specifically designed for humans with eight fingers and two thumbs to hold for a long period of time. So, most often the default control schemes a designer can offer maps to very common, middle-of-the-road movements for most people. For example, most people are right-handed, so they're therefore "right-fingered" and "right-thumbed." That means it's pretty natural for people to want to "pull a trigger" with their right index finger and press down on something precisely with their right thumb. Why bother to offer anything else for what is such a natural movement for people?
Finally ...
* Most players will never, ever bother with this, even if it were offered. Seriously, if we're talking about a mainstream game that sells millions of units, you're like a fraction of a fraction of the audience to even want this and even know that it can be done.
posted by Cool Papa Bell at 1:45 PM on December 22, 2010
The reasons are development and testing costs, as mentioned above. Some other reasons:
* If the game is out on a console as well as PC, it's likely that a console version was the "lead SKU," meaning that all initial decisions were made with one specific console in mind. The PC port may have had a skeleton team working on it.
* The data must be stored somewhere, which opens up its own development and QA cans of works.
* On-screen prompts must change to reflect the re-mapped button. If you switch "jump" to the Y button, for example, the tutorial will have to know that and display the correct control, otherwise the tutorial will be telling you to do the wrong action.
* Perceived complexity. Some may think it better to just offer an alternate control scheme instead of a true re-mapping ability.
* Console controllers are actually pretty sweet designs themselves. They're specifically designed for humans with eight fingers and two thumbs to hold for a long period of time. So, most often the default control schemes a designer can offer maps to very common, middle-of-the-road movements for most people. For example, most people are right-handed, so they're therefore "right-fingered" and "right-thumbed." That means it's pretty natural for people to want to "pull a trigger" with their right index finger and press down on something precisely with their right thumb. Why bother to offer anything else for what is such a natural movement for people?
Finally ...
* Most players will never, ever bother with this, even if it were offered. Seriously, if we're talking about a mainstream game that sells millions of units, you're like a fraction of a fraction of the audience to even want this and even know that it can be done.
posted by Cool Papa Bell at 1:45 PM on December 22, 2010
There's a more general principle at work here with all software. When you think of something simple, like "why can't I just assign the controls arbitrarily?" its true that that in and of itself is probably a pretty short job for a dev to implement. There's probably some branch in the codebase somewhere where they can do this easily, by editing a resource file of some kind, for testing, but the reason these features don't make it into production, is even the simplest, simplest feature, beyond being coded needs to be:
- 'designed'. Every feature is 10x more complex than it sounds. What if the user assigns multiple actions to one button? What if one action is never assigned? What if the settings are invalid when the user tries to save them, how do you communicate exactly which are the problem and which ones do you change? What do you revert to what? What if the user loads a saved game with one set of button mappings, and the user's current button mappings are different? Which one should win? What if he saves _from there_, which settings should be saved? What if the player starts changing the key mappings, and the system crashes or the power goes out? Even the simplest software feature will have a zillion edge cases that complicate things, and each one needs to be designed around or coded for. On big software projects, there are people who _just do this_ all day. They take a simple, human description of a feature and then work out alllll the crazy edge cases, and they don't write a lick of code. They just pass detailed specs off to devs. And they still miss tons of stuff the devs end up kicking back up or having to figure out for themselves. This goes on forever.
- Documented. Somewhere in the help or the manual someone needs to produce screenshots and text that explains exactly how this all works, plus it needs to be documented for the team internally. Further, the design of this feature, including the UI, needs to be done early enough for the doc team to get it into the docs. AND that means you need to commit to it, early in the schedule.
- Tested. Every time you add an option, you open yourself up to unforeseen interactions with that option. A huge amount of the effort developers make is limiting the possibility for these unforeseen interactions, but its very, very difficult to do, so we rely on various testing strategies to make sure there are no problems. But you'd have to burn even more test hours just to try various combinations of these buttons, and then various pathological combinations of the buttons to make sure there are no crash-cases, and then all the edge cases outlined in the design (for example reloading from saved games).
- Designed in the UI sense. Which includes localizing it for all the different versions of the game. You have to make all the screen assets for assigning the controls, and translate them into all the game's target languages.
- Compatibility, backwards and forwards. In games, this is sometimes less of an issue, but if your game lets you use savefiles or assets from old games, or a new game is going to allow you to use them from this game, you need to design, document, and test a procedure to make this new feature compatible forwards and backwards, or to at least not break anything.
So a software feature that might require like an hour or two of actual coding to implement, can easily swell to several man-days of time across multiple teams. Game schedules are already psychotic. So when you have a feature like this, which has exactly zero potential to help you sell more copies of the game (no one is ever going to be at GameStop and say, "Aww man, the new Call of Duty doesn't allow arbitrary button mapping! Screw this! I'll buy a different game!") is the first kind of feature to get cut, because even these little tiny simple features are way more work than they sound like.
In general, building the underlying feature in software takes about 5% of the time. 95% of the work in software development is handling edge cases, testing, all that kind of stuff.
posted by jeb at 2:29 PM on December 22, 2010 [2 favorites]
- 'designed'. Every feature is 10x more complex than it sounds. What if the user assigns multiple actions to one button? What if one action is never assigned? What if the settings are invalid when the user tries to save them, how do you communicate exactly which are the problem and which ones do you change? What do you revert to what? What if the user loads a saved game with one set of button mappings, and the user's current button mappings are different? Which one should win? What if he saves _from there_, which settings should be saved? What if the player starts changing the key mappings, and the system crashes or the power goes out? Even the simplest software feature will have a zillion edge cases that complicate things, and each one needs to be designed around or coded for. On big software projects, there are people who _just do this_ all day. They take a simple, human description of a feature and then work out alllll the crazy edge cases, and they don't write a lick of code. They just pass detailed specs off to devs. And they still miss tons of stuff the devs end up kicking back up or having to figure out for themselves. This goes on forever.
- Documented. Somewhere in the help or the manual someone needs to produce screenshots and text that explains exactly how this all works, plus it needs to be documented for the team internally. Further, the design of this feature, including the UI, needs to be done early enough for the doc team to get it into the docs. AND that means you need to commit to it, early in the schedule.
- Tested. Every time you add an option, you open yourself up to unforeseen interactions with that option. A huge amount of the effort developers make is limiting the possibility for these unforeseen interactions, but its very, very difficult to do, so we rely on various testing strategies to make sure there are no problems. But you'd have to burn even more test hours just to try various combinations of these buttons, and then various pathological combinations of the buttons to make sure there are no crash-cases, and then all the edge cases outlined in the design (for example reloading from saved games).
- Designed in the UI sense. Which includes localizing it for all the different versions of the game. You have to make all the screen assets for assigning the controls, and translate them into all the game's target languages.
- Compatibility, backwards and forwards. In games, this is sometimes less of an issue, but if your game lets you use savefiles or assets from old games, or a new game is going to allow you to use them from this game, you need to design, document, and test a procedure to make this new feature compatible forwards and backwards, or to at least not break anything.
So a software feature that might require like an hour or two of actual coding to implement, can easily swell to several man-days of time across multiple teams. Game schedules are already psychotic. So when you have a feature like this, which has exactly zero potential to help you sell more copies of the game (no one is ever going to be at GameStop and say, "Aww man, the new Call of Duty doesn't allow arbitrary button mapping! Screw this! I'll buy a different game!") is the first kind of feature to get cut, because even these little tiny simple features are way more work than they sound like.
In general, building the underlying feature in software takes about 5% of the time. 95% of the work in software development is handling edge cases, testing, all that kind of stuff.
posted by jeb at 2:29 PM on December 22, 2010 [2 favorites]
...but the impression I have is that this is a minor piece of functionality that wouldn't noticably impact the time spent in development. Is this correct?
No, this can have a major impact on the development process, depending on how the software was developed. It could be relatively easy if designed in from the beginning, but if added at any point once code is written, it can quickly become a nightmare.
posted by blue_beetle at 2:41 PM on December 22, 2010
No, this can have a major impact on the development process, depending on how the software was developed. It could be relatively easy if designed in from the beginning, but if added at any point once code is written, it can quickly become a nightmare.
posted by blue_beetle at 2:41 PM on December 22, 2010
One way to save money and time on any software development project is to reuse code that already works and has already been thoroughly tested. So if the company is putting out more than one game for a platform, they may be reusing a big chunk of the game engine. If there's time and money available, it's better business to something cool to the gameplay than it is to go back and redo something that's already been done.
posted by SuperSquirrel at 6:20 PM on December 22, 2010
posted by SuperSquirrel at 6:20 PM on December 22, 2010
*...it's better business to ADD something cool to the gameplay...
posted by SuperSquirrel at 6:21 PM on December 22, 2010
posted by SuperSquirrel at 6:21 PM on December 22, 2010
Best answer: Raymond Chen, one of the longest serving members on the team that builds MS Windows, has something to say about thinking through a feature. It isn't about key remapping specifically but everything he writes hold true for your wish.
posted by mmascolino at 7:08 PM on December 22, 2010 [1 favorite]
posted by mmascolino at 7:08 PM on December 22, 2010 [1 favorite]
This irritates me as well, and I've played a number of games that would have been a lot better with configurable controls. A few have been almost ruined by poor button layout decisions (the worst example I can think of is the old Xbox game Phantom Crash, which was not possible to play with a normal pair of human hands). As well as the reasons given above, I'd add a couple of others:
1. A lot of games are just not very good. If you're designing, say, Dynasty Warriors: Gundam, you're already making so many sub-optimal decisions that the chances of getting something right, e.g. by allowing button reconfiguration, are very small (actually I can't remember whether DW:G had configurable controls. Maybe it did. It wouldn't have helped, anyway).
2. How many reviews of console games have you read where the reviewer mentioned the configurability of the control scheme? If it doesn't have a direct, measurable effect on metacritic scores it's going to be pretty low on the priority list.
posted by A Thousand Baited Hooks at 2:26 AM on December 23, 2010 [1 favorite]
1. A lot of games are just not very good. If you're designing, say, Dynasty Warriors: Gundam, you're already making so many sub-optimal decisions that the chances of getting something right, e.g. by allowing button reconfiguration, are very small (actually I can't remember whether DW:G had configurable controls. Maybe it did. It wouldn't have helped, anyway).
2. How many reviews of console games have you read where the reviewer mentioned the configurability of the control scheme? If it doesn't have a direct, measurable effect on metacritic scores it's going to be pretty low on the priority list.
posted by A Thousand Baited Hooks at 2:26 AM on December 23, 2010 [1 favorite]
The games that DO tend to offer this feature, or at least multiple preset configs that you can choose from, are often action heavy games. FPS games. Fighters. Games where frame by frame timing matters and tweaking your controls scheme to perfection is a requirement (or in the case of fighters, you are decently likely to be using a non-standard controller).
For a laid back RPG with a bit of "action" that doesn't really require much dexterity or finesse to play, it's really not a high priority at all.
posted by utsutsu at 7:22 AM on December 23, 2010
For a laid back RPG with a bit of "action" that doesn't really require much dexterity or finesse to play, it's really not a high priority at all.
posted by utsutsu at 7:22 AM on December 23, 2010
On top of what everyone is saying here.....most gamers at this point have a few years of experience playing these games (and at least in my case) have been brought up with a certain amount of configurations. Because only a small part of the people that are playing these games are not used to this set-up it does not make sense from a designing standpoint to accommodate for them.
Case in point. I recently bought NBA 2K11 after a 5 year hiatus of playing the game. The controls at this point have gotten extremely complicated and it has become extremely difficult for me to get used to anything outside of the basics. As a result I think I m not buying any more NBA 2K games because I dont want to deal with the difficulty of it.
posted by The1andonly at 7:57 AM on December 23, 2010
Case in point. I recently bought NBA 2K11 after a 5 year hiatus of playing the game. The controls at this point have gotten extremely complicated and it has become extremely difficult for me to get used to anything outside of the basics. As a result I think I m not buying any more NBA 2K games because I dont want to deal with the difficulty of it.
posted by The1andonly at 7:57 AM on December 23, 2010
Best answer: I hear where you're coming from; it's odd but one of the first things I do when playing any game, PC or console, is to hop into the option menu and figure out what I can play with. This, as I've come to realise, especially with experience as a professional software engineer, is spectacularly rare. In fact, this is so rare in many different fields, not just software, that the concept has a name - status quo bias (I prefer "sticky defaults"), for example soft paternalism when it comes to government policy.
All of this to say - choice, in and of itself, is expensive, and imposes a high cognitive cost on people. I'm not talking about the software engineering complexities of it, but just from a consumer's perspective. Ever wonder why HP printers only have one button, or Apple iPods have such sparse UIs? Simply offering choice can turn off people from your product! I cannot, for the life of me, empathise with this, but study after study confirms this.
Haha, as a hilarious side note, there's one game for which an alternate keyboard mapping would be hideous to design and test - Jane's Apache Longbow 2. Every single key on the keyboard, plus every ALT, CTRL, and SHIFT combination thereof, is used for some function. Stuff like CTRL-E-E-E for eject and CTRL-SHIFT-F for fire extinguishers on engines. Oh, they don't make games like they used to.
posted by asymptotic at 3:38 PM on December 25, 2010 [2 favorites]
All of this to say - choice, in and of itself, is expensive, and imposes a high cognitive cost on people. I'm not talking about the software engineering complexities of it, but just from a consumer's perspective. Ever wonder why HP printers only have one button, or Apple iPods have such sparse UIs? Simply offering choice can turn off people from your product! I cannot, for the life of me, empathise with this, but study after study confirms this.
Haha, as a hilarious side note, there's one game for which an alternate keyboard mapping would be hideous to design and test - Jane's Apache Longbow 2. Every single key on the keyboard, plus every ALT, CTRL, and SHIFT combination thereof, is used for some function. Stuff like CTRL-E-E-E for eject and CTRL-SHIFT-F for fire extinguishers on engines. Oh, they don't make games like they used to.
posted by asymptotic at 3:38 PM on December 25, 2010 [2 favorites]
This thread is closed to new comments.
FTA: "Chuck received a response from a developer letting him know that it wasn't the coding that map remapping difficult, but the amount of testing required that keeps it out of many big-budget titles."
More from Mr. Bittner. http://www.askacapper.com/petition
posted by anti social order at 1:23 PM on December 22, 2010 [1 favorite]