Travel time, hyperspace, etc

[impaktor]

The deeper you are in the gravity well, the closer to infinity is the spool-up time, dropping significantly as you climb out from the well.

That's an interesting idea.

How about tying fuel use to it, proportional to the gravity, apart from preciseness?

I'd say that making hyper-jumping "depend on everything" will not only make it more difficult to find a good balance for implementing how it should depend on some new variable (i.e. find good parameters for whatever function is implemented), but also make it unclearer for the player, I guess. So in this case, I suspect it would obfuscate and complicate how the player would plan jumps in the star map, if the distance (fuel usage) depends on when/where you start the drive.

The same thing goes with making it depend on hyperdrive class that was suggested in an earlier post. I think it complicates things unnecessarily. Let's just say higher class just extends the range.

A fine will be waiting for you if you get back to the system?

That's what I had in mind.

Also would a close jump cost a bit of reputation?

At the moment, no crime costs you any reputation. All characters also have "notoriety" which isn't being used at all.

[DraQ]

I fully agree with fluffyfreak, that travel should take some time. And I don't think a 3 and a half minute trip to Pluto (33 or so AU) is that excessive or boring.

Sol s far from the largest system in Pioneer, though. Multiple systems, or anything involving more massive stars is likely to be far more spread out so those 3.5 minutes may easily become hours.

• lower jump range:
  I'm all for it. Not only would it help bring back the feeling of space being big, but it would also help players make sense of their immediate stellar neighbourhood. If you have just a few stars within your jump range you can pay attention to their spatial relationships, plot out possible travel and trade routes and so on. If it's tens or hundreds then it all becomes a blur.
• In-system jumps:
  I'm all for those as not having them is arbitrary and doesn't make sense. Also, they should allow targeting any celestial body (of course keeping current inaccuracy of around 10AU) - this would also remove an arbitrary restriction and allow reaching bodies orbiting far away from stars. However they might effectively break systems up into disjoint parts as far as gameplay is concerned, for example, if there is around 10AU uncertainty there will never be a reason to go to, for example Pluto using conventional drives, because jumping will always be better. Do note that Sol isn't particularly big system by Pioneer's standards - yes, many are much smaller but quite a few are much larger. There is also the problem of fuel - with current fuel usage system in-system jumps would be effectively free. I propose an alternative system where instead of fuel and jump range cap there would be a lower limit (could be equal to current upper to make jumping a bit more fuel hungry and scooping more worthwhile) - the amount of fuel required to energize the drive. Is upper limit apart from the one dictated by the amount of fuel carried even needed? Abolishing it would help in possible cases of well isolated systems and help keep ships with poor jump performance usable even after the ranges get cut down. Range VS fuel VS time doesn't need to be a linear relationship and could make a series of short jumps more favourable than a single long one.
• L-points:
  I quite liked the L-points mechanics in IW2 and it can be explained in satisfactory manner, but having L-points as exit points as well would rob the game of random element and the feeling of being alone in space. L-points of any parent-child body pair should be included, anything else would be arbitrary, unclear in more complex systems and would screw anyone trying to travel from bodies orbiting far away. Having all traffic pass through L-Points would also make hard to justify the existence of piracy - natural chokepoints tend to be well guarded.
• Hyperspace limitations close to planets:
  Gravity seems like a good criterion and has precedents in sci-fi. I'm not particularly keen on precision based penalties as imprecise jumping is still kind of needed for good gameplay (a game of lonely space adventure not jumping from spaceport to spaceport) and fluff (precise hyperdrive makes for a terrifying weapon) and I think it would be hard to make such imprecise jumping work in terms of gameplay. Fuel consumption seems like a better idea - baseline consumption would only be possible at infinity and in L-points, everywhere else there would be some penalty based on gravitational field (it would be nice to calculate summed gravity vector of system's bodies, not just current frame). Drive efficiency could be displayed on the icon as percentage/bar assisted by colours.
  For very low altitudes and intratmospheric jumps there could be the problem with jumping requiring very precise computation and external matter getting in the way - basically, if there is measurable atmospheric pressure around the ship or anything substantial (like terrain) clips the jump bubble drawn around the ship, the bubble collapses in an unpredictable manner nuking the ship.

I would also propose:

• General hyperdrive limitations:
  Since jumping away is a bit easy way to escape danger there could be additional limitation of dropping all defensive measures and forcing ship to remain inert during countdown (no weapon fire or thrusting), explained by energy drain and need to avoid interference (at some point all but most essential equipment in the cockpit could be made to shutdown). Doing anything active or suffering weapon damage would abort jump or cause drive to misfire. It would also work as another layer of implicit jump prohibition near planetary surface - going inert while flying low would end up in a crash.
