（圖片來源：www.cnblogs.com）

原文出處：OpenGL 3 & DirectX 11: The War Is Over

現今在 DirectX 與 OpenGL 皆已相當普及的年代裡，我們似乎也逐漸淡忘了兩者從前的那段江湖恩怨。在著名硬體網站 Tom’s Hardware 的這篇專欄文章裡，作者帶領我們重新回顧這場「繪圖 API 戰爭」中的起伏轉折，以及 OpenGL 3 與 DirectX 11 的未來展望，是篇值得仔細閱讀的好文章。

「DirectX 最殺！很強很邪惡的微軟帝國萬歲！」
「想跨平台嗎？OpenGL 才是唯一的光明道路！」
「我是初學者，應該要選擇 DirectX 或 OpenGL？」
「我想做出一款超棒超好玩的遊戲，要用 DirectX 還是 OpenGL 比較好？」

身為遊戲程式設計者，如果你有定期瀏覽國外各大程式論壇的習慣，應該會對以上這些問題感到非常親切、熟悉，而且可能還會有些反感吧？在遊戲程式設計相關領域的討論區裡，最常見的萬年討論串非「DirectX 與 OpenGL 的比較」莫屬。DirectX 與 OpenGL 雙方各有死忠的支持者陣營，只要在網路上裡提出類似以上敘述的問題，往往會引來雙方擁護者激烈的對抗與辯論；如果又不小心觸動了某些資深程式設計者的「逆鱗」，就更加會戰到天荒地老無以復加。

在過去的短短幾年之內，我們親身經歷了消費性 3D 顯示卡市場的爆炸性成長。從以前只有硬派玩家會花大錢購買的「3D 加速卡」，到現在幾乎已成為標準配備的「3D 顯示卡」，電腦繪圖硬體不僅成功地打入了一般消費者的市場中，其性能也獲得革命性的突破，目前 GPU 的電晶體數量甚至已經超越了 CPU。時至今日，DirectX 與 OpenGL 在電腦繪圖與遊戲業界中的地位，究竟是處於分庭抗禮的情勢，或者已經分出了勝負？且讓我細說從頭。

這場由 Microsoft（簡稱為 MS）與 Silicon Graphics（簡稱為 SGI）公司相互交鋒的繪圖 API 戰爭，已經持續了十年之久。當年 DirectX 初試啼聲之時，MS 挾其龐大的企業資源以及 Windows 作業系統的市佔率，正摩拳擦掌準備傾全力推行自家設計的繪圖 API 標準。而相較之下，雖然 SGI 的資源比較弱勢，但是行之有年的 OpenGL，早已佔據了電腦繪圖界的王者地位而無可動搖；同時，OpenGL 也得到最強而有力的同盟軍 John Carmack 的支持背書。由於當時使用 OpenGL 開發的 Quake Engine 所達到的驚人繪圖效果，因此使得所有繪圖顯示卡的製造商，都必須提供完整的驅動程式支援 OpenGL 標準，才能夠符合遊戲開發者與遊戲玩家對於顯示卡硬體的期望。

SGI 的 OpenGL 是當時專業繪圖市場中的龍頭老大，佔有極大的優勢，而與此同時 MS 只能夠一切從零出發。要開發出既好用且功能強大的繪圖 API，學習曲線可說是相當的嚴峻；在早期的 DirectX 版本中，很多程式設計者都無法適應那種與 OpenGL 全然不同的複雜程式概念，因此許多人都對於 DirectX 不屑一顧，並不看好它的未來發展。但是 MS 並沒有輕言放棄，隨著每次釋出的全新版本，DirectX 正一步步逐漸跟上 OpenGL 的腳步。

在雙方開戰初期，OpenGL 擁有非常顯著的有利優勢，然而整場戰役的轉捩點，發生於 2001 年 MS 釋出的 DirectX 8 之中。這是首次 DirectX 的 API 不再僅止於拷貝 SGI 的規格標準；MS 在這次 DirectX 的全新版本中，引入了對於整個電腦繪圖界來說極為重要的創新與變革：Vertex Shader 以及 Pixel Shader。頂點著色器與像素著色器的誕生，為繪圖程式開發者們開拓了一條前所未見而且閃閃動人的星光大道。

相較之下，當時 SGI 的主要收益來源是非常昂貴的 3D 繪圖工作站，他們沒能預期到 3D 繪圖顯示卡市場的驚人需求爆發，而 ATI 與 Nvidia 這兩間新興的顯示卡廠商，又竟然能以相當低廉的價格，將繪圖顯示卡打入遊戲玩家的市場。另一方面，OpenGL 規格標準的發展，也受到各軟硬體廠商之間的利益衝突因素牽連而遲遲無法達成共識。而在 MS 這方，卻僅僅與 ATI 以及 Nvidia 兩間公司合作制訂 DirectX 的 API 規格，並且擁有最終的關鍵裁量權，因此能夠相當順利且迅速地持續發展。

在彼消此長的情況下，當 DirectX 9 推出後，更是成功地獲得了一場決定性的勝利。於是，有許多軟體與遊戲的開發者，決定開始使用 DirectX 或者同時提供兩者的支援；只有 John Carmack 以及有跨平台需求的開發者，仍然對於 OpenGL 忠心耿耿，但是他們的陣營已經比從前衰弱許多。當然，OpenGL 陣營手上仍然握有逆轉命運的契機。於是在二年前，OpenGL ARB 組織終於將 OpenGL 的開發權交付給了 Khronos 集團，將一切的希望都寄託在他們的身上。經過了二年的漫長等待後，在今年八月的 SIGGRAPH 研討會中，Khronos 終於發表了萬眾矚目的 OpenGL 3，所有 OpenGL 陣營的支持者莫不期待能夠藉此扳回一成。然而，事情並沒有如原先計畫般的順利。

將時序拉回 2002 年，此時 OpenGL 正逐漸失去電腦繪圖界的領先地位。MS 的 DirectX 9 提出了全新的著色器 (Shader) 繪圖功能以及高階著色語言 (HLSL)，而 OpenGL 陣營卻拿不出可以相比擬的功能。在 Shader 繪圖架構問世之後，顯示卡硬體很難再依循著傳統的繪圖管線架構生產製造，於是為了彌補現有 OpenGL 不足之處，各家顯示卡廠商開始各自擴充原有的 OpenGL 規格，自訂出一套自己專屬的延伸繪圖 API。

