Oolite Bulletins

Cody wrote:

JazHaz wrote:

What does everyone think?

I think I ain't too impressed - especially with the nebula!

JazHaz wrote:

What I meant, is it an Oolite nebulae?

JazHaz wrote:

What I meant, is it an Oolite nebulae?

Cody wrote:

<patiently awaits delivery of the latest news from the front>

Sandro Sammarco wrote:

Hello, you lovely backers!

Our initial proposal for in-system fast travel raised almost universal concern from the DDF. As developers, we of course make the calls and live with the consequences, but it's fair to say that even in such a small, fanatical (in a good way!) demographic, the response was clear enough to make us step back and take another look at what we were trying to achieve.

Well, it turns out that look become a long, unyielding gaze into the abyss of design. Brains were racked until you could use them for pizza base, stones were turned until the insects had nowhere to sleep, and teeth were gnashed until we were forced to drink our dinner.

The often conflicting issues of multiplayer and scale made this an extremely thorny issue, requiring compromise between many disciplines, but we pushed through to the other side, and I think we found something pretty darn good along the way.

Now it's time let our concept out into the wilds and get some feedback. This is a fairly meaty proposal update, so it's split into two posts. Have a gander, have a think, and let us know.



THE FRAME SHIFT DRIVE

1 GLOSSARY
1.1 POWER PLANT
A ship’s power plant is an internal module. It consumes fuel and converts it into energy that is used by powered modules when they are turned on.

As each powered module is turned on the power draw of the power plant increases, meaning that fuel is consumed at a higher rate.

Power plants have maximum draw levels; once reached, the commander will have to turn off powered modules to turn on new ones.

1.2 ENGINES
A ship’s engines consist of the following elements:

• One or more powered, internal modules, that consume fuel and generate thrust
  • The greater the thrust produced the higher the fuel consumption
• A series of external thrusters that direct the thrust to provide ship movement

A ship’s engines allow it to travel at speeds of several hundred metres per second.

1.3 FRAME SHIFT DRIVE
A frame shift drive is a powered internal module. Basically a cut-down version of a hyperdrive, it consumes fuel to allow a ship to travel at a significant fraction of the speed of light.

1.4 HYPERDRIVE
A hyperdrive is a powered, internal module. It consumes fuel to allow a ship to perform hyperspace jumps, travelling vast distances (light-years) in seconds, and to frame shift. The hyperdrive is the name given to the whole assembly, but essentially a frame shift drive is an intrinsic part of it.

2 MODES OF TRAVEL
There are three modes of ship locomotion in Elite: Dangerous, allowing commanders to travel around the galaxy. Both super-cruise and hyperspace travel are inertia-less. Both are closely related, and involve shifting the frame of reference such that distances become very much contracted – essentially distorting space-time in the immediate vicinity to achieve this effect. This means people travelling on such a ship do not feel an acceleration when doing so (though that’s not to say it doesn’t involve jolts and some violent motions so people should be strapped in!):

• Conventional Travel: Conventional travel allows it to attain speeds in hundred of metres per second. Conventional travel uses a ship’s engines. The following activities are possible:
  • Docking
  • Combat
  • Trading
  • Mining
  • Some methods of exploration

• Super-Cruise Travel: If fitted with a Frame Shift drive, a ship is able to travel at speeds approaching significant fractions of the speed of light, colloquially known as super-cruise. The Frame Shift Drive is a discrete, powered module. The following activities are possible whilst at super-cruise:
  • Freeform travel between in-system bodies
  • Freeform high speed orbit around in-system bodies
  • Freeform travel to arbitrary in-system locations
  • High-speed pursuit and artificial mass locking of targeted ships
  • Some methods of exploration

• Hyperspace Travel: If fitted with a Hyperdrive, a ship is capable of near instantaneous travel between gravity wells, either within a system or between systems. These journeys are known as hyperspace jumps. A Hyperdrive is an upgraded Frame Shift Drive. As such, it retains all Frame Shift functionality. The following activities are possible:
  • System-to-system jump
  • In-system jump to in-system body

3 THE FRAME SHIFT DRIVE
The Frame Shift Drive (FSD) is a module that has grid, ship class, mass and power requirements like any other module.
It allows a space ship to travel at super-cruise:

