Changes to the Engineering Station

I would like to propose a couple changes to the UI of the Engineering station to make it more efficiently managed.
Here's my 15 minute MSPaint mockup of what I have in mind.
image
Sliders for output and coolant could lay on top of the label itself, using a great deal of the unused space on the screen. This could free up a great deal of real estate on the screen for additional stations (or if Scanners or other future stations get their own systems that require power). It also makes adjusting output and coolant much faster between systems, which I think can be a great asset to the crew.
Secondly, I'd like to see the ability to save presets, effectively copying the feature of Artemis. Being able to switch from my "warp only" power config to my "max front shields, max beams" config via keystrokes would be a huge quality of life improvement.

Comments

  • Sorry my mockup image was too wide. Now everyone has to click on it to see it.
  • I also forgot another part to the sliders suggestion: the color of the bar filled up to show heat could be colored based off if the temperature of that system is rising or cooling: deep red for rising, deep blue for dropping, and purple for stable.
  • For reference, engineering presets were debated here : https://github.com/daid/EmptyEpsilon/issues/106

    I personally think that it may defeat engineering's purpose.
  • Here's a GitHub Gist for my Engineering Presets using the httpserver.
    https://gist.github.com/kwadroke/5d62491d81a625b077aa

    You'll need to run it on another monitor, on a tablet/phone, or run the game in windowed mode.

    Right now it has 5 settings:
    * Standard (default power distribution)
    * Standard + Charge (Running the reactor above normal to recharge energy)
    * Cruise (Shields & beam weapons turned all the way down, missiles turned down - all to save energy)
    * Battle (Weapons & shields turned up)
    * Emergency Power (all systems turned off except reactor turned up with coolant as much as possible without overheating)

    Settings can be controlled with 1-5 on the keyboard if the browser is in focus.

    Might want to grab a copy of jquery and put it on the web server and remove the server address from the file, so no internet access is necessary.

    I'll upload this to a git repo with the necessary files sometime in the future.
  • I think something that could be done to make engineering feel more involved in the battle, and less just frantically trying to manage heat levels while everyone else yells about needing power, is to give the engineer more focus over damage control, and have interesting decisions to make about repairing and overclocking systems.

    Basically I read this: http://www.projectrho.com/rpg/cidiagram.html

    For instance, instead of each system having a health score, they could have subsystems, each of which control some aspect of that system's function. Some can be repaired in place, others need replacement parts which can only be obtained in dock. So maybe your [technobabble] on the jump drive is damaged, and now you can still jump, but you can only jump exactly 33.33km. Maybe the beam targeting systems are damaged, and you can still fire, but all their arcs are reduced to 1 degree.

    For bonus points, the engineer could cannibalize parts of other systems to jerry rig into damaged ones. So many you steal the missile guidance system and duct tape it to the jump drive. Now you can control distance again, but missiles can only fire directly forward.

    The overall theme should be the engineer has to choose between two conflicting options, with pros and cons to each. Right now the only decision the engineer really has is which system to repair first, and which system needs extra power. Deciding where to place coolant is not very interesting, because it's a very formulaic decision- coolant goes wherever there is overheating.

    In fact, if something as complex as this subsystem idea were put in, I'd say coolant should be automatically distributed to systems based on heat; with the engineer able to override that if they choose.
  • I approve of the increased focus on damage control, as there's more meaningful decision making, though I think that is because my philosophy is that the effort you put forth be meaningful. If 60% of what an engineer does is manually switching between what could be resets, and 40% modifying the values from there to fit the exact situation at hand and make trade-offs, why not automate as much of that 60% as possible? I'm here to play star ship engineer, not star ship engineering droid.
Sign In or Register to comment.