Feedback for the design of a simulator I’m working on.

Hello, I’ve been working on a bridge simulator in my spare time for a long time now, and I’d like to post the console layouts that I’ve come up with, to see if anyone has any options or feedback on them.

My goal is to make a bridge simulator with a little more complexity than what is out there, so the console have a higher control density than most other games. The plan is to have a set of guided tutorials or training missions to teach crew members how to use a console.

This is just the individual crew consoles. Like most bridge simulators there is also a “Main screen” view that shows an out the window view from the ship.

There is a lot of info, I’ve designed a lot (maybe too much), so I’ve put all the info in a PDF here(https://www.hyperdrive.tech/artbox/frontiers/posts/Screens_layouts_post.pdf) because I can't post it all in one shot. I will make a comment for each section so it all fits.

Comments

  • Screen layouts Navigation
    image
    The ship is navigated in full 3D space using realistic physics, with a flight assist system to help out the pilot as needed. Full real physics controlled by a human can quickly get out of control and become non-fun, so the flight assist option is enabled by default, and can be toggled on and off as needed for maneuvers.

    Control Sections
    image

    (A) Main Map
    The main map shows sensor objects around the ship. The map is aligned to the plane of the vessel, and objects that are above or below the ship are indicated with + or – pips next to the object’s icon. More pips are added the further away the item is. Map icons can be clicked on for more options, such as select as target, add to course waypoint, rotate ship to align with object, or send to science and/or tactical.
    By default the main map is rotationally locked with the ship (the map objects rotate, and the ship always points “up”) and zoom controls are located to the left. Above the main map is a mini map that always shows the most zoomed out view.

    (B) Mini Map
    Above the main map is a smaller version of the map that shows a small version of the most zoomed out view of the main map. By default this map is rotationally fixed to global “map” orientation (the ship rotates). A swap control between the main and mini map allows the navigator to swap the 2 map types, making the main map be synced to the global map orientation and the mini map fixed to the ship.

    (C) On Screen Movement controls
    In addition to keyboard, mouse, and joysticks, there is a set of on screen controls to steer the ship and set the main throttle. On screen joysticks provide access to 6 degrees of motion (linear and rotation). The main throttle slider on the right sets the forward or reverse acceleration of the ship.

    (D) Motion Display
    The motion display shows information about where the ship is and how fast it’s moving. There are also controls to toggle the flight assist system on and off, as well as force the ship to stop moving in all axes.

    (E) Course Plotter
    The navigator can plot complex courses using waypoints provided by the course plotter. Once plotted the ship can automatically align itself and proceeded to waypoints in order, using ether sub-light drives (for local waypoints) or the FTL system for more distant locations.

    (F) Course History
    The list of previous waypoints is shown in the course history. Any item can be reloaded into the current course, or simply selected as the current navigation target.

    (G) Navigational Database
    The navigational database provides the navigator with information about all known systems, objects, and locations. The database is searchable. All available science information and last known locations are shown to the navigator in this display. The results of database searches can be used to plot courses. Databases updates can be provided by other ships, stations, or settlements.

    (H) FTL Controls
    The FTL system is a jump drive type system that requires a vector and a distance to jump. The vector is always relative to the ship’s location and may need to be updated if the ship moves before executing a jump. The vector and distance entered are desired results, and are fed into a Navigational Computer (NaviComp) that will do the required FTL jump computations to correctly and safely make the jump. These computations take time. Jumps of longer distances have more variables and take longer to compute and introduce additional inaccuracy in the exact destination location. Jumps to know locations from the navigational database can be computed quicker due to the database having cached components of the jump equations.
    The FTL system must be charged before a jump can be made, but once charged the actual jump time is short. Items near the ship may be pulled into the jump, or damaged.

    (I) Shield Inspector
    The shield inspector shows the status of the 4 shield quadrants of the ship (shaped like orange slices). Any inbound beam weapons or munitions are shown on the outer ring to allow the pilot the opportunity for evasive maneuvers, or to spread damage over multiple shields.

    (J) Ship Status
    The status display shows a quick overview of the important ship properties, fuel, thruster power, maneuver power, and hull damage. Engineering has a much more detailed view, this is just to give the pilot a quick glance overview of what is available to them.
  • Screen Layouts Tactical
    image

    The tactical station shares a number of elements with the navigation station, for consistency in interface

    Control Sections
    image


    (A) Main Map
    The main map is identical to map from navigation, just with more section options for targeting and firing arcs.

    (B) Mini Map
    Again, identical to the mini map from navigation

    (C) Motion Display
    Tactical has the same motion display as navigation, just without the flight assist or all stop controls.

    (D) Shield Inspector
    The shield inspector is on the tactical display as well, with additional controls to bring the shields up or down as needed.

    (E) Beam Weapons
    All available beam weapons are listed and can be controlled individually or as a group. The current power and charge level of each weapon is shown along with controls to fire them individually. Beams can be placed in auto mode to have them fire at their current target when fully charged. Optionally different beams can be assigned to different targets as needed.

    (F) Missile Weapons
    All available missile launchers are listed and can be controlled individually or as a group like beams. The current loading status of each launcher is shown with options to load/unload or fire each tube. The stores list shows available munitions and is used to select what each launcher is loaded with.

    (G) Tactical Database
    This is a specialized version of the navigational database that shows detailed tactical information about objects or selected targets. The tactical officer can look up known ship types in the databases in order to make the best tactical decisions possible, such as known weaknesses or common tactics.

    (H) Target Information
    The currently selected target is shown here, and displays an overview of its overall structural integrity and shield strength. A small shield inspector shows known data about the targets individual shields as well as the vector of any inbound weapons to the target.

    (I) Ship Status
    Like navigation, tactical has a simplified engineering overview to show general ship status.

  • creen Layouts Engineering
    image

    Engineering as expected shows detailed information about the ship’s systems. This graphic is not complete, but does show all the various items that will be available to the engineer (not all system have all items, but all items are shown on eat least one system as an example).

    Control Sections
    image


    (A) Ship Status
    Like other stations, engineering has a simplified engineering overview to show general ship status. This is mostly so the engineer can quickly know what other stations see. The data in in this summary is detailed on the rest of the screen.

    (B) Engine Power
    This represents the state of the ship’s main power generation system. The engine converts fuel into power. The power is then sent over the power bus to the various systems. Engine use generates heat. Heat is directed to the cooling system for disposal. The engine can be run at different levels of operation, generating more or less power, with corresponding changes in fuel conception and heat generation.

    (C) Coolant System
    This represents the state of the ship’s coolant system. The cooling system removes heat from the engine and other systems. To do this it uses coolant. The engineer can allocate more or less coolant to systems as needed. The core coolant system is only able to remove a fixed amount of heat from the ship at a time. Additional heat is stored by the coolant system as coolant temperature. As the coolant temperature rises, the coolant system becomes less efficient at removing heat from systems. Damage to systems may cause coolant to be lost and also affect the system’s ability to remove heat. Additional coolant reservoirs are available. These reserves can be pumped into the coolant system or filled from the coolant system as needed. The temperature of the reserves are independent of the main coolant supply when they are disconnected, and thus can be flushed (ejected from the ship) to quickly remove large amounts of heat quickly, at the cost of coolant capacity.

    (D) Power Bus
    The power bus is responsible for distributing power from the engine to attached systems. The bus is capable of a nominal level of power transfer without issue, but if the power needs of systems are increased, the bus will generate heat. The bus contains links to each attached system (not shown). Damage to the bus can sever power connections to systems and the engineering crew may be required to repair or reroute power from or through adjacent systems to restore functionality.

    (E) Motion Display
    Engineering has the same motion display as navigation, just without the flight assist or all stop controls.

    (F) System Displays
    The bulk of the engineering console is the various system displays.
    Each system is grouped by function, propulsion, weapons, defense, and suplimental. Each system has controls to set the desired power draw, coolant, heat, and damage status. All systems have one or more sub systems that can be damaged (shown as the single letter boxes to the right). As systems are damaged, these displays indicate what parts of the systems are damaged (details are shown when hovering over each item) as well as the status of any backup’s the sub system may have. Damage may reduce efficiency, increase power requirements, increase heat, or shutdown a system completely until it is repairs. Assigned repair teams are shown underneath each system during repairs.
    Some systems can be overdriven/overclocked by forcing them to draw more power from the bus. If the power is available the system will increase its performance at the cost of heat generation. If the cooling system is unable to remove the heat quickly enough the system will overheat and cause possible damage to sub-systems. Not all systems can be overdriven or generate significant heat.

    System details posted below

    (G) Shield Inspector
    Engineering gets a copy of the shield inspector as well, to help them balance shield power based on incoming weapons fire.

    (H) Damage Control (TBD)
    This sections show available damage control teams and there current assignments. Additional crew may be assigned to damage control from the communications station (TBD). Damage to systems that are being repaired may injure damage control team members who will then have to be sent to medical, and managed by the communications officer or captain.

    (I) Stores
    This section shows all available stores, including motions and spare parts used for repairs and jury rigging.

  • System Details

    FTL Power

    The FTL system uses the most power of any system on the ship, and generates the most heat. The FTL system has additional states, such as warming/cooling and charging that are displayed in a separate status bar.
    Sub-systems:
    • Drive coils
    • Power couplings (primary and secondary)
    • Drive control computer
    • Field stabilizers

    Sub-light Power

    This is the system that powers the main thrusters for Fore/Aft propulsion, used for primary sub-light motion.
    Sub-systems:
    • Fusion Core
    • Plasma Driver Assembly
    • Exhaust Accelerator

    Maneuver Power

    This is the system that rotates the ship and provides maneuver thrust.
    Sub-systems:
    • Flight assist computer
    • Thruster control grid
    • Reaction wheels

    Life Support

    System controls the environmental systems for the crew. Cannot be over driver and does not generate significant heat, but does have power that can be rerouted to other systems if needed. If life support is left underpowered for any significant time, crew response will slow down and eventually stop. All displays will dim to black if left offline for too long, with eventual crew death (game over).
    Sub-systems:
    • Oxygen Delivery System (primary, secondary, and backup)
    • Recycler
    • Gravametrics

    NaviComp
    System processes jump equations to be feed to the FTL’s drive control computer. Can be overclocked to increase performance at the cost of heat generation and possible computation errors.
    Sub-systems:
    • Core Computer (primary and secondary)
    • Navigational Database
    • Mass gradient tensor flow sensor

    Communications

    System handles transmission and reception of data external to the ship. Can be over-driven at the cost of heat and power to increase range.
    Sub-systems:
    • Transmitter
    • Receiver
    • Translation Database

    Sensors

    System runs the external sensors for the navigation, tactical, and science stations. Can be over-driven at the cost of heat and power to increase range and improve processing ability
    Sub-systems:
    • Passive Sensor Array
    • Active Scanning Beams
    • Gravimetric Sensors
    • Optical Sensors

    Shields

    The defensive systems of the ship can be managed to a higher degree than other systems in order to optimize defenses.
    • Shield Capacitor
    o This is the connection from the main power bus to the shielding system. It stores power in the shield buffer and feeds it to the actual emitters. The capacitor can be overdriven to increase its charge time at the cost of heat. Damage to the capacitor will sever links to individual emitters or affect charge/discharge time.
    • Shield Emitters
    o Each quadrant has an emitter
    o Emitters are not directly connected to the power grid, the capacitor is required to provide the high energy charge that the emitter needs to form the protection field.
    o Emitters have a shield rating for how much protection they are offering.
    o Damage to shields will temporarily lower a shield’s rating until it can be recharged from the buffer.
    o Each emitter can have its recharge rate adjusted individually, up to the maxim discharge rate for the capacitor.
    o Damage that is not absorbed by shields is taken by the hull. If the hull is damaged severely the ship will be destroyed.

    Beam Weapons Grid

    System runs power to the beam weapons of the ship. Can be over driven to increase charge rate, damage, and range of beams at the cost of heat.
    Sub-systems:
    • Targeting sensors
    • Power couplings
    • Beam Emitters
    • Focusing Arrays

    Missile loading

    System runs the missile tube stores management and loading mechanisms. Cannot be over driven (the missile won’t load any faster than normal, but can load slower if there is less power)
    Sub-systems:
    • Stores Management
    • Tube Loaders
    • Launch Accelerators

    ECM Transceivers

    System runs the electronic countermeasures system that is available to the communications officer, to disrupt other ships and munitions.
    Sub-systems:
    • Broadband Radio Transmitters
    • Optical Interference Lasers
    • Data security penetration database
  • Expected Bridge Layouts.

    These screens and the others planned are expected to be setup in the following layouts.

    Standard layout

    This layout is the default expected layout, with all crew members in the same physical location.
    image

    The system is designed to allow for multiple view screens so the additional main and side views are optional. This diagram shows 3 displays for each station, allowing for extended screens. This is optional as well. In this layout communications is handled by the captain’s station.


    Remote Crew Layout

    This layout is setup to allow some crew members to be located remotely from the main crew. It is best if the helm and tatcial stations can be located as close to the main system as possible for the lowest latency of inputs, so this layout has sciences and engineering being remote, each with their own copy of the main view screen.
    image


    Extended Bridge Layout

    Below is an example of an “ultimate” bridge layout, with numerous external displays and separate stations for nearly every role.

    image

  • Hi JeffM

    Good to see you here. A lot to take in on those screens.

    Is the big circular overhead view an orthogonal projection? Do those squares in the main circular display always line up with the ship, or, if you pitch up and down, say, do those squares move with the ship, or stay still? If I understand correctly the view is always in the same relative orientation as the ship. Is this just a mockup or is it working already? With just the static picture it's a little hard to tell how effective it will be for visualizing things in 3D. For SNIS (you probably have seen) on the NAV screen I went with something akin to the old Elite -- perspective view from behind, with vertical lines from each ship showing the distance from a plane oriented with your ship,, but added some navigation rings so you can tell the current heading and elevation easily and a few different camera positions. Conveying all that 3D info effectively isn't easy. (BTW, in the lower right corner of the first screen you posted, you seem to be using "azimuth" to mean "elevation" -- or maybe I misunderstand.) I suppose if your weapons aiming is mostly automated, maybe you don't actually *need* to be super effective at conveying all that info. But that is what jumped out at me -- that you're going for full 3D but your display looks pretty 2D, but hard to tell without seeing it in motion.

    Keep us posted with your progress.
  • The ship is navigated in full 3D space using realistic physics
    What kind of realistic physics? Basic Newtonian physics? Gravity + orbits? Time dilation? There is a lot of wiggle room between "realistic" and "realistic"


    Note that my initial prototype spaceship simulator had newtonian physics with gravity and orbits. I opted not do use this for EE due to all the invisible complexities to the players. I had no problem with controlling it, but I have quite a few hours of KerbalSpaceProgram under my belt.


    With EE, I already noticed that players had difficulty keeping their full bearings in 2D. With 3D, I think most players would quit. Especially if the UI isn't helping them. And I don't think you have the right solution yet, but maybe science will help there (I don't see science yet?)


    I do see some cool ideas! Your complexity will be properly conveying information about those complex systems to the players, what happens if the translation database is broke? How do players know it's because that part is broken?
    Even EE fails at that right now at times. For example the effectiveness of boosting power to shields isn't always clear. Even tough, Captains do this, because "More power to the shields!" always sounds like the right thing to do ;-)
  • New Horizons looks incredible!!

    I'll be watching this project from now on!
  • edited April 25
    Thanks for the input.

    The main map view is an orthogonal projection onto the plane the ship is in, so yes as the ship pitches up and down, the projection plane rotates with the ship, it’s a slice of space. The images are halfway between a mock-up and active code. They are implemented in the client application but not everything is hooked up to real inputs just yet, so I can jiggle things around to see how they move, but it’s not getting input from the flight system just yet (I want to see them in full motion too :) ). The map is toggle-able between a global and a relative map view (the big one shown is relative), the global one will most likely not be relative to the ship, but relative to the map. My hope is that depending on what the crew is doing they may swap to the most appropriate map type.

    I have a version of the map that looks like elite as well, with the perspective view. I may keep it as an option. My concern with that view is that due to perspective, you lose resolution the further in front of the ship you are (less pixels due to the taper), and my feeling is that with capital style ships it’s important to have equal information on all fronts. Flight mechanics in elite are mostly “fighter like” in my option so having more resolution for items behind you is important so you can shake pursuers, I’m not sure that is as important in bridge sim style games, but I may be wrong :). I’ve already got the concept of swapping map views from fixed to rotating, so maybe there will be benefit to having a 3D view in the mix as well.

    For vertical deviation, there is a little mark next to each icon on the map that indicates if it is above or below the projection plane. I need to experiment with what to do for heading, I may do a vector marker based on the items current relative movement. For alignment I want to do a lot with context menus on the map items (most likely radial) that gives the option to automatically align the ship’s plane with the target (and keep it aligned) to make it easier to keep relative bearings. I’m also going to have items keep a preference on being aligned with a global vertical axis (galactic up) to make it simpler. If it turns out too complex, I can easily flatten it out to 2D, or narrow 3D by limiting the ship motions. And yeah Azimuth may be the wrong word, I was going for “angle you need to pitch to align with this”.

    Physics wise it’s just Newtonian with a flight assist system, I don’t want to go for full orbits (that’s what computers are for). The current flight model feels a lot like elite dangerous, and I totally understand that the bearing issue can be a problem, that’s why I want a lot of controls for relative alignments. The science and nav databases are there to provide the navigator with ways to align the ship with various targets. Maybe it’ll work, maybe it won’t, but I think the only way to see is to try it out :)

    Engineering will display additional information about systems using tooltips and notifications. So when the translation database is out on the coms system, the subsystem marker will highlight red, and hovering over it shows what the effects are (communications to/from non-native ships will not be understandable). The communications screen will also have a notification on it that the translator is offline and what the effects are. I want all the systems to have this context sensitive info, so that the engineer can see when they hover over the shield systems, what adjusting each of them does. I also want an optional “master systems” display screen that can be shown to everyone in the crew that gives details about the ship operation, such as how fast the shields are charging, etc…
  • Dofuso,

    It will actually be called New Frontiers. New Horizons is the name of an existing NASA probe and I accidentally type that all the time :)
  • jeffM said:


    It will actually be called New Frontiers. New Horizons is the name of an existing NASA probe and I accidentally type that all the time :)

    Pretty close in name to "Elite 2: Frontier". Could cause googling problems or other confusion...
  • There are only so many space words, I didn't want to fret over all possible overlaps.
    There is already a bridge sim with horizons in it so that was out.

    At one point the code base was just called "Boldly" as in To Bodily Go", but I kept typing "boldy" :)
  • Short gif of the current out the window view.

    image
  • Nice! I like the randomness in the engine flames. Which game engine are you using? Also good looking models, where did you get those from? :-)
  • Wow that looks great! Nice models, and the exhaust does look cool and I'm curious how it's done.

    I have an animated exhaust in SNIS, but it doesn't have any randomness, so the repetition is somewhat obvious. I recently mitigated this obvious repetition somewhat by adding what I call an "exhaust flare" at the source of the exhaust, which is nothing more than this texture as a slightly tinted billboard at the source of the exhaust, but I vary the size of it randomly at 10 Hz (might be even better at higher frequency). This also makes the exhaust seem brighter, and more flickery, kind of like the arc of a welder, which draws the eye, and to some degree helps with the problem that far-away ships are small and hard to see. It looks like this... (static image, no gif, sorry)

    image
  • The engine is Unity, and the models are various ones from the asset store. I've been picking them up for years now when they go on sale :).

    The thruster is using unity's "shuriken" particle system. It supports ranges for size, speed, and emission rate, picking random values for each particle created.
    image
  • edited May 3
    I agree with daid and smcameron, looks very nice!

    Some questions:

    - as you are using unity, I guess/hope will multiple platforms will be supported?

    - The flight assist system you mentioned, does it work similar like in pioneer?
    There you can set a fixed speed relative to a reference point, and the ship will try to automatically maintain that speed in the direction is currently heading. You can still manually control thrusters, which temporarily overrides that setting.
    You can also set any object as a reference point.
  • 1) yes the main display app should be on the 3 big ones, windows, osx, linux. The console app should be available for those as well as whatever mobile devices I can test on. I also have plans for an API, so the main display app could have plugins to expose consoles via HTML, or other protocols if needed.

    2) there are actualy 3 different flight modes.

    Manual control Full 3D = no assist, you are on your own and squirrelly has hell. I expect this to be used for evasive maneuvers or leaf on the wind style flying.

    Manual control with flight assist = You still drive, but the system keeps you from getting out of controls. Feels like elite dangerous a bit. Used for close in maneuvers, docking, etc...

    Course mode = You say "go here, this fast" and the ship does. Used to get from one place to another, or follow an other object (the "here" can be something moving". The pilot can plot a course using waypoints to chain together a series of locations, and they can be traversed ether in realspace or with FTL jumps as needed.

    The pilot can swap modes at any time, set a target as the current waypoint, jiggle the controls, then cut back to the waypoint, etc...
  • Why is there not a jaw drop emoticon for this. Amazing!!!!
  • Very cool. Keep posting updates, jeffM
  • Have there been any new developments in this project? I was very excited to see its announcement!
  • it's just at the very start of development. I work on it when I can.
  • Been taking Daid and smcameron's advice into account and reworking the radar/sensor map.
    image

    this view will always be relative to the ship and show things above and below your current plane elite style.

    Here is a video of it in motion

    https://hyperdrive.tech/artbox/frontiers/posts/2018.07.20-20.51_01.mp4
  • edited July 21
    Looks nice. Maybe the firing arcs should be firing hemispheres (or whatever fraction of a sphere)... ? Tthough I'm not sure showing that would be useful without some additional info, as it would be a little hard to tell whether you were or were not within the firing volume, though this could be mitigated by changing the color depending on if you were in or out.
  • Yeah they are placeholders for now, I may draw a ghost line when there is a firing solution ether way so you know.
  • This is very exciting to see! I must confess that I check the Hyperdrive website periodically for updates, although most of your development progress is probably offline at the moment. :) Looking forward to seeing more!
  • Yes, development happens when I cannot it in. I had to take a little break to get some features stared for the next release of an open source project I work on, but that has settled down now.

    My plan is to get a basic single ship simulation going with the framework of a nav console hooked up in order to test motion and flight mechanics. Hence the work on the ship centric sensor view.

    The website is mostly a placeholder so that I have it for when I need it, I should update it more 0ften.
Sign In or Register to comment.