UNION is a cooperative spaceship simulator with deep tactical gameplay. You, and up to four friends, take control of up to five stations (Captain, Helm, Tactical, Engineering and Science) on the ship, working together to survive, and maybe conquer. The first release of UNION will be multiplayer only (with multiple ships, each with it's own crew). A singleplayer/cooperative campaign is planned for later.
UNION is a large game with quite a large scope. I've had a few enquiries as to my plans for the game, so here is an overview for those interested.
Posted by Faerdan on Dec 10th, 2012
UNION has quite a large scope. I've had a few enquiries as to my plans for the game, so here is an overview for those interested.
And yes, this is pretty much a wall of text. ;)
UNION is spaceship simulator. The player takes on the role of ship Captain, issuing orders to one of five Stations: Helm, Tactical, Engineering and Science. The player can also take direct control of each Station, giving him/her fine control of ship systems. At any time other players can join the game, taking control of one or more Stations on the ship, creating a compelling cooperative experience.
Multiplayer (PvP) and campaign (singleplayer/co-op) and game modes will be available. Multiplayer will come first (in the initial release) as the game is built on a network framework.
When asked for a one liner on UNION I say "submarines in space" as they share many characteristics, from the tactical nature of tracking and engaging ships to the tension of evading enemy patrols.
The main goal in designing UNION was to take the kind of spaceship experiences and stories that I love from science fiction film, and books, and make them possible within a game. In order to do this the game needed to have lots of depth, with emergent gameplay. A huge amount of thought and effort has gone into developing simple, interesting, fun, mechanics which can deliver on this goal to create the best possible experience for each player.
The initial inspiration for UNION came from Artemis Bridge Simulator; I fell in love with the concept but had a very different take on design and implementation. I began to prototype elements of that design in Unity3D and thus UNION was born (the setting, story and name come from a pen and paper RPG that I'd created to run for friends).
Gameplay focuses around the five "Stations" on a ship, Engineering, Science, Tactical, Helm and Captain. Players can control one or more Stations at any one time.
The Captain's station has a context sensitive UI which allows the him/her to quickly and easily give orders to each Station. If the Station is crewed by a player these orders are displayed to him/her, allowing them to be acted upon.
If the Station is not crewed by a player then the order is fulfilled by the AI, allowing the Captain to command the ship without any crew. This is key to the singleplayer experience.
If the Captain wants finer control of the ship he/she can switch to any Station which isn't under the control of another player.
The Captain gets an overview of all systems in order to make the "big picture" decisions.
Systems & Energy
The ships has eight "Systems": Engine, Short Range Sensors, Long Range Sensors, Forward Weapons, Rear Weapons, Forward Shields, Rear Shields and Cruise Engine.
Each System has a "bank", or battery, which holds energy for that system. This energy is consumed as the System is used.
For each System the engineer controls two variables, Energy Input and Energy Output.
The higher the Energy Input, the faster the System's bank (battery) recharges. The higher the Energy Output, the more power is consumed per System use. Examples of this are weapons, where Energy Input is the recharge rate and Energy Output is the weapon's power/speed/damage/penetration (depending on the weapon type), and shields, where Energy Input is the shield recharge rate and Energy Output is how much damage is absorbed per impact.
The Input and Output energy variables must be balanced against heat. The higher the Energy Input the more heat the System generates per second. The higher the Energy Output the more heat is generated per use. Systems dissipate heat at a constant rate, depending on the heat-sink attached. The optimal Energy Input/Output setting for a System is when it's dissipating heat as fast as it is generating it. When a System is generating more heat than it is dissipating through its heatsink the System will begin to overheat.
Too much overheating of a System causes its structural integrity to drop. As this happens the System's heatsink becomes less effective, it dissipates less heat, lowering the System's operating efficiency. Unless the Engineer gets control of the situation, bringing power levels down or venting heat, overheating could get out of control, causing the System to completely fail (and potentially explode, doing damage to other Systems and/or the Core).
The Engineer has a finite amount of coolant, which he/she can use to flush heat from Systems or the Core. Flushing heat ejects the heat into space, which temporarily increases the energy signature of the ship (see Energy Signature below).
The graphic below illustrates a Systems and its controls. Each Station's UI contains a display of any Systems which affect their Station, so that they can use power most efficiently and help to prevent overheating.
The Core (which is the ship's power generator) supplies energy to the Systems. The amount of energy the Core outputs equals the total Energy Input of all Systems. The higher you set the Energy Input on a System the more energy it'll draw from the Core and the higher the Core's Output will be. The Core generates heat, per second, based on its Output. Overheating in the Core causes its structural integrity to drop. If the Core's structural integrity drops too low the Core will lose containment and it will explode, destroying the ship.
The Core cannot power all systems at full power without generating excessive heat, the Engineer needs to prioritise power to certain Systems. A key example of this is the cruise engines, which require a large amount of power. By default when the cruise engines are turned on, and begins to draw power, other hungry systems such as weapons and shields are automatically shut down to prevent overheating of the Core. An Engineer can engage overrides to prevent this happening but it is not recommended.
The final part of the energy/heat mechanic I'll discuss here is energy dumps. This is the ability to dump power from one System's bank to another. Dumps can be very dangerous, as they generate a lot of heat, but sometimes you've got to roll the dice.
Your ship is losing a battle with another vessel and your Captain decides to retreat. To get away you need your cruise engines but they take time to charge and you mightn't survive that long. The Captain orders that you dump the forward shield bank into the cruise engine bank, allowing you to jump to cruise speed in a matter of seconds, making your getaway.
Damaged Systems (with a structural integrity lower than 100%) can be repaired by assigning one of a limited number of repair drones to them. Systems must be shut down before repairs can commence.
The Engineer monitors the structural integrity of the ship's hull. The hull is split into sections and each section contains one or more of the ship's Systems. A damaged hull section can lead to weapon hits damaging, or even transferring heat to, Systems in that section. The Engineer can expend nanobots to do field repairs on ("patch up") each section of the hull.
The total heat output of a ship (the combined heat generated by the Systems and Core) contributes to the ship's energy signature. The stronger this energy signature is the easier the ship is to detect and lock onto. A high energy signature leads to a stronger lock, making targeted weapons more accurate which leads to a higher potential damage.
Long Range Sensors
The Science officer uses the ship's retractable long range sensor array to scan locations for enemy vessels, using power from the Long Range Sensors System. All sensors (long and short range) detect energy signatures, which are mostly generated by heat. Shipwrecks and environmental bodies, such as asteroids, can give off energy and heat making it possible to get false or "ghost" sensor readings. The Science officer can investigate these with further scans, drones, or by having Helm fly closer to the location.
The long range sensor array can only be used when it is fully extended. When extended the sensor array adds to the ship's energy signature. It is also very fragile and prone to damage in combat, for that reason it is recommended that the Science officer retract the sensor array before entering combat.
Short Range Sensors
Short range sensors are available at all times, offering a continuous sensor view within a limited range. If an enemy vessel is detected, and the Captain decides to engage, the ship will intercept the vessel and the Tactical officer will attempt to lock onto the enemy. The Science officer can use energy from the Short Range Sensor System to boost the strength of the lock, making getting it faster and the resultant lock better. Once a lock has been made the Science officer can then do "deep scans" of the enemy ship, giving the Science officer a breakdown the enemy ship's Systems. The Science officer can then flag one or more of these Systems for the Tactical officer, allowing him to lock onto them instead of the ship as a whole.
The Science officer also has electronic warfare abilities, using drones and expending short range sensor energy to create decoys and disrupt enemy sensors.
Weapon & Shield Modulation/Penetration
The Science officer gets reports on the estimated penetration of hits on enemy shields, as well as penetration of hits on his/her own shields. He/she can then use energy from the sensor banks to change the weapon or shield modulation, trying to hone in on the enemy sheild frequency, which increases shield penetration, while keeping them from doing the same to his/her own shields.
It's the Helm officer's responsibility to pilot the ship. The flight model in UNION uses Newtonian physics in full 3d space (Though there is some drag. This is to give the game a terminal velocity, which is required for the networked physics simulation).
Positioning is key to success in combat. As with naval battles the key is to position the ship so that the enemy is within as many firing arcs as possible, while minimising how many weapons the enemy ship can bring to bear.
The Helm is responsible for defensive measures, including shield control and torpedo/missile countermeasures.
The Tactical officer's most obvious job is getting target locks on enemies. This opens up the potential for him/her to fire weapons; it also opens up abilities for other Stations, which rely on Tactical locking the target (such as the Science officer's deep scans).
Before speaking about weapon loadouts it's important to speak about the composition of a ship's hull. The hull is made up of three layers: Ablative (which partially absorbs energy and ballistic weapon blasts), Kinetic (which partially absorbs kinetic weapons such as projectiles from a gauss cannon) and Memory Metal (which is equally good at absorbing everything). The integrity of each layer is affected by each weapon hit, depending on the weapon's type.
If the lock strength is strong enough Tactical gets a report on the condition of the target's hull, including the estimated integrity of each layer.
The Weapon officer must take a target's shields and hull condition into account when choosing which weapons to use against it. Shields absorb energy weapons best, so it's best to use ballistic or project weapons against these first, then each layer of the hull has its weaknesses. While blasting away with any weapon could work, tactically choosing the best weapon for each situation is key to continued success.
Firing weapons generates heat (which also increases the ship's energy signature), depending on the Energy Output set by the Engineer. It is the Tactical officer's duty to ensure that the Forward and Rear Weapons Systems don't overheat, limiting online weapons and weapon fire and to ensure that this does not happen.
If you missed the first Dev Diary entry, which talks about the flight system in UNION, you can find it here.