As with the vast majority of game design questions, the answer is "It depends". Imagine a game like Legend of Zelda: Link's Awakening. There are a significant number of items in the game and each one does something completely different. Each item has a specific ability, animations, effects, etc. associated with it, each would take a significantly longer amount of time to develop than a chestplate in World of Warcraft that gives +150 stamina and Strength.

The general rule is that the more that an item/ability/feature/etc. does, the longer it takes to build that item/ability/feature/etc. In a game where we expect players to go through lots of items, then we need to make lots of items for them to play with. Since we have a finite total amount of development time to spend, we need to spend relatively small amounts of time the average item we create. Not all items are created equal, either - we can churn out a bunch of the vendor trash items that players will use until something better comes along very quickly, and we reserve more of our dev time for the subset of "interesting" items like the ones that have special procs or abilities or whatever.

Design has some input on art for items but not a lot. The amount of time it takes to build art and VFX is significant, so item designers and artists are often given the same broad strokes for a batch of items (e.g. "This is a water dungeon, so think general water themes for your cool items") and we each do our work in parallel. Most of the time it works out, but sometimes we end up with some wires crossed at the end.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

They're not wrong in that building such things isn't free. However, you're also right in that we on the dev side should be thinking about better ways of doing this - there isn't only one solution to these problems. Whatever final solution we implement doesn't have to be the most expensive means of doing so. It's actually up to us to think of better/more efficient ways of doing the things we want to do. Adding accessibility options is often a worthy goal, not only to the players who need those options to be able to play, but also for general quality-of-life. If we're making changes after the fact, of course they're super expensive. If accessibility options are a production goal that we plan for, they're much cheaper because we don't have to redo work - we do it with accessibility in mind in the first place.

For example - let's say that we're working on UI and we have this system:

Let's say that we want to improve things for colorblind players. If we wanted to make this more accessible, instead of just using color to differentiate the choices, we could also add different border visuals to provide additional context.

In such a situation, the difference in choices is still obvious if you're colorblind and it helps legibility for non-colorblind players as well.

These kinds of UX changes can be expensive if we decide to do it after the fact, but if it's something we decide is important to us from the jump we can compensate for those costs by creating efficient and smart solutions early. Remember, the cost of any change in game development is directly proportional to how close that change is to shipping the game. The earlier the change is made, the cheaper it is. Furthermore, we make resource allocation choices based on our goals. If we want to make a game more accessible, we will figure out a way to do so that fits within our budget and provides a good player experience. Players don't really have a say in how we allocate our resources and that kind of armchair producer talk isn't particularly constructive anyway. Telling us what's important to you and why (including accessibility requests) is really the best kind of feedback we can hope for. Don't sweat coming up with the solutions or fretting about where we spend resources, that's our job.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

Most game dev teams have a strong idea of who our game's target audience is, and that includes the kind of context they should already have. If we're building a big budget AAA first person shooter, we can expect that our representative player recognizes and likes first person shooters and is likely already familiar with the basics of how to play them. It is unlikely we will need to teach them the very basics like how to move about the map and aim or what strafing is. If we're building a casual mobile game where we expect our representative player is new to games and lacks the context needed to play, we'll need to spend more effort to teach them that context.

The need for tutorialization is especially high in two major cases:

1. When introducing new kinds of gameplay for which there the player doesn't have much or any existing context from other games or real life. Players have no context for the new gameplay, so they need to be taught much more carefully so they can learn. If you've ever seen a player play Dance Dance Revolution for the first time, you'll see what I mean - there's a lot of awkwardness before they start to look more comfortable with playing it. Final Fantasy 13's role change system was similar - it was so significantly different from conventional wisdom that the tutorial elements were spread out over many hours in order to get players familiar with it.
2. When introducing gameplay that specifically conflicts with conventional wisdom. Players already have habits, conventions, and muscle memory associated with that kind of gameplay, so having things work differently will require a lot of unlearning the old habits in order to learn the new ones. If anyone's played the first Mass Effect, you'll probably understand - the aiming and reticle system in Mass Effect 1 is a façade. Putting the crosshairs on a target's head and firing will not guarantee a headshot, even with a sniper rifle. This choice broke a lot of established shooter conventions and caused significant player confusion.

In these situations, it is a good idea to spend significantly more resources on tutorials than games with more traditional gameplay. We, unfortunately, don't always get the resources to do that. In those cases, it ends up hurting the game's reception because players will often miss the features entirely and then complain they aren't there.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