why are quick time events so popular in games? and do you see accessibility options that change these game play mechanics becoming more common?
Haha, so this is a funny question to ask me in particular because I see this as a primarily AAA trend and I actually don't play that many AAA games, and especially the type of prestige-games that tend to feature this. But i guess FF16 does have them, so I'll try and reason it out.
IMO there's a few reasons these are a thing, but I'd guess that the primary reason is a fairly simple: Expensive games want the climax of a fight to happen in a cutscene so it can be flashy and under their full control, but developing an entire design/cinematic language that's cutscene compatible and still feels like 'gameplay' is fairly difficult, while making the player do timed button presses is fairly straightforward. And because almost every expensive game has expensive cutscenes, this cheap way of leveraging them to spice cutscenes up has proliferated.
So IMO it's popular in games because it's a very understood way to have a cutscene-heavy game that still feels "active", while requiring minimum interaction between the design and cinematics teams. In AAA, where complex intersection between art and gameplay generally has to be planned for WAY in advance (because it's expensive), this is something you can insert even late in dev without hurting your timeline too much. Which is to say: It's popular because it's safe.
Personally I've always been much more of a fan of doing important scenes in gameplay as much as possible, but that's something that takes a lot of design work and custom setup, and in AAA where everything is exponentially more expensive, I suspect that's a harder sell.
As far as accessibility features.. okay, so this kind of raises another question, right? What is it about QTEs that demands accessibility separate from the rest of the game? And the answer is usually "injecting strict timing elements and/or mashing into games that didn't otherwise have them". It's the juking of gameplay standards that's an issue here, imo, because if the game already required mashing during normal play it'd probably have an accessibility feature for that most likely. IMO the way I'd like to see this thing solved is more for designers to find way to integrate their existing gameplay principles into QTEs if they exist, because then players will already be set up with features that solve those issues. But since most QTE systems are just glued in regardless of the rest of the game, instead we end up needing bespoke accessibility options.
I think doing things this way is a waste, but it's cheap and I bet it shows well to CEOs who don't know how to play video games, soooo. I think accessibility re: these features is going to continue to be kind of crapshoot that's determined far more by whether the company in question typically does good accessibility features in their games or not. But I also don't have a lot of insight into the accessibility space so, you know, take my opinion with a grain of salt.
One final note: The one place I feel like I bafflingly do see this cropping up in indie is what I would call the "sudden rhythm game pivot", wherein a game with no realtime elements abruptly introduces mandatory rhythm minigames as an excuse to get some music montages in. Which TBH is one of my least favourite modern indie narrative game trends - and I'm saying that as a rhythm game fan. I kind of just hope indies do less of that in the future. Doing rhythm games well is very hard, because it requires a lot of more subtle design understanding of how to pace narrative elements and what "difficulty" means in this context (and I think it introduces a lot of problems trying to bridge the HUGE skill gap between very skilled rhythm game players and casual players who are just trying to play a story game). Doing it badly is a real drag on many players' experience. So IMO don't unless you really, really are gonna commit to it.
Anyway! That's what I got. Thanks for the ask - it's nice to have an excuse to ramble about gamedev stuff again, haha.
I once worked on a prototype for a rhythm-based brawling game (for a AA-ish sized studio), where the high-level idea was that the player would want to hit buttons in time to the music track playing.
So many of the variations on it just hit a wall because the level of difficulty that was the minimum to make me (and a few other folks) engaged at all was unplayably hard for a handful of folks on the other end of the rhythm-game-enjoyer spectrum. That gap is enormous and even letting players pick a difficulty level really wasn't enough to manage that.
We wound up with something in the ballpark of what Hi-Fi Rush would eventually do, though with a bigger focus on the enemies acting in time with the music (really, about half a beat behind so you'd want to time your defensive actions on the beat) and that played OK.
We then started working on a radically different kind of combat input system where instead of buttons being your various types of attack we assigned enemies and objects in the scene to buttons and it was about responding to the situation (so you got to watch your character play out all these cool fluid animations in time with the music even if you were only sometimes even acting on the beat)... and the the project got canned at the go/no go call to move it out of preproduction. Which was for the best, the timeline to hit the narrow ship window would have killed us.
