Let’s talk about the options the player has for moving around the Sector! For a long time, the set of movement mechanics has been incomplete, with additions made here and there (slipstreams, unlocking the use of the Gates), but still lacking some of the options that in my mind would make up the final picture. Perhaps “final” isn’t the right word – things will certainly be tweaked as necessary – but it’s about having a more complete set to tweak, rather than what has been, until now, a partial implementation.

The overall goal is to … well, of course it’s to make moving around the Sector more fun, though that’s a given and doesn’t actually say much. In practical terms, this means giving the player more options, and making those the kind of options that ask the player to make some decisions.

Let’s start with a quick recap of the current movement mechanics.

Just Flying There. Yep, that’s the basic one; terrain factors in here, as does fuel use. Can be a bit of a slog for longer trips, and this is the baseline we’d like other mechanics to play off of. It’s important to keep some of it, though, if only for contrast with the other mechanics. If the player could instantly teleport anywhere, all sense of scale would be gone.

Slipstreams. Very fuel efficient and fast – if you’re lucky enough to find one going in the right direction, which you’re often not. Also function as an obstacle if they’re going across your path; not their main goal but anything that gives the topology of hyperspace more meaning is a positive. Easy to cross with an Emergency Burn, but that has a cost. As of the previous release, there are new options for detecting slipstreams in a wider area (around your colonies, or near sensor arrays), making it more likely you’d be in position to use one.

Activating the Gate system. Allows instant travel between systems that have gates, which is a fairly small fraction, but they’re well spread out. Fairly fuel efficient, but still does have a hefty fuel cost – it’s just low enough that you’re not tempted to fly there instead. The gates become usable later in a campaign; I think it’s nice to have some of the travel-related options become available over time, so there’s a feeling of progress and the relative freedom of movement by the end feels more satisfying.

With this in mind, let’s dive into the new stuff!

Reverse Polarity
This is a new toggle ability that makes your fleet go in the opposite direction when inside slipstreams, a little slower than usual. It’s unlocked by progress in the Hyperspace Topography “event” – scanning  various interesting stellar phenomena and the like.

The main point here is pretty simple – having this ability doubles the odds that a slipstream is useful, making them very good indeed. With the fuel cost reduction of slipstreams, even one going vaguely in the direction you want is going to be handy.

The design process was not without its difficulties, though. One immediate consequence of the initial design was that slipstreams stopped being an obstacle; this is undesirable both because it makes the topography more same-y (i.e. slipstreams cease to matter as obstacles), and because it steps on the toes of Emergency Burn, making that ability less useful.

For clarity, the process for slipstream-crossing would be to 1) start the crossing and 2) reverse polarity midway through and be carried back to where you started by the time you finish going across.

I tried several things to deal with this. The first was making the ability take some time to activate; this doesn’t work because it can be timed correctly anyway, and it also makes the ability feel less responsive. Another idea was giving it an activation cost – that certain solves the “too easy to cross” problem, but introduces an annoying calculation for travel – is it worth the cost? Ideally we’d just want it to be clearly useful if it’ll let you go in the direction you want, without needing to worry about costs.

The eventual solution was to keep it as a toggle ability, and to give it a cost for both activating and deactivating, but *only when already inside a slipstream*. So if you want to travel along a stream, just activate it before you dive in, and it’s free. If you change your mind midway through, then it has a cost, so it’s not as appealing of an option. This makes a lot of in-fiction sense, too; one can imagine that messing with the drive field’s polarity while already in a high-velocity slipstream is a more difficult proposition. And the ability has a low cooldown and activation time, nice and responsive – all of the design goals are met!

To make sure you can tell whether it’s on or off without looking at the ability bar, when its on, your fleet’s engine flows and trails are shifted towards purple – the color commonly used by the game to indicate that some kind of high-tech shenanigans are going on.

In the context of asking the player to make decisions, whether to use this ability or not isn’t much of one – if you want to use a slipstream going against its current then yes, otherwise no. Rather, the decision is about whether a particular slipstream will be beneficial to you, and this is a factor that makes this decision more interesting – and, importantly, makes the answer be “yes” much more frequently.

