I’ve gotten a bit of feedback about OmniBlade (current release here), a portion of which I can’t directly address, specifically in terms of Quality of Life (QoL) features.
As far as OmniBlade goes, it’s in a weird design space as a retro-style game. Firstly, if you give a retro-style game all of the quality-of-life features that people have come to expect from modern games, it ceases in many ways to be a retro-style game. You have to give them SOME quality of life stuff, for sure. But the question is where to draw the line?
Take Final Fantasy on the NES for example. One of the reasons dungeons in Final Fantasy are so intense and satisfying is because it lacks the Quality of Life feature that provides a way to instantly exit them (at least for about the first half of the game). In doing so, it forces players to engage in resource management strategy far more intently than if they can just fly out with an Exit spell or item. Resource management, however, is at the heart of what makes old school RPGs so interesting and fun (despite all of the technical limitations).
More importantly in this case, the adrenaline rush the player gets when barely escaping a level with their life is hard to match. When you have several minutes of progress on the line, it makes the stakes much higher than if you can just spam continue whenever you die.
Additionally, a lack of an Exit action makes it so levels can require multiple runs before getting to their boss and beating them, creating a ‘looting’ style gameplay mechanic. This is a great game mechanics that newer games don’t at all capture, again due to being thwarted by QoL. This looting style of play is specifically something I was going for with OmniBlade (although due to balance issues, I think it’s currently a little overdone). If I directly relented to player’s QoL feature requests, the core gameplay mechanics around the game were built would cease to function properly.
However, there is a partial, compromised way to satisfy player demands. Having a two-way warp gate after each mid-boss will keep players from backtracking through areas with weaker enemies, but still keeping the looting style of gameplay in tact (when exploring a new area, you have to at least make it back to the previous warp gate to get out alive). UPDATE: this has been implemented and works as well as predicted.
This dynamic between retro-style mechanics and QoL features is precisely why you have to be extremely careful on which and what type of QoL features you give the player when making a retro-style game. Unfortunately, modern reviewers will most likely dock your game based on lack of QoL regardless of whether their lack actually improves the intended part of the experience. Some game journalists are probably going to dock your game for have any challenge or stakes at all. But them’s the breaks.
It’s good to remember that retro-style games are not modern games, and that’s intentional. Modern games are often less interesting than retro games, primarily because they don’t draw in the player despite all of their graphical luster. One thing you often see happen often in modern game development is that the developers start with a fun and challenging game, but by the time the testers and previewers get all of their pet QoL features in, it’s no longer much fun because many of the game mechanics have been watered down by QoL features. How can you be emotionally invested in your character’s survival if every time you die, you just go back three seconds in time and lose nothing? All those cool gameplay mechanics your development team spent so much time on come to mean nothing because the player can just get out of trouble for free with a QoL feature.
So don’t let QoL requests, as reasonable as they may initially seem, compromise your retro-style game’s design. If you can find a way of addressing the issue for which the QoL is being suggested without sacrificing your existing design goals, that is probably better. Always listen to feedback, but also be cautious when triaging QoL feature requests.
Vsyncronicity 