3.1 INITIATING SUPER-CRUISE
When fitted, the FSD allows a ship to engage super-cruise:

• There is a wind up time when engaging the FSD, with associated visual, audio and sensor effects
• The FSD cannot be engaged when the ship is within a calculated distance of another vessel or structure that has a large mass– the greater the mass the greater the required distance – conventional flight using engines must be used to clear the distance
  • Modules and consumables exist that can delay/prohibit/cap speed and allow FSD engagement, creating an arms race between those who want to engage super-cruise and those who want to prevent them doing so

3.2 TRACKING AND MATCHMAKING
When a ship successfully engages the FSD it is removed from the session and joins a super-cruise session:

• The act of engaging the FSD leaves a brilliant particle trail that dissipates over time – other vessels which match the position and vector when engaging their own FSD increase their chance of being matched in the same super-cruise session
• Any players in the session that is left will see the commander having engaged FSD dart off at an incredible speed in their initial super-cruise direction and then disappearing – enabling such a ship to be followed.
• Targeting a ship which then engages its FSD increases the chance of being matched with the vessel if engaging super-cruise within a window of opportunity
• Allies can slave their FSD to guarantee that they enter super-cruise in formation at the same time and in the same session
  • When slaving the FSD, all vessels use the capabilities of the weakest drive
  • The vessel that others slave to has flight control during super-cruise, though slaved ships may break off at any point (and re-slave if they are within a set distance)
• As with all matchmaking, there is no guarantee of being successfully matched with a particular session beyond slaving FSDs

3.3 SUPER-CRUISING
Once super-cruising, a commander can employ the following ship systems:

• They can linearly accelerate up to the ship’s maximum super-cruise speed (though in practice this will almost never be reached) and decelerate down to a standstill (these two rates will most likely be different – it will be easier to come out of super-cruise than enter it), at which point they drop out of super-cruise and into normal space
  • Commanders that drop out of super-cruise far from any gravity well may broadcast their location directly to known ships which can use the data as a hyperspace destination
• They can manually control the direction of the vessel
• If outfitted with the correct sensors they can attempt to scan for un-mapped celestial bodies, phenomena and other points of interest using associated sensor interface options
• They can use long range sensors to track other ships super-cruising nearby
• If they have the correct modules or consumables they can attempt to mass-lock a targeted ship or nearby ships, dragging them all out of super-cruise into normal space relatively near each other
  • Ships do not automatically mass lock each other out of super-cruise no matter how close they visually get – the process must be commander initiated
  • Ships that have a slaved FSD will be dragged out of super-cruise when they are in proximity to a slaved FSD ship that is mass locked, even if they were not targeted themselves
• Whilst in super-cruise a ship with a hyperdrive can engage a hyperspace jump to a gravity well within the system (a micro jump) or to the major gravity well of a different system (a hyperspace jump) assuming they have the fuel
• Whilst travelling in super-cruise, the effects of gravity will be accentuated, so travel is both ‘bumpy’ and any gravity well will distort the player’s direction of travel.

3.4 SUPER-CRUISE EXPERIENCE
When travelling at super-cruise the commander pilots the ship using standard controls. They can speed up, slow down, pitch, yaw and roll.

However, several aspects of the flight model are significantly reduced in efficiency; pitch, yaw and roll are much slower.

Although the ship accelerates and decelerates at incredible speeds, the range of acceleration and deceleration is such that it takes in excess of twelve minutes to reach maximum velocity. This fact combined with reduced manoeuvrability, places a greater emphasis on planning ahead.

Because super-cruise relies on the frame shift drive rather than engines, manoeuvrability and acceleration are dependent on the capabilities of the frame shift drive, as well as the ship’s construction; some vessels are inherently better suited to super-cruising than others.

When fitting a FSD/hyperdrive module, the various brands and models have different capabilities in terms of cost efficiency speed and resistance to debilitating effects.

