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

Production makes the final call on bug prioritization, but they take the advisement of the other departments under consideration while making those choices. You are correct that the bugs that stop people from working are the top priority. Below broken builds, live issues that allow players to exploit or grief others are often top priorities. Other than that, it's a jumble of completing the remaining tasks that need to be done for our next release (especially those that allow others to work) and fixing the bugs that come in. Things that are mission critical are more important than things that are good to have, which are more important than things that are nice to have, which are more important than wishlist items. These get ranked against bugs that ruin experiences, bugs that bother players but don't ruin experiences, bugs that are annoyances but not real bothers, and so on.

[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

The good news is that the PS5 and the XSX aren't too far away from each other in terms of hardware power and architecture. Further, developing on XSX also mostly works out of the box with DirectX, which means it is easy to also get the game running on PC. It's relatively easy to build a game out of a generic system and task our engine programmers with getting that generic system working on each of our target platforms.

The difficulty in multiplatform development comes from trying to get the same generic system to run on drastically different hardware power profiles or architectural differences (commonly known as the Nintendo problem). If we have a game that assumes the player's hardware have at least 16GB of RAM and an 8-core 3.5GHz CPU and we suddenly have to fit that game into 4GB of RAM and a 1GHz 4-core CPU, we've got to make a lot of drastic changes in order to get the game running at all. I'm fond of saying that porting PS/Xbox games to Nintendo hardware is trying to get an entire Honda Accord to fit inside a Mini-Cooper.

The general rule when estimating the cost of making a change is how early during the process the change is made. The earlier in the process the change is made, the cheaper the cost of the change. Making a change to a movie before it's cast and shot is much easier and cheaper than making a change after the filming is complete. Making the decision for a project to go multiplatform from the jump means that the entire project will be built with maintaining multiplatform stability as a major goal. This means that further decisions will be made with that goal in mind - the team might spend those resources elsewhere instead of optimizing for certain platform-specific hardware features.

As for why Square-Enix decided to go platform exclusive with FF16 and the FF7 Remakes, it is likely that Sony offered them a seemingly-better deal. Most third party publishers get a standard deal with the platform - the platform takes a 30% cut of all of the game's revenue, the game must pass certification, the platform gets some kind of exclusive content for that version of the game, and so on. If the platform wants to get an exclusive, they offer a better deal than that - maybe Sony agrees to pay for some of the marketing of the game, maybe Sony takes a smaller cut of the revenue, maybe Sony waives the certification costs on the publisher's next five Playstation games, and so on and so forth. These concessions and incentives are certainly worth considering. Sometimes they work out well for the third party, like Insomniac's Spider-Man games. Sometimes they don't.

[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

It's really hard to say because every project is different. The kind of games that have the least cut content are annual sports titles - they have the most stringent schedules and know exactly what they are committing to with each annual cycle, so they have significantly less wiggle room than a project with a longer schedule and bigger scope (e.g. GTA6). The games with the most cut content are often those that manage to make it out of development hell, the kind of games that are lucky to get released at all.

The other thing is that cut content often comes in various degrees of completion. Some cut content never goes beyond existence in documents, let alone a prototype. Most gets a few iterations on a prototype before the plug gets pulled, often because we can't find the fun in the idea within the time we've allotted to it. Rarer, we have nearly-finished content that gets cut for other reasons - the senior developers pushing for the feature get laid off or leave the company, there's a big leadership shake up that changes the game's direction, the senior developer working on it is needed elsewhere more mission-critical for the game to ship, additional funding for the project falls through, and so on. This kind of content is what the data miners are often able to dig up.

Also, it can vary based on technical constraints - if cut content eats up a whole bunch of disk space and we need to shrink the install size, we have to remove it. If the cut content is shared by a bunch of load-bearing assets, it will probably stay with those assets so that we don't accidentally break the game. Generally, we leave stuff there unless there's a good reason to remove it. It is often tough to know whether something is load-bearing so removing anything is always riskier than leaving it inert.

That's basically it - the amount of cut content that players/data miners can possibly discover depends primarily on the kind of game, the kind of content, and the circumstances of the game's development.

[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

The importance of the narrative depends primarily on how important the narrative is to the game. For a game like Overwatch, where the core gameplay is team pvp, the narrative is a lot less important and things like relationships are generally prioritized. It matters more that each character fills the specific gameplay needs of a team-based pvp shooter than it matters that these characters are brothers or that group has a rivalry with this one. In a situation like Overwatch, the narrative tends to be more like the glue that holds the bigger parts of the game together - it's decided on later once the big decisions have been made (e.g. we are locking in a flying rocket character and a fast teleporting character).

The important thing to think about when it comes to development is that we can't build the game sequentially, we have to build as much of the game in parallel as we can. This means we have to start work on the things that take the longest as early as possible (e.g. building environments, creating animations and rigs, building the technology), and then do the things that take less time to complete later. For features like cutscenes, it depends on how much difficulty it takes to build the cutscenes. In the original FF7, the FMV sequences were set in stone. Making changes to pre-rendered FMV was untenable, so everything in the FMV sequences had to be locked in very early on in order to get it all done on time. The in-game bits - the low-poly characters moving, talking, and animating - were cheaper and easier to build, so they could be changed significantly later in the dev cycle. Today such things would be much more difficult due to the necessity of voice acting and the difficulty of getting the voice actors back into the recording booth.

When we're in deadlines, we have deadlines - this is the last day for us to make changes to the feature we're working on. That could mean combat, it could mean itemization, it could mean summoning magic, it could mean narrative, it could mean cutscenes/cinematics. After that deadline passes, we commit to fixing bugs with what we have and not making any more changes or additions, no matter how good the ideas are. If we can always make changes forever, we'll never ship the game. As the inestimable Dolly Parton said, "Sometimes you need to to tinkle or get off the potty."

[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