Feedback for the design of a simulator I’m working on.
in Other Games
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.
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
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
(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.
The tactical station shares a number of elements with the navigation station, for consistency in interface
Control Sections
(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.
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
(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.
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
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.
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.
Extended Bridge Layout
Below is an example of an “ultimate” bridge layout, with numerous external displays and separate stations for nearly every role.
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.
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 ;-)
I'll be watching this project from now on!
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
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
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…
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
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"
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)
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.
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.
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...
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
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.