Fw: [情報] EVE 的時間膨脹機制(Time Dilation,TiDi)

[LayerZ (無法如願)]

※ [本文轉錄自 C_Chat 看板 #1H1pMa6- ]

作者: art1 (人，原來不是人) 看板: C_Chat
標題: Fw: [情報] EVE 的時間膨脹機制(Time Dilation,TiDi)
時間: Tue Jan 29 10:36:18 2013

※ [本文轉錄自 ONLINE 看板 #1FklrJrd ]

作者: art1 (人，原來不是人) 看板: ONLINE
標題: [情報] EVE 的時間膨脹機制(Time Dilation,TiDi)
時間: Tue May 22 10:43:29 2012

我最愛的時間膨脹系列終於翻譯第一篇了
其實在這篇之前還有一整個系列CCP為了改善大會戰延遲，做了哪些努力的開發日誌，希
望有一天能全部看到


時間膨脹已經在今年一月實裝了，一直到今天為止，凡是有實際參與戰鬥的絕大部分都是
好評，也有相關的開發日誌討論幾場大會戰的時間膨脹數據，時間膨脹更是在Burn Jita時
讓大家都能玩的很愉快(除了那些被爆船的)



英文 http://community.eveonline.com/devblog.asp?a=blog&nbid=2307
簡體 http://eve.tiancity.com/homepage/article/2012/05/22/35417.html

以下是簡體轉繁體


=============================================================================

【開發日誌】關於時間膨脹（Time Dilation或簡稱TiDi）

    作者：CCP Veritas 譯者：CCP Albo


    常言說，與卡機延遲之間的戰爭我們是一定贏不了的，因為玩家總是可以叫更多的艦

船來。這個說法從根本上看是正確的，而正視這個事實也對Gridlock小組的工作有重要的

意義。除了之前的一些優化工作之外，我們還想著手解決戰鬥時卡裝備的問題，這樣當服

務器不堪重負時，它也能比較合理地去應對。這就是本篇開發日誌要講的內容。不過，在

理解我們的做法之前，你先要明白我們目前的處境。現在，當服務器負載過高時，它並沒

有明確的機制去解決這一問題，負責常規操作的機制只是按照它自己的步調前行。遊戲中

某些有趣的現象正是出於這個原因。不過在進一步闡述這個問題之前，我需要先對一些術

語做出定義。



    小任務(tasklet)，調度程序(scheduler)和讓步(yielding)


    基本上來講，EVE的服務器運行著一系列的任務——可能是對客戶端命令的回應，也

可能是維持著裝備（不止裝備，幾乎所有的內容）的正常狀態。它們被稱為小任務——你

不需要知道為什麼這麼叫。但只要我們使用電腦，在特定某一時間內就只能運行一個小任

務，而且我們需要一種軟件來決定運行哪個小任務，這個就叫做調度程序。



    調度程序分為不同的形式，負責EVE中的小任務運行的那種很簡單，是一種循環合作

式多任務調度程序。「循環」意思是每一個小任務都有機會運行，直到所有的小任務都運

行了一遍為止，沒有優先級，沒有特殊待遇，非常公平不是嗎，誰都有機會。合作式多任

務意思是每個小任務在執行過程中都不會受到來自外部的干擾，它會一直運行下去直到運

行完畢，或是走一種特殊的步驟，發出信號給調度程序，表明它希望讓其它小任務現在來

運行。這後一種情況就叫做讓步。



    所以這個系統就像這個樣子：

http://cdn1.eveonline.com/community/devblog/2011/simple_scheduler.png



    你可能會自言自語「為什麼有小任務會讓步呢？」這個……如果它們很自私的話，它

們當然不會讓步，而是會把自己的一切全部搞定之後再把機會讓給別的——往往也是不那

麼重要的任務。不過這樣做並不好，因為獨享CPU資源可不是個好主意。正因為如此，當

我們在編寫可能會用比較長的時間來執行的程序時，我們會在合適的地方添加讓步指令，

這樣它和別的程序之間就能和諧共處了。



    小任務會做出讓步的另一個常見原因就是，它可能在等待來自其它地方——比如數據

庫的指令輸入。一直停在那裡等待返回指令並沒有任何意義，我們可以讓別的任務先來，

而我們繼續在一旁等待。（嗯沒錯，這個就是基於I/O完成指令的暫停狀態。）



    好吧夥計，那你怎麼處理它們呢？


    非常抱歉，下面我要涉及一些計算機科學方面的專業內容了，它會解釋清楚小任務在

高負載下的主要運行方式。當服務器負載過高時，它在讓步之後至少5秒鐘才會開始下一

個流程，這就導致任務無論是否順利執行，都會花費非常長的時間才能完成，因為它一直

在等待執行的流程。爆船就是個很好的例子——它會多次訪問數據庫，所以頻繁地進行讓

步，這就把整個完成時間拖得很長。同樣地，裝備的運算流程有時會非常滯後，因為處理

它們的小任務會在進行100毫秒的執行之後做出讓步。



    上面說了那麼多都是為了下面這句做鋪墊：

    EVE的服務器應該將小任務等待執行時的隊列時間降至最短——降到零最好。

    這就是時間膨脹的意義所在。



    要想在維持服務器正常運行的情況下實現這一目標，我們的選擇並不多。基本上可以

歸結為兩點：降低負載或是提高運算能力。


    Gridlock小組花了很多時間，試圖通過優化的方式達到降低負載的目的。我們可以，

而且也很有可能繼續為此而努力，而且也已經搞定了這方面的一些簡單工作。使用多線程

是提高運算能力的一種方法，它可以提高每秒鐘的處理能力，但其實並沒有人們想像的那

麼多。總有一天我們可以實現，但是現階段它所需的工作量要遠大於實際收益。


    調節負載現在看來是勢在必行了，因為我們已經完成了一大堆簡單的優化工作。我們

已經制定了幾個不同的可行方案，最為大多數人認可的一個方案，是將Destiny——我們

的物理模擬器——進行升級，這樣當過載時它的每秒物理解析度將會降低。這樣做可以幫

助我們減少實際的模擬工作量，不過只能降低5%-10%的負載，所以也不怎麼划算。


    另一個普遍的觀點是延長裝備的循環時間，相應地提升效率與消耗。這樣我們會有更

多的自由空間，但是會極大地改變遊戲的設計，改變的程度取決於負載的高低，這樣可不

行。現有的卡裝備現象已經會改變遊戲機制，所以為了不讓事情變得更糟，我們不予考慮

這種方法。


    不過謝天謝地，我們終於找到了一種在不改變遊戲設計的前提下有效控制負載的方法

：將時間的流逝放緩。大型會戰中很大一部分負載與時間計算有關——裝備激活、物理模

擬、飛行及躍遷等——這些都是在一定的時間內完成的，所以將時間分割開來將會相應地

按比例降低他們的負載消耗。因此，我們的方法是將遊戲時間放慢，盡量減少小任務執行

時的等待時間，而當負載回歸常態時，再將時間恢復正常。這個過程的執行將是動態的，

並且有較細的檔位劃分，比如說，如果負載較輕的話，我們完全可以將時間調到正常的

98%來運行。



    好吧，那麼在大型戰鬥中它的表現如何？

    以下是我對它在大型會戰（比如1600人）中的表現的預想。當敵人的艦隊躍遷進來時

，服務器負載一下子變得很高（躍遷來去和放出無人機這類行為非常佔用資源），於是遊

戲內的時鐘也大大放緩，只有正常的5%左右。當這些運算都處理完畢後，服務器將允許時

間恢復到正常的30%，這個時候戰鬥打響了。我們要面對1600個同時發生的戰鬥行為，他

們的處理請求將迅速而平等地由服務器進行處理，只不過要花費比平時長三倍的時間。玩

家們將會感受到艦船界面中裝備循環變慢了，爆炸的動畫也變慢了。伴隨著一陣煙花，艦

船減少到1200艘了，那麼我估計時間將恢復到正常的60%。這時候一方的指揮官覺得大勢

已去，呼叫撤退。躍遷是很占資源的，所以隨著艦船的離開，時間又大大變慢，到了正常

的10%。最後戰鬥結束了，失敗者也逃掉了，服務器負載變得很低，所以時間就恢復正常

了。


    當然這裡面還有些很棘手的設計問題，比如說計時器遭遇時間膨脹會怎樣。我覺得大

多數情況下這個問題容易解決——如果增強模式計時器也能夠被膨脹的話，那麼玩家就可

以在增強模式快結束的時候進行移動，這和我們的設計初衷相悖，所以增強模式計時器是

不可以隨著時間膨脹的。而另一方面，護盾的回充是持續性的，在戰鬥中具有重要意義，

所以它必須要隨時間膨脹而膨脹。基本原則就是，如果某件事情是偏重於現實中的時間的

，那麼它就不可以被膨脹。如果你覺得哪些情況不應該牽涉到時間膨脹，請在官方論壇中

留言。



    合理預期！



    時間膨脹並不是萬能的。有些負載和時間毫無關聯，所以我們不能處理規模不確定的

戰鬥。我今天提到的應該已經涵蓋了所有的常見情況。不過，我覺得我們應該為時間膨脹

設定一個硬性的限制。在某個星系中出現0.1%的時間流速毫無意義，因為時間幾乎靜止，

你什麼都幹不了。我不知道這個臨界值將是多少——具體的還要等看看今後的部署效果再

說。如果實際戰鬥中總是會突破這個臨界值的限制，那我們就又回到現在這種服務器無響

應而且時不時抽風的狀態了。一切等待時間檢驗吧。



    這篇日誌很長，而且談論的是一項試驗性的內容。時間膨脹這個想法我早已有之，但

直到今天也沒有實際上投入太多的工作。我們去年八月做過一個試驗品來測試遊戲是否能

夠處理得了膨脹的時間，之後直到今天再無建樹。我在全球玩家聚會上得到了大量的積極

反饋，再加上星際管理委員會（CSM）將此作為他們最強烈的願望，這些都激勵了我，讓

我覺得是時候將其推出了。這可是一項大工程，所以2011年夏天你們就不要想看到它了。

一切順利的話，在秋季上線還是有希望的。



    太長了，總結一下吧


    時間膨脹的作用是將時間放慢，這樣服務器就有足夠的時間來處理你的請求。我們將

會開始著手進行這項工作，如果一切順利，它將在一段時間後與玩家見面。

    原文http://community.eveonline.com/devblog.asp?a=blog&nbid=2307

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.130.245.45
※ art1:轉錄至看板 C_Chat                                          05/22 10:43
※ 編輯: art1            來自: 220.130.245.45       (05/22 10:46)
推 zop:這想法跟做法真是前無古人,一般延遲都是被迫的,EVE改為主動 XD
推 mobilx:萬一大型會戰時間會不會無限度減緩,一戰打好幾天?
→ mobilx:那玩家怎麼睡覺才好....
→ art1:不可能無限減緩的，文中就有提到時間流逝慢到 0.1% 毫無意義
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: art1 (220.130.245.45), 時間: 01/29/2013 10:36:18
→ art1:文章中的今年是指2012年
→ art1:重看一次發現有錯字沒改...orz
→ tsunamimk2:好怪的名詞....這不就是time sharing system
→ tsunamimk2:喔 我大概懂他的寫法了 這值得參考
→ tsunamimk2:其實這就是把cpu instruction的概念拉上來
推 dotZu:這個 idea 很妙啊。會戰的時候時間就會變慢，哈哈。
推 LaPass:這叫作控制下的lag啊......
推 npc776:嘎....所以簡單的說就是....慢動作? 類似TAS馬力歐那樣?
→ LaPass:可以理解成慢動作沒錯..... 其實在遊戲的世界中，時間也是
→ LaPass:遊戲者可控制的範圍.....
→ tsunamimk2:就是大家都很忙的時候就變成慢動作操作和鏡頭XD
推 zseineo:人多的時候大家都變NEO
推 jeff101234:手速不需要400了\(￣▽￣)/
→ art1:其實這系統有更進化了，除了放慢外，也可以加速，不過沒開放
推 angol1337:真有趣  所以時間膨脹是會影響到整個宇宙的嗎?
→ angol1337:如果不是影響整個宇宙 那結束後的時間差又該怎麼調節?
→ art1:只會影響在同一個伺服器結點上的星系，由於不影響現實計時器
→ art1:所以不會有所謂的時間差
→ art1:一個伺服器結點涵蓋的星系數量不一定，有些星系活動比較頻繁
→ art1:那一個結點可能就只包含四個星系，有些星系玩家很少，一個結
→ art1:點就會包含幾十個星系
推 LayerZ:超讚，子彈時間的完美呈現，可以借轉嗎
推 angol1337:所以是大量艦隊的質量影響時間導致不對稱性的發生(啥鬼
→ art1:請轉
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: LayerZ (60.251.182.68), 時間: 01/29/2013 12:29:24
推 Ebergies:主動 Lag System XD
→ StubbornLin:Python的coroutine
推 KanoLoa:現在畫面停住緩慢 官方可以說是故意設計的了
推 cowbaying:他是區域時間膨脹還是全域?
→ hermitwhite:感覺像是單一封閉區域整個膨脹
推 adxis:jitter 轉 latency 感覺很妙!
推 a83a83cjcj:有看有推!