正當 OpenGL 陣營陷入一片混亂之時，3DLabs 這間公司瞭解到 OpenGL 亟需迅速而徹底的變革，才能夠跟得上顯示卡硬體一日千里的發展腳步，於是當仁不讓地提出一項擁有許多重大改革項目的 OpenGL 重整計畫。首先，他們為 OpenGL 加入了高階著色語言 GLSL，接著為了使 OpenGL 得到良好的效能，必須將 API 進行全面性的整理修改；在 OpenGL 2.0 Pure 的核心規格裡，他們計畫刪除那些過時以及多餘的功能特徵，只留下最符合現今硬體主流架構的功能，使開發者能夠慢慢地由老舊的 OpenGL 1.x 版本，轉移到全新的 OpenGL 2.0 版本。

然而很遺憾地，經過 OpenGL ARB 組織的冗長討論後，這項周全的改善計畫被回絕了。在最終釋出的 OpenGL 2.0 裡，僅僅加入了對於 GLSL 的支援，而 3DLabs 所提案的其他功能全都隨風而逝，導致 OpenGL 2.0 的版本仍然遠落後於 DirectX 所提供的功能。好不容易到了 2005 年時，OpenGL 終於趕上了 DirectX 在三年前所釋出的 API 功能。此時各家顯示卡廠商與軟體開發者，都同意事態不能夠再繼續這樣發展下去，否則 OpenGL 將會逐漸失去地位而被人遺忘。最後，OpenGL ARB 終於在 2006 年時，將接力棒交到了 Khronos 集團手上。

Khronos 以過去管理 OpenGL ES 的高效率與負責態度著稱，在接手 OpenGL 的開發後，他們很快地建立起對外的溝通管道，並且對於 OpenGL 的未來發展與多方廠商進行周詳的討論，最後提出了兩項 OpenGL 發展計畫的里程碑：Longs Peak 與 Mount Evans。首先，在第一個開發里程碑 Longs Peak 中，他們打算刪除那些已經過時的 API，使 OpenGL 能夠集中在一組比較先進的功能組之中，並且提供與 Shader Model 2 相同等級的功能；而第二個里程碑 Mount Evans，則期望能夠加入全新的 API，並且提供與 Shader Model 4 相同等級的功能。

時程很緊迫，需要完成的項目非常多，剛開始的開發狀況仍稱得上是一切順利，沒想到自 2007 年年末開始，Khronos 就不再公布任何關於 OpenGL 新版的開發進度消息，突然間由開誠布公的溝通，一瞬間轉變為完全封閉的態度。直到今年八月 SIGGRAPH 的研討會裡，OpenGL 3 總算是千呼萬喚始出來。但是在驚喜之後，則是失望、不滿以及憤怒的情緒，如同洩洪般在網路討論區裡漫天蓋地而來。

But while some people were expecting a pleasant surprise, Khronos had a serious disillusionment in store for fans of OpenGL.

這些強烈的負面回應，不只是因為 OpenGL 3 比原先預定的時程延後了將近一年的時間才發佈，同時也因為大多數在 Longs Peak 中所承諾的新功能也完全地被捨棄了。檢視最終公布的成果，OpenGL 3 看起來簡直就像是 OpenGL 2.2 版本一樣，只不過是個「增進性的更新」(incremental update) 而已，API 並沒有真正地產生改變。OpenGL 3 所提供的新功能，也與 DirectX 10 非常相似。

根據 Carmack 的說法，OpenGL 3 標準未能達到預期成果的主要原因，在於某些 CAD 軟體的開發者並不滿意 Longs Peak 中制訂的規格。這些軟體廠商，害怕相容性的問題會使得他們的應用程式某些比較老舊的功能失效。深入參與研發程序的 Nvidia 公司 Lichtenbelt 也說：「我們在應該移除哪些功能的議題上，遭遇到意見不一致的情勢，主要是因為不同的市場需求所致。我們發現我們無法做出一個滿足所有人需求的 API。」

回過頭來看看另一方的 DirectX 陣營。在 2006 年發佈的 DirectX 10 裡，MS 對 DirectX 整體做出了史上最徹頭徹尾的修改。近年來，傳統的 API 繪圖架構已經快要跟不上顯示卡硬體的發展腳步，因此 DirectX 10 的遠大目標，就是要為未來的硬體架構提供一項穩固的根基建設。然而，DirectX 10 並沒有如預期般獲得遊戲玩家與開發者的喜愛及關注。

對於遊戲玩家來說，即使使用了 DirectX 10 可能也感受不到明顯的改變；更糟的是，新的 API 只為 Vista 以上的系統撰寫，正好為敵視 MS 的使用者找了一項非常充足的開戰理由。而對於遊戲開發者來說，在 Windows XP 仍然佔據絕大多數消費者市場的情況下，DirectX 10 與 Vista 作業系統綁在一起，不僅轉換成本極高而且也發揮不了顯著的市場作用，因此多數的遊戲專案，仍然選擇堅守著傳統的 DirectX 9 標準。

（圖片來源：www.socgame.com.tw）

在最近剛揭露初步訊息的 DirectX 11 中，公布了不少值得遊戲開發者引頸期盼的全新功能。DirectX 11 奠基於 10 之上，也可以稱為是一次增進性的版本更新；在 DirectX 11 正式問市以後，許多開發者應該會選擇略過 DirectX 10，直接使用 DirectX 11 開發最新的遊戲。而最棒的是，DirectX 11 不僅能夠向下相容於 DirectX 10 的顯示卡，同時也能夠在 Windows 7 與 Vista 上執行！

在 DirectX 11 的許多新功能中，我個人認為最重要的莫過於多執行緒繪圖功能的支援。再者，在 GPU 的專用開發語言上，相較於 Nvidia 大力推行的 CUDA，DirectX 11 的 Compute Shader 優勢在於能夠同時支援 ATI 以及 Nvidia 的顯示卡，甚至是未來的 Intel Larrabee 顯示硬體，而且也與 DirectX 的功能具備有更佳的整合能力。另外像是 Tessellation 階段的導入、Texture Compression 效果的改善，以及物件導向化的 Shader Model 5 等等，也都是對於電腦繪圖與遊戲開發領域非常具有吸引力的功能特點。

許多人對於 OpenGL 失望之處，不僅是 API 本身的能力，同時也包含被處理的過程。在 OpenGL 3 裡，僅僅勉強跟上了 DirectX 10 的腳步，而在幾乎同一時間裡，MS 已經公布了次世代 DirectX 11 版本的細節。雖然相較於 DirectX 10，最新的 DirectX 11 並沒有什麼革命性的創新之處，但是自 DirectX 10 推出以來，MS 已歷經了二年的困難處境，所以現在 MS 得以在穩健的基礎上，回收當時花費龐大心力重建 API 的功夫。

原文標題所下的「The War Is Over」，已經很明確地表達了作者對於 DirectX 與 OpenGL 之戰的心得感想。但是在文章最後，即便未來的可能性相當難以預期，作者仍希望在後續 OpenGL 3 的更新內容裡，能夠證明他所做出的結論是錯誤的。就我自己的感想來說，OpenGL 仍然是跨平台繪圖應用程式的唯一選擇，我也不希望 OpenGL 從此衰落而一蹶不振，演變成 DirectX 獨占鼇頭的局面。唯有正向的競爭壓力，才能夠加速促進繪圖 API 以及繪圖顯示硬體的發展。

在瞭解了 DirectX 與 OpenGL 兩強相爭的歷史淵源以及來龍去脈之後，或許有些讀者還是會想問：「到底應該要選擇學習 DirectX 或者 OpenGL？」對於想進入遊戲程式設計領域的初學者來說，我的建議是：兩者都需要學習。DirectX 與 OpenGL 具有不同的設計理念與實作技巧，也擁有各自獨具的優勢與弱點；在遊戲業界中，兩方都有廣泛的使用族群，並沒有特別偏向某一方，所以兩者皆不可偏廢。

如果非要從兩者中挑一個入門，那麼我會建議由 OpenGL 開始學習電腦繪圖理論與實作技術。因為學習 DirectX 的初學者，往往很容易被視窗程式的建立以及 COM 元件的架構所迷惑，反而會模糊了學習電腦繪圖程式設計的焦點。若是使用 OpenGL，便可以利用 GLUT 或其他的輔助函式庫，大幅簡化與平台相關的視窗程式建立細節，使學習者能夠專注在電腦繪圖理論與程式實作技術的領域中。當然如果你在進入電腦繪圖領域之前，已經相當熟悉 Windows 視窗程式設計，那麼選擇 DirectX 做為出發點也同樣是沒問題的。

在學會了 DirectX 與 OpenGL 之後，就可以把它們當成「個人工具箱」裡的兩把利器：當我想要學習最新的 Shader 程式設計，將顯示卡性能發揮到極限時，我會拿出 DirectX 這把屠龍刀；而當我有個程式概念想要快速完成雛形試做時，我就會揮舞 OpenGL 倚天劍。不管是 DirectX 還是 OpenGL，隨你自由來去，豈不樂乎？

我要誠心誠意地推薦一個網站「程式者的胡言亂語」，以及其中的一些文章，給各位現在身處業界或者未來即將成為程式設計者的讀者。

• 漫談程式碼的相依性 – 1
• 漫談程式碼的相依性 – 2
• 漫談程式碼的相依性 – 3
• 漫談程式碼的相依性 – 4

「緊緊相依的心如何 Say Goodbye，你比我清楚還要我說明白……」身為遊戲程式設計者，在撰寫遊戲系統的時候，你是否曾經考慮過類別之間的相依性問題？如果你對於相依性的定義與影響不甚瞭解，閱讀這幾篇文章之後，應該能夠得到很大的收穫。

當你的下一個專案、下一款遊戲或下一間公司，有機會重新撰寫遊戲中的子系統時，請用心想想如何利用 Manager 類別來扮演子系統與子系統之間的 Facade 介面層，以及如何降低表頭檔間的編譯依存關係，別再把繪圖、網路、使用者介面與其他雜七雜八的家族類別們，全都混在一起開雜交派對了。

程式員與開發文件之間的恩怨情仇

如一般人所知，程式設計者與文件之間，經常處於某種微妙的對立關係。真正能夠發揮功能作用的好文件，應該是隨著開發而不斷演進的有機生命體，而不是為了交差了事，完成以後就束之高閣或者拿來墊便當用的東西。如果你是程式部門的主管，不論擅長的是專案管理這把倚天劍，或者是軟體工程那把屠龍刀，請許你的程式設計者們，一個認真撰寫文件的動機與誘因吧！

程式碼共有下的團隊開發

即使遊戲業界距離極限編程 (eXtreme Programming) 的流程方法仍然有很遙遠的距離，我們還是能夠應用其中的某些準則規範，做為遊戲程式開發中的指引。為了達到集體程式碼共有 (Collective Code Ownership) 與共同認識 (Shared Understanding) 的目標，可以運用在之前文章中提過的 Code Review 程序，逐漸凝聚起團隊中的思維共識與程式寫作風格。從此以後，不分你我，再也沒有誰不能更改的 Code，達到「你 Code 中有我，我 Code 中有你」的理想境界。

• 程式設計的兩個觀點 (1/2)
• 程式設計的兩個觀點 (2/2)

「演算法 V.S. 架構設計，Round 1，Fight！」不論你是對於幾毫秒執行效能斤斤計較的演算魔人，或者是注重系統之間設計與連繫的架構魔人，請好好地閱讀這兩篇文章，或許你也會和我一樣，擁有另一番不同的體悟。

實際上，在我所撰寫過的程式碼中，並沒有使用到什麼非常複雜的演算法，或者是效能極為關鍵的單一函式。但對於程式設計者來說，即使你想要窮盡畢生心力追求程式架構中的美麗境界，也不該輕易忽略各種函式庫背後隱藏的效能成本，才能夠撰寫出執行效能良好的程式碼。

工作以外的程式設計

身為程式設計者，你還記得自己最初的動機與熱情嗎？程式設計，應該是一件很快樂的事情；如果你和我一樣，曾經失去熱情，每天上班不知為何而戰，逛網站比看程式碼的時間還多，那麼你必定要認真地讀一讀這篇文章。

做為大學科系的選擇、目前工作的選擇或者未來志業的選擇，興趣是個很重要的參考要素。然而當我們將自己的興趣與專長，轉化成為謀生工具以及經濟來源時，或多或少也必須屈服於現實環境之下，而無法像從前一樣隨心所欲的發揮。於是，當初的熱情與不顧一切的狂熱投入，也難免會隨著時間的遞移，一點一點的被現實面的種種挫敗所打散。

