We chat about videogames and videogame accessories.

I can think of a few reasons (if we discount the observation that sometimes, people are just asinine) that such apparently commonsensical decisions are decided in non-commonsensical ways (in other words, I am redirecting my answer towards why things go wrong as opposed to why specifically you often can’t change your name or stuff like that in a game).

One is efficiency. Even if they have considered that people >90% of people won’t want to change these things, yet putting that in will take not-insignificant development time to design around the new requirements. Since video games from big companies are usually developed with this business attitude, it gets Pareto’d out due to budget constraints. It’s more attractive to work on things you can advertise “on the box” than it is to work on something that is a hidden sign of quality.

Another is the problem that changing requirements after things have already been made can take more effort than making the already-made thing did in the first place. This is a frequent problem in translating games from Japanese, if the game is already done and the problem is making a translation from it. For instance, names in Japan are unlikely to need more than a small number of characters, and sometimes the people who localize the games don’t have a lot of wiggle room to play with that despite understanding the problem—it is often assumed that text is a drop-in thing (but that’s usually not true unless we’re talking about a book here, because screen size matters), or they just don’t have an artist on hand to (for example) resize things properly. In the bad old days, the people tasked with translation often had to actually reverse engineer the game to get their job done!

Sometimes, the system has limitations or game developers aren’t creative enough to work around their own limitations (which is why you see this problem in some games of yesteryear).

Sometimes, though, people simply plan out software requirements incorrectly, and this is one of the most frequent traps because of that “unknown unknowns” problem. When you make software, you typically have a very good general idea of what you want, but a very poor idea of what needs to be there specifically. This ties in with the localization process again—you might have known about these issues if your localization team saw your design before the software and art assets were actually made (in fact, a few years ago, Square Enix revealed that they had integrated their localization people with with the rest of the developers, which is really cool... but sounds kind of expensive, too).

Finally, in developing software, particularly for “closed” systems (by that I mean ones that don’t run on the paradigm that anyone who uses the system can change anything anytime any way they want), it is easy to fall into the “set it and forget it” mentality. A programmer knows how to set a setting; that’s what the job mostly is. A programmer knows how to let someone set a setting when the programmer wants it to happen; that’s also an obvious part of the job. A programmer does not always know to let someone set a setting when they want it to happen, and it takes a great deal of foresight to plan that out even if you actually do want to work on that sort of issue.