牧遊社 牧有漢化翻譯
Stellaris Dev Diary #149 - Technical improvements
Moah, Platypus Admirer
Hi everyone, this is Moah. I’m the tech lead on Stellaris and today I’m here to talk about the free 2.3 "Wolfe" update that will be arriving together with Ancient Relics, and what it brings to the table in terms of tech.
大家好啊，我是@Moah。作為Stellaris的技術領導，今天由我來介紹將與遠古遺物一同發布的免費2.3版本號更新「沃爾夫Wolfe」（譯註：此處致敬作家吉恩·沃爾夫Gene Wolfe，是美國的科幻及奇幻小說作家，曾各獲得過兩次星雲獎與世界奇幻獎，也獲得過四次坎貝爾紀念獎與軌跡獎，他也曾多次獲得雨果獎提名，在1996年榮獲世界奇幻獎頒發的終身成就獎，代表作《新日之書》），以及這些更新在技術層面上帶來了什麼。
Stellaris is going 64 bits.
Stellaris將轉向64位
People have been clamoring for this for a while now, and various factors have led us to finally do this for this patch. I should temper your expectations though: while many have claimed that this would be a miracle cure for all their issues with Stellaris, the reality is somewhat more tame.
大家已經為此吵嚷了一段時間了，而多種因素促使我們最終在這個補丁中將它做了出來。但我應該對你們的期待澆盆冷水：儘管很多人聲稱這會是解決Stellaris一切問題的靈丹妙藥，但現實有時更為骨感。
What does it mean?
這意味著什麼？
The one solid benefit is that Stellaris is no longer limited to 4gb of memory, and won’t crash anymore in situations where it was reaching that limit. For people who play on huge galaxies, with many empires, many mods or well into 3000s, this will be a boon.
一個可以保證的好處是群星不再限於4GB內存，所以在達到該限制的時候不再會崩潰。對於那些遊玩一個有眾多帝國的巨大銀河系、打了很多MOD或者闖入3000年以後的玩家來說，這將會是一個福音。
In terms of performance, though, it doesn’t change much. Without drowning you in technical details, let’s just say that some things go faster because you handle more data at once, some things go slower because you have more data to handle. In the end, our measurements have shown no perceptible difference.
但是，在性能方面遊戲沒有太大變化。就不把你們淹沒在技術細節裡面了，我們就直說有些東西跑得更快了，因為你的遊戲一次能處理更多數據；而有些東西變得更慢了，因為你的遊戲需要處理更多數據。最後，我們的測量結果顯示沒有明顯差異。
Finally, the last effect of switching to 64 bits is that the game will no longer playable on 32 bits computers or OSes. We don’t think this will affect many people, but there you have it.
最後，切換到64位的最後一個影響是，遊戲將不再能運行於32位計算機或作業系統。我們認為這不會影響很多人，但你得知道一下。
What about Performance?
那性能又如何？
I know that’s everyone’s favourite question, so let’s do our best to talk about it. First, let me dispel some notions floating around in various forums: Stellaris does use multithreading, and we’re always on the lookout for new things to thread. In fact between 2.2.0 and 2.2.7, a huge effort was made to thread jobs and pops, and it’s one of the main drivers of performance improvement between these version.
我知道這是每個人都最喜歡的問題，所以讓我們盡力說明一下。首先，讓我澄清一下出現在論壇各版塊中的一些流言：Stellaris確實是使用多線程的，而且我們總是在留心找新東西來多線程化。事實上，在2.2.0版本號到2.2.7版本號之間，我們在崗位和人口方面做了大量的工作，這是這些版本之間性能改進的主要驅動力之一。
Pops and jobs are indeed what’s consuming most of our CPU time nowadays. We』ve improved on that by reducing the amount of jobs each pop evaluate. We』ve also found other areas where we were doing too much work, and cut on:
人口和崗位確實消耗了我們現在大部分的CPU時間。我們通過減少每個人口計算的崗位數量來改進這一點。我們還發現了其它做了無用功的地方，然後將其消除：
Ships calculating their daily regeneration when they’re at full health
船舶在滿血時仍然計算其每日恢復。
Off-screen icons being updated
屏幕外圖標也在被更新。
Uninhabitable planets doing the same evaluations as populated planets
非宜居星球與居住星球進行了相同的計算。
Why do these seemingly pointless things happen? Well, we generally focus on getting gameplay up and working quickly so that our content designers can iterate quickly, and sometimes things fall through the cracks. Some of these systems are also quite complex and the scale of the new code is not so easily apparent. Sometimes, not limiting the number of targets is good enough because you’re not doing much but then, months later, someone adds more calculations or the number of objects explodes for unrelated reasons, and suddenly you』ve got a performance issue.
為什麼會出現這些看起來毫無意義的事情？呃，我們通常專注於提升遊戲性並快速推進工作，這樣我們的內容設計師就可以快速迭代，而有時某些東西就會被疏漏過去。其中一些系統非常複雜，新代碼的規模也不那麼明顯。有時候，不對目標數量加以限制也問題不大，因為你也沒處理那麼多；但幾個月後，當有員工加入了更多的計算量，或者目標的數量因為某些無關原因而炸裂後，突然你就發現自己陷進了性能問題中。
Modifiers
修正項
One thing that sets Stellaris apart from other PDS title is how much we use (or abuse) modifiers. Everything is a modifier. Modifiers are modified by other modifiers themselves modified by other modifiers, and sometimes by themselves. It’s quite hard to follow, and leads to every value being able to change at any time without your noticing.
群星和其他PDS出品遊戲之間的一個巨大區別，在於我們使用（或者說濫用）修正項的程度。萬物皆是修正項。修正項由其它修正項來修正，而這些其它修正項又由其它修正項來修正，有時也被自己的修正項所修正。這難以為繼，而且會讓每一個值隨時都可能一個不注意就在你眼皮底下改變。
「Why don’t you just compute jobs when a new one appears?」 has often been asked around these parts. Well, a short answer to that is it’s really hard to know when a new job appears. You can get jobs from any modifier to: country, planet, pops. Each of these can get modifiers from ethics, traditions, perks, events, buildings, jobs, country, planets, pop, technology, etc.
「當一個新的任務出現時，為什麼不直接計算它呢？「經常有人圍繞著此類問題進行提問。對此一個簡短的回答是，我們很難知道什麼時候會有新的任務出現。你可以從任何修正項那得到新的任務：國家、行星、人口。其中每一個都可以從思潮、傳統、超凡飛升、事件、建築、崗位、國家、行星、人口、科技等方面得到修正。
Until now we were trying to calculate modifiers manually, forced to follow the chain in its entirety: when you recompute a country modifier, you then calculate their planets modifiers, and then each planet would recalculate their pops modifiers. Some of our freezes were just that tangled ball of yarn trying to sort itself out.
到目前為止，我們一直在嘗試手動計算修正項，並強迫它整個兒遵循計算鏈：當你的遊戲重新計算一個國家修正時，將先計算它們的行星修正，然後每個行星將重新計算它們的人口修正。我們的一些卡頓現象只是一團糾纏在一塊的毛線球試圖把自己理清楚。
This is our modifier flow charts. It’s not quite up to date, but gives you an idea of the complexity of the system (Unpolished because it’s a dev tool, and not made for the article).
這是我們修正項計算的流程圖。它並不是最新的，但會讓大家對系統的複雜度有個概念（因為它是一個開發工具，而不是專為本文而設計的，所以沒有經過打磨優化）。
No More!
沒了！
For 2.3 「Wolfe」 we have switched to a system of modifier nodes, where each node register what node they follow, and is recalculated when used, following the chain itself. We have modifiers that are more up to date, and calculated only when needed. This also reduces the number of pointless recalculations.
對於2.3版本號「沃爾夫Wolfe」來說，我們已經將系統更換為一個由修正項節點組成的系統，其中每個節點記錄它們所跟隨的節點，並在使用節點時重新計算，遵循整個計算鏈本身的流程。我們使得修正項更符合最新狀態，並且只在需要時才計算。這也減少了無意義的重新計算的數量。
This system has shown remarkable promise, and cut the number of 「big freezes」 happening around the game (notably after loading, for example). It has some issues, but as we continue working with it, it』ll get better and help both with performance and our programmers』 sanity.
這個系統展示出了非凡的前景，並且減少了遊戲中發生的「重大卡頓」的數量（例如，在加載遊戲之後）。它還存在一些問題，但是當我們繼續努力後它會變得更好，並且對遊戲性能和保持我們程序驢的理智值都有幫助。
So, what’s the verdict?
那麼，結論是什麼？
In our tests, 2.3 「Wolfe」 is between 10% and 30% faster than 2.2.7 right now. Hopefully it』ll stay that way until release, but the nature of the beast is that some of these optimizations break things and fixing the issues negate them, so we can’t promise anything.
在我們的測試中，2.3版本號「沃爾夫Wolfe」比2.2.7版本號要快10%到30%。希望它會一直保持這種狀態直到發布，但問題的本質是，其中的一些優化會搞壞掉一些東西，而修復這些問題又會抵消優化，所以我們不能在這裡做出任何承諾。
Measurements provided by @sabrenity , using detailed info from the beta build. It’s worth noting the 「SHIPS_SERIAL」 purple line has since been eliminated.
測試數據由@sabrenity提供，使用來自beta版本的詳細信息。值得注意的是，「SHIPS_SERIAL」的紫線已經被削除。
AI
人工智慧
Another forum favorite, we have done some improvements to the AI. First, with @Glavius ’s permission, we』ve used his job weights to improve general AI job distribution. We』ve also done the usual pass of polish and improvements, and of course taught the AI how to use all our new features.
另一個論壇上最喜歡討論的話題。我們對AI做了一些改進。首先，在@glavius的許可下，我們利用他的任務權重來改進AI的整體任務分配。我們也做了一些常規的優化和改進，當然還教會了AI如何使用我們所有的新功能。
What else is new?
還有哪些東西是新的？
We’re also getting a new crash reporter that will send your crash report as soon as they happen rather than next time you start the game. We』ve improved our non-steam network stack for connectivity issues, etc.
我們也搞了個新的崩潰報告器，它將在你的遊戲崩潰發生時發送報告，而不是下次開始遊戲時。我們也改進了我們的非Steam網絡棧以解決連接問題等等。
All right, enough of my yammering. This has turned into a GRRM length novel, and even though there are many more areas we could cover, we』ll just turn this for your perusal.
好吧，我說得夠多了。這已經變成了一部喬治·R·R·馬丁的長篇小說，儘管我們可以涵蓋更多的領域，但我們只列舉出了這些來方便你們閱讀。
翻譯：子炎君 Lithium
校對：萬豪頓 三等文官猹中堂
歡迎關注鬥魚主播小牧Phenix！
歡迎關注牧遊社微信公眾號和知乎專欄！微信公眾號近期改版為信息流，歡迎置頂訂閱不迷路，即時獲得推送消息！
歡迎加入牧有漢化，致力於為玩家社群提供優質內容！翻譯人員募集中！