要找回那股最初的感動與熱情，我想說的是：「孩子，勿忘初心。」請不計成本、不論勝敗，然後一往無前地去做你真心喜愛的事物吧！我相信，即使是沒落已久的熱情，也能夠一點一點的找回來。

即使上述幾篇文章與遊戲程式設計並沒有直接的關連性，我仍然覺得，對於遊戲程式設計者來說，這些都是非常值得仔細閱讀的優秀文章。網站作者 Qing 的文筆相當精鍊而且說理清晰，把一些我曾經思考過與困擾過的議題，全部都鋪陳敘述的十分詳細，完全無須額外的贅言補述，請各位讀者慢慢閱讀、細細品嚐，必能達到心有同感、點頭稱是、拍案叫絕，接著豁然開朗以至於醍醐灌頂的境界。網站中其他的精彩文章，就留給各位去探索發現吧！

本文接續前篇文章「《Programming Responsiveness》：遊戲程式設計中的回應性」的遊戲回應性 (Responsiveness) 以及遊戲回應延遲 (Response Lag) 議題，進一步提出能夠實際測量反應時間的方法，同時對各款遊戲作品的回應性表現進行測試與分析。

（圖片來源：http://www.geardiary.com/）

在前文中，提到了遊戲開發者易於忽略的遊戲回應性問題，但是並沒有提出實際的測量方法；如果我們只使用人眼去觀察遊戲是否產生延遲情形，是相當主觀而且不準確的測量方法。身為遊戲開發者，我們需要更加精確的方法以及更為客觀的數據，才能夠證明遊戲的回應性緊密或者遲緩。在 PC 平台的遊戲上，通常比較少對於 FPS（遊戲每秒畫格）做出限制，強制鎖在 30 FPS 或者 60 FPS 的數值；但是在 Console 的平台上，遊戲需要從 30 FPS 或 60 FPS 中做出選擇。如果能夠取得客觀的延遲時間數據，遊戲開發者就能夠更明智地在兩個數值之間做出抉擇，進一步強化遊戲畫面以及遊戲操控性的表現。

想要測量遊戲中的延遲時間並不困難，只需要準備一台具備攝影功能的數位相機，對準遊戲中的電視螢幕與操縱手把進行錄影。作者使用的是便宜且常見的 Canon Powershot SD800IS 相機（我不清楚這台相機的價格算不算是便宜 XD）；將相機設定調整至「運動模式」或「快速畫格取樣率模式」，然後把取樣數調整至「60 FPS」後，使用腳架置放於電視螢幕前面；如圖所示，使相機能夠清楚地拍攝到電視螢幕畫面以及手上的遊戲手把，就可以開始拍攝遊戲中的各種操縱動作與結果反應。拍攝完畢後，可以使用 QuickTime 或其他播放軟體，以鍵盤的方向鍵每次移動一個畫格播放，計算出由按下按鈕到畫面呈現結果所花費的畫格數，也就是遊戲中的回應延遲時間。

由於目前市面上廣為流行的電漿電視與液晶電視，會在顯示畫面之前經過一些數位訊號的處理程序，因此無可避免地會導致一些額外的延遲時間；而傳統的映像管電視，反而能夠呈現出較高的回應時間值。瞭解如何進行測量，以及各種電視螢幕之間的延遲因素之後，就可以開始對各款遊戲進行實地測量。首先，我們需要一個校準數據，做為與各款遊戲的比較基準數值。在此作者選擇最單純應該也是最快速的「PlayStation 3 選單系統」操作，做為基準測量數值。

根據作者在傳統電視上使用 PS3 的選單系統所進行的測試，按下遊戲手把的方向鍵之後，直到第三個畫格，電視螢幕才顯示出選單項目。由結果可知，PS3 選單系統的反應時間為 3/60 秒，也就是 50 毫秒，是一個相當優秀的測試數據，同時也是理想上能夠在 PS3 平台上所達到的最快反應時間。另外，PS3 選單系統於電漿電視上的測試結果為 5/60 秒，與傳統電視之間存在著 2 個畫格，也就是 100 毫秒的差距。既然 PS3 選單系統能夠達到 3/60 秒的反應時間，所以對於以 60 FPS 為執行標準的遊戲來說，理想上也應該要達到 3/60 秒的反應時間值。

有了基準測量數值之後，就能夠開始測量各款遊戲中的動作反應時間了。作者所做的第一項測試，是在 PS3 與電漿電視上測試《俠盜獵車手 4》的開槍動作。由這張連續圖片可以清楚地觀察到，當玩家按下 R2 鈕擊發時，從第 0 個畫格開始計算，直到第 12 個畫格才出現相對應的槍火特效反應；也就是說，開槍動作的反應時間是 12/60 秒，即使是在延遲較低的傳統電視螢幕上，也會產生 10/60 秒的回應延遲時間！而這項測試結果，也反映出了許多玩家對於《俠盜獵車手 4》某些動作反應不流暢的抱怨，的確是其來有自。

除了《俠盜獵車手 4》以外，後續進行測量程序的各款遊戲裡，其中以 60 FPS 進行的遊戲反應時間數據為：

• PS3 選單系統：3/60 秒
• 《吉他英雄 3》（XBox 360 版）：3/60 秒
• 《實感賽車 7》：4/60 秒
• 《虛擬網球 3》：4/60 秒
• 《忍者外傳 SIGMA》：4/60 秒
• 《PixelJunk Racers》：4/60 秒

以 30 FPS 進行的遊戲反應時間數據為：

• 《源氏：神威奏亂》：6/60 秒
• 《托尼霍克極限滑板：練習場》：8/60 秒
• 《黑暗地帶：51區》：8/60 秒
• 《最後一戰 3》：8-10/60 秒
• 《極限滑板》：10/60 秒
• 《俠盜獵車手 4》：10/60 秒
• 《哈利波特 5：鳳凰會的密令》：10-14/60 秒
• 《玄天神劍》：7-18/60 秒

在這份列表中，可以看到《吉他英雄 3》的表現非常突出，能夠達到 3/60 秒的反應時間，這也正好是音樂節奏類型的遊戲，所必須具備的基本需求。另外，在上列的數個 PS3 遊戲中，沒有任何能夠達到 3/60 秒基準數值的遊戲，其中最佳的反應時間是 4/60 秒。而有幾個遊戲的數值範圍呈現出相當不穩定的狀態，其中又以《玄天神劍》最為嚴重；攻擊動作花費了 7/60 秒，而轉動方向的動作竟然需要花費兩倍以上的 18/60 秒！很顯然地，在這款遊戲的程式碼或者設計架構裡，必然隱藏著某種未解的臭蟲。

