Felipe Falanghe在开发一周年回顾Kerbal太空计划最早的故事

Cesrate

　　感谢小薑一隻分享了HarvesteR在tumblr的Dev Blog。

　　原文来自
　　http://kerbalspace.tumblr.com/page/12
　　及之后的4个Posts

　　文/ Felipe Falanghe（亦称HarvesteR）
　　译/ Cesrate

KSP一周年！
　　2011年1月17日，是Kerbal太空计划（KSP）正式启动的日期。这个项目在这之前已经确立了，但这是第一行代码被写下的日子。
　　我想一整年的开发是值得庆祝的，在这时也应该花点时间来看看KSP在这一年走了多远。
　　给你看看游戏最初最初版本的一张截图：

　　这是我们做出的最初样本，仅仅是为了证明这个计划可行。你既不能控制火箭也不能控制视角。几个设定好的常量使得火箭可以起飞，而连接点（是的，那时候已经有连接点了）被小心地设计使得它们会在火箭仍在场景内时断掉（译注：KSP的传统在那时就确定了……）。
　　你所看到的地面只是一个绿色的平面，而天空是Unity默认的天空盒。
　　明天我会再贴一张截图——KSP 0.1的。在两三个星期的工作之后KSP稍微地有了点样子，不过等明天再讲吧。
　　在那之前，发射快乐！
　　Cheers


KSP的故事 — KSP 0.1
　　为拖延抱歉，本来一个看起来会是美好普通的工作周变成了一个疯狂的烂摊子。
　　无论如何，继续我们的“KSP起源故事”，给你看看版本0.1：

　　在这时，我们已经有了一些占位用的模型，一个占位用的地形。现在还没有火箭建造，火箭是直接在游戏场景中组合的，来测试组件物理和代码。

　　另外，那时的游戏是一个“2D游戏”——游戏世界和对象是3D的，但是控制被锁定在了2D平面上。
　　差不多在这个时候，我们加入了航天器装配大楼（VAB）的第一个版本：

　　注意这个VAB的背景跟飞行模式中的非常相似。这是因为它们就是一个场景。在我们第一次的尝试中飞行模式和VAB使用同一个场景，而不是现在这样使用分离场景。不用说，跟面条式代码和无尽的Bug斗争实在是噩梦。
　　另外，这个VAB模式引入了第一个用户控制的视角。你可以旋转或者上下平移视角。很别扭的一点是，尽管你能在VAB中旋转视角，建造还是限制在2D平面上——就是在飞行中火箭被锁定在的那个平面。
　　现在，在你开始想那时的地面比现在的看起来好看之前，我来告诉你为什么：

　　这样你就明白了。那时的地形只不过是一个平面，放置在一个更大的水的平面上。如果你飞离边缘，你会永远下落下去（译注：直到程序无法处理，不过那会是很长很长的时间之后……）。
　　现在差不多到我们开始费心考虑怎么做出一个可以绕转的球形世界了。不过那是另一个故事了，需要另贴一篇文来讲 ;)
　　Cheers


KSP的故事 — KSP 0.2
　　好了，让我们继续参观0.2版：

　　可以看到，这个版本有很多改变。有些东西改进了，其他的，好吧，那时所有的东西都只是占位而已。
　　这个版本我们有了最初的火箭分级系统。你可以看到右边简陋的蓝色按钮，它们表示着在火箭上识别到的所有分级。你可以上下移动分级，但不能影响分级的顺序。而且我们有了“发射”级的概念，也就是说你在发射台上按空格才会激活火箭。这个系统有（真的）相当多的Bug，但它能用，差不多吧。
　　在这个版本里飞行模式有了可控的视角，使得你可以看到火箭的两边。但是飞行仍被锁定在XY平面上，也就是说你还是只能上下、左右飞，而不能“向里”、“向外”。

　　但这个版本真正的成就是我们做出了向心的引力系统——允许飞船绕着星球转动的引力系统。在多数游戏中，世界是一个平坦的面，而引力始终均匀地绝对地向下。但在这里，世界是球形的，而“向下”会变得非常地相对。
　　创造这样的引力，只要，简单地说，让飞船的加速度永远朝向星球中心。但正是在那时我们遭遇到了最初的浮点数精确度问题——精确度问题实际上在之后一直困扰着开发。
　　浮点数精度问题，或者“distance shakes”，是由于引擎使用的浮点数的数位有限导致的。任何游戏（或模拟，译注）理论上都潜在地会受其影响，但多数游戏将游戏世界限制在了一定的小区域中，从而避免了精度问题。
　　事情是这样的：考虑一个表示距离的数，当你描述一个很小的距离，如100米时，你使用的浮点数足够用来分辨100.0000米和100.0001米之间的差别。但是如果你浮动小数点使其用来表示100,000.0米和100,000.1米呢？可以看到，就没有足够的数位来表示额外的小数点后数位了，因为我们的单精度浮点数只能表示这么多。
　　这是一个很简单的例子，因为浮点数实际的工作方式要复杂而且无聊得多。但它说明了，在诸如1,000,000.0米这样的情况下浮点数只能达到分米级的精度。也就是说浮点数无法再表示小于这个精度的细节，结果就表现为各种可见的颤动。
　　宇宙非常大，令人畏惧地大。百万米只不过是宇宙中很小的一段，所以你可以想象，在一百万千米之外，我们会失去多少的精度。你飞船的各个组件可能会在100米半径范围内的任一位置出现。

