超空间滑流与传感器上的幽灵 (2021-09-24)
## 超空间滑流与传感器上的幽灵
Posted September 24, 2021 by **`Alex`** in `Development`
Translated on September 25 by **`jn_xyp`**, **`Rody_`**
于2021年9月25日翻译，译者：**`jn_xyp`**, **`Rody_`**
## **摘要（译者添加）**
**本文主要介绍了下个版本将会添加的超空间滑流以及传感器上的幽灵两项内容。超空间滑流是自然生成在超空间中的条带状区域，有流向和速度，舰队在其中可达到高达40的航速，并节省50%的燃料。滑流将以每年两次的频率半随机生成。传感器上的幽灵则是出现在超空间中的不明物体，在移动时会在身后留下一条滑流尾迹，允许玩家搭便车。会有不同种类的幽灵，与探索、战斗、剧情等有关，将会极大地丰富超空间中的游戏内容。**
Technically, the next release was meant to be a “bugfixing and polish” release. It’s true that the (https://fractalsoftworks.com/2021/07/02/skill-changes-part-1/) already pushes the boundaries of that, but still, we’ve somehow ended up with some major new features, too, which will be discussed in this post. The short answer to “how did we get here” is “weeeeell, one thing led to another, and before you know it…”
按理来说，游戏的下次更新应专注于修复bug和打磨细节。虽然上次对于[技能系统的更新](https://www.fossic.org/thread-3124-1-1.html)已经破例了一次，但最终我还是给游戏添加了一些主要的新功能，并将在本文中予以介绍。你要是问为啥又开始搞新功能了，简单来说就是搞了一个就想搞另一个，然后不知不觉地就变成这样了...
I’d actually like to give a longer answer, too. The first thing I want to say, though, is that this is ok! Ultimately, it’s all stuff that was going to be in the game one way or another (though the specific form would depend on exactly how it happened), so as long as it’s added in a way that lets it fit into the existing mechanics nicely, it’s all good.
I could have held off on adding these until a later release – there’s something to be said for sticking with a plan. But also, I think it’s important to take advantage of inspiration when it strikes – and to occasionally, have some fun!
一个更为详细的回答是，我认为这样没什么问题。毕竟这些内容迟早都要加入到游戏中（尽管表现形式可能有所不同），所以只要新内容的表现形式能使其很好地融入到现有的机制中，就都没问题。
我也可以将这些内容推迟到后续的版本中，毕竟遵守开发计划有其道理所在。但我认为，抓住一闪而逝的灵感也同样重要——偶尔也得给自己找点乐子！
So, how did we get here? A little shy of two months ago, I thought to myself: “I’ve got this document about sensor ghosts laying around, I bet I could just knock these out in a week”. To be fair, I probably could have, but one of the tricky parts of gamedev is deciding how far to follow an idea. Is it something that’s not strictly necessary, or is it something that’s crucial to making the rest of it “click”? There’s a time to cut ruthlessly, and a time to follow through.
所以，这套东西是怎么搞出来的？不到两个月以前，我心想：“我已经构思好了关于‘传感器幽灵’的细节，一周之内绝对能在游戏里整出来”。讲道理，我大概的确可以做到，但游戏开发中棘手的一点，就是决定你要在一个想法上投入多少精力。有的想法可能对于游戏来说并不重要，而有的则可能是使整个游戏大放异彩的关键所在。对于前者，所需的时间可以被无情地消减；而对后者，则需付出更多的坚持。
The idea, in this case, was that I wanted a certain type of sensor ghost to leave behind it a wake that made it easy to follow. This is a big deal, mechanics-wise – it has implications for how travel in hyperspace fundamentally works! If you can take advantage of these kinds of “slipstreams” to get around faster, that’ll shape gameplay. “Sensor ghosts” without that element – they’d work, sure, and there’s plenty of other mechanics there to keep things lively (and spooky), but cutting out the “wake” idea felt like leaving something vital on the table.
So, I thought to myself, alright, wake, fluid dynamics, let’s read some papers and hack something together. A basic velocity field implementation (not “mathematically correct” in any sense, just “good enough”) looked something like this:
而这次我的想法是，在超空间中，有某种出现在传感器上的不明移动目标；为了方便玩家追踪这传感器上的幽灵，其会在其身后留下一条尾迹。这条尾迹类似于一条**滑流**：玩家可以在其中加速航行，更快地穿梭来往。从游戏机制的角度来说，这无疑会对超空间中的航行方式产生重大的影响，进而改变游戏的玩法。到头来，就算去掉所谓的“传感器幽灵”，这套**在超空间中生成滑流，以便玩家快速穿梭的机制**仍然可行，我们也可以围绕其构筑更多的游戏机制，使其更加生动（和诡异）。即便如此，丢掉“幽灵的尾迹”这一想法仍然使我感到有些遗憾。
所以，我进一步想到，尾迹这玩意应该是属于流体力学的范畴，所以我应该去看点相关的论文什么的。我做了一个简单的流速场demo，虽然不符合数学原理但看起来还凑合：
> From the cutting room floor - a fluid-dynamics-inspired visual effect. Doesn't quite "work" for various reasons - too harsh looking, iffy performance, doesn't quite suit what it's needed for, but thought it was neat enough to share!
>
> 最终未采用的样品：受流体力学启发的一个特效。看着太粗糙，性能不稳定，效果一般，不太符合最终的需求，但值得发个贴分享下！
attach://13523.mp4
It looks pretty decent in motion, but it really doesn’t look good at all in a still shot:
这个特效在运动中看起来还行，但一旦视角停止移动就显得很丑。
It’s extremely noisy and high contrast. Trying to add some antialiasing didn’t help things much. Another attempt involved rendering it using lines instead of individual points, like this:
特效看起来有很多噪点，对比度过高。尝试过添加抗锯齿效果也没有改善。在另一次尝试中，试着用线而不是点来渲染粒子，像这样：
> A variation of the same "turbulence" effect - the underlying math is just about the same as in the previous one, but it's visualized differently, with flow lines rather than particles! Also let on the cutting room floor, for various reasons.
>
> 之前“湍流”特效的一个变种：其中的粒子模拟算法没什么变化，但使用了不同的渲染方式，将之前的点渲染成了线！不过最终因为各种原因，还是没有采用这一版本。
attach://13524.mp4
This looks a bit better, but still doesn’t cut it. In particular, this doesn’t convey any sense of “enter this area to go faster”. The “curving line” particles look pretty nice, though – so, let’s keep those, and toss the fluid dynamics. Here, unfortunately, I don’t have any screenshots, but what followed was these particles going in a straight line along a wider area. That definitely had more potential – there was finally the sense of “this is an area that’ll make you go faster”, though it still needed a lot of work.
这个效果看起来好一点，但仍然没有达到要求。具体地说，这个特效完全传达不出“进入这个区域可以走的更快”的意思。不过，用曲线来渲染的粒子看起来不错。所以，我们将只保留粒子，抛弃流体动力学的部分。虽然没有截图，但接下来干的事情，就是让这种粒子在更广阔的区域中呈直线行进——虽然还有待改进，但终于制造出了“这是一个能让你走得更快的区域”的感觉。
At this point, David got involved and suggested adding some textures and borders to the thing. I also got the idea to make it support curved shapes and varying widths; honestly not sure why – it was one of those exploratory “I could probably do it, and want to see how it’d look” type of things, rather than doing it with a specific goal in mind. The sensor ghost from a few paragraphs could only travel in a straight line, so supporting curved shapes wasn’t necessary for it.
这时候，David参与了进来。他建议给滑流添加一些材质和边界。我也有了让滑流有弯曲形状和可变宽度的想法——老实说，这种尝试并没有明确的目的，仅仅是为了探索我能做到的程度和实际的视觉效果罢了。之前提到的幽灵尾迹的设计只考虑了直线运动，并不需要这种曲线形状。
One of the earlier versions looked like this:
早期的一个版本长这样：
Below is a shot of me debugging the curved version of the stream. The white curves represent the direction of the flow within the stream at any given point. Note how the curves start to get a little unsteady towards the very bottom – generating parallel curves is a difficult problem! Good enough, though. It’s important to note that this isn’t the actual geometry of the stream; that’d be way too many polygons – this is just rendering a bunch of debug data – curves, normals, and so on.
下面这张图是我在调试弯曲滑流时的画面。白色的曲线代表在滑流中任意一点的粒子流动方向。可以注意到在弧的内侧，白色曲线显得有些不稳定——生成平行的曲线确实不简单！不过这也差不多了。需要注意的是，这并不是滑流的实际几何形状，没有这么多的多边形。这只渲染了一堆调试数据，法线啊曲线啊什么的。
And here’s a shot of particles following these curves!
然后这是当粒子沿这些曲线流动的样子！
And another shot, combining particles with some textures:
另一张截图，给滑流加上了材质。
Still not great by any means – but it’s looking promising; you can see how that could turn into something good with some effort. After said effort (which included David’s key suggestion of using multiple scrolling textures), it finally came together.
无论如何仍然不是很好，但未来可期。可以预见通过更多的努力，可以获得出色的效果。经过上述的哪些努力（尤其是David关于使用多个滚动的滑流背景材质的宝贵建议），我们最终大功告成：
It’s worth noting that the “it finally came together” part, despite getting the fewest words, took at least as long as the rest of the process put together. There’s just not as much to talk about there – a lot of iteration and things incrementally looking and working better. There’s a “wobble” effect of the same type that the hyperspace background has (if you came from twitter: you’ve seen it! if not: the animation is embedded at the end of this post), and a border that makes it fit in with the deep hyperspace clouds, looking almost like a channel that cuts through it. The particles that it all started with are still there, too, just more subtle – but instrumental in showing the speed of the stream.
At this point, we had a really nice (if I do say so myself) looking slipstream, and it was a shame to waste it on something that only happened very occasionally. What happens if I just slap one of these across the entire Sector? … what happened, of course, was that the frame rate went through the floor. But it also looked very cool, so much optimizing followed (more on that, later).
提一句，这“最终大功告成”的步骤虽然只有六个字，但却花费了和之前所有步骤加起来差不多的时间。我们在背后进行了大量的迭代，每次都比上次好一点点，但这些也没什么可说的。我们添加了和超空间背景类似的“抖动”效果（发在Twitter上了，也贴在这篇文章末尾了），以及一个使其与深层超空间云相结合的边框，看起来像是在云里挖了个洞过去。粒子特效还是之前那种，但是把粒子缩的更小，而且可以显示滑流本身的速度。
现在，我们有了一个（我觉得）挺好看的滑流效果。这么好看的效果，要是仅出现在偶发事件中，那不就白瞎了吗？如果滑流可以出现在整个星域中，会怎么样呢？结果是，帧率跌破地板，但看着贼帅。有大量的优化工作要做，稍后细说。
What followed that was some thinking about what it’d take to actually make this good gameplay-wise. After all, this is a bit backwards – you don’t generally want to take something cool and just try to cram it in everywhere. On the other hand, it’s just an extension of the “ghost leaves a wake” idea; the fundamental concept of “use this to spice up (and speed up!) hyperspace travel is still the same.
So, we started with sensor ghosts, and ended up with Sector-spanning slipstreams. No problem, let’s just roll with it! It’s pretty common to start with one thing and have it not quite work, but eventually turn into something different that does.
接下来就是琢磨一下怎么把这一机制变成一个好的玩法了。毕竟，对于这种很酷的好东西，我们一般不希望把它随便到处乱塞进游戏里。但也不要忘了，这仅仅是“幽灵移动会留痕”这一想法的一个扩展；而其根本目的仍是使超空间旅行更加快捷和刺激。
所以，我们从传感器上的幽灵讲起，最后扯到了跨越整个星区的滑流？没毛病，干就完了！毕竟一件事情干着干着变成另一件也不是什么罕见的情况。
## Movement mechanics 在滑流中移动
Before looking at the bigger picture of, say, how to generate a layout of slipstreams in the Sector, it makes sense to make sure the fundamentals are in good shape – that moving through a slipstream feels good and is an interesting thing for the player to do. How does it work?
Starting with the obvious, slipstreams make fleets inside them go fast – we’re talking in the area of burn level 40, which is about double what can be achieved normally. Maximum speed is achieved near the center of the stream. Narrower sections are faster, while wider sections slow down considerably. This is all indicated by the movement of the particles in the stream, so is easy to get the hang of.
在开始讨论那些更大的话题之前，例如如何生成星区中的滑流布局之类的，必须首先确保滑流的基本功能运作良好。在滑流中移动需要足够有趣，并给玩家良好的体验。咋整呢？
最明显的一点，在滑流中的舰队会跑得更快，可以有高达40的航速，是一般情况下最高航速的两倍。处于流的中心可以跑得最快。滑流上较窄的部分流速较快，宽的部分较慢；可以通过观察粒子的流速来轻松地掌握情况。
To get the most speed, you need to stay in the middle of the stream. You have reasonable control over your fleet’s position inside the stream – but the faster the stream, the less control, as your fleet is carried along by the stronger current. Once you get to the middle, as long as the stream is going straight, it’s easy to stay there – but streams will generally curve a bit, and a narrow (and thus faster!) section combined with a sharper curve makes it hard to maintain your position – it’s much like spinning out on a turn on a race track. And much like in that case, you can prepare for an upcoming turn by getting on the inside track. You can see the slipstream on the radar, making this process easier.
要达到最高速度，舰队必须保持在滑流的中心。在滑流中航行时，玩家仍可以控制舰队的位置，但随着流速的加快，控制将会变得更加困难，因为滑流将裹挟着舰队一起流动。当你到达了滑流的中心，只要滑流不拐弯，那么保持在滑流中心并不困难。但滑流通常是弯曲的，而当滑流在变窄的同时突然转向，就会很难继续停留在中心，像是开赛车转弯一样。在这种情况下，你可以预先靠向弯道内侧来准备过弯。滑流的形状会显示在雷达上，应该会让这一过程简单一些。
In addition, several active abilities interact with slipstream movement. “Emergency Burn” boosts your acceleration, and lets you get around within the stream more easily – and its speed bonus gets added to your maximum speed, too. Saving an e-burn for a tight turn can be a really good idea. “Sustained Burn”, on the other hand, comes with a hefty penalty to acceleration – but its speed bonus can be handy, too. It’s useful in the calmer, wide stretches – or in straightaways. It’s also useful when there’s a break in the slipstream – engaging Sustained Burn inside a stream doesn’t stop your fleet like it would in normal space, and it can be a nice way to keep some momentum going before re-entering the stream.
除此以外，几项主动技能也可以影响在滑流中的移动。“紧急加速”可以让舰队更快地被滑流加速，并降低在其中移动的难度。紧急加速提供的额外速度也会叠加到加速后的速度上。可以考虑留着“紧急加速”技能来应付滑流中的急转弯。另一方面，“持续加速”技能则会降低舰队的加速度，但在沿着宽而直的滑流前行时，其提高的航速上限仍然有用。在滑流中开启“持续加速”时，你的舰队并不会像在外面一样停下来；而在经过滑流中间的断点时，持续加速也可以保留一定的动能以便再入。
Overall, I think that provides enough options and considerations to stay engaged. And besides, going really fast is just fun! And that brings us to another point.
(Oh, and worth noting: being inside a slipstream takes precedence over any other terrain your fleet might be in. So, for example, the bonuses/penalties from being in deep hyperspace, or in a storm, and so on, do not apply.)
## Fuel use 燃料消耗
Flying through a slipstream is fun – so we need to be really, really careful to make sure it’s definitely worth doing. No matter how we lay these out as far as the overall map of the Sector, it’s going to be rare that “through a slipstream” is the shortest way to get where the player needs to go, purely in terms of distance. And the player won’t even know exactly where the stream they’re in is going, most of the time! (More on that, later, too.)
One thing helping here is an existing mechanic – going at a speed above burn level 20 doesn’t cost extra fuel. For example, going at burn level 40, covering the same distance costs half the fuel that you’d spend covering it at burn 20. By itself, though, that isn’t enough – when you factor in the detours required to get to and from the stream, it’s often unclear whether taking a stream results in a fuel savings.
在滑流里航行很爽 — 所以我们需要小心翼翼地确保这样做是物有所值的。无论这些滑流在星域地图的什么地方，如果单纯从航行距离方面考虑，它们都不太可能是你到目的地的最短路径。此外，玩家们大部分时候甚至并不清楚他们身处的滑流到底通向何方！（后面还会提到这个的。）
好消息是，一项现存的游戏机制对此会有些帮助——大地图航速超过20后，并不会消耗额外的燃料。举例来说，如果你以40航速航行，那么此时消耗同样的燃料就可以达到20航速时两倍的距离。但这样仍然不够吸引人——考虑到进入和退出滑流时都需要绕些远路，使用滑流是否能节省燃料仍然值得商榷。
Therefore: traveling through a slipstream provides an additional 50% fuel use reduction. This way, it’s going to be “worth it” for any halfway-reasonable set of detours – if taking a stream looks at all like it might be faster, it’ll also definitely be cheaper.
因此，我们添加了这一设定：在滑流的舰队将额外减少50%燃料的消耗。这样一来，即使玩家需要绕不少远路，滑流也应当是‘值得’的了——如果走滑流看上去会快那么一点，那么也一定会更省油。
## Slipstream layout generation 滑流布局生成
With these lower-level mechanics squared away, the big remaining task was to figure out how a big a role slipstreams play in hyperspace travel overall, and how to generate the slipstream layout for the Sector.
在搞定这些小细节后，接下来的主要任务，就是确定滑流在整个超空间旅行中的作用有多大，并决定滑流在星域中的生成布局。
To answer the first question, I don’t think slipstream travel should be something you *always* do – it should be frequent, but it should leave ample room for travel through regular hyperspace. It should be possible to be in deep hyper and not know where the nearest slipstream is. Finding one should be an exciting opportunity. This is largely a subjective feel issue, so it’s not something that’s objectively “right”, but that’s the design goal.
As far as generating a slipstream layout – I think here I’ll just talk about how it works and what effect that has/is intended to have, rather than talking about how it got there. So! First off, slipstreams are dynamic – there isn’t a single fixed layout. Instead, a new layout is generated twice per cycle, and the player only sees as much of the slipstream system on the map as they’ve explored – though unlike with sensors, merely getting near enough for it to show up on your radar is sufficient to “see” it and have it be remembered on the map.
对于第一个问题，我不认为滑流应当成为超空间旅行的*最优*选择——玩家会经常使用滑流来穿梭，但传统的航行方式仍有一席之地。处于超空间中时，找到最近的滑流并不总是轻而易举；而发现一条新的滑流则应当是一种难得的机会。虽然这些说法很大程度上取决于玩家的主观感受，并没有一个客观的标准，但这仍是我们的设计目的。
至于如何生成滑流的布局，这里我就只讲一下设计目的和最终的实现效果，不再细说具体的迭代过程了。滑流的生成是动态的，没有一个固定的布局。在每个星历年中，滑流的布局会刷新两次。玩家在地图上只能看到已经被探索过的滑流——但与传感器上的物体不同，只要接近到足以让滑流显示在雷达上，这条滑流就会被记录在地图上了。
Here’s what the player might see after exploring a bit of it:
这是玩家在探索过滑流后显示在地图上的样子：
And here’s what a full (different) layout might look like:
然后这是星域中滑流的整体布局：
These layouts are not fully procedurally generated, rather there is a pool of hand-crafted layouts which are then randomized slightly. Initially, I’d thought to generate these entirely with code, but it proved surprisingly difficult to produce nice layouts. For example, you don’t want slipstreams intersecting at a shallow angle – it becomes a mess!, and you also *do* want intersections at specific points along their lengths (where these offer more interesting choices about where to go, when the player comes to one). Hand-crafting a bunch of possible layouts was both faster and produced better results.
Combining the layout being dynamic with it also being picked from a pool of possible options means that 1) there’s an important aspect of the hyperspace map that keeps changing and is there to be discovered/explored, but 2) that it’s also learnable, and you can make inferences about what the rest of the slipstream system looks like after discovering and recognizing a portion of it. To keep things fresh, some of the handcrafted layouts have a much higher randomization factor, and can’t be relied on in the same way.
这些布局并不是完全由程序生成的，而是从一个手工制作的布局池中抽取，然后经过随机化的样子。一开始我其实是想完全用程序来生成的，但事实证明自动生成漂亮的布局十分困难。例如，自动生成的滑流可能会以小夹角相交，导致相交处一片混乱！并且，为了给玩家提供更有趣的路径选择，我们通常希望两条滑流在其特定的长度位置上相交。手工制作一堆布局模板不仅更快，效果也更好。
使用这种随机选择固定布局模板+随机微调的机制意味着：（1）超空间环境不再一成不变，可以让玩家不断地探索和发现，不过（2）也并不是完全没有规律可言。在探索了滑流的一部分后，你就可以根据模板的规律来推断其剩余部分的走势。为了保持新鲜感，某些布局在应用时叠加了更高的随机变化，所以这种推断并不总是可靠。
To aid in the task of mapping the slipstream system, the Neutrino Detector active ability now functions in hyperspace, and instead of detecting other fleets and similar entities, detects slipstreams instead – out to a distance of 10 light years.
为了帮助玩家绘制滑流的走势，“中微子探测器”可以在超空间中启用了，但并不是去探测舰队和类似的实体，而是可以探测十光年内的滑流。
And, finally, a big feature of the system is that the general flow direction of the streams is seasonal. In the first half of the cycle, they tend to flow to the galactic east (which is like the regular east, but in hyperspace), while in the second half of the cycle, they generally flow west. This is another thing that the player can learn and plan their expeditions around.
One might ask, “but why is slipstream flow synchronized with the Domain cycle, which is an arbitrary human construct?”. I could say that the wizard did it. Or, perhaps, that it’s a good question with terrible implications. But, instead – let’s just say that this isn’t a fixed state of affairs, but at the current time in the Sector, two otherwise independent cycles have conveniently lined up.
最后，滑流系统的一大特性就是季节性的流向变化。在上半个星域年，生成的滑流倾向于流向星域东部（上北下南左西右东的东，但是是在超空间里）在下半年，滑流则会向西流动。这是玩家在探险时可以掌握的另一条规律。
有人也许会问，“为什么滑流的变化周期会与星历年这一人造概念同步呢？”。我可以简单地说不知道，毕竟这确实是一个影响设定的大问题。但在这里，我会说滑流的周期并不是固定的，但在目前星域中的这个时间点，它正好和星历年同步了而已。
## Encounters 遭遇战
One of the design principles of Starsector is that mechanics in the campaign should, generally speaking, funnel the player towards combat. This isn’t a hard and fast rule, there are exceptions, and the degree to which one feature or another might do that can vary – but still, it’s something to use as a guide.
With the above in mind, we could just say that slipstreams let you travel faster and lead the player towards combat simply by virtue of getting them around faster. And that’d be fine! But I think there’s potential here to do better.
《远行星号》的设计原则之一，就是通常来说，生涯模式中的各种机制，应当引导玩家进行战斗。这并不是一个硬性的规定，有很多例外，而且每种机制对玩家的引战程度也有所不同。但总体上，这仍然可以作为一条指导原则。
从这个原则的角度来说，我们可以说滑流通过让玩家方便地跑来跑去的方式来鼓励玩家出门打架。确实，但我觉得我们可以在这方面再进一步。
One important bit of information is that slipstreams are interrupted when crossing hyperspace areas occupied by star systems. Otherwise it just looks odd, with the slipstream covering up jump-points – and trying to route streams around star systems would be too involved, never mind that there wouldn’t always be a clear path. In a fortunate turn of events, these stream breaks make for a perfect spot for an ambush!
Imagine: you’re cruising along at burn 40, switch over to Sustained Burn to cover the break more quickly, when your sensors officer reports hostiles coming in, weapons hot. Maybe you should’ve gone dark instead.
滑流的一大特点，就是在其穿越恒星系所在的超空间区域时，会发生中断。毕竟如果滑流直接覆盖在跳跃点上就太奇怪了，而且让滑流绕开恒星系实现起来也很麻烦，更不用说也不一定有条清晰的路能绕开。但这一设计，让滑流的断点成为了布阵伏击的理想场所！
想象一下：当你正以40的航速沿着滑流飙车，并打开了“持续加速”来穿过前面的滑流断点，结果你的副官忽然报告检测到敌军舰队信号，且对方的武器已经预热时，你可能就会后悔没提前开“匿踪”了。
This sort of encounter isn’t completely random – rather, it happens if there’s a pirate base nearby. Or a Luddic Path base. Or a system with ruins. And you won’t always encounter hostiles; sometimes you might encounter mercenaries or scavengers instead. So it’s both a potential combat encounter, and a source of information for a more observant player – information that could lead into yet more combat, if they so choose. And, importantly, it’s something that can be predicted to some degree – for example, you can be more careful if you know there’s a pirate base nearby.
这种遭遇战的发生并不是完全随机的——相反，只有当附近的星系中有海盗、卢德左径或余晖基地时，这种情况才会出现。而且你可能遇见的也不全都是敌人；有时也可能遇见雇佣兵或拾荒者。因此，这种遭遇既可能是一场战斗的开端，也可以是更加细心玩家的信息来源。当然，所提供的信息也可能让玩家参与更多的战斗。重点是，这种遭遇是可以预测的——例如当附近存在海盗基地时，你就应当更加谨慎地穿过断点。
(This “encounter point” system is flexible, and isn’t limited to slipstreams. For example, Remnant stations will now send occasional patrols into hyperspace, provided the player has made a disturbance in their system.)
（这种“埋伏点”的设计十分灵活，并不止会在滑流断点处出现。例如，如果你在某处余晖星系大闹一番，那么余晖空间站偶尔就会派遣巡逻队到跳跃点附近的超空间里。
## Performance 性能
I’m not going to dig too deeply into the various optimizations required to make these run smoothly when scaled up from the original use case of “one small slipstream now and again” to “Sector-spanning network”. Mainly those were about not doing things – not generating particles unless the player is close, not recomputing certain data for segments unless they’re visible, and so on. What I wanted to show here is this screenshot, because I think it looks neat:
从“一股一股的滑流尾迹”到现在横贯星域的滑流网络，我并不会太深入地讨论使其正常运行所需的各种优化。所谓的优化主要在于去尽量少做一些事——例如，除非玩家靠近，否则不生成粒子；除非某段滑流在屏幕上可见，否则不计算片段的某些数据等等。
What it shows is how the game generates a bounding box for a slipstream. Taking a step back, the game often needs to know “is this fleet (or derelict ship, etc) inside a slipstream?” We could check every segment in the stream to see if it contains the entity, but that gets computationally expensive – there are a lot of slipstreams with a lot of segments, and potentially a lot of entities to check, too.
这张图上展示的，是游戏为一段滑流所生成的碰撞边界。一个基本的问题是，游戏经常需要检查“舰队（或遗弃舰等等）是否位于滑流内部？”我们可以依次遍历滑流上的每一段，并检查其是否包含该实体，但这样的性能消耗会非常大——会有很多的滑流和更多的滑流片段，以及大量的实体需要检查。
Instead, a typical approach to this sort of problem is to say “is this entity close enough to bother checking?” If not, we don’t need to do a detailed check, and that saves a lot of computation time. This works pretty well for most things, but for a Sector-wide stream, the answer to “is this entity close enough to it to check” is always “yes”, at least if we’re doing a simple distance check, which can be thought of as “is this point within a circle that contains the stream?”. The entire freakin’ Sector is in that circle.
一种典型的解决方法，是预先检查“该实体是否足够接近，值得进行碰撞检测？”如果不是，则没必要进行复杂的碰撞计算，并节省许多的计算时间。这种方法通常非常有效，但对于滑流这样一个跨越整个星系的实体，进行“该实体是否足够接近”检查的结果一直为“是”；因为如果画一个能把整个滑流包括在内的圆形，那么实体所在的点几乎总是在这个圈里——整个该死的星域都特么的在这个圈里。
So a bounding circle isn’t good enough, but a bounding box around the slipstream is, especially if the stream is relatively straight, since the bounding box will have a much, much smaller area. In the screenshot above, the edges of the stream’s segments are in yellow, a “convex hull” (just a polygon, really – computing this is a required intermediate step) containing all of the stream is in white, and the final bounding box – with a bit of padding – is in cyan. One thing to note is that every tenth segment is artificially widened; this is done so that the convex hull has less points in it, which speeds up the bounding box calculation.
For a slipstream that curves around a lot, this approach doesn’t help as much – the box gets a lot bigger and there’s a lot of empty space inside it, which means more unnecessary checks when entities are inside it but not inside the stream. As a further optimization, each stream is split into a bunch of subsections, each of which has a bounding box calculated for it – so, just imagine the same thing as in the screenshot above, but chained together following the shape of a longer stream. This hugs the shape of the stream closely, so we’re going to be able to rule out a lot of potential checks!
所以使用简单的圆形边界并不可行，但矩形的碰撞边界则可以做到，因为对于相对来说较为平直的滑流，矩形外框内的面积要比圆形小得多。在上面的图中，黄色圆点为滑流的边界点；白的的“凸包”（就是个多边形，是计算边界框的中间产物）包裹了整个滑流；而最外侧的青色边框，则是最终的矩形碰撞边界，在内测额外添加了一些边距。值得注意的是，在滑流上，每经过十个边界点，就会有两个点被人为地加宽出来；这样做是为了减少计算凸包时需要考虑的点的数量，以加速碰撞边界的计算。
对于更加弯曲的滑流，这种方法的优势则会减弱。因为弯曲滑流的矩形外框内会包含更多的空白空间，意味着当实体进入外框但尚未进入滑流时，会执行许多不必要的检查。为了进一步进行优化，每个滑流会被切分为一系列滑流片段，每个片段都会生成独立的碰撞边界。你可以想象一下和上图差不多的情况，只不过会有许多个滑流片段首尾相接形成更长的滑流。这样一来，滑流就会被矩形边框紧密地包裹起来，减少了大量不必要的计算。
## Sensor ghosts 传感器上的幽灵
And now, we’ve come around full circle – back to the sensor ghosts that started it all. There’s now, indeed, a type of ghost that leaves a slipstream behind – but instead of being the only means of producing slipstreams, it’s instead a supplement to the main slipstream network, to be used when it happens to be going in the right direction – and when the player is quick enough to be able to hitch a ride. There’s another type, that’s fairly similar but starts off stationary, and can be herded in a specific direction by the player – needless to say, very handy if you happen to find one.
转了一圈，我们又回到了最初提到的“传感器上的幽灵”本身。在下个版本中，确实会有某种在其后留下滑流尾迹的幽灵。但幽灵的尾迹仅仅是作为对天然形成滑流网络的补充，而不是生成滑流的主要方式。如果幽灵正好朝着玩家想去的方向行进，反应快的玩家就可以搭一程便车。还有另一种十分相似的幽灵，但起初是静止不动的，可以被玩家驱使着前往特定方向——不用说，如果能碰巧找到一个，对于旅行来说是再方便不过了。
As for other sensor ghosts, it’s the sort of thing where figuring things out (or not, as the case may be) is half the fun, and I don’t want to spoil it. Let’s just say that there are many different kinds, with tie-ins into exploration, combat, certain story elements, dire implications, and several non-obvious (and entirely, intentionally unexplained) interactions with some of the active abilities.
All in all, these additions should do a lot to liven up hyperspace – which it could really use. Almost more importantly, though, they should also strengthen other aspects of the game, because of the tie-ins with abilities and combat encounters.
对于其它种类的幽灵，一旦明白了（或者不明白，视情况而定）它们是怎么回事，带来的乐趣就会减少很多，而我在这里也无意剧透。我只能说会有很多不同的种类，与探索、战斗、特定的剧情元素、可怕的暗示有关；还可能与某些主动技能产生一些不明显（且动机不明）的互动。
总而言之，这些内容的添加一档可以极大地丰富超空间部分的内容。更加重要的是，因为这些内容与主动能力和遭遇战的紧密联系，其应当也会帮助增强游戏的其他方面。
In case you’re not coming to the blog from twitter, by the way, here’s what the slipstream animation looks like in action:
如果你不是从Twitter上点进来的，这是滑流动画实际的效果：
> New Starsector blog post! "Of Slipstreams and Sensor Ghosts"
>
> https://fractalsoftworks.com/202 ... -and-sensor-ghosts/
>
> Livening up hyperspace!
>
> 新的更新日志！"超空间滑流与传感器上的幽灵"
>
> https://fractalsoftworks.com/202 ... -and-sensor-ghosts/
>
> 让超空间更加生机勃勃！
attach://13525.mp4
*If you click on the blog post link in the above tweet and get caught in an infinite loop re-reading this post, I will not be held responsible. I will however be amused.
*如果你点了上面推文里的博客文章链接并进入读这篇文章的无限循环，我对此并不负责。但我会很开心的。
: https://fractalsoftworks.com/202 ... -and-sensor-ghosts/
好耶！ Jn，我的超人 {:tieba_43:}好耶 JN~我的高性能机器人~好耶~！ 好耶！ 好耶~ 好耶！
哈，终于可以英仙座逮虾户了，感觉有人拿这个做mod整活应该会很爽。{:5_118:} {:5_132:}等一个超空间生物 《远行星号》的设计原则之一，就是通常来说，生涯模式中的各种机制，应当引导玩家进行战斗。这并不是一个硬性的规定，有很多例外，而且每种机制对玩家的引战程度也有所不同。但总体上，这仍然可以作为一条指导原则。
One of the design principles of Starsector is that mechanics in the campaign should, generally speaking, funnel the player towards combat. This isn’t a hard and fast rule, there are exceptions, and the degree to which one feature or another might do that can vary – but still, it’s something to use as a guide.
这大概是Alex的开发思路，它不想把开发重点放在舰队与领土运营这些其他游戏都做的非常好的内容上，而是做自己的特色，鼓励玩家多去探索游戏机制。 逆着滑流走会减速吗？{:5_124:} 龟龟坐锅观天 发表于 2021-9-28 08:57
等一个超空间生物
超空间蠕虫{:5_136:} 新来的萌新 发表于 2021-9-28 15:39
超空间蠕虫
英仙座：惊世浩劫{:5_118:} 宇宙的肠道 新来的萌新 发表于 2021-9-28 15:38
逆着滑流走会减速吗？
估计会，如果滑流会产生相当于20航速的推力的话 总感觉像是不明巨型蠕虫（） 等议长出一个超空间舰队，欸嘿嘿 之前reddit上看到这篇leak的时候下面有网友回答：
“感觉就像在探索星区的直肠一样”
草 好耶！ 说实话这滑流的外观看起来不太像是某种流动的介质或者是通道，反而像是一条蠕虫或者是肠道。
我真觉得alex应该给这玩意换个外观。 之前版本的超空间确实太过安静了。
就该来点这种神秘而伟大的生物，哪怕是敌对野怪都没关系{:tieba_12:} 蟋蟀 发表于 2021-10-23 12:32
之前版本的超空间确实太过安静了。
就该来点这种神秘而伟大的生物，哪怕是敌对野怪都没关系 ...
这个想法好棒! 蟋蟀 发表于 2021-10-23 12:32
之前版本的超空间确实太过安静了。
就该来点这种神秘而伟大的生物，哪怕是敌对野怪都没关系 ...
以后做mod可以参考群星的{:5_124:} 这个滑流搭便车风险相当的高
出来就是一组余辉\拾荒者，迎头撞上跑都跑不掉
相对于比较大的舰队搭搭便车还不错，小探索舰队还是别搭便车了 所以才说如果打得过的话，那么他们就是过来送菜的，我已经想象到那种场景了，辛辛苦苦蹲了大半年，一出头发现别人比你还强，而且因为对面车速太快你还躲不开，虽然我知道是人机但还是好开心，怎么办我突然感觉我好坏
页:
[1]