大家都頃向於把自己遊戲所使用到的資源，以自己的檔案格式作加密打包。我也不例外，以前也和大家一樣設計了自己的檔案格式，可以將多個檔案加密壓縮打包起來，當然也還需要製作可以讀寫這種檔案格式的工具程式。實作出來後感覺還不錯，只不過其實這只是多此一舉的動作。
後來我改使用zip格式作資料包。想要加密？也沒有問題，加上密碼保護就可以了。工具也有一堆現成的，要用WinZip或7-Zip什麼的都可以，完全不必花費任何力氣就擁有工具可以讀寫資料包。所有我需要作的事就是設計一個程式庫，可以用來讀寫Zip檔案格式就行了。事實上zlib已經能夠滿足這個需求了，只需要再多作一點程式包裝。所以我多花了些功夫在程式介面的設計上，最後完成了虛擬檔案系統的設計(smallworld2::Archive)。
為什麼把它叫作虛擬檔案系統呢？因為它目前支援了二種檔案系統，一個是一般的路徑檔案系統，另一個就是剛剛提的zip檔案系統。不管你使用的是那一種檔案系統，對於呼叫者而言是抽象的。呼叫者只需要透過統一的介面只存取檔案，完全不必考慮這個檔案是在那個資料夾或那個zip檔內，或甚至是在那一塊記憶體內(這是第三種形式)。
如上是虛擬檔案系統的C++程式介面，很簡單。因為其中也使用了C++ stream作為資料交換介面，所以也能很容易的和C++ IOstream家族結合使用，變的很有彈性。
addFileSystem是用來增加一個路徑或zip檔案到搜尋路徑。而另一個stream的版本則是用來加入一個來自串流的檔案系統，這個串流可以指向C++ FileStream或者是指向記憶體的StringStream。isFileExist和loadFile也很直覺，不必再多作說明。
這裡只需要對搜尋次序多作點解釋。
在實際應用時，如果整個遊戲會使用到的資源數量很多時，可以根據不同方法分類，區分成幾個子檔案系統，分別以addFileSystem加入。因為加入時會有次序關係，所以假如在不同的檔案系統內(如fs1.zip和fs2.zip)同時存在同樣名稱的檔案，則在呼叫loadFile時，只會回傳第一個找到的檔案。利用這個特性，我們可以用它來設計一個簡單的線上遊戲的檔案更新機制。
應用一
在遊戲開發初期，我習慣不作資料打包，所有資源都放在資源資料夾裡(如media)，當然這個資料夾裡根據規劃還可以有其它子結構。這樣一來，每當美術資料或企劃資料有任何更新，我可以直接Copy新的檔案蓋過去來更新，不必作什麼打包的動作，所以可以很快的完成一個測試動作。把測試程式交給美術或企劃也是一樣，他們可以用同樣方法很快的作修改和測試。
等到最後階段再把整個資源資料夾裡zip起來(或視情況分成幾包)，然後在程式裡面多寫幾行addFileSystem，其它程式完全不必動。當然，對於資料包我可能改個副檔名，把zip改成dat什麼的，不過加上個密碼後要解開也不是容易的事。
應用二
底下介紹一個使用虛擬檔案系統建立的小型線上遊戲更新機制。
線上遊戲每隔一陣子都會有更新，每一次的更新都會有一個更新資料包，這個更新資料包其實就是一個zip包，裡面包含了所有這個版本需要更新的檔案。
首先Client程式更新時會先從Server下載一個List，這個List會列出從第一個版本開始到目前版本的所有更新資料包的檔名和CheckSum。下載下來後，Client就拿這個List裡的名單來檢查自己Local端資料包，如果CheckSum不對或不存在就把它下載到Local端。
完成更新後，把List名單裡的所有資料包以addFileSystem一個一個加入，因為這份名單是根據更新的版本次序建立的，所以在以addFileSystem加入後，當程式裡去loadFile時能夠確保可以從這一堆資料包裡取出最新版本的檔案。
後來我改使用zip格式作資料包。想要加密？也沒有問題，加上密碼保護就可以了。工具也有一堆現成的，要用WinZip或7-Zip什麼的都可以，完全不必花費任何力氣就擁有工具可以讀寫資料包。所有我需要作的事就是設計一個程式庫，可以用來讀寫Zip檔案格式就行了。事實上zlib已經能夠滿足這個需求了，只需要再多作一點程式包裝。所以我多花了些功夫在程式介面的設計上，最後完成了虛擬檔案系統的設計(smallworld2::Archive)。
為什麼把它叫作虛擬檔案系統呢？因為它目前支援了二種檔案系統，一個是一般的路徑檔案系統，另一個就是剛剛提的zip檔案系統。不管你使用的是那一種檔案系統，對於呼叫者而言是抽象的。呼叫者只需要透過統一的介面只存取檔案，完全不必考慮這個檔案是在那個資料夾或那個zip檔內，或甚至是在那一塊記憶體內(這是第三種形式)。
class Archive
{
public:
bool addFileSystem(std::string const& path);
bool addFileSystem(std::istream& stream);
bool isFileExist(std::string const& name) const;
bool loadFile(std::string const& name, std::ostream& outs, std::string const& password="");
};
如上是虛擬檔案系統的C++程式介面，很簡單。因為其中也使用了C++ stream作為資料交換介面，所以也能很容易的和C++ IOstream家族結合使用，變的很有彈性。
addFileSystem是用來增加一個路徑或zip檔案到搜尋路徑。而另一個stream的版本則是用來加入一個來自串流的檔案系統，這個串流可以指向C++ FileStream或者是指向記憶體的StringStream。isFileExist和loadFile也很直覺，不必再多作說明。
這裡只需要對搜尋次序多作點解釋。
在實際應用時，如果整個遊戲會使用到的資源數量很多時，可以根據不同方法分類，區分成幾個子檔案系統，分別以addFileSystem加入。因為加入時會有次序關係，所以假如在不同的檔案系統內(如fs1.zip和fs2.zip)同時存在同樣名稱的檔案，則在呼叫loadFile時，只會回傳第一個找到的檔案。利用這個特性，我們可以用它來設計一個簡單的線上遊戲的檔案更新機制。
應用一
在遊戲開發初期，我習慣不作資料打包，所有資源都放在資源資料夾裡(如media)，當然這個資料夾裡根據規劃還可以有其它子結構。這樣一來，每當美術資料或企劃資料有任何更新，我可以直接Copy新的檔案蓋過去來更新，不必作什麼打包的動作，所以可以很快的完成一個測試動作。把測試程式交給美術或企劃也是一樣，他們可以用同樣方法很快的作修改和測試。
等到最後階段再把整個資源資料夾裡zip起來(或視情況分成幾包)，然後在程式裡面多寫幾行addFileSystem，其它程式完全不必動。當然，對於資料包我可能改個副檔名，把zip改成dat什麼的，不過加上個密碼後要解開也不是容易的事。
應用二
底下介紹一個使用虛擬檔案系統建立的小型線上遊戲更新機制。
線上遊戲每隔一陣子都會有更新，每一次的更新都會有一個更新資料包，這個更新資料包其實就是一個zip包，裡面包含了所有這個版本需要更新的檔案。
首先Client程式更新時會先從Server下載一個List，這個List會列出從第一個版本開始到目前版本的所有更新資料包的檔名和CheckSum。下載下來後，Client就拿這個List裡的名單來檢查自己Local端資料包，如果CheckSum不對或不存在就把它下載到Local端。
完成更新後，把List名單裡的所有資料包以addFileSystem一個一個加入，因為這份名單是根據更新的版本次序建立的，所以在以addFileSystem加入後，當程式裡去loadFile時能夠確保可以從這一堆資料包裡取出最新版本的檔案。
留言
張貼留言