遊戲開發‧遊戲程式‧遊戲設計
Aug 05 2009
遊戲平台
遊戲連結
遊戲概述
考驗你對色彩的記憶能力！
請記憶「色彩方塊」出現的順序，然後依此順序一一點選畫面上的「色彩機器人」。每次遊戲共有三次機會，結束後會對你的記憶體能力值做出綜合評比。
Jul 01 2009
從以前到現在，陸續有一些朋友及讀者向我反應這個問題，所以我想我必須好好地解釋並提出聲明。
「閱讀選錄是什麼鬼？」
關於猴子靈藥的「閱讀選錄」分類下的文章，目前總共包括「遊戲業界閱讀」、「遊戲程式閱讀」、「遊戲設計閱讀」、「遊戲美術閱讀」與「遊戲開發閱讀」五類。請注意，在這個分類底下的文章，全部都不是由我自己原創撰寫的內容，而是來自國外遊戲開發網站的優質專業文章。
Jun 30 2009
（圖片來源：www.cals.ncsu.edu）
原文出處：Game Artists: The Three Cardinal Rules
這是一篇專為遊戲美術設計者所寫的文章，同時也是一篇對所有遊戲業界從業者很有幫助的文章。
在這篇文章裡，作者提出了三項最基本也最重要的準則：自我意識管理、專業面向的溝通，以及接受多樣化任務。其中，佔最多篇幅的內容在於專業溝通的議題上。多數人都知道「溝通」非常具有重要性，但是在現實生活與每天的工作中，到底該怎麼做才能達到良好的溝通成效？該用什麼樣的態度與主管溝通？該用什麼樣的方式與同儕溝通？要如何說話提問，那些該死的企畫設計者與程式設計者才聽得進去？本文為遊戲美術設計者，提出幾項實用而懇切的溝通要領。
本文作者 Keith Self-Ballard 從普渡大學 (Purdue University) 的電腦繪圖技術系畢業後，旋即進入遊戲產業工作。目前他在遊戲公司裡擔任美術部門主管的職務，也同時兼任母校的業界諮詢委員。去年，電腦繪圖技術系的教授向他詢問，是否能夠提供一些給美術設計者的小提示，讓學生們能夠瞭解什麼是他們必須學習與追求的東西。
這是個令 Keith 十分感興趣的議題。十年多以前，當他剛進入遊戲業界時，對於如何成為專業的遊戲美術設計者，他只有非常非常稀少而有限的認識。當他學習到新的工具與技術之後，同時也發展了自己的知識，瞭解該如何與同儕以及領導者協同合作，在製作過程中解決問題，並與各種不同類型且擁有獨一無二特質的人共同工作。
在那個時候，Keith 也在自己專業工作上犯了一些錯誤。我們每個人都會犯錯，幸運的是，他犯的錯並沒有糟糕到使他的業界生涯終止的程度；其中大多數的錯誤，應該都是剛進入業界的新血員工容易犯的那種錯誤。這些年來，不論是對於自己或者他人所犯的錯，Keith 繼續以這些錯誤行為做為自己的警惕，並持續地觀察這些錯誤所造成的衝擊與影響。
當他在兩年多前成為管理階層的一員時，他開始面對關於美術設計者的成員管理、人才招募，以及個人績效評量等各種事務。正因如此，他熱切地想要識別出對專業美術設計者的共通期望。於是，他開始研究遊戲業界對於美術設計者，究竟保持著什麼樣的期望。最終他想要獲得某些具體的東西，使他能夠與美術設計者分享，並對於那些直接從教育機構進入業界的新血，或者從其他業界進來而不夠清楚瞭解準則的員工，能夠用來做為一項訓練輔導工具。
繼續閱讀 < < "《Game Artists: The Three Cardinal Rules》：給遊戲美術設計者的三大基本準則"
Apr 30 2009
（圖片來源：diplomaguide.com）
原文出處：So You Want To Be A Producer
「遊戲製作人」(Game Producer)，或許你曾聽過這個高貴的職稱，或許你心中有幾位崇拜的業界典範，或許你從小就立下志向想成為一位遊戲製作人。但是，你真的知道什麼是「遊戲製作人」嗎？
製作，是個有點過於廣泛而籠統的詞彙，也使得「製作人」職位蒙上了一種神秘的色彩。在遊戲開發過程中，程式設計者不斷製作程式碼，美術設計者不斷製作圖片與模型，企畫設計者則不斷製作規則、數值與文件。在這樣分工明確、三足鼎立的研發團隊中，製作人究竟扮演著什麼樣的角色？是肉盾坦克、控場輔助、看護療癒、傷害輸出者，或者只是個可有可無的尷尬角色？
讓我們先回頭想想，遊戲界裡的幾位大師級遊戲製作人，像是製作《模擬城市》系列的 Will Wright，製作《潛龍諜影》系列的小島秀夫，以及製作許多任天堂經典作品的宮本茂，他們是不是成天坐在自己舒適寬敞的辦公室裡，憑空想像出遊戲的各種設計與創意玩法，然後豪爽地說聲「去吧！」就把自己天馬行空想出來的好主意交給底下的人，進而製作出一款又一款經典遊戲作品的那種人？
到底應該如何定義「遊戲製作人」？更進一步來說，遊戲製作人的職責與任務為何？如果你是嚮往遊戲業界的學生，你可能想瞭解要成為遊戲製作人必須具備哪些專業技能與個人特質；如果你是身處遊戲業界的遊戲人，心裡可能已經有一套對於遊戲製作人角色的定見。不論你對遊戲製作人的認識有多少，藉由這篇文章，作者將帶領我們一窺遊戲製作人在開發過程中所需承擔的各項職責與任務。
Producer 〈名詞〉
- 能夠成為遊戲發行商與遊戲開發團隊之間的聯繫橋樑的人
- 製造煤氣的熔礦爐
英文的 Producer 具有兩種截然不同的意義，如果你想要知道熔礦爐是怎麼製造出煤氣的話，你肯定是走錯地方了。而如果你想要學習成為遊戲製作人的各種基礎概念的話，請繼續往下讀吧！
Apr 09 2009
（圖片來源：potq.cl）
標題壞掉了？沒壞，就是 12345。
從 2004 年 4 月踏入遊戲業界開始，到現在 2009 年 4 月為止，已經滿 5 年整了。說起來就像是算算數一樣，用完一隻手的五根指頭 12345 剛剛好，但卻又不是像算算數一樣簡單的 12345。
五年，代表著什麼樣的意義？有人說，在一個行業裡持續工作滿五年的時間，表示你正式從菜鳥的行列中畢業了，雖然還稱不上是功力深厚的老手，但至少也是個具有一定裝備等級的「中手」。最近這段時間以來，幾次試著動筆想為自己的五年下些註解，卻不知從何開始。回首來時路，在這五年的光陰裡，雖然經歷過大大中中小小數個不同的遊戲專案，但竟沒半個能夠稍微拿來說嘴，或者能夠引以為傲的遊戲作品，想來真是有些令人沮喪。
所以我害怕，也不害怕。
Mar 27 2009
這是我在近期內對於 Threading 主題的學習整理文。如果你對於多執行緒程式設計沒有半點概念的話，建議可以先從我之前寫的「多核多緒多樂趣」開始閱讀，然後再視個人需求取用以下各項資源。
所謂的「多執行緒」程式設計，或者可簡稱為「多緒」程式設計，在英文中有許多相關的專業技術名詞，例如 Threading、Multithread、Concurrency、Parallel、Multicore 與 Multiprocessor 等等，在搜尋資料時可以嘗試不同的關鍵字，往往可以找到不少意料之外的好東西。而其中最常見的總括性簡稱，應該就是 Threading 了。
既然要學習 Threading 程式設計的知識，首先要瞭解的當然是 Threading 的基礎概念：
Mar 17 2009
（圖片來源：www.codinghorror.com）
原文出處：Physics in Games: A New Gameplay Frontier
截至目前為止，在猴子靈藥中從未探討過與遊戲物理學相關的課題，主要原因是我以前從未接觸過任何物理引擎或物理面向的應用程式，所以相當缺乏對於遊戲物理學的概念與知識。讀完這篇文章以後，我總算是開了眼界，對物理學有了一番新的體悟，也開始能夠想像如何在遊戲中的運用各種物理學的觀念。所以我希望藉由分享原作者所寫的這篇文章，讓大家都能認識並且開始思考遊戲物理學的設計應用。
如許多老玩家所知，在遊戲中使用物理學，並不是什麼新鮮的事情。事實上在許多年代久遠的老遊戲，譬如《Lunar Lander》與《Marble Madness》中，已經充滿許多與「重力」這項物理特性互動的遊戲性。隨著時代的推移演進，今日我們所擁有的嶄新技術方案，使遊戲開發者能夠將更進階而且更新穎的物理學特性運用於遊戲之中。
物理學處理程序對電腦運算能力的要求非常高，所幸拜核心數目越來越多的中央處理器，以及專門的硬體加速卡誕生所賜，身為遊戲開發者，現在我們可以真正深入考量如何在遊戲中緊密結合物理學的使用。而真正的問題所在，是我們該利用這些新的資源來做些什麼事情？直到目前為止，遊戲中所使用的物理學大多侷限於裝飾性的效果，雖然這些效果能帶給玩家很重要的沈浸感受，但卻無法真正改變現有的遊戲性。
當我們瞭解物理學在遊戲性中各種應用的可能性以後，我們又該如何提供給玩家與物理學相關的全新體驗？本文的目的就是為了回答這些問題，同時作者也分享了他從設計多人連線地圖模組 CTF-Tornado 中所學習到的經驗。（CTF-Tornado 是在《Unreal Tournament 3》中，被設計來充分發揮 Ageia 物理加速卡優勢的地圖。）
首先讓我們從一些物理學的基礎定義開始吧。物理學的範疇並非僅侷限於模擬重力或者物體與物體間的碰撞行為，實際上物理學也包含了以下這些應用：
由此可知，物理學涵蓋了相當廣泛的內容，而其中有些理論仍未實際被應用於遊戲之中。因此我們可以預期，物理學的發展潛力非常龐大，但遊戲開發者所面臨的各項議題也十分具有挑戰性。隨著開發者在遊戲中使用物理學而產生出來的難題，主要可以分為以下四個項目：
讓我們更進一步仔細地檢視每一個項目。
繼續閱讀 < < "《Physics in Games: A New Gameplay Frontier》：遊戲中的物理學，遊戲性的新疆界"
Mar 09 2009
很久沒有寫程式設計入門知識的相關文章了，這篇文章要來談談程式庫 (Library) 連結，以及關於 MSVC 與 CRT 之間的種種恩怨情仇。
如果你使用的作業系統是 Linux、Mac 或其他非 Windows 平台，你可以忽略這篇文章；如果你使用的作業系統是 Windows 平台，但沒有用 Microsoft Visual Studio C++（以下簡稱為 MSVC）軟體撰寫 C++ 程式的話，這篇文章對你的幫助可能很有限；但如果你的作業系統是 Windows，而且你使用的程式整合開發環境是 MSVC 軟體撰寫 C++ 程式的話，這篇文章應該能夠幫助你釐清一些重要的基礎觀念。
身為程式設計者，在學習程式設計的過程中，你是否曾經遇過某些看起來不知所云的錯誤訊息，卻不知該如何解決？例如當你快快樂樂地寫完程式，並且確認所有的程式碼都能成功通過編譯之後，接著執行「建置方案」(Build Solution) 的步驟，結果卻跑出一堆莫名其妙的錯誤：
LIBCMTD.lib(mlock.obj) : error LNK2005: __lock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定義過了
LIBCMTD.lib(mlock.obj) : error LNK2005: __unlock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定義過了
LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup 已在 MSVCRTD.lib(crtexe.obj) 中定義過了…………
LINK : warning LNK4098: 預設的程式庫 ‘MSVCRTD’ 與其他使用的程式庫衝突，請使用 /NODEFAULTLIB:library
LINK : warning LNK4098: 預設的程式庫 ‘LIBCMTD’ 與其他使用的程式庫衝突，請使用 /NODEFAULTLIB:library
D:\Workspace\CrtLibTest\Debug\CrtLibTest.exe : fatal error LNK1169: 找到有一或多個已定義的符號
以一般的情況來說，如果在你的程式專案中有使用某些由他人所撰寫的第三方程式庫或是開源專案的程式庫，比較容易會發生上述的錯誤狀況。從上述這些看似離奇而令人摸不著頭緒的錯誤訊息中，我們大概可以猜測問題點應該在於 LIBCMTD.lib 與 MSVCRTD.lib 這兩個程式庫身上。但到底什麼是 LIBCMTD.lib 和 MSVCRTD.lib？在我們的程式碼中有使用這些程式庫嗎？
Mar 02 2009
原文出處：Postmortem: RiverMan Media’s MadStone
「有許多人以為他們想要製作遊戲，但是只有非常少數的人瞭解遊戲開發所需的投身奉獻與持續耐久力。在專案最初的興奮感褪去之後，你必須在數以月計或數以年計的日子中，身處看不見光線的隧道盡頭裡辛勞地工作。你必須足夠熱愛製作遊戲，以致於就算在視線中看不見終點或者金錢時，仍然能夠保有無與倫比的熱情。」—— Jacob Stevens
（圖片來源：www.paec.org）
在 18 年前，當 Jacob Stevens 只有 8 歲大，而他的弟弟 Paul Stevens 只有 4 歲大的時候，他們就下定決心要為任天堂公司製作遊戲。當時他們並不知道要做些什麼，更不懂該如何去做。雖然如此，在將近 20 年的時間之後，他們成功達成了童年的夢想。這是一篇為任天堂的遊戲平台製作遊戲，也為自己實現夢想的真實故事。
RiverMan Media 是一間由 Jacob 與 Paul 兩人共同創立的小型獨立遊戲開發公司，而《MadStone》是一款 2D 型態的方塊掉落解謎遊戲，也是他們所製作的第一款 WiiWare 平台遊戲，售價 8 塊美金。在這款遊戲之前，他們曾於 PC 平台發售兩款表現中規中矩的休閒遊戲《Cash Cow》以及《Primate Panic》。
標題的 Postmortem 是「後鑑之明」的意思，也就是在完成整個遊戲並且發行上市之後，重新回頭檢視專案開發過程中的種種是非對錯。在龐大的遊戲產業中，或許 RiverMan Media 只是一個微不足道的小公司，但在這篇自我檢討的文章裡，Jacob Stevens 非常坦然且毫無保留地剖析他們的心路歷程，娓娓道來許多令人深思的想法。看看他們做對與做錯的事情，再回頭想想自己，或許也能夠使我們的遊戲開發旅程少走一些冤枉路。
同時，我也想將這篇文章獻給所有對遊戲設計感興趣，以及將遊戲產業視為未來職涯目標的讀者們。
繼續閱讀 < < "《Postmortem: RiverMan Media’s MadStone》：奉獻、持續，以及無與倫比的熱情"
Feb 23 2009
Strategy Pattern
身為一位程式設計者，你是否曾面臨條件判斷式繁殖過盛的困擾？經常用折疊不完的 N 層 if-else 結構來考驗自己的腦力？或是只能瞪著超過 500 行的 switch-case 條件判斷式舉手投降？您的困擾我瞭解，請容許我向您引薦本篇文章的雙主打星——Strategy 與 State 範式，讓它們帶領我們一同邁向美妙動人的範式之道吧！
首先要瞭解的是，為什麼要將 Strategy 與 State 範式放在同一篇文章裡介紹？因為兩者雖然在設計層面的動機與出發點有所差異，但是在實際的應用面中非常地相近。根據《物件導向設計模式》(Design Patterns) 書中的定義，只要將右圖中的 Strategy、ConcreteStrategyA 與 ConcreteStrategyB 角色，更改為 State、ConcreteStateA 與 ConcreteStateB，就會變成 State 範式的結構圖，可以說兩者就像是孿生兄弟般密切相關。
如果真的要區分出 Strategy 與 State 範式之間的差異，可以參考《重構——向範式前進》中論述的內容：
State pattern 對「必須在一整族 state classes 的實體之間輕鬆轉換」的 class 有益，而 Strategy pattern 則是有助於讓 class 把演算法執行任務委託給「一整族 Strategy classes 的某一個實體」。
從我理解的角度來解釋，Strategy 範式比較著重於包裝相同派系的演算法，而 State 範式則特別注重在各狀態之間的轉換邏輯。所以只要瞭解 Strategy 或 State 範式兩者之一，就等於學會了兩種設計模式，真的是太划算太值得啦！雖然 Strategy 與 State 範式非常單純而且易於理解，但這兩項看似不起眼的小小範式，卻經常能夠在程式系統中發揮很好的應用效果，絕對是程式設計者不可不學的必備基礎知識。本文中將以 Strategy 範式為主，說明兩者在遊戲系統中的相關應用。
Loading ...