• Exhaust Velocity vs thrust throttling:
  Being able to fire main thruster at elevated exhaust velocity if set to low thrust would make all kinds of sense:
  • physically - at given power maximizing exhaust velocity allows for much higher delta-v but cuts into thrust as thrust increases with exhaust velocity but power requirements increase with its square, correspondingly increasing propellant flow allows for much higher thrust at the expense of EV.
  • in terms of gameplay - by making travel busier (less coasting more thrusting) and by making combat and orbital maneuvers use up disproportionally lot of fuel putting more weight on the interesting parts of the gameplay and making fuel relevant also in short term.
• Delta-v VS payload:
  Allowing this tradeoff would increase customization and reopen some avenues of gameplay - for example piracy via intercepts would be possible without having to tweak the mechanics or the AI in some unphysical/irrational manner as traders would likely skimp on delta-v to take more valuable cargo while pirates could load up on cheap hydrogen to chase them down. The simplest way would be reducing internal tanks to whatever is not usable cargo space in given ship (things like wings, etc.) and letting the ships auto refuel from cargo hold by default.
• Delta-v budget management:
  This is pretty much necessary if there is ever going to be more gameplay than going between ports. The simplest way I can imagine would be doing the above, then letting player "flag" their hydrogen for use or not for use by having it implemented as two distinct cargo types (for example "Hydrogen" and "Hydrogen (propellant)") that could be converted into one another in inventory screen.

Also if I remember correctly, there was some kind of local traffic script in Scout+ that didn't bothered simulating all the AI ships in the system with buying and whatnot, but generated some random (semi-random, not sure) traffic close to the player. Wouldn't something like that be useful? Like giving a range to sensors, so you can't see ships too far, simulate ships a bit beyond that range, so the player could follow them. Maybe keeping a table with ships and destinations, travel speeds, and only show them (on the sensors) when they are close enough. Does this makes sense?

Maybe precalculate ships' trajectory for most of the travel and keep updating their position without doing anything with the AI or collision detection as long as they stay away from other ships and abstract local traffic near planets and stations completely unless it happens close to the player, keeping only minimum information required to make other ships persist as long as player is in the system?

[impaktor]

L-points as exit points as well would rob the game of random element and the feeling of being alone in space

No one suggested that.

if there is around 10AU uncertainty there will never be a reason to go to, for example Pluto using conventional drives,

That's the point of in-system jumps right? You jump to the L-point, then go to the planet.

There is also the problem of fuel - with current fuel usage system in-system jumps would be effectively free.

No, because we haven't discussed this at all, so nothing here is decided. Obviously in-system jump fuel consumption cant have the same dependence on distance as for travelling inter-system, since then any in-system distance would consume 0t.

Range VS fuel VS time doesn't need to be a linear relationship

Well, it's not. time goes quadratic with distance, for instance.

and could make a series of short jumps more favourable than a single long one.

That's how interstellar jumps work now.

General hyperdrive limitations: ...explained by energy drain and need to avoid interference

Energy drain is something that remains to be implemented, and not what's currently discussed here. There are/were plans to speed up jump drives, and what-not by lowering shields, etc.

Please let's keep it simple, and at least initially implement something fast and easy:

• code to find and target L-points
• find a function for "noise" as function of distance to mass.
• find a function for how that noise will influence the count down and entry into target system

I can promise you that just doing that is a lot of work (maybe you care to help out?), and might be too much to see the finish line as it is.

[FluffyFreak]

Finding L4 and L5, or places close enough most people won't notice the difference, is really easy and I did that on Sunday night :)
L1, L2 and L3 are more complicated so unless there's a lot of demand I might not bother.

I'll need a Lagrange Point icon from nozmajner for use in SystemView and then I can have a PR ready to show them.
Though they won't do anything for the time being people can at least see where they are.

[impaktor]

Sweet!

With more L-points than L4,L5 there will be a myriad of places to jump to. I think just using the stable ones limits us (in a good way) to a few/fewer "hot-spots". Also, then you know that when you enter the system, you typically jump to the L4/L5 on the orbit of the planet you want to go to.

[FluffyFreak]

Do we want to use them to jump-to, to jump-from, or both?
I think I prefer the original suggestion of jump-from, and the ships arrival point should be a (variable?) distance out from the near-side of the destination planet.