Travelling at super-cruise distorts space-time around the ship in a manner that effectively contracts distances – though this effectively greatly increases gravitational effects too. If these speeds were achieved in normal space the accelerations of many hundreds of ‘g’ would turn the occupants into jelly. It also alters the visuals from the cockpit significantly, for example other ships travelling at super-cruise are rendered as distorted flaring lights, visible way beyond normal visible range, and other astronomical effects, like magnetic fields become accentuated too, rendering them visible in many cases.

Travelling at such speeds causes the ship’s HUD to engage a number of additional elements to help the commander correctly pilot the vessel:

• All celestial bodies and phenomena within a large distance are enhanced with AR elements, showing distances and collision warnings based on the commander’s speed
• Other ships travelling at super-cruise within a large distance are also highlighted with AR elements showing distance and direction of travel
  • The commander may target these ships as in normal flight – this is a pre-requisite for some methods of using optional technology fitted to the ship dragging down ships out of super-cruise

3.5 RISKS OF SUPER-CRUISE
Super-cruising allows a commander to theoretically fly their ship anywhere in a system under manual control. However, there are risks involved with travelling so quickly:

• Although ships cannot collide with each other, they can collide with celestial bodies and phenomena
  • Because the FSD frame-shifts at a constant rate it is possible the player is forcibly ejected from super-cruise while still at a high level of frame shift when approaching a celestial body or phenomena. This can be damaging to the ship (and its contents) – in extreme cases resulting in their destruction.
  • Manoeuvrability whilst in super-cruise is significantly less effective than under conventional drive, requiring earlier intervention to avoid collisions
  • Celestial bodies and phenomena are still present regardless of whether a commander’s system map knows about them
    • When travelling directly towards a known celestial body the ship interface will be able to provide collision course warnings
    • Flying close enough to a celestial body, phenomena or point of interest will update the system map, though this will not necessarily leave the commander enough time to react
  • Atmospheric/surface impacts will cause a ship to drop out of super-cruise – potentially causing damage or destruction to it depending on their degree of frame shift at that point.
• Although the FSD locally distorts space, effectively shrinking distances, it does not affect gravity, so the effect results in apparently massively increased gravitational forces:
  • Gravitational influence from locations is significantly extended in both range and strength, dragging the commander’s vessel off course, but also allowing skilful slingshots around massive bodies.
  • A skilled pilot is able to use gravitational effects to their advantage, skimming around locations to gain additional temporary gains to turning arcs
• Super-cruise consumes fuel; running out of fuel will cause the FSD to drop back down into conventional space, potentially leaving the vessel stranded
  • Stranded vessels can use their escape pod or begin transmitting a distress signal
• Some consumable devices can be deployed by vessels and structures that create a “net” capable of dragging super-cruise vessels down to conventional drive speed if they get too close

Sandro Sammarco wrote:

Part the Second

(Apologies in advance for low quality designer art!)

4 THE HYPERDRIVE
The hyperdrive is a module that has grid, ship class, mass and power requirements like any other module. As well as allowing a ship to travel at super-cruise, a hyperdrive also allows it to make hyperspace jumps (system-to-system) and micro-jumps (between points of interest within a system).

Whilst travelling at super-cruise a commander may execute any hyperspace jump or micro-jump they have plotted beforehand.

Separate documentation exists covering the hyperdrive, with the following additions:

• When the commander has plotted either a hyperspace jump or micro-jump destination, it will be present as an AR element in the cockpit interface
• When using a hyperspace jump to a system, the ship arrives nearby the largest mass present, normally the most dense star
• A hyperspace jump can only be initiated by a ship already at super-cruise
• A hyperspace destination can be programmed at any time (the ship does not have to be at super-cruise)
• Programming of hyperspace destinations can be done by (a) pointing at the destination object and selecting it, (b) using the galactic map and selecting an object, (c) by selecting a destination address that has been stored or sent electronically from another player and (d) by slaving the hyperdrive to another player, flying in formation.

4.1 PLOTTING A MICRO-JUMP

• The commander can directly select a known location using the cockpit interface, either before or whilst super-cruising :
  • The cockpit interface allows the commander to interrogate and select the destination by directly highlighting the location in the star field
  • Engaging the hyperdrive causes the vessel to micro-jump in a straight line directly to the location, arriving nearby at super-cruise speed
    • The destination point is calculated to be at the centre of location on the edge facing the commander (imagine a snooker cue hitting a cue ball dead centre)
    • There is some amount of arrival point fudging to maximise the chance of matchmaking with commanders already present at the location and nearby
  • Using this method it allows no control over the destination point, but it is the fastest method of quickly reaching a point of interest and does not require use of the orrery system map