（圖片來源：http://scifipulse.net/）

另外一個值得注意的遊戲是《源氏：神威奏亂》；這是一個與《忍者外傳 SIGMA》玩法類型很相似的遊戲，不過《忍者外傳 SIGMA》是以 60 FPS 進行，而《源氏：神威奏亂》則以 30 FPS 進行。雖然以較低的 30 FPS 進行遊戲，但是《源氏：神威奏亂》讓人感覺不出延遲的問題存在；因為遊戲攝影機比較少快速地轉動，加上低對比度的圖像設計，以及遊戲所使用的動態模糊 (Motion Blur) 技術，全都成功地減少了遊戲的遲緩感。由於設計與實作層面的用心，雖然《源氏：神威奏亂》只有達到 6/60 的低反應時間，但是卻沒有對遊戲的操縱反應造成顯著的影響。這樣一來，程式設計者不必把遊戲硬撐上 60 FPS 的執行速度，反而使企畫設計者能夠放入更多的圖像、特效或者敵人，讓遊戲的內容更加豐富多樣化。

最後，根據各款遊戲的實地測量數據以及實際操縱體驗的比對，可以做出以下幾點結論：

• 雖然理論上 3/60 秒應該是可能達成的目標，但是根據測試的結果來看，4/60 秒的反應時間已經算是非常優秀的執行成果。
• 《源氏：神威奏亂》讓我們看到以 30 FPS 執行、反應時間 6/60 秒的遊戲，仍然能夠有很不錯的執行表現。
• 有些遊戲，例如《玄天神劍》，反應時間缺乏一致性與穩定性。既然某些動作反應能夠達到 7/60 秒的最佳數值，就應該使每一項動作的反應時間都達到 7/60 秒才是良好的遊戲設計與實踐。
• 遊戲開發者應該使用本文所述的方法，測量自己遊戲中各項動作的反應時間。由於越來越多的玩家，甚至是遊戲評論者，都開始使用平面顯示器進行遊戲，所以延遲的因素也越來越明顯可察覺；因此，遊戲開發者必須要努力解決遊戲的回應延遲問題，才不會使得嘔心瀝血製作的遊戲，因為操縱反應不順的小缺陷而招致負面的觀感與評價。
• 遊戲評論者也應該開始測量遊戲的反應時間數據，才能夠對遊戲做出更為客觀的評價。

除了節奏迅速的動作類型遊戲以外，我認為回應性與回應延遲的觀念也可以延伸應用於其他遊戲類型中。以我們常見的 MMORPG 類型遊戲來說，遊戲介面以及角色動作的反應性，都有進一步改善的空間。你是否曾經抱怨過遊戲介面的開啟速度過於緩慢？你是否覺得遊戲角色的攻擊動作與傷害特效看起來沒有同步？身為遊戲開發者，我們如何在網路的延遲因素影響之下，達到理想的回應性表現？針對遊戲的回應性，以下列出幾點我認為可以嘗試改進的方向：

• 視覺提示：在無法立即反應的介面中提供視覺上的提示，例如進度條、小動畫或提示訊息等等，清楚地讓玩家知道遊戲系統正在進行處理程序，而不是發生了網路延遲、系統當機或者是斷線的情形。
• 資料快取：將已知的歷史資料儲存在快取區中，就能夠很快地顯示沒有更動過的內容，同時只需要更新少部分有所變動的內容，因此可以減少資料處理與網路傳送的反應時間。
• 分層傳送：如果有大量的資料需要傳送，可以先傳送相關的綱要項目，再接著傳送細節內容；例如在任務介面的任務歷史列表功能裡，可以先傳送任務列表中的名稱、等級與需求，再接著傳送每一項任務的細節內容。
• 先斬後奏：在玩家按下輸入指令後，直接由 Client 端程式系統進行動作回應的「演出」，同時傳出訊息給 Server 端，再由 Server 處理資料邏輯面的判斷，並且視實際情況進行必要的校正。

另外，我們同樣能夠運用本文中所使用的測量方法，檢測開啟各項遊戲介面的延遲時間，以及各項角色動作的同步性來相互比較，藉此找出反應遲緩的介面與動作。乍看之下，遊戲反應性與延遲時間似乎是非常微不足道而旁枝末節的問題，但是對於玩家來說，往往就是這些細節決定了「這個遊戲很爛」或者「這個遊戲很好玩」之間的分別。身為遊戲開發者最重要的任務之一，就是使遊戲呈現出來的結果能夠符合玩家心裡的期待感，盡最大可能達到同步化的目標，使玩家全心全意地投入遊戲世界並且樂在其中。

在玩遊戲的經驗裡，你是否覺得有些遊戲玩起來不太順暢，但又說不上來是什麼原因；明明是單機的遊戲，卻覺得操作反應有些 Lag；狙擊槍的準星明明抖個不停，竟然也可以命中敵人。這篇文章裡，作者對於遊戲的「回應性」(Responsiveness) 這個鮮少有人提及的議題，做出了詳細的觀察與探究，非常值得遊戲程式設計者與遊戲企畫設計者閱讀參考。

（圖片來源：http://games.mattsarrel.com/）

如果以軟體領域的角度來檢視，遊戲軟體與其他軟體最大的不同之處，或許就是在於遊戲對「即時反應」(Realtime Response) 的嚴格要求。在一些節奏比較快速的遊戲中，如第一人稱射擊、賽車競速或音樂節奏類型遊戲等等，甚至不能夠承擔超過零點幾秒的延遲誤差。那怕只是一點點的延遲反應而已，都會破壞玩家對於遊戲的投入感；更甚者，也可能就此在玩家心中埋下難以逆轉的負面印象。

Response lag is the delay between the player triggering an event and the player receiving feedback (usually visual) that the event has occurred.

「回應延遲」(Response Lag) 的定義，是指從玩家觸發事件，直到玩家得到回饋反應的延遲期間。觸發事件，是指玩家藉由搖桿、手把、鍵盤或滑鼠等輸入裝置，觸發遊戲系統中的行為動作；而回饋反應，則通常是指遊戲中的視覺面呈現。如果在「觸發事件」與「得到回饋」兩者之間的延遲期間過於冗長，將會造成玩家認為遊戲反應遲鈍、動作慢吞吞或是操縱不順暢等等負面觀感。

當遭遇回應延遲問題的時候，許多玩家，甚至是遊戲設計者，都沒有辦法用正確的詞彙敘述遊戲的問題何在；多數玩家不會說「這個事件在我按下按鈕的 0.1 秒後才發生」，而是會說「這個遊戲感覺緩慢」、「遊戲的節奏不對」、「遊戲太過於困難」，或者只是說「這是個爛遊戲」。他們無法真正瞭解「爛」的成因為何，因為他們並沒有意識到延遲現象背後的成因。在進行遊戲測試時亦然如此；即使測試者沒有明確地回報關於回應延遲方面的問題，但這些問題可能只是以不同形式的敘述句表達。無論是企畫設計者，或者程式設計者都不應該忽略掉這些問題的嚴重性。

回應延遲通常不是由單一因素所造成的局面，而為了解決這個問題，首先我們必須知道現象背後的成因。由前述的定義可知，延遲時間簡單來說就是玩家按下按鈕到螢幕產生結果的期間；而為了瞭解延遲從何而來，首先必須知道遊戲程式在主迴圈 (Main Loop) 中進行了哪些工作程序。在遊戲的主迴圈中，主要有兩項基本任務：邏輯運算與繪圖；邏輯運算程序用於更新遊戲物件的狀態與數據，繪圖程序則負責繪製遊戲畫面的畫格 (Frame)，並且將結果呈現在螢幕上。除了上述的兩大程序之外，在主迴圈中，還會有個負責偵測輸入裝置系統的程序。以最簡化的遊戲主迴圈流程來說，程式碼如下所示：

// 遊戲主迴圈
while (1)
{
    // 偵測輸入
    Input();
    // 邏輯運算
    Logic();
    // 繪圖
    Rendering();
}

特別要注意的是，在 Rendering() 函式中所執行的工作，其實僅限於 CPU 端進行的繪圖運算程序，例如 Transform、Culling、Sorting 等等工作；而真正的低階繪圖程序，則是在 CPU 端的繪圖程序之後，以非同步化 (Asynchronous) 的方式交由 GPU 端進行處理。

那麼，遊戲主迴圈中的回應延遲從何而來？請參照這張精美的圖片；從玩家按下按鈕直到結果顯示於螢幕上，總共可以分為 4 個階段，分別為 Input、CPU、GPU 與 TV：

• Frame 1：在第 1 個畫格時，於其中的某個時間點，玩家按下了按鈕。
• Frame 2：第 2 個畫格中，主迴圈於 Input() 函式中偵測到了玩家的輸入事件，並且於接續的 Logic() 與 Rendering() 函式中進行相關的更新與繪製動作。
• Frame 3：第 3 個畫格中，由 GPU 非同步化進行真正的繪圖程序。
• Frame 4：最後，在第 4 個畫格裡，將剛完成繪製的畫面顯示到螢幕上。

由 Input 至 TV 階段，正好對應於 Frame 1 到 Frame 4，共計需要花費 3 個畫格的時間。所謂的 3 個畫格是多久的時間？對於以 30 FPS（每秒 30 個畫格）進行的遊戲來說，3 個畫格就是 3/30，十分之一秒；對於以 60 FPS（每秒 60 個畫格）進行的遊戲來說，3 個畫格就是 3/60，二十分之一秒。所以，當玩家按下輸入裝置上的按鈕時，在最佳的情況下，至少需要二十分之一秒的時間，才能夠見到螢幕上呈現出來的結果。

以上，只是最佳狀態 (Best Case) 的情境；但是現實世界經常不是處於最佳狀態。所以，不如來看看怎麼把事情弄得更糟一點。在上述的程式碼中，假設我們把 Logic() 與 Rendering() 函式的順序對調，遊戲的主迴圈程序就會變成：

// 遊戲主迴圈
while (1)
{
    // 偵測輸入
    Input();
    // 繪圖
    Rendering();
    // 邏輯運算
    Logic();
}

在這個主迴圈的程序裡，由於 Redering() 先於 Logic() 函式執行，所以於 Logic() 函式中更新的遊戲物件狀態，就必須等待下次進入主迴圈，也就是下一個畫格裡，才能夠將邏輯運算更新的物件狀態傳入 Rendering() 函式中繪製。因此，只要單純地改變函式的順序，就能夠順利地多出額外的一個畫格延遲！

只是多了一個的畫格延遲，看起來不夠糟嗎？精彩的還在後頭。

假設在遊戲裡，我們使用了某個物理引擎藉以改變物件的行進方向與位置。與物理引擎程式碼相關的部分，可以在 Logic() 函式中進行處理：

void Logic()
{
    // 處理玩家的輸入，並且丟出相關的事件訊息
    HandleInput();
    // 更新物理引擎
    UpdatePhysics();
    // 處理事件訊息，進行相對應的動作
    HandleEvents();
}

看起來是沒有任何問題的處理程序。然而，上述的遊戲系統，又再度多出了一個額外的畫格延遲。

以遊戲中的開槍行為為例，當玩家按下射擊按鈕，在 HandleInput() 函式中，會接收到輸入的指令，並且發出事件訊息告訴「槍」這個物件執行「開火」的動作；而在 HandleEvents() 函式中，「槍」物件會接收到事件訊息，並且做出實際的開槍動作與邏輯處理。然而，由於 UpdatePhysics() 先於 HandleEvents() 函式執行，所以開槍事件對於遊戲中各物件物理狀態的影響，會直到遊戲主迴圈下一次進入 Logic() 函式時才產生效果，因此也就再次成功地製造了一個額外的畫格延遲。

另外一個類似的情境，發生於「先更新物件位置，隨後才更新物件速度」的狀況裡。理由同上，因為已經更新完物件的位置數值，所以在同一個畫格中，即使物件的速度產生了變化，也無法立即反應在物件的位置上；只能夠在下一次處理物件更新程序時，物件的位置才會正確對應於上個畫格中改變的物件速度。

總結以上所述，共計有三項顯而易見的錯誤：

• 在進行邏輯運算之前，先進行繪圖程序。
• 在更新物理引擎之後，才處理事件訊息邏輯。
• 先更新物件的位置，之後才更新物件的速度。