Generate Slipsurge
I have to admit, one of the first things I did after implementing slipstreams is try making short and really, really, really powerful ones. No, more powerful than that. It’s just what you do! You add a new mechanic, and then you crank it up to eleven… thousand or so, just to see what happens. In this case, the answer was “it’ll shoot your fleet out like a bullet”. Fun, but clearly something that breaks various game rules so badly would be an irresponsible thing to add to the game. Right? Weeeeell, yes and no. Or rather: yes, but also no, we’re doing it.

Enter the “Generate Slipsurge” ability – you guessed it, it generates a short and really, really (etc) powerful slipstream. Also unlocked by increasing Hyperspace Topography progress, it only works in hyperspace, and requires a nearby gravity well – for example, a star or a gas giant. The slipsurge points away from the well, and its power depends on the object that’s at the bottom of that well. This accomplishes a couple of things:

1. The question of “how do you aim the surge” is solved. The game doesn’t generally support a “use a campaign ability then select a target for it” type of interaction. Not that it couldn’t but it seems like that could get really fiddly, and now we don’t need to worry about it.
2. The layout of stars on the map now matters for movement. For example, you might identify a series of black holes about the right distance apart for you to be able to chain together slipsurges for a faster journey.

So how *is* slipsurge strength determined? An obvious answer would be for more massive objects to generate stronger surges. That makes a ton of sense, and we’ll stick to that – but only kind of. The emphasis has to be on making it clear to the player what to expect, and actual star/black hole masses and so on are quite messy. A star in one class can mass more or less than the star in another, or indeed more than a black hole. It’s a mess! Rude of nature to be so inconsistent, really.

So instead of an approach grounded in science, we’ll go for one grounded in truthiness – what feels right. Unless you’re an astronomer; in which case my apologies. As a nod to science, the game does say that the surge strength depends on the object’s “mass, density, and other poorly understood factors”, so at least it’s not claiming that it’s based on just mass. The ranking is, roughly:

• Black holes, neutron stars
• Supergiant stars
• Giants stars
• “Regular” stars (i.e. not one of the other types)
• Dwarf stars
• Gas giants

This feels like something that’s pretty easy to internalize, hopefully you won’t need to keep checking the tooltip for too long.

A few other points that came up while implementing this:

It felt pretty strange for the fleet to be going this fast (up to burn level 900+, where the normal maximum is 20) if it had its selection circle showing. I think it’s because the circle makes the fleet feel a bit like a UI element, and it just felt like the UI going wild. The solution was to 1) fade the selection circle out during this fast movement, and 2) to add a shimmering/jittering effect to the ships, with a bit of a trail, to really sell the feeling of speed and power. A sound effect to help this along is also in the works.

It’d be nice to be able to control the distance you travel, at least a little – so, using the “go slow” control (default: S) will very rapidly slow the fleet down. It’s not fine-grained by any means, since you can travel up to 15 light years in just a few seconds, but it can make a difference of a few light-years to how on-target you are.

Your fleet can’t be interacted with during this transit – i.e. if you fly through a pirate fleet, you won’t all of a sudden end up in a fight while ostensibly going at 900 burn. Your fleet’s sensor range is also reduced; not a big deal, but that feels right.

Traveling fast in hyperspace grants you points in the “Hyperspace Topography” event (mentioned earlier in the post), and what would happen is you’d get the notification about gaining those points while mid-transit. It really ruined the moment – here’s something cool happening, and then game chimes in with a “you gained some points!!!” notification. No good. So: the notification won’t happen during transit, and is delayed until a few seconds after it’s over.

And, finally, hyperspace storms – hyperspace is pretty big, and for performance reasons, the game only simulates storms in the area around the player. But when the player breaks expectations and travels faster then the game assumed was possible – you’d see the point where the storms end pretty clearly, and you’d see them slowly start to wind up. To fix this, when the ability is activated, the game will – for a few seconds – fast-forward the storm simulation in a larger radius.

As you can see, there’s quite a bit going on under the hood to try to make something like this work cleanly!

Ability slots
With two new abilities, there’s a bit of a problem – the set of abilities the player is generally expected to have no longer fits on one ability bar. On the one hand, that’s why there are multiple ability bars. On the other hand, switching between bars can be a pain, and these new abilities are only useable in hyperspace, so it seems like there’s room to make improvements.

So: the idea is that for each slot, you can configure it to switch to a different ability when the fleet is in hyperspace. “Scavenge” and “Distress Call” are good candidates to do this with, since they are only useful in normal space. To streamline the process, when you unlock the new abilities, “Reverse Polarity” is automatically slotted as the hyperspace alternate for “Scavenge”, and “Generate Slipsurge” is slotted in as the alternate for “Distress Call”. This also makes sure that new players, who might not be super aware of how slotting abilities works in the first place, benefit from the feature.

If we added more abilities down the line, there’d still be a problem, though. I’m considering whether to bring back the default keybindings of Q and W for the first two ability bars – it makes switching between them an absolute breeze. The problem with this was that some players would hit Q or W by accident, end up with an empty ability bar (especially fun during in the tutorial), and be confused. So the question is exactly how to handle this; the concept of switching bars needs to be introduced at some point.

Perhaps a tutorial note for it would be enough. Or perhaps a “hey, you’re on the second bar and it’s empty, here’s what happened” help popup would do the trick. Either way, this seems like a solvable problem, but definitely something to watch out for.

Wormholes
There will be some spoilers from this section onward. I’ll try to keep them light, but: be warned!

The goal here is to let the player connect any two points in the Sector – it’s very powerful bit of customization for the playthrough, but limiting the number of wormholes helps keep the other  travel options relevant.

The way it works is there are two “Wormhole Anchor” items to be found. They can each be deployed at a stable location, to create a “Wormhole Terminus”; the anchor can be retrieved from the terminus at any time, closing it. Visually, the wormhole is like a larger, more intense jump-point.

When first deployed, the wormhole is unstable and unusable for an in-game year – otherwise, the optimal way to go about it would be to deploy one anchor at a colony, and carry the other one around with you, using it as a town portal scroll, and making all of the other travel mechanics fairly obsolete. The point of these is to make a fairly static bridge, not something dynamic.

Using the wormhole requires a “Wormhole Scanner” item. Primarily, this is to explain why these are only used by the player’s fleet. If other fleets can use them, they become potentially very disruptive to the Sector’s status quo in ways it would feel strange not to at least acknowledge. Not that it’s necessarily a bad idea (it might or might not be), but more importantly it’s very much not the point of this addition, and the resulting implications spiral out quickly in terms of the extra work required. Thus: wormhole scanner.

While there are only two wormhole anchors in vanilla, under the hood, the game supports a larger number of these, potentially in separate networks – that was not very complicated to code, and I figured it might be useful for a mod.

Gates
And, finally, the player will have the ability to put a gate into a system of their choosing. To do this, they’ll need to [COMSEC REDACTED, AGENTS DISPATCHED].

Abyssal hyperspace
This is technically not directly related to the new movement mechanics, so why talk about it here? Well, it’s sort of related (for reasons best avoided due to spoilers) and also I think it’s neat and want to talk about it.

So! You might have noticed the “Orion-Perseus Abyss” label in the lower left corner of the Sector map; it’s been there for a *long* time. Now, finally, it’s more than just a label – the area in the lower left corner of the map is “abyssal” hyperspace. Which means what, exactly?

Movement is 4x slower, and sensor/detection ranges are reduced by a like amount – basically, it’s as if the area was 4x larger, without it actually being that. Utilizing the map space more efficiently!

It’s very, very dark. As you get deeper into the abyss, the background fades out, and so do the other things you might normally see such as the deep hyperspace clouds outside it.

Gravity wells and jump-points are only visible at close range, though star gravity wells are visible as normal – you can see them on the map, anyway.

Other fleets mostly try to avoid it.

There are things inside.

Also, there is now abyssal hyperspace all around the Sector, beyond the edges of the map. It isn’t necessarily canon that the Sector is surrounded by abyssal hyperspace – the Abyss is canon, of course, but the rest of it is just a more satisfying way of having a map border. Or perhaps more than that? We’ll see. This is pretty clearly an area that could have a lot more content added to it.

 

Comment thread here.

 

 

Tags: abilities, ability, abyss, campaign, hyperspace, movement, slipstreams