　　浮点数精度问题影响了所有东西，不仅仅是位置。如果你创造了一个特别大的物体，它将无法被引擎正确处理，这样它无法被正常地渲染，无法被准确地贴图，很多问题。
　　但我们仍然需要向心的引力系统。KSP项目要求我们做出一个半径为地球1/10的星球，这是我们最低的目标，我们被迫让步。最初版本的Kerbin只有20千米大，而且只是一个大球而已。
　　这足够做出一个向心的引力系统来使飞船入轨了。我们甚至做了一个小一些的球来充当月球，来测试我们的转移飞行和其他的类似的事情。
　　这时，我们感到了对信息标示的强烈需要——我们还没有一个UI。所以我很快做了一个非常简略的、仅仅是刚好能用的显示轨道的面板——就是左上角那个恐怖的黑色方块了。注意它不显示星球表面，当轨道位于星球表面以下时线会变红，就是这样。
　　这样我们就能看到飞船的轨道了，但飞船内部也发生着变化，那时我们还无法知道哪个燃料罐快没燃料了。于是我们需要一个显示信息的正确方式，这也是我们下一个版本需要做的。
　　Cheers


KSP的故事 — KSP 0.3
　　KSP的故事现在到了0.3版了。
　　正如我之前提到过的，在上一个的版本之后我们急需知道飞船飞行时的各种信息。于是这就是我们在0.3版主要需要做的。

　　这个版本不仅仅加入了新的UI，还加入了一些声音（虽然这点无法从截图中体现出来），以及航天器组装部分的一些改进（那时严格上还不能称它为VAB），以及你所见的场景中的那个大显示屏。显示屏会在建造航天器时显示一些短消息，并在发射时显示倒计时（尽管通常都会被完全无视掉）（译注：注意截图中显示屏上显示的有些幽默的消息是“研发：‘一些零件比另一些零件更好’” ——有趣的是直到两年后的0.22研发部分才被真正地加入）。
　　这个显示屏很简陋，但在那时我们做的所有东西都只是占位用的——一个很字面的也很懒的设定，也就是说这些都是半成品。这个显示屏在后来的修改使其完全不再适合系统并且我们对它的笑话感到厌倦时被移除了。

　　在那时，我们开始看到KSP作为一个未来的游戏正在逐渐成型。你已经能把飞船送入轨道，新的UI也十分有用，尽管大部分还不完整。燃料和温度计是“通用的”，它只会显示总体的燃料和温度水平，所以你无法具体知道哪个燃料罐即将耗尽或是哪个发动机将要爆炸。RCS燃料表还没有用，还有屏幕右上面的那三个显示屏是给那时还没有被发明出来的Kerbals准备的。
　　另一个从这个版本中被移除的物体是0.2版中加入的月球。在0.3版我们想让游戏更具有展示性，所以那些难看的半成品被除去了。我们甚至加入了一个在发射时会弹出的教程：

　　那时的控制非常简单，没有很多需要记的东西。控制仍然被局限在2D平面上，所以你只会向左或向右失控。
　　但这些都完成后我们开始考虑，Kerbal星球（那时还没有现在的名字）（即以后的Kerbin，译注）还只不过是一个大球，即使发射台周围的地形看起来好些，这也不过是看起来而已，而当你飞到空中之后它就没有了。

　　是时候开始考虑如何做出一个真正的星球大小的星球了。这也正是我们下一个版本需要做的。
　　Cheers


KSP的故事 — KSP 0.4
　　继续我们的故事，在KSP 0.4我们决定开始处理地形问题——在星球的尺度上。
　　我一直在做一些程序化创造的东西，在那时都是一些很简单的工作。我做了一个很简单的小行星生成器，主要只是向自己证明我能做到：

　　之后我做了一个基于噪声算法的地形生成器，但它只能创造平坦的世界：