「反正只不過是相差一個畫格而已嘛！」或許一個畫格延遲的效應看似微不足道，不會對遊戲造成任何影響；然而，畫格延遲的問題本身具有累積效應，如果遊戲程式設計者，同時犯了上述三項錯誤，將很有可能使得原來只有 3 個畫格的延遲時間，倍增為 6 個畫格的延遲時間。對於 60 FPS 的遊戲來說，6/60 已經佔去 0.1 秒的時間，而對於 30 FPS 的遊戲，6/30 更是達到 0.2 秒，足足有 200 毫秒的延遲時間！就遊戲軟體的需求條件來說，這是相當令人難以接受的執行表現。

而除了上述三項常見的錯誤以外，還有更多其他的因素可能造成時間延遲的問題。有時候美術動作設計者 (Animator) 會在動作上加入一點點額外的速度改變，使得角色的動作看起來更加符合視覺上的效果；然而在配合遊戲操控時，卻可能變成看起來好看，玩起來感覺很糟的情況。另外，像是觸發角色的動作 (Animation) 事件時，系統可能會在下一個畫格中，才真正前進至指定動作的第一個畫格，因此使得角色動作的反應延遲現象更加嚴重。以上這些比較難以察覺的畫格延遲因素，也很容易悄悄地潛入遊戲系統之中。

最後，作者提到一般人對於「回應性」這個議題最大的誤解，就是與反應時間 (Reaction Time) 之間的關連性。在討論遊戲反應性問題時，經常會被提起的反駁論點是：「玩家的反應時間最快約可到達 0.15 秒至 0.3 秒左右，再怎麼樣也不可能有快於 0.1 秒的反應能力。」然而，這項推論其實相當值得懷疑。

It’s not how fast a player reacts to the game; it’s how fast the game reacts to the player. The issue is not one of reaction times, but of synchronization.

真正的關鍵在於同步化的感受。以《吉他英雄》為例，玩家必須在音弦符號來到特定區域時，準確地按下相對應的按鈕；在這樣的情境下，身為玩家的你，已經預測了未來幾秒內即將發生的事件，而與所謂的反應能力全然無關。重點在於玩家預期按下按鍵之後，音弦符號的誤差最多不會超過幾個像素點。所以如果在遊戲中發生了時間延遲的現象，就會造成音弦符號飄移過該區域才產生結果反應，也因此導致玩家心理預期與視覺回饋上的落差。

（圖片來源：http://electronics.howstuffworks.com/）

對於其他類型的遊戲來說，同樣存在著同步化的需求；例如在 FPS 類型的遊戲中，熟練的玩家不會等到敵人落在準星範圍內才按鈕開火，而是會先一步預測敵人的行進路線，提早約 0.5 秒左右開槍射擊才能命中目標。如果發生了時間延遲的情形，就會看到敵人明明位於準星的範圍之外，卻仍然中槍爆頭，造成邏輯與視覺效果的不同步狀況。簡單來說，遊戲的表現與回饋機制，必須要能夠符合玩家預想中的結果。

在遊戲的過程中，有許多操控行為例如走路、跳躍、攻擊等等，是每次進行遊戲都需要重複幾百次，甚至上千次的動作；如果在這些基本的操控行為中，產生了嚴重的時間延遲問題，而沒有被研發團隊與測試團隊發現，那麼即使是一款美術再漂亮、玩法再創新的遊戲，都很有可能無法獲得玩家的青睞而只能黯然下台。對於遊戲企畫設計者與程式設計者來說，這些反應性的問題並不容易在開發過程中引起注意，我們需要積極地去發現時間延遲的問題，才能夠製作出操控性更佳的遊戲。以後聽到有人說「這個遊戲真爛」或者「遊戲玩起來有點卡卡的」之類的話，你也能夠從另外一個角度思考了。

在下一篇文章裡，作者將帶領我們使用簡單的器材與方法測量遊戲的延遲時間，並且檢驗各款上市遊戲的延遲數據。

這是一篇很有意思的短文。文中條列出不多不少、總共十項優秀軟體工程師所應具備的特質，並且很微妙地將軟體工程師比喻成搖滾明星。你是公司的主管嗎？按照這些特質尋找人才就對了！你是在學的學生嗎？按照這十項特質的方向努力學習就沒錯了！

在這十個特質中，我認為最關鍵、同時也是寫得最為貼切的莫過於第一點：Loves to Code。

1. 真心喜愛程式 (Loves to Code)

程式設計，是一種發自於內心、不求回報的付出 (Labor of Love)。如同任何的職業一樣，唯有具備滿滿的熱情，才能完成真正偉大的事情。一般人的誤解，常認為撰寫程式是一種機械化，或者純然科學化的行為。事實上，最棒的軟體工程師是工匠 (Craftman)，能夠將能量、巧思以及創造力注入每一行的程式碼當中。優秀的工程師，知道程式碼區塊何時被琢磨至完美的程度，也知道在大型的系統中，這些區塊何時會如同謎題般巧妙地拼湊組合起來。熱愛撰寫程式的工程師所獲得的喜悅感，就像是作曲家完成一首交響樂所感受到的狂喜；而也正是這種興奮感以及成就感，使優秀的程式設計者們真心熱愛程式設計。

我個人非常、非常地喜歡以上整段的敘述。Labor of Love 是一個非常棒的形容詞，幾乎將我內心最深層的感動，完整無缺地表達了出來。是否有時會覺得累、覺得倦，或是覺得不知所做為何？不妨回頭找找自己最初的本心吧。

2. 把事情完成 (Gets Things Done)

有些技術人喜歡只說不做，而優秀的工程師是會真正去做事的人。有些人為了找出最佳的方法解決問題，會花費數週的時間設計出複雜且多餘的系統架構與函式庫；真正優秀的程式設計者應該問自己：什麼才是解決問題最容易的途徑？

請記得我們身處現實世界中，而非傳說中的理想境界，沒有所謂的完美解決方案存在。做為程式設計者，我們所應當盡力去做的事情，就是利用手邊既有的各種資源，以最有效率的方式完成交派的任務。如果不能夠把事情完成，再神妙的構思與設計都只能活在白日夢，以及那些不著邊際的大話裡。

3. 持續地重構程式 (Continuously Refactors Code)

撰寫程式，與雕刻非常相像。就像藝術家會不斷地改善自己的創作作品，程式設計者也會持續性地改造自己的程式碼，只為了以最好的方法達到需求的目標。

