QuickFire was a failure, but not for the reasons a lot of people think. What happened wasn't out of malice, nor was anyone trying to force anything despite what many say.
I feel like Quickfire failed due to the following reasons:
Any good and enjoyable game mechanic should never add complexity for the sake of it. When designing a mechanic, a game designer should ask the following questions:
All those threads and arguments over Power 2.0 failed to actually realize the true problem, and only divided the community and in turn muddied the waters further. The real problem was never balance, it was the design of the core mechanics themselves. Any attempt at fixing Power 2.0 purely through configuration was therefore doomed from the start. There is no reality where QuickFire could have actually succeeded because attempting balancing a system that is fundamentally not fun will only serve make it even less fun.
We all argued amongst ourselves, pointing the finger at each other, arguing whether the QuickFire changes were good or bad. The truth is that it doesn't matter if they were good or bad, wrong or right, because either way the overall mechanic still wouldn't have been fun. There is no combination of changes that would have fixed that. Even if QF didn't change anything, the Power system still wouldn't have been fun.
So then, is it Schema's fault? I would argue yes, but also no. Why? Because programmers are fundamentally incapable of good game design. I know this sounds silly, but hear me out:
Programmers are supposed to be the ones that implement the mechanics laid out by the game designers. Programmers rarely actually actively play the game they are making. Like I said before, there is a difference between testing and playing. Schema should never have been expected to design a good power system because he doesn't play the game enough to know what one would feel like. At the same time, I wouldn't expect Schema to do so either, because it's not his job.
I feel like Quickfire failed due to the following reasons:
- The QF Team - Game development studios have people test their games well before release in order to help get feedback on gameplay balance. The QF team weren't game developers in the slightest, they were just a couple of players who happened to know some basic math and scripting skills. In fact, I actually agree with the sentiment that they were not "qualified" to be experimenting with this stuff, but I don't think that's any fault of their own. That leads me into my second point:
- Feedback in a Vaccum - The only people testing the changes were the QF members themselves. And to be fair, asking people to test the dev builds on their own was never going to work. From my experience, there's a difference between "testing" and "playing". Making a test ship in single player, firing a few shots at a target, then tweaking the numbers, is testing. When somebody plays on a server and builds systems and fights stuff, that's playing. When trying to balance (and bugtest) a game, the former is almost useless. Testing as I described above won't catch many issues, and of the ones it catches you tend to only get basic surface-level information about it. Actively playing meanwhile, not only catches far more issues, but you also get much more information on them which is much more useful in making an informed decision. The problem with the latter approach is that it tends to take much more time and effort, and unless QF hired people to actively play on a dev build server, it was never going to happen. This leads me to my third point:
- Inability to do What Was Necessary - Let's say the QF team did actually pay people to play on a dev build server for a while, and got actual, meaningful feedback. Even with this feedback, their ability to actually fix anything was very limited. In order to actually balance Power 2.0 in a way that mattered, the ability to actually make code changes was absolutely required. Simply tweaking some numbers and equations was never going to be sufficient. To describe the decision making behind the design of Power 2.0 "questionable" is to be a comedian. The fundamental design of Power 2.0 has deep structural flaws and many of it's features were unnecessary bloat that serve only to add complexity. It is not only unfun mechanic-wise, it runs in direct contrast to how people actually play.
Any good and enjoyable game mechanic should never add complexity for the sake of it. When designing a mechanic, a game designer should ask the following questions:
- What purpose does it serve? And to be clear, there is a difference between functionality and purpose. Functionality describes how it works and what it does. Purpose describes why it's important / needed and how it ties into other mechanics. Let's take Stabilizers for example: The purpose of Stabilizers are to "stabilize" the reactor. Do they actually do this? No, but that's not my point. What they actually do (as of this writing) is simply add more regen. This brings me into the second question:
- Are both the functionality and purpose unique? Continuing on the stabilizer example, lets ask this question. Do stabilizers add any functionality that is unique when compared to other mechanics? The answer to that question is no! Stabilizers add power regen, but do you know what else adds power regen? Reactors! Not only do they add power regen, they also are essential to both chambers and the overall combat system. So in a way, Stabilizers are just reactors with less functionality.
- Without the mechanic, what would change? And would said changes make the game better or worse? If Stabilizers weren't in the game, what would change? Well, ships would have less overall power regen, and therefore reactors regen would need a buff. Other than that, nothing would change. And that's just the current implementation, when Power 2.0 first came out you had to worry about stuff like axis rotations, which were the literal embodiment of "burdening the player with restrictive mechanics for the sole purpose of adding unnecessary complexity". Stabilizers are in the game purely to add unnecessary complexity - they don't introduce anything unique and the complexity they add actively make the game less fun. If a mechanic that adds needless complexity isn't fun in any way, it shouldn't be in the game.
All those threads and arguments over Power 2.0 failed to actually realize the true problem, and only divided the community and in turn muddied the waters further. The real problem was never balance, it was the design of the core mechanics themselves. Any attempt at fixing Power 2.0 purely through configuration was therefore doomed from the start. There is no reality where QuickFire could have actually succeeded because attempting balancing a system that is fundamentally not fun will only serve make it even less fun.
We all argued amongst ourselves, pointing the finger at each other, arguing whether the QuickFire changes were good or bad. The truth is that it doesn't matter if they were good or bad, wrong or right, because either way the overall mechanic still wouldn't have been fun. There is no combination of changes that would have fixed that. Even if QF didn't change anything, the Power system still wouldn't have been fun.
So then, is it Schema's fault? I would argue yes, but also no. Why? Because programmers are fundamentally incapable of good game design. I know this sounds silly, but hear me out:
Programmers are supposed to be the ones that implement the mechanics laid out by the game designers. Programmers rarely actually actively play the game they are making. Like I said before, there is a difference between testing and playing. Schema should never have been expected to design a good power system because he doesn't play the game enough to know what one would feel like. At the same time, I wouldn't expect Schema to do so either, because it's not his job.
Last edited: