首先放一张上个月放出来的金属星概念壁纸
不知道那些蓝色光斑是否是可通过区域。
杂想：对于星球这个概念，有两点值得注意
1.在一个球面上，两个玩家间的距离最多只能是球体周长的一半。
2.因为透视及遮挡的原因，球面看上去会比等面积的矩形小得多。
中微子（即John Mavor）分享了一个很有趣的想法，两个雷达的侦测范围重叠起来可以豁免掉一个雷达干扰装置的效果，两个雷达干扰装置的作用区域重叠起来可以屏蔽两个雷达的侦测，依此类推。这只是个想法，不一定会在游戏中用上
中微子：PA的随机地图生成器有两个不同的层面，程序性生成（procedural generation，通常译成过程生成，只是PA这种RTS没有探索的成分所以这么译不合适）以及决定生成规则的数据。最终的实际地形不是被程序性生成定死的，modder可以在生成之后做出具体的修改。当然，我们打算把地图生成的前端部分做得脚本化，所以人们可以扩展我们的生成器，加入新的地貌和行星样式等等，这些都将是由一些json文本文件驱动的
无关话题：Faster Than Light大家不知玩过没有，第一款正式发售的Kickstarter游戏，画面为像素风格，玩法明显启发自星际迷航之类的科幻剧，游戏素质在独立游戏中绝对是顶尖的，跟粘粘世界，Braid等在同一个水平。
磁力下载：
magnet:?xt=urn:btih:164F035F4AE5D5E84CDCAAED70511B33B66C6630&dn=FTL_Faster_Than_Light_v1.02.6_setup.exe&tr=udp%3a%2f%2ftracker.publicbt.com%3a80
嗯貌似还没出汉化 不过个人更喜欢远行星号
我希望可以在打起仗时候给对应的方向在屏幕上显示一个箭头，打的越激烈箭头越大，点下箭头就可以让屏幕飞过去，
这个可不好比，Starfarer是太空战游戏，FTL基本上是在模拟舱内管理，连战斗也是舱内管理式的
游戏预订即将开始
以下是详细细节
战斗版40美金
战争版60美金，买家将可进入beta测试
银河版90美金，买家将可进入alpha测试及beta测试
所有版本都含有数字版游戏原声及仅预订者（包括kickstarter及paypal捐赠者）享有的theta指挥官使用权限
以下是theta指挥官概念图
https://smnc-cdn.s3-us-west-1.amazonaws.com/store/4/theta_commander_email.png
到时候可是要通知下咱们啊！我的意思是组个团啥的:4_196:
嗯 各有千秋 话说求团购游戏啊
中微子：
我打算谈论一下横扫千星UI（界面）的引擎结构，这不意味着一份复杂的描述，只是我想在看着火鸡被烤熟时（译者注：当天是感恩节）聊一些我愿意聊的内容罢了。
UI对于游戏开发来说基本上是一种灾难，你有很多路子可以走，但没有哪种路子是特别好的，建立一套UI很困难并且很花时间，外加那些可能得用到的不好使的开发工具，结果可能会很不理想。再加上我们的主要设计目标之一是让UI可mod化，最好是能让多个mod协同工作，那意味着我们不能简单地将UI嵌入在C++代码中，即使是采用DLL系统也会有问题，因为我们打算让游戏跨平台运行。
我们所需要的是一个灵活，可扩展性强的系统，有能力构建在一套能在各种平台运行的UI，构建方法最好能大众化点并且已经有一些工具可以利用，另外UberNet（UE的官方联机平台）主要是基于web建立的，这要求我们必须得有办法将一个网页浏览器嵌入到游戏客户端之中。基于以上几点，什么才是合理的选择呢？我们可以创建一套嵌入lua的自制系统，或者我们可以获取Scaleform之类的第三方技术授权，使用Actionscript，或者干脆弄个网页浏览器当UI使，而最后一种正是我们所采用的方案。
我们的客户端基本上是一个处在OpenGL背景中的透明的webkit窗口，所有的前端和顶层UI都是用Javascript写成的。我绝对不喜欢JS，但作为地球上最流行的语言，它确实有一些优点，它有许多套专用工具可用，它有个很好的即时编译器。
我们的主意是让引擎曝露出一组JS界面，让web浏览器描绘出所有的UI元素并控制选择和命令发布等等，通过曝露更多的界面我们将能够给予JS更多的支配权，我打算曝露出的部分会比我们实际所用到的更多。
行星生成器的UI是我们所做的第一个真正的UI，它就是用这样的方法写成的，这意味着社区将可以扩展它。以下是它的早期截图，请不要以此来判断最终成品的功能及外观，通常我们不会这么早地曝光这些东西，但这条规则已经因为kickstarter改变了。
http://4.bp.blogspot.com/-A_oMbWFjNe0/UK5_qXmKrRI/AAAAAAAAAGs/KslYXQQmtt0/s1600/Screen%2BShot%2B2012-11-22%2Bat%2B11.38.45%2BAM.png
总的来说我目前为止对这个决定感到满意，我们已经能让UI在windows/MacOS/linux上运行了，长远点看我仍然有点担心JS的运行效率及它作为一门语言的不足，不过我觉得由于web正变得无处不在，这种做法可能会成为未来的趋势之一。
O（UE的Bob Berry）：虽然JavaScript绝对令人憎恶，不过我在Uber已经支持这个主意有一段时间了。如果它能在所有平台正常运转，它带来的好处将盖过语言本身的缺陷。
就像中微子所说的，JS是世上应用最为广泛的的语言，这意味着我们将会吸引大量的modder，包括从来不觉得自己能做mod的人。你可以使用像jquery，knockout这样的库，有海量的由JS社区开发的技术可供你我选择，听起来似乎挺棒的。
本人对编程几乎一窍不通，这里面有好多程序术语，所以译得不好请见谅
中微子今天汇报了一下工作进展
http://forums.uberent.com/forums/viewtopic.php?f=61&t=41531
这里就不译了，Sorian在试图让游戏支持各种值的auto-reloading，对于modder可能会很有用，其它几人在做着本职工作，引擎的地形系统离完工还有段距离，中微子目前在做着其贴图部分。
Sorian在感恩节那天的日志
（Sorian，即Michael Robbins，曾是最优秀的SupCom第三方AI作者，后被GPG雇用，最近刚跳槽到UE）
我发现在这一天写这篇文章很合适，回顾这一年确实有很多事情是我应当感恩的，对于我得到一个在UE同这些有才华的人一起工作的机会这件事情来说尤其是如此，PA对我来说是个非常不同的项目，这当然与游戏类型无关（Sorian之前参与过三个RTS的开发），而是因为这是我第一次能够在这么早的开发阶段参与进一个项目来。
之前几个星期我主要在做些基础性的工作，比如为了将跨平台的细节内容埋藏得更深，我为信号对象（semaphore objects）创建一个封装类（wrapper class），另外我还创建了一个线程池对象（thread pool object），一个线程安全任务序列（thread safe task queue），一个条件变量封装（condition variable wrapper），你看到了，都是些核心级的事情，挺有趣挺有挑战性的。
上个星期我主要在花时间将游戏的资源系统替换为某种更好的版本，这包括让各种变量支持极高速的重复读取（顺便说一句，第一次看到这个功能运转起来很有趣）好让迭代开发更轻松。新系统的基础部分已经可以正常运转，现在我只是在执行的细节上花功夫，找出各种可能阻碍它运行的问题，调整执行方式以避开它们。我估计我这个周末会花些时间修好最后一个已知的漏洞，之后就得花功夫让新系统支持贴图以外的东西，最后我会把老系统剔除出去好换成新的。
UE有一套很不同的文化，他们对于公司的内部工作十分公开，我觉得那很新鲜，我也很喜欢除我之外有其他人经常同社区交流的事实，官论上的玩家言论也经常会在内部会面和会议中被提起。
说到听取社区意见，PA的预订已经开始了，这么早就开始似乎挺奇怪的，不过因为社区中很多人都想要提早预订，所以UE就这么做了，如果你对预订感兴趣的话，可访问https://store.uberent.com
另外，我为之写了一篇文章的那本书现在已经被亚马逊列出，封面很漂亮：http://amzn.to/R4cllh
我很确定出版日期不准确，反正到时候就知道了，我等不及要得到一本了。
老消息：中微子本人将参与游戏原声的演奏，他会弹电吉他
这是一个好消息!
可以把我的想法也提交到官网吗?
以屏幕边缘的箭头作为画面外战斗的指示物，点一下就能切屏的想法我许久前在官论提过，只是我没有提到战斗规模越大箭头越大。
PA的UI设计有一个很大的问题是想把画面做得informative很困难，你的摄像机拉得近点的话只能看到单个行星的一面，拉到行星系层次也只能看到星系的一面，而且因为东西显得太小可能什么也看不清楚，如果你给每个天体弄个同时包含正反两面的小地图的话，那就太占画面空间了，所以加些个箭头什么的可能会有帮助。
官论上有些人讨论VOIP语音聊天，大部分人觉得这不是个很有必要的功能
中微子：我本来想着把这个包含在游戏里的，听了你们的话后我降低了它的优先级。
我们使用fmod作为我们的音效系统，fmod将来可能会支持VOIP，那样子的话会捎带上我们的游戏，所以等着看看吧。
中微子说不出意外的话他们这周会开始将Elijah的那套流场寻路整合进网络代码里。我们或许可以在不久后见到与此有关的更多消息
好消息啊！