不要變成老舊程式碼的奴隸。當這些程式碼是由其他人撰寫的時候，你或許可以輕易地推卸責任或者怪罪於別人；但是在多數的情況下，當這些可惡的程式碼，是由你自己所撰寫的時候，才是最令自己捶胸頓足、欲哭無淚的時候。請拿出細心、耐心與愛心，勇敢地挑戰那些殘破不堪的老舊程式碼吧。

4. 使用設計模式 (Uses Design Patterns)

所謂的模式 (Pattern)，是不斷重現在自然界與人類行為中的各種情境以及機制；而軟體工程也不例外。優秀的工程師能夠辨認出系統中所使用的設計模式，並且善加利用各種設計模式，同時也不受制於它們。

設計模式是前人智慧的結晶，幫助我們解決重複出現的類似設計難題，同時也成為程式設計者之間的溝通橋樑；但請記得，它們絕對不是程式設計中的萬靈藥：不要為了使用設計模式而使用設計模式；設計模式並不能使原來就很差勁的程式碼變得比較高明。

5. 撰寫測試 (Writes Tests)

有經驗的程式設計師，總是能夠瞭解撰寫測試程式碼的價值所在。測試的存在，能夠證明撰寫完成的系統運作無誤，並且確保過去曾經發生過的臭蟲問題不會再次重現。

為了進行測試而撰寫多餘的、與功能無關的程式碼？專案的進度怎麼辦？還有許多功能項目需要完成？所有的理由都是忽略撰寫測試程式碼的好理由。直到被臭蟲痛咬一口之前都是。花費心力在關鍵的程式碼區塊中撰寫測試，將能夠為你節省下難以計數的除錯時間；但很遺憾地，就我所知，目前台灣的業界並沒有撰寫測試程式碼的風氣，仍然亟待改進。

6. 善用既存程式碼 (Leverages Existing Code)

重新發明輪子一直都是軟體產業中的大問題。優秀的工程師會專注於三種不可或缺的復用 (Reuse) 層面：第一，使用同儕已經撰寫好並且經過測試的系統架構；第二，善用第三方團體所提供的函式庫；最後，則是利用某些網路服務所提供的便利功能。正確地善用既存的程式碼，才能使程式設計者專注於真正重要的任務上，也就是應用程式本身。

不要再寫第一千零一個 Linked List 類別了！不使用其他人撰寫的元件，堅持所有的功能都要由自己親手完成，究竟是自大、自爽、自衛還是自慰？請搞清楚自己的目的、專案的目標，以及核心關鍵的任務。

7. 專注於可用性 (Focuses on Usability)

好程式設計師專注於使用者。無論使用者是事業體或者個人，無論程式設計者為消費性軟體公司或者投資銀行工作，專注的焦點同樣在於可用性。優秀的程式設計者會非常努力地工作，只為了使系統更加簡單並且更為容易使用。他們無時無刻都會想到使用者，不會撰寫出錯綜複雜只有怪咖能夠理解的系統。

這是一項經常被忽略的重要特質。有時候，程式設計者寫得太開心太入迷，往往會忘了撰寫出來的程式，是需要交給其他使用者使用的東西。對於程式設計者來說，使用者的角色其實存在於許多不同的面向中，包括專案中的主程式、企畫設計者，以及遊戲成品的玩家，都是開發過程中需要「常在我心」的使用者。

8. 撰寫可維護的程式碼 (Writes Maintainable Code)

工程師界的小秘密：撰寫好程式碼或者壞程式碼，所花費的時間一樣多！紀律良好的工程師，會從第一行程式碼就開始思考維護性以及程式碼未來的演化。絕對沒有任何理由寫出醜惡的程式碼、橫跨數個頁面的函式，或者帶有稀奇古怪名稱的變數。每一字、每一句、每一行的程式碼，都應該恰如其份地展示出它們原先擁有的意涵。

不要總是認為以後、未來或者某一天，一定會有機會回頭改寫那些從前寫不好的程式碼，因而和自己做出妥協，寫出只是暫時堪用的程式碼。事實上，不遵守紀律的程式撰寫方式，不僅難以節省開發的時程，更無法順利推動專案的進度。重構的觀念與程序並不是偷懶的藉口，也不能拯救一個病入膏肓的系統架構。維持良好的寫作風格、命名規則以及嚴謹的設計架構，都是非常重要的基本守則。

9. 能夠以任何程式語言撰寫程式 (Can Code in Any Language)

優秀的程式設計師或許會有個人喜愛的程式語言，但從不固執迷信於其中。在很多的情境中，程式語言的重要性往往不如那些伴隨程式語言而來的函式庫。優秀的程式設計者能夠體認這項事實，並且願意去學習新的程式語言、新的函式庫以及新的方法以建造出更好的程式系統。

對於知識，要求知若渴；對於自己，要能虛懷若谷。保持開放的心態，對新鮮的事物保持孩子般的好奇心；而不是像個「大人」般被冷漠的態度與嘲諷的言語佔據內心，困守在象牙塔中而不自知。電腦科學與軟體程式設計領域的進展飛快無比，不止要從書本中獲取知識，更要盡可能地從網路、研討會，甚至身邊的同儕，學到那些經過真實歷練的經驗與智慧。

10. 瞭解基礎的電腦科學 (Knows Basic Computer Science)

優秀的工程師需要紮實的基礎。也許你沒有資訊科系的學位，但你不能不認識其中的基礎知識：資料結構與演算法。明星級的程式設計師不但需要瞭解，更要能夠內化這些基本知識，因為擁有這些知識基礎，將能夠幫助我們在軟體系統中做出正確的設計決定。

在 90% 的狀況中，我們不會需要使用複雜可怕的資料結構或令人畏懼的演算法，但是請至少先瞭解其中最基本首要的部分。什麼時候該用 vector？什麼時候可以用 list？如果使用 deque 的話有什麼差別？應該優先考慮執行效能，或者優先考慮記憶體空間，甚至是未來擴充的彈性？不同的資料結構與演算法之間，有沒有不同的取捨？招式是死的，用的人是活的，能夠順應局勢見招拆招，才是好本事！

以上，就是為了成為超級星光大道的 Super Star Programmer 所需具備的十項基本特質。看完上述十點特質之後，是不是覺得好像還少了點什麼？是不是有某個很重要的特質沒有被列入其中？還有什麼樣的態度、能力或特徵，是你認為做為一位優秀的程式設計者所不可或缺的呢？歡迎提出來討論喔～ ^_^