這是 (Youtube) Blizzcon 2015 Engineering Community Amphitheater Discussion 的部分內容。挑了重點，簡單記錄了一下。
設計和工程
- 風暴英雄的資料驅動做得很好 (因此設計自由度很大)。在這樣靈活度的支援下，設計師在 Blizzcon 上想搞個大新聞：兩個不同的玩家可以控制同一個英雄。程式設計師們一聽都慌了，後來想了想，搞定了。
- 工程師們不會隨便說“這不行”，要想讓設計師們盡情發揮就不該隨便說 No ——尤其是你要是不給弄，設計師們分分鐘自給自足把自己的需求給實現了(掩面)。有張圖 (此處應有圖) 上畫的是，一個垃圾桶上放了個插著電的熨斗，熨斗上放了咖啡壺，咖啡壺裡裝著義大利麵。duang, 搞定，義大利麵做成了~
- 守望先鋒有 “strike team” 內含來自不同部門的 n 個人 (Gameplay/Engine/Designer/Animator/FX Artist) 在一起配合完成一個功能 (通常是某個特定的英雄，如 Hanzo) 這些人一起配合，把一個特性打造到極致。(下一條緊接著說的是 —— 即使這樣，D.Va 還是很難搞，花了 n 個月 —— There are two types of heroes in Overwatch: D.Va and not D.Va.)
- 從工程師的角度，尋找並解決設計師的痛點很重要 (就像產品經理找使用者的痛點那樣) 要是設計師隨便開個對話方塊都有 128 個核取方塊等著他們的話，根本就不會有啥好心情去為玩家創造優質體驗了。所以工程師需要儘可能地把無關的細節隱藏起來。
- 工程師和設計師的目標是互補的：設計師的目標是“讓儘可能多的玩家獲得最好的體驗”，工程師的目標是“儘量不要讓任何人有糟糕的體驗” (這兩個互補的目標能夠讓他們考慮和覆蓋儘可能多的邊界情況，帶來更好的體驗)
- 解決設計問題的時候，他們考慮的最多的不是解決方案，而是對玩家實際體驗的影響。
編碼和優化
- 對 WOW 的伺服器團隊來說，如果開原始碼能解決問題的話，他們會用的。在客戶端的宣告中能看到大量被使用的開源許可證。他們傾向於不要重複造輪子。
- 伺服器上的 Lua 引擎在經年累月的各種新增需求輪番轟炸下已經有點不堪重負了 (worse than not having documentation) 比如有 17 個名叫 teleport 的各不相同的函式用來傳送~~ 對寫外掛的人來說挺痛的對吧，對內部開發者更痛。
- 暴雪的絕大多數團隊都是做 Code Review 的，而且積極使用現代的 C++ 特性來改善程式碼的可讀性，尤其是考慮到暴雪產品的超長生命期。
- 如果對同一個問題有一個快速方案和一個正確方案，團隊往往會選擇後者 (即使會花更多的時間) 回頭修那些設計糟糕的系統非常痛苦。
- 是努力嘗試理解當前的邏輯，還是試著重寫那些“看起來有點亂”的邏輯，這經常會是一個問題。一個好的標準是，即使是老程式碼，只要有清晰並明確定義的方式去擴充套件，那麼就是“好的”程式碼，不必大動干戈。
- 常用的方案往往過於通用，不總是能解決暴雪在開發遊戲時面對的問題。暴雪的團隊總是會試著跳出給定工具的限制，限制他們的往往是他們自己的設計。
- 最初的 WOW 開發者在揹包裡用了陣列，陣列的起始部分是裝備，接著是揹包裡的道具，再後面是後來加的銀行。這些不同的資料的位置通過一系列算術運算來定位，而且相關的程式碼充滿了硬編碼。這些情況最直接的後果是揹包沒法很方便地擴充。大夥都忙著做功能，到後來已經修不動了。這就是固定尺寸揹包的由來。
- VTune 和一些內部工具被用於效能分析。效能迴歸是自動化的：比如“在某個地圖放上 10 個英雄混戰”，每個成功的 build 之後都自動執行並比較效能情況，這樣效能上一旦有啥異動能第一時間捕獲。做優化時，重要的是取捨：優化的能力，時間，可維護性，優化後新增的限制等等。大量的優化時間被用於與美術溝通，簡化碰撞體。
- Battle.Net 以一致的方式 (最小公分母) 對待所有暴雪的遊戲。比如如果戰網決定增加好友數量，需要所有的遊戲都打好對應的補丁，支援新的數量之後才能進行
- 已經在運營的遊戲有大量的靜態資料，所以補丁和更新往往意味著多地間大量的資料複製。使用 live test 確保基本的正常。伺服器組需要以特定的順序開啟和關閉，尤其是 WOW / Battle.Net (他們的部署體系更古老一些)
專案和資源管理
- 守望先鋒團隊使用 Perforce 管理程式碼和資源
- Battle.net 使用 Git/Jenkins
- WOW 伺服器團隊使用 SVN (但正在逐步遷移到 Git)
- Team 1 使用 Git/Perforce/Jenkins
(暴雪的團隊代號)
- Team 1 – SC2 and Heroes
- Team 2 – WoW
- Team 3 – Diablo
- Team 4 – Overwatch
- Team 5 – Hearthstone
- WOW 團隊主體沒有使用太多的敏捷開發，但一些小團隊正在開始做 scrum。暴雪不太在意一致性，在專案管理上團隊都有自己的自由度。
其它
- WOW 團隊正在研究 DX12 等新技術，不過現階段還沒啥好說的。
- 在暴雪有很多人體驗 VR，但他們更關心精彩的點子，而不是隻想著堆一摞高科技。
- 所有的團隊都在往移動上靠，爐石之後更是如此。玩家在移動裝置上玩的呼聲很高，團隊內部也是如此。
- (對應聘者) 有一個完整的遊戲專案經驗，對你的簡歷無疑具有很高的價值。對學習本身的熱情和技能多樣性同樣很重要。