Basic Jump

• The commander can use the orrery to plot a more precise micro-jump:
  • In the orrery view the commander can select a location and move a cursor over its face to pick a destination point
  • Much like aiming a snooker cue at the cue ball, the commander cannot select a destination point round the back of the location, only to a point that their ship has a direct line of sight to
  • The arrival point is still subject to some amount of fudging as required by matchmaking

Plotted Jump

• The commander can use the system map (orrery view) to plot a multi-stage micro-jump, potentially allowing them to travel to locations and destination points that they do not have direct lines of sight to
  • In the orrery view the commander can select a location and move the destination cursor to the edge of the location’s visible face
  • This triggers a slingshot corridor to be displayed – this is a three dimensional volume that curves and expands around the location
  • The commander can select a new destination point at any location that can be reached whilst staying within the limits of the slingshot corridor
  • A micro-jump can consist of as many slingshots as the vessel has fuel for

Slingshot Jump

• A micro-jump that contains slingshots is treated as a single journey; the vessel jumps to each slingshot, arriving at super-cruise, realigns for a few seconds then automatically jumps again
  • However, the game checks all slingshot points when the micro-jump is initiated and is able to determine if the ship should be dragged down to conventional drive speed during the alignment stage

4.2 PLOTTED MICRO-JUMP RISKS
When a commander plots a micro-jump there is potential for the route to become invalid:

• Various locations have orbits of different speeds
• If the commander plots a route to a location with an orbit, the route may eventually become invalid as the location moves out of alignment with the route
  • The system map interface warns of potential miss-alignment issues with a route
  • The ship will not be able to initiate a micro-jump with an invalid route

OK, so, there it is. I personally think that our revised proposal is ambitious, exciting and inclusive, offering lots of game play opportunities and really supporting the concept that space is really big as opposed to a set of corridors and boxes. It's also hopefully a real positive result of opening up the design process and getting input from the community. But who cares what I think!

Importantly, now, what do you guys and gals make of it? Does this proposal fan the fires of desire or is it too darn complex and unnecessary? Are we making the right call by mixing jumps and cruising or are we messing with balance.

Whether it's issues you can see or potential, we'd really like to hear.

Engage!

DaddyHoggy wrote:

It does put us potentially back in the "not fun" zone that Frontier and FFE suffered from, where you can run out of fuel and be stranded...

There are a few DDF members have been carrying the DDF proposals over to the Oolite forum and I have been one of them (there are a few others as well). As has been said before in this thread, this is well within the rules of the DDF, but I try to be sensitive to the general opinion. Also, there has been no attempt to hide this, but there hasn't been any attempt to advertise it either. I know it can be seen as controversial and personally I do this with a few self imposed rules.

I always wait 2-3 days before posting. (I know that this didn't happen this time)

I never carry opinions from the Oolite forum over to the DDF. Any discussion in the Oolite forum may well influence my opinion, but when I post in the DDF it's my opinion, not the "Oolite forums opinion".

I never carry the discussions in the DDF to the Oolite forum. I have on occasion posted general comments on how the discussion is developing, and also clarifications posted by the FD designers.

In addition to being within the DDF rules, I also feel that this is within FD's intentions for the DDF. One of the rules of the DDF reads:

We’re happy [FD] for you to talk about developments and conclusions made within the Design Decision Forum with people outside of it.

There are probably people that disagree with me, and I will stop doing this immediately if this causes controversy, but I will miss the, admittedly rather short, discussions we have had around DDF proposals on the Oolite forum.

I will cross post this to the relevant thread on the Oolite Forum.

Gimi wrote:

Our posting of DDF proposals here is currently being discussed on the Frontier forum.

Cody wrote:

Gimi wrote:

Our posting of DDF proposals here is currently being discussed on the Frontier forum.

Yeah, I've been reading the gripes, Gimi. If it's causing so much hassle, you might as well stop posting the agendas.