That's more like the current hyperdrive where you are dumped into a star system on the near-side of the star from your origin point, but several AU away.
The question then becomes, how far away from the planet?

When we discussed it before I saw it working something like:

• takeoff from planet/station,
• fly to L4/L5,
• target another planet in the system to jump too,
• jump,
• arrive at some-distance from planet,
• fly to destination planet/station normally.

I would also like to add another couple of factors to using the hyperdrive, both in-system and conventionally:

• must be facing destination direction of jump, to within a few degrees not 100% of course,
• must not be jumping through planet/star/massive-body.

Those two are interlinked obviously :)
As a player you will need to know which direction your destination is in, we can show that on the HUD and once pointed in that direction it should be obvious if there's a massive great planet directly between you and your destination ;) Planets further away but still in your line-of-sight to target shouldn't matter, only those within some arbitrary gameplay judged distance should matter.

[DraQ]

No one suggested that.
...
That's the point of in-system jumps right? You jump to the L-point, then go to the planet.

Ok, I'm officially confused.

And yeah, that's the point of having better way of going between A and B, but it still would be nice to find some way to make the possibility of actually flying all the way relevant to the gameplay.
But overall the benefits do seem to outweigh the costs.

No, because we haven't discussed this at all, so nothing here is decided. Obviously in-system jump fuel consumption cant have the same dependence on distance as for travelling inter-system, since then any in-system distance would consume 0t.

Equally obviously the game mechanics should be consistent and both AUs and lys measure distance and can be translated into one another. Going with minimum fuel per jump for given drive class would allow both consistency and in-system jumps that would actually use significant amounts of fuel.

time goes quadratic with distance, for instance.

So we're all set. :)

Energy drain is something that remains to be implemented, and not what's currently discussed here.

Not as generalized mechanics (I would love to see energy and heat management, BTW) but it can still be used as explanation for other mechanics. I imagine a hyperdrive to be an energy hungry beast.

Please let's keep it simple, and at least initially implement something fast and easy:

• code to find and target L-points
• find a function for "noise" as function of distance to mass.
• find a function for how that noise will influence the count down and entry into target system

I can promise you that just doing that is a lot of work (maybe you care to help out?), and might be too much to see the finish line as it is

[/quote][/quote]
L-points could be a useful thing to have while generating systems as both natural and artificial objects could be placed there.
From another angle, if gravity is changed from single body to sum of gravity vectors, then resulting gravity vector will implicitly find L points.

As for the noise I'm still unconvinced - how much noise should it be at most? How little at least? What about players cheating the system by reloading?

Fuel consumption seems like much nicer mechanics, easier to express to the player in terms of some simple measure (like % drive effectiveness), deterministic and with a well defined floor.

[clausimu]

Do we want to use them to jump-to, to jump-from, or both?

I guess I'm getting confused now... :)

If you use L-points to jump from for in-system jumps, then wouldn't players expect the same behavior for between-system jumps?

- takeoff from planet/station
- fly to L4/L5
- target wherever you want to go (in-system or out of system)
- ...

Different game mechanics for in-system and between-system hyperjumping might kill the illusion of seamless space. But then again - I may have misunderstood...

I would also like to add another couple of factors to using the hyperdrive, both in-system and conventionally:
must be facing destination direction of jump, to within a few degrees not 100% of course,
must not be jumping through planet/star/massive-body.

I like that idea.

[FluffyFreak]

- takeoff from planet/station
- fly to L4/L5
- target wherever you want to go (in-system or out of system)
- ...

Different game mechanics for in-system and between-system hyperjumping might kill the illusion of seamless space. But then again - I may have misunderstood...

Ah yes I see, you are quite correct but my approach was just to hand-wave that away and ignore it ;) Maybe some passing reference to targeting a giant ball of fusion versus targeting an inert ball of rock 1/100000th of it's size or something.

All up to discussion of course.

Some of this is just going to have to "play out", I mean we can discuss it, and I'm implementing the L4/L5 viewing right now, but whoever implements the rest is going to have to expect testing and tweaking based on feedback in the thread & PR.

[FluffyFreak]

Ok so entertaining the "jump-to" idea for L4/L5 it would work something like:

• takeoff from planet/station,
• reach hyperspace safe distance,
• target another planets L4/L5 in system OR a different system entirely,
• jump,
• arrive at planets L4/L5 OR the usual several AU from star in another system,
• fly to destination planet/station normally.

That might be more workable actually.