Dirty Coding Tricks

Dirty Coding Tricks by Brandon Sheffield

================================================

今天在Gamasutra上看到的一篇文章。

遊戲開發有時程壓力，而當我們發現一個很難解的Bug，時間又已經來不及的時候，我們該怎麼辦? 這篇文章就舉出了幾個偷吃步的故事。

頭一個故事就很慘了。

在一個PS2遊戲即將要發行的時候，測試團隊發現，在第一個關卡裡，玩家只是靜靜的站著就偶而會造成crash，而且更不幸的是，是在燒成光碟之後，這個問題才會出現。

於是開發團隊為了解決問題，不斷的修改程式，燒成光碟，然後測試，弄了十幾個小時( 為了等程式 crash，只好拿 World of Warcraft 打發時間.... )。

後來奇蹟出現了。有人發現，一開始攝影機向右轉個90度的話，程式就不會出問題，於是乎，PS2的版本，就在攝影機轉個角度之後，順利通過測試而發片。而已經上架的另外兩個平台的版本，攝影機角度還是維持原先的設計。

我的結論是：寫程式，也需要奇蹟。

第二個故事，真的就是偷吃步了。

遊戲程式中所用到的資源，例如一大堆的檔案，在檔案系統中通常會想些編碼的方式當作索引來存取這些檔案。這個故事裡的團隊很倒楣，他們將檔案的檔名CRC32編碼，同時也將檔案內容做CRC32編碼，用這兩個值組成64位元的索引來存取檔案內容。

開發了兩年，處理了幾萬個檔案，從來沒有發生索引值衝突到的狀況。

可是，它真的發生了。兩個不同內容的檔案，卻有完全相同的檔名(也不知道為什麼要這樣設計....)，而且檔案內容在編碼之後也得到相同的CRC32編碼--這下子事情大條。

改檔案系統，改索引方式，都是個大工程，而且誰知道改了之後會不會發生同樣的狀況? 這時候，再怎麼完美的編碼方式，都沒辦法給人信心了。

沒時間了，只好用一個最簡單的偷吃步解決這個問題 -- 把其中一個文字檔案打開，在最後面加一個空格，然後存檔。

於是乎，遊戲如期發行。

 

當然啦，這些方法都不是好的解決方式，而且會帶來後續的問題，不管是程式穩定度還是程式維護上的問題。

不過，對我們老是在有限時間跟疑難雜症打仗的人來說，這些故事是會讓人會心一笑的。

Design Patterns for Game Programming -- Reference Count

這是提供入行的新人教育訓練用，我們自己整理的Game Programming中的Design Patterns。我們所想到的第一個項目，就是Reference Count。所以就先將它整理出來了。

既然是寫設計模式，自然必須依照設計模式經典的編排方式來做。

以下進入正題。

 

Design Patterns for Game Programming -- Reference Count

使用時機

遊戲程式中充滿了使用記憶體資源的物件，其中有些物件的特性是，佔用大量的記憶體，又常常重複出現在遊戲中。例如，3D遊戲中的模型、貼圖，2D遊戲中的圖片資源等等。

(場景中重複出現的樹木就包括了重複使用的模型與貼圖) ( Screen-Shot from World of Warcraft )

針對這種物件，我們會將它設計成共享的資源物件，以節省記憶體的使用量。同時，我們也在共享資源物件中，加入參照計數(Reference Count)，以便記錄每個共享資源所被參照的數量。

目的

將共用的資源做有效的管理。改善資源與記憶體的使用。

設計實作

架構上主要有三種物件。

Shared Resource :

也就是共享的資源物件，像是貼圖、模型、圖片等。成員變數m_iReferenceCount記錄的就是參照計數，而IncRefCount與DecRefCount則是用來對Reference Count遞增與遞減之用。每個Resource有一個唯一的Key值(例如，資源檔案名稱或是某種編碼後的整數)。

Resource Table :

存放Shared Resource的地方，通常會使用Hash Map、Binary Tree或是其他能夠快速的從Resource Key值搜尋物件的資料結構。

Resource Manager :

做為與應用程式溝通的介面物件。提供兩個最主要的成員函式 : Query Resource 與 Release Resource。

應用程式透過呼叫Resource Manager的Query Resource函式，來取得共享資源。

首先會在Resource Table中搜尋是否有對應Key值的資源存在，如果存在，就將資源的參照計數遞增之後，傳回給應用程式。如果不存在，就產生一個新的資源( 此時新資源的參照計數為1 )，插入Resource Table中，然後傳回給應用程式。

另外，應用程式也透過Resource Manager的Release Resource函式來釋放資源。

首先Manager會先將Resource的參照計數遞減，並且取得結果。如果參照計數小於或等於0，表示已經不再需要這個共享資源，就先從Resource Table中將資源移除，然後，刪除這個資源。

多緒環境下的設計實作

有兩項必須做到Thread-Safe，一是Resource Table的存取，避免多個執行緒同時修改Table內容以及相關的索引資料，另一個則是Reference Count的遞增與遞減計算，避免多個執行緒同時修改，造成資料錯誤。

使用設計上的限制

1. 在這個機制下，共享資源的生成與銷毀都必須是透過Manager的Query / Release來負責，應用程式要避免直接使用new / delete來生成 / 銷毀共享資源。一個可用的設計方式是，將資源物件的建構子與解構子封裝起來不公開，封鎖應用程式對共享資源的new / delete權限，同時宣告Manager為friend class，把權限讓給Manager。

2. 共享資源的Inc / Dec Reference Count操作必須是成對的，否則容易出現Memory Leak ( 當 Inc Reference Count次數大於 Dec Reference Count時 ) 或是使用到無效的指標 ( 當 Inc Reference Count次數小於 Dec Reference Count時 )。這項限制，可以透過Smart Pointer的設計來改善。