http://www.watch.impress.co.jp/game/docs/20070910/gf_live.htm
LIVEのクロスプラットフォーム化、Xbox 360でのMMO実現に向け
マイクロソフトのオンラインゲーム開発支援内容を紹介
Gamefest Japan 2007，講了很多東西，不過先對裡面一小段寫一點東西。
裡面提到兩種實驗的方向：一種是透過分散式運算來強化AI的研究，第二種是透過P2P來改善連線所需頻寬的部分。
方法是將程式碼整合到Q3A(反正已經Open Source很久了)裡面，然後來進行實驗。
- 分散システムによりNPC AIの劇的な強化が可能に
集中型ネットワークでサーバーに過度の負荷をかけるNPC AIの実行を部分的にクライアントが担当することにより、パフォーマンスやセキュリティ上の犠牲を受けることなく性能を劇的に強化することが可能である、という内容で解説がおこなわれた。
將路徑尋找等比較複雜的工作從Server轉移到Client上，只在Server上進行單純、高速並且可透過參數調整的AI，而在各個client上進行比較複雜而低速度的AI處理，在遊戲進行的過程，Server定期將snapshot傳給Client，然後Client進行完複雜的運算後，將參數回傳給Server，Server則以這些資訊為依據來強化AI。結果將新的AI拿去和原始的AI對戰，得到了明顯的差異。
- 特定のサーバーを必要としないP2PネットワークでのMMOプレイ体験とは
通常FPSではクライアント・サーバー(C/S)形式のネットワークが使われるが、この方式ではピア・ツー・ピア(P2P)方式を使う。P2P方式では、通常の実装によると「人数の2乗に比例して帯域を食う」ため、一般にはMMOに全く不適といわれる。ところが提案された「Donnybrook」方式では、「人数に比例して帯域を食うC/S方式よりも負荷がゆるやか」になるのだという。
這邊的DonnyBrook指的是把遊戲的各個client以P2P來連結，正常狀況以P2P連結的話頻寬需求會與人數的平方成比例，但是這個實作把連線同步時傳輸資訊量大幅壓低，而配合各個client的AI來補正這些頻寬被壓低而損失的資訊，而連線時只傳輸玩家特別會關心的資訊：比方說已經要接近敵人了，或者是已經在接戰的時候，才提高連線資訊傳輸的優先度，否則平常的時候則將其他物件的位置加以大幅度地省略，只由client的AI來進行補正。
結論來說，即使在頻寬極度受限的環境下，也可以得到接近於LAN game的體感，頻寬需求甚至低於傳統的Server/Client。
其實上面這些觀念感覺上看起來都有利用分散式運算特性的策略。本來Server的性能與頻寬就不是無限大，所以透過重新分配運算的比重，來改善連線遊戲時的品質，以達到前述的”一千人規模的FPS”的目標；只是這邊MS是從軟體開始approach，SONY這邊則是先從硬體(CELL)開始approach，沒有軟體的話硬體只是箱子，但是有軟體的話箱子的品質可以慢慢等待改進，結果就是軟體的路線先有成果，感覺上也相當有趣就是了。
—-
不過，如果從遊戲性本身來審視的話，上述的作法有意義嗎？
第一個，上面提到連線時的頻寬壓低靠的是AI在各個client上”代替”其他player行動產生的動作，所以造成「特定武器」嚴重影響平衡度，而這應該毫無疑問是陷阱系的東西，如果變成AI替其他玩家踩到陷阱的話，那大概很多人會翻桌吧。
第二個，如果遊戲步調很快的話，接戰的頻率會很高，由於接戰狀況下你還是得維持一定量的傳輸才能達到順暢的程度，其實省不到多少頻寬。
第三個，由於改善法是透過分散式運算，所以代表單機模式底下AI能不能有改善？總不可能為了改善AI而去連線吧。
所以細部來說會有很多執行上的麻煩；然而這些麻煩和這些實驗想達成的目標相比之下應該要有些取捨，所以目標是什麼呢？為了「千人單位的FPS」下的「Server維護成本」合理化。
小光舉了個例子，F.E.A.R的AI是已經很精密、很強了，但是玩熟的玩家還是可以無傷過關，原因是因為敵人地點固定，並且行動模式沒什麼改變。如果單機模式下真的要提高難度，只要同樣的AI加上隨機戰場就很夠了。至於連線模式下透過分散式運算提高AI的性能這點也有個問題，玩家上線了就是想和真人打，結果用分散式運算強化的Bot要用在哪邊？要玩家們和Bot對戰？還是拿來當玩家的友軍？兩者應該都不太實際。
人數上的問題，以現存的大規模對戰(BattleField系列的32×32)，就已經常常會遇到一群人出去一起掛掉的狀況，人數太多所以一直在死，沒什麼熟練的空間，結果玩家平均的skill因為環境過於混亂而很難提高，地圖上的大目標也很難統籌所有人去執行(過於混亂)，整體來說遊戲性反而會降低。
那，為了減緩這些問題，來提升場景規模呢？在Multicore、CELL、MegaTexture之類的技術下，其實我們能夠做的場景是應該比以前大上許多，真的要做的話20GB的場景全程無縫讀取應該都不是問題。但是用一個大場景把比較多的人散布在和過去同樣密度的狀況下，結果來說其實和過去沒什麼改變，在地圖彼端的戰鬥，和另外一個room的戰鬥一樣與你仍然沒什麼交集。
更別提其實MegaTexture的目的是改善美術人員的工作流程，達到更好的效率，所以結果來說可以得到更大規模、更高品質的場景；但是遊戲性來說擴大場景並不會因此得到什麼改善，這或許是Crysis在設計當初曾經考量過21km平方的場景，但是最後仍然切割成多塊4km平方的場景。
所以MS這些做法是不是有價值會是值得質疑的部分；不過如果可以培植出其他有價值的know-how的話是樂觀其成….