在專案管理領域中，所謂的時程，也就是一般常聽到的 Schedule 一詞。當上司、主管或者指導教授交付給你一項工作時，需要知道這項任務的預估完成時間。我們身為遊戲開發者以及工作執行者的身份，應該要使用什麼方法來預估工作的時程？如何達到預估的準確性？工作時程中又隱含著些什麼樣的秘密呢？
經過前篇文章「遊戲開發入門：專案管理管什麼？」的介紹之後，相信即使是從未接觸過專案管理領域的讀者，也能夠對於專案管理的基本概念有一些基礎的概念與認識。接下來，本篇將深入時程的層面，探討在專案管理中相當重要的專案時程估算議題。
（圖片來源：www.codinghorror.com）
任何一項工作的時程安排，都需要具備三項條件：起始日期、結束日期以及與其他工作的依存關係。在專案管理領域以及專案時程表中，最受到廣泛使用的甘特圖 (Gantt Chart)，可以用清楚易懂的圖示來描述工作項目的這三項條件。而另外一項在專案時程中會經常聽到的術語是 Work Breakdown Structure（工作分解結構），或經常簡稱為 WBS。簡單來說，WBS 近似於前篇文章裡所提到的「工作項目階層分解程序」，能夠將原來非常龐大的功能項目，逐步往下分解為可處理的單一工作項目。
在遊戲開發流程中，為什麼我們需要制訂出專案時程表？
繼續閱讀 << "遊戲開發入門：專案時程怎麼估？"
本篇是推薦文。很短，但藥效很靈而且不傷身體噢。
我要誠心誠意地推薦一個網站「程式者的胡言亂語」，以及其中的一些文章，給各位現在身處業界或者未來即將成為程式設計者的讀者。
繼續閱讀 << "給遊戲程式設計者的推薦文章"
３，是一個很奇妙的數字，經常用來描述相互抗衡，同時又彼此連結的能量關係。
生命生存的三要素是陽光、空氣與水；色彩學中的三原色是紅色、綠色與藍色；三國演義的三霸主是曹操、孫權與劉備；程式的三元素是語言、API 與工具。而在《薩爾達傳說》的故事背景中，則仰賴著力 (Power)、知惠 (Wisdom) 與勇氣 (Courage) 所結合而成的 Triforce 維持著世界的平衡。
（圖片來源：http://www.neoseeker.com/）
以遊戲作品來說，受到玩家喜愛的原因可能有很多，例如畫面漂亮、故事感人、音樂動人、操縱流暢以及玩法創新等等許多不同的因素。但是如果從遊戲創造者的觀點檢視，各位是否曾經思考過遊戲開發的三大原力為何？遊戲業界中是否也存在著神秘又奧妙的三原力？本文中，將分別以研發部門、專案管理以及遊戲開發，這三種不同角度的觀點，探討遊戲開發領域中的「三大原力」。
繼續閱讀 << "Triforce：遊戲開發三原力"
原文出處：Measuring Responsiveness in Video Games
本文接續前篇文章「《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 或其他播放軟體，以鍵盤的方向鍵每次移動一個畫格播放，計算出由按下按鈕到畫面呈現結果所花費的畫格數，也就是遊戲中的回應延遲時間。
繼續閱讀 << "《Measuring Responsiveness in Video Games》：測量與分析遊戲的回應性"
原文出處：Programming Responsiveness
在玩遊戲的經驗裡，你是否覺得有些遊戲玩起來不太順暢，但又說不上來是什麼原因；明明是單機的遊戲，卻覺得操作反應有些 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) 的定義，是指從玩家觸發事件，直到玩家得到回饋反應的延遲期間。觸發事件，是指玩家藉由搖桿、手把、鍵盤或滑鼠等輸入裝置，觸發遊戲系統中的行為動作；而回饋反應，則通常是指遊戲中的視覺面呈現。如果在「觸發事件」與「得到回饋」兩者之間的延遲期間過於冗長，將會造成玩家認為遊戲反應遲鈍、動作慢吞吞或是操縱不順暢等等負面觀感。
繼續閱讀 << "《Programming Responsiveness》：遊戲程式設計中的回應性"
自前一篇「物件導向設計新思維：探索Policy-Based Class Design新視界」發佈以來，已經過了很長的一段時間。在這篇千呼萬喚始出來的續集裡，將會進一步深入探索 Policy-Based Class Design 背後的設計概念與理論，以及在實作層面上經常會遭遇到的問題；最後，以一個遊戲系統中常見的音源引擎 (Audio Engine) 類別設計為範例，做為本文的片尾曲目。
記得曾經有人問過比爾蓋茲，如果有天他被迫一人獨自在荒島上生活，身旁只有一樣物品陪伴的話，最想要什麼東西？他的回答是：「一部電腦與編譯器。」許多程式設計者心裡所嚮往的美好世界，就是那種無拘無束、無邊無際的自由；好像只要手指還能夠活動、頭腦還能夠寫程式，天底下就沒有辦不到事情！只是，有時候這種無限度的自由，反而會對程式系統造成負面的影響。
在《C++ 設計新思維》(Modern C++ Design) 書中的第一章，就對於程式系統的設計就開宗明義地闡述：
理想上，一個良好設計應該在編譯期強制表現出大部分 constraint（約束條件、規範）。
身為一位程式設計者，或多或少都有把自己的程式碼交給其他程式設計者使用的經驗，相對於「程式撰寫者」來說，所謂的「程式使用者」，就是那些使用你所撰寫的程式碼的人。就像是遊戲程式中經常使用的 DirectX、OpenGL 或者 .NET Framework 以及遊戲函式庫與引擎等等，我們都是身為「程式使用者」的身份。
繼續閱讀 << "物件導向設計新思維：深入Policy-Based Class Design新大陸"
Loading ...
