Main > Gameplay
1.3.3 ENGINEER AND REPAIR TOOL BALANCE
awkm:
All these are feature requests. A number is not a good solution either.
While the mechanic is interesting, we can't entertain them before all other possibilities are exhausted. Possibilities that don't require features or more opaque UI.
awkm:
And I am not approving any mechanic here.
The Djinn:
--- Quote from: awkm on October 30, 2013, 02:39:39 pm ---While the mechanic is interesting, we can't entertain them before all other possibilities are exhausted. Possibilities that don't require features or more opaque UI.
--- End quote ---
Alright. I guess my contributions will not help here then: I don't really like having to balance blanket immunity to fire with duration, as it seems to me that the all-or-nothing ratio of that either makes Chem Spray the be-all-end-all against fire (if it lasts to long) or merely a haphazard way of preventing damage to one or two components (if it doesn't last long enough). I'd be interested in seeing only partial resistance, but that turns Chem Spray into more of a "buying extra time" tool rather than a proactive prevention tool.
So I guess I'll ask: what was your concept for Chem Spray? Should it reward proactive work by having a better defense than the Extinguisher? Should it require constant upkeep at the possible expense of other engineering work? Should it collapse if the rest of the ship is threatened and engineers are needed elsewhere?
I'd love to toss out ideas that are more in line with what you're looking for, but I guess I'm not currently sure what you envision as the ideal "proactive" gameplay for fire protection. Obviously it's used before the damage hits...but how do you envision the ideal gameplay around that, and what that should (conceptually) accomplish?
--- Quote from: awkm ---And I am not approving any mechanic here.
--- End quote ---
Of course. I suppose I worded it poorly: I wasn't looking for approval, so much as wondering if you didn't like the idea because you thought the implementation was poorly conceived, or merely because of the potential UI complexity.
awkm:
If possible, feature requests should be avoided. If features are needed, UI must be considered. That Repair UI is really messy as it is.
If you can react perfectly, you can prevent all fire. If you are perfectly proactive, you can prevent all fire. that's the basis of the choice you're making. You're right saying that if the chem spray just has partial immunity, it becomes a buying more time tool. It breaks the previously established metaphor.
The risk of reactive is you can't be react fast enough and can't get to it in time. The risk of proactive is similar in that you prevented it too late. It seems that 5s cooldown for chem spray is too substantial. You failed prevention and now you can't really extinguish the many stacks due to the long cooldown. So decreasing chem spray cooldown may be a potential solution, you can't extinguish all the stacks at once (you're penalized for failing) but you can at least fix it better.
Another alternative may have fire stacks decay over time after extinguished. It's similar to a lower cooldown except that you don't have to be at the component to keep extinguishing. You have the choice of moving on and extinguishing it later or staying there trying to get those 20 stacks down. Not sure if that one was mentioned or not.
While the latter is a little opaque, it's a little better than absorbing charges ebcause the effect is always a positive. You don't really need to keep track of something that's positive. Also, the Floating Repair UI tells you if you have 8 or more stacks so we have at least some global indication of how many stacks something has.
The Djinn:
--- Quote from: awkm on October 30, 2013, 03:03:11 pm ---*stuff*
--- End quote ---
Thanks. That was really helpful. :D
So we want something that allows a skilled and aware Engineer to potentially prevent all fires by well-timed preventative measures. We also probably don't want this to come to to much of an expense to his standard repairing, or it becomes something he cannot do in combat.
I believe stack decay was mentioned, and I think it ran into the "feature request" problem, although I'm not positive.
It seems what you're suggesting could be fairly well accomplished by a cooldown reduction to be closer to the Extinguisher's cooldown (I'd probably say the same cooldown would be fine for both). I'd personally like to see this combined with either a decent duration increase (I feel it should be long enough that I could theoretically run a constant circuit of Chem Spraying while having just enough extra time to heal one or two parts in critical need), or a severely reduced cooldown (down to maybe 1 second) for parts that do not currently have fire stacks. Either would have a similar effect of having an ideal circuit on a nearly undamaged ship result in solid and reliable fire protection.
I think this would result in a very skilled Engineer being able to keep up an almost solid wall of Chem Spray on important ship elements...provided he doesn't need to stop to repair more than one or two components, and provided he doesn't need to rebuild any components. You could counter his proactive wall by destroying crucial parts and forcing him to break his Chem Spray cycle, which gives the strategy a fairly intuitive form of counter-play. It also forces an engineer put in that position to only really have Chem Spray on critical components, as, once his defenses have been overrun, he must really make some key choices on what to repair, what to proactively protect, and what he wants to ineffectively extinguish.
It would also really fit into a Chem Spray Engie + Extinguisher Engie, as with these greater defined roles you'd have an optimal situation of, say, the Chem Spray Engie running around constantly keeping his protection up and trouble-shooting repairs, while the Extinguisher Engie is on board as an emergency response engineer who reacts to components that have had their Chem Spray covering breached, or components that are broken and would pull the Chem Spray Engie off his rotation.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version