　　在上面你看到的地形系统中，地形网格上的方块会跟随角色运动，当你移动时远处的地形会前移，于是你能在这个系统里一直走下去。这个系统虽然很棒，但这些方块只是在平坦世界中变化，所以我们需要想出别的点子。我们需要一些能做出球形星球的方法，而事情开始变得有些麻烦。
　　如果你在网上寻找程序化地形系统，你会找到成千上万的尝试，但99%的尝试都是基于平坦世界的。很少很少的项目真正接触到了星球的处理，而在这之中做成的对那时的我来说太难了。
　　我开始觉得心有余而力不足了。但游戏不能没有地形系统，于是我绞尽脑汁想出了一个，呃，看起来确实像地形的方案，而且它是基于球面的。
　　它甚至有大气层。这是用一个叫Sean O'Neil的家伙公开分享的“大气散射”着色器做的，他在开发者刊物《GPU Gems》上发表了一篇相关文章。拜其所赐，我们有了几个现成的着色器可用。操作它们是一个很精细的活儿，但经过了几天的调试，我们有了这个：  
　　这个地形系统跟之前那个平坦世界的地形系统有些相似。它使用一个称作LibNoise的噪声系统——你可以在网上下载到这个程序库，在这里有现成的噪声生成工具组。我从这里找到了适用于Unity的版本。它能做一些非常惊人的事情，只要你不考虑性能。
　　在平坦世界中，把这些数字噪声转变成地形是很简单的事情。只需要从LibNoise中找到对应于世界中某一点的数字然后把地形网格上对应的顶点往上推这样一个高度就行了。
　　但对于星球来说，事情就没那么简单了。当考虑球形物体时，“上”会是一个非常相对的概念，于是我们无法再把顶点向“上”移动了。我们需要将其“推离”中心。好吧，还不是太糟。但如果有一个方形的地形网格，你要怎么把它放到球面上？试过用礼盒纸包装一个足球吗？这是相似的问题。
　　我的“解决方案”（我想不出更好的词了）是完全不再使用方块了，而是在3Ds Max中做出的一个单独的、巨大的“盘子”。它分多个区段进行细分，这样在中心的多边形密度比边缘的大很多：

　　这个截图代表的方案是，盘子一直跟随着角色，当你飞高了它会变大，当你接近地面时它会变得更低。由于盘子一直在你的下面，分区段的网格细节可以充当一个简单的LOD系统。
　　在一定程度上它有效，但是有一个很大的问题。这个盘子的网格有大约19,000个顶点，Unity可以比较轻松地逐帧更新它。问题在于你必须能和地面碰撞——而给整个盘子加上碰撞，很简单地，是件不可能的事情。Unity在一般情况下都很快，直到你试图在一个一直在改变形状的物体上加上碰撞网格——而这正是我们现在要做的。
　　解决方案就是让地形继续做地形自己的事情，加上一个一直保持在角色下面的很小的碰撞区域。碰撞区域不可见，它被设计得足够小以不显著影响性能。
　　（译注：地形方案在某种意义上是KSP之后设计思路的体现。为了避免浮点数精确度的问题，不移动飞船，而是移动整个世界。）
　　然后就有了另一个问题。由于地形是一个盘子，它的顶点理论上可以定位在世界的任何位置，这就使得一些很怪异的事情可能——而且确实发生了。如果在一帧中某个顶点位于山顶，在下一帧它就可能在半山腰上，在山顶的位置就没有顶点了。这就意味着由于“噪声场”比地形网格要精细得多，当你移动时地形会不停地闪烁颤动。
　　为解决这个问题，我们让地形只在当你移动了一定距离后才移动。通过降低地形更新的频率，地形颤动就不那么明显了。
　　于是在0.4版的更新周期结束时我们已经有了这个：

　　我们实际上使用了两个盘子，一个是地形，另一个是水。贴图是由我从网上找到的一个着色器渲染的，经过修改使其真正能用。在这个截图中你实际上能看到地形盘子在哪里结束——星球远景从那里开始。
　　星球远景也是问题的一部分。由于地形盘子的大小是有限的，在远方它需要被一个简化的星球的视觉效果替代。这由一个放置在地形盘子“下面”简单贴图的球形完成，然后在地形之前被绘出。它和会在远离视角的位置渐隐的地形模型组成了我们最初的满足基本要求的星球地形。
　　我们后来发现这个系统实际上没有满足所有的要求，但那是另一个故事了。现在，我们对我们现有的已经满意了，并开始考虑把我们的角色放入游戏中来。
　　Cheers

394966931

程序猿表示看了很有启发..

eifinalyam

Cesrate 慢慢寫吧

天空の遗迹

果断前排支持！虽然看不太懂不过也要看~~~

Cesrate

eifinalyam 发表于 2013-12-18 21:49
Cesrate 慢慢寫吧

= =早期的Dev Blog就到这里，不知道哪里会有其他的……

TimChen

到现在0.23，的确不容易啊

蓝瓜`

现在是0.24.2了，你倒是更新啊

BLAKSTO

顶~

siemens33

不是程序员表示专业术语有些难理解
不过看那样子KSP一开始不缺美工

MKT

其实当初开发人员要是知道分形地形生成算法，就可以省时间，而且地形更接近真实地形！
貌似Space Engine就是这个算法生成的星球！