這是我在近期內對於 Threading 主題的學習整理文。如果你對於多執行緒程式設計沒有半點概念的話,建議可以先從我之前寫的「多核多緒多樂趣」開始閱讀,然後再視個人需求取用以下各項資源。
所謂的「多執行緒」程式設計,或者可簡稱為「多緒」程式設計,在英文中有許多相關的專業技術名詞,例如 Threading、Multithread、Concurrency、Parallel、Multicore 與 Multiprocessor 等等,在搜尋資料時可以嘗試不同的關鍵字,往往可以找到不少意料之外的好東西。而其中最常見的總括性簡稱,應該就是 Threading 了。
基礎定義
既然要學習 Threading 程式設計的知識,首先要瞭解的當然是 Threading 的基礎概念:
- Thread:看看 Wikipedia 裡的定義,至少把最前頭那段 Thread 的基本定義,以及 Thread 與 Process 的不同之處搞懂。簡單來說,執行緒是用來執行電腦程式的執行環境;而多執行緒,就是能夠使程式系統同時執行多個不同程式碼區段的一種技術。
- Thread Safety:雖然使用 Threading 技術能夠提升程式系統的執行效能,但伴隨而來的則是麻煩又難解的 Thread Safety 議題。大致上,我們可以使用 Re-entrancy、Mutual exclusion、Thread-local storage 以及 Atomic operations 這四種方法來達成安全使用多執行緒技術的目標。
繼續閱讀 < < "快快樂樂學遊戲Threading程式設計"

(圖片來源: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》:遊戲中的物理學,遊戲性的新疆界"
很久沒有寫程式設計入門知識的相關文章了,這篇文章要來談談程式庫 (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?在我們的程式碼中有使用這些程式庫嗎?
繼續閱讀 < < "MSVC與CRT的恩怨情仇"
原文出處: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》:奉獻、持續,以及無與倫比的熱情"