謝謝你的回應。 ：）

不過我以前所做的東西之中，asset還會繼續分爲working和complete兩個部分，美術人員可以一直在working目錄中工作，而最後遊戲運行則使用製作完成放在complete中的部分。

我沒用過 SWIG，不過我也同意對於比較複雜的函式庫，直接用安裝的方式就可以。而如果會自行修改，或者建立不同平台設定檔的開源專案，自然就應該放在 ThirdParty 目錄中。

把 asset 和 source code 放在同個 repository 或者分開，兩種方法我都用過，我覺得是各有利弊。目前我也是採用將兩者放在一起管理的方式。

有關於 Asset 管理的部分，在文章裡沒有解釋的很清楚，這裡再補充一下我的想法：

除了將 text 轉為 binary 格式以外，還有另一種情況會有兩種不同狀態的資料存在——就是把原來單獨存在的多個檔案或者整個子目錄，打包成一個 Zip 格式的檔案。所以我認為，在專案 Asset 目錄中放的是 debug 用的素材檔案，可以是 XML、binary 或者其他格式，只要是能讓程式設計者方便進行除錯的格式即可。藉由檔案路徑的設定，遊戲程式在除錯時就可以順利讀取 Asset 目錄中的這些資料。

而當要建置專案的 release 版本時，可以利用 post build event 的設定，在執行檔建置成功後執行一份自訂的腳本。在這份 Script 中，可以利用 Tool 目錄下的工具，批次化地自動將 Asset 目錄中的資料，全部轉換為最終的格式。而轉換後的資料，會直接產生在 Build 目錄中，以保持 release 版本的執行檔與遊戲資料的正確相對路徑。

怎麼會見怪哩。有關 Asset/Content Pipeline Management 的討論議題真的非常少見，而且我也不太熟悉，所以能夠收到你這麼深入的分享真是求之不得啊～

@yuxioz:
對啊，我也很好奇怎麼很少見到書籍文章討論這個議題。

請用力分享你看過的作法吧～（伸）XD

@EYE:
不會消掉的俄羅斯方塊！真是個超讚的比喻！ XD

不如來寫個程式，幫使用者自動清除桌面上連成一線的圖示好了。（誤）

@lsk:
沒想到相似程度這麼高。 @_@

我也認同應該把美術製作完成的 raw asset，放在另外一個獨立的目錄中管理。因為由美術軟體存檔後產生的原始模型檔、動畫檔或者材質檔，不僅容量大而且數量也多，如果一起放進遊戲專案的目錄中，反而會造成管理上的困擾。所以應該只需要把轉換之後，可供遊戲程式直接使用的 game asset 丟進專案的 Asset 目錄中就可以了。

原來在遊戲光碟片中燒進 dummy 資料的用意是這樣啊！又學到了一項新知識哩。 ：D

非常感謝各位的分享～ ^^

因為我們是做console game，我們最後run game所需的檔案都會放到一個叫dvd的資料夾，不管是ps2、wii還是xbox 360，遊戲的image或是iso檔就是用這個資料夾去製作了。Dvd裡面(理論上)只會有玩家會用到的東西，不過像PS2的dvd有4G多，要是我們的遊戲用不到那麼多空間，我們會在build iso的時候在dvd的內圈塞進dummy data，讓真正的遊戲燒在外圈上，因為外圈的讀取速度快多了(轉一圈就可以到比內圈多好幾倍的資料)。

這個題材很切身, 每個人都會遇到,
但是偏偏網路上討論的很少,
這個 issue 我目前有看過的分析就只有在
一書中的一小節

我想大家都很好奇其他團隊或公司的 folder 結構是怎麼設計的
有機會也來分享一下我所遇過的好了 ^^

1. 一些 thirdparty 的 EXE/DLL，如果不是在 src/thirdparty 裡編譯出來的，會直接放到 project 裡，例如 D3DX 的 DLL、一些 .Net DLL ，適合 VC2008 用的版本會放在 project/bin/win32_vc80。並且在系統的 PATH 加上這個目錄。那麼不同的使用者/server checkout 時也會得到所需版本的 DLL/EXE。而項目裡生成的 EXE/DLL 也放到這個目錄，OBJ 等檔案則在臨時的 build 裡。

現時這個科案的一個特例是 SWIG。因為 SWIG 不單有 EXE，還有其他檔案，所以我把它當作 compiler 一樣，需要自行安裝。

為了跨平台而設的目錄名稱，我現時用 _，因為同一個平台可能支持平同的 compilers，同一個 compiler 又會支持不同平台。

而如果是 static link 到項目的，又是開源的，我會放到 thirdparty 裡。例如 Lua 雖然是很穩定的代碼，但我會為每個 platform/compiler 設立 project/makefile，並且有機會要修改代碼，例如刪去不會在遊戲使用的 Lua libraries。

2. 最大的問題，我覺得仍是否把 asset 和 source code 放到同一個 repository。我現時雖然也是把它們 (只是一些測試用的 asset) 放在一起，但是如果真的在 production 階段，repository 會不好管理。例如很可能會使用一些 build 工具，當有 check-in 時就自動執行 build，檢查每個 check-in 有沒有問題。另外，在看 change log 時不分開也很難看。

我覺得比較奇怪的是在程式的 debug/release 模式下，使用不同的 asset。如果 asset 是有分製作過程中的，和最終的版本 (例如一些檔案會由 XML 轉為 binary 格式)，那麼理想地是 debug 模式可以讀兩種版本，release 模式只可讀後者(或兩者)。不然 binary 格式會不能 debug。我目前是想把 asset 也需要 build 的概念，把來源 asset 轉換為平台特定的版本來執行。

理想地，一個項目應該可分為項目特有的資料和多個項目共用的資料。例如引擎/工具的 source code 就可能被多個項目(同時)使用。項目的 asset (包括 artwork 等 script) 最好可以分開處理，最好有一些 asset management 的工具。我的 Mil 項目也希望將來加入一些 Asset Management 的方案。

3. 我覺得一些項目的文件如果可以用一些 Content Management 的工具 (e.g. ShartPoint、MediaWiki) 等統一儲存會比較好。因為這些文件之間沒有很重要的依賴性，不需要 build 的過程，文件也比較小，沒有必要在每台電腦本地留下一個版本。我在家裡的項目則是用 Google Document。

4. 總結一個簡單的規則也許是，跟據隊伍不同需求來規劃檔案的存取方式。不同職能的 team member 會有不同的需求，除了考慮程序編譯的架構，最重要是如何把資料在不同隊伍中有效地整合。一些團隊會有專門的隊伍去管理資料和流程。

看到這麼切身的原創文章，我想到甚麼就寫甚麼，回應得比較雜亂無章，請不要見怪。