很讚的遊戲編輯器

大家都頃向於把自己遊戲所使用到的資源，以自己的檔案格式作加密打包。我也不例外，以前也和大家一樣設計了自己的檔案格式，可以將多個檔案加密壓縮打包起來，當然也還需要製作可以讀寫這種檔案格式的工具程式。實作出來後感覺還不錯，只不過其實這只是多此一舉的動作。 後來我改使用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++ Fil...

遊戲資源編輯 貼圖 (Texture editor, Jpeg, PNG, BMP) 聲音 (Audio, OGG, WAV) 地圖編輯 (Map editor) 精靈編輯 (Sprite editor) 關卡編輯 (Level editor) Script編輯 (Script editor) 範例程式 打磚塊/寶石方塊/踩地雷等16個小遊戲範例 遊戲範例 25940m 輸出WIN32獨立可執行檔 (Stand-alone exe) ; 本來要等到加上文字物件後再釋出，不過這陣子比較沒時間更新，所以先把目前的版本作為1.1beta釋出... 這個版本作了許多小更新，主要在加強 particle的部份，應用方面可參考25940m，另外API reference也作了更新。 下載good Game Editor 1.1 Beta API 參考手冊

前幾天午睡時突然被告知要參加公司內部的程式設計比賽，題目是用C寫一支文字模式的4位數字猜數字遊戲，由使用者來猜電腦的數字。在上星期時其實就已經有公佈了，但我沒有注意到所以是臨時加入，還好這是個簡單的題目，不用花多少時間就可以寫出來。 規則： - 這是一對一比賽，雙方各選擇一4位數字，不讓對方知道。 - 4位數字由數字0至9組成，每位數不得重複。 - 雙方輪流猜對方的數字，直到一方猜中為止。 - A方猜B方的數字後，B方根據A方的猜測回答幾A幾B。 - 一個A表示猜中一個數字且位置正確，一個B表示猜中一個數字但位置不正確。 - 當一方猜中4A0B時即表示猜中對方全部4個數字且位置正確，贏得比賽。 - 例：B的謎底是4208，底下箭頭左測是A的猜測，箭頭右測是B的回答。 　　　1234 ==> 1A1B 　　　5678 ==> 1A0B 　　　2406 ==> 1A2B 　　　... 　　　4208 ==> 4A0B ; 寫個程式讓玩家來猜電腦的數字不難，不過我從來沒有寫過讓電腦來猜玩家數字的版本，所以花了點時間想想怎麼寫。 研究後歸納出二個點。 1, 使用窮舉法將所有可能數字組合列出。 2, 每次猜測後根據結果排除不可能是答案的組合，重複這個動作直到猜中答案為止。 第1點只是實作問題，第2點概念也很簡單，但要過濾不是答案的組合根據的是什麼？乍看之下沒什麼頭緒，不過想通之後就非常簡單了。 它的基本原理如下：假如謎底是4561，如果猜1524則會得到1A2B。從相反的角度來看，如果謎底是1524，則猜4561時也會得到1A2B的回答。 利用這個方法，每一次猜測一個數字X後，再以這個數字當作答案，來和所有剩下來的候選答案作比對，如果得到的結果(幾A幾B)和數字X是一樣的話，就把這個數字保留下來繼續作為候選答案，否則就過把這個數字過濾掉。下一把，繼續從候選答案裡選一個出來猜，重複上面的動作，直到猜中為止。 ; C++ STL的algorithm裡有個叫作next_permutation的函數，可以用來生成排列。 #include <iostream> #include <algorithm> using namespace std; int main () {   int myints[] = {1,2,3};  ...

前面我們透過 手工的方式 實作了一個簡易的算式計算機，現在我們要開始使用工具來作同樣的事，比較看看手工和使用工具有什麼不同的差別。首先要介紹的就是lex&yacc。 lex & yacc lex(Lexical Analyzar)及yacc(Yet Another Compiler Compiler)是用來輔助程式設計師製作語法剖析器的程式工具。lex的工作就是幫助我們將輸入的資料文字串流分解成一個個有意義的token，而yacc的工作就是幫我們分析這些token和我們定義的規則作匹配。下圖中所表示的是使用lex及yacc的一般工作流程。 首先看到yacc會讀入一個.y檔案，這裡.y檔案的內容就是我們使用類似(E)BNF語法定義的語法規則，yacc會分析這些語法規則後，幫我們產生可以用來解析這些規則的程式碼，而這個檔案一般名稱預設為y.tab.c，產生的程式碼裡面最重要的一個的函式叫作yyparse。 同yacc類似，lex也會讀入一個.l的檔案，這個檔案裡面定義的是如何從文字流裡解出token的規則，使用的方法是常規表示式(regular expression)。在圖的左側中間我們還可以看到有一個叫作y.tab.h的檔案從yacc產生出來並餵給lex作輸入，這個檔案是yacc根據在讀入的.y檔裡面所定義的token代號所產生出來的一個header，這樣yacc及lex產生出來的程式碼裡面就可以使用共通定義的代碼而不必各寫個的。lex分析過.l檔案後也會產生一個一般預設叫作lex.yy.c的原始碼檔案，裡頭最重要的一個函式叫作yylex。 最後，我們把yacc產生出來的y.tab.c還有lex產生出來的lex.yy.c，以及其它我們自己撰寫的原始碼檔案一起拿來編譯再作連結，最後產生出來的就是一個可以用來解析我們定義的語法的解析器工具。以上是整個lex及yacc的使用流程概觀。 常規表示式 在正式使用lex之前，我們首先來對常規表示法作一個基本的認識。常規表示法是一種用來表示字串樣式(pattern)的中繼語言，就好比前文所介紹的(E)BNF表示式一樣，都是用來描述其它語言的語言，只不過用途不太一樣罷了。 常規表示式使用一些中繼符號(meta-symbol)以及ASCII字元定義字串樣式，以下列出一些常規表示式所使用的符號。 . 表示除了換行字元...

之前提過，我平均每年至少會作個一款小遊戲(不管是新開發或重製)，這些小遊戲會開放免費下載。到目前為止已經推出12款了，其中7款Windows遊戲，2款Symbian遊戲，1款J2ME遊戲和1款WindowsMobile遊戲。 開發這些遊戲除了自己好玩外，也是練功的好題目。所以可以發現到，這幾個小遊戲裡面，有好幾款其實只是不同平台的移植(同平台上用不同方式實作練習就不提)。透過這種方式我能接觸並學習到不同平台的開發，同時也能加強跨平台的經驗也訓練小技巧，一舉數得。 會把它開放到 網站 上，只不過是基於獨樂樂不如眾樂樂的簡單想法，有沒有獲得迴響其實也沒所謂。至少每當看著首頁那一堆自己的作品，只有一個爽字能夠形容！ (PS:這些遊戲有差不多一半都是WindowsGDI程式...所以效能難免有時不理想，不過那不是重點) ; 25940m (by good) 25940p 實驗中國象棋 (WindowsMobile,240x320) 實驗中國象棋 (Symbian s60, 176x208) 單人撲克101 小香咪咪方塊 小香咪咪方塊 (J2ME1.0) 867 ( upup 原型) 鋤草機 ( 說明 ) 拼吐 ( 說明 ) 傷心掃雷 (Symbian s60, 176x208) Paint by Numbers 2005 ( 說明 )

上次談到 C++編譯時期靜態多型 的原理，這次要介紹C++編譯期靜態多型要如何應用在遊戲中。雖然這篇文章主要是在談C++編譯期靜態多型的應用，不過其中也牽涉到跨平台的程式設計，所以也順便作點和跨平台程式設計的介紹。 跨平台程式本身不難，困難點在於如何把和平台有關的部份和平台無關的部份切割開，只要作到這點剩下來的就沒什麼難的了。至於要怎樣才能作的好跨平台程式設計並不是在這邊三言二語就能講的清楚。 總之記住儘可能的把平台有關和無關的部份分離，以及儘可能的使用標準的程式庫。例如std::string就是C++標準和平台無關，CreateWindow就是和Windows平台相關的API。 ;;; 如果我們是以C++物件導向來作遊戲程式設計，我們可能會有個上層的CGameApp類別，其它還有遊戲物件如CGameObj等類別。 ; 範例1 class CGameObj { }; class CGameApp { public: CGameMgr<CGameObj> mObjMgr; }; 在範例1中，CGameApp管理所有遊戲物件。這邊我們先不管CGameMgr<>是什麼東西，實際上在本例中我們也不需要去知道。 因為CGameApp是整個遊戲程式的核心，它除了管理所有遊戲物件(CGameObj)外，同時也管理所有其它和遊戲相關的物件或資源或者說狀態(State)。 ; 範例2 class CGameApp { public: CGameDB mGameDB; CGameMgr<CGameObj> mObjMgr; }; 如範例2中的mGameDB，是和遊戲會使用到的資料庫。現在問題來了，如果CGameObj的實體物件需要存取mGameDB怎麼辨。一個簡單的方法就是讓CGameObj內涵一個mGameDB的參考，我們可以在建立一個CGameObj物件時把它傳入CGameObj的constructor。 不過這樣作另一個問題又來了。在CGameApp內不一定只會有一個像mGameDB這樣的東西，通常還會有其它資料是其它物件需要存取的。如果全都傳到物件內，那肯定不是一個好辨法。 有一個更好的解決辨法，那就是把所有資料都集中在一起管理，把它變成一個 singleton ，讓所有物件都能存取到它，也就能存取到所有資料。為了簡單起見，我們讓...

測試驅動開發(Test Driven Development, TDD) 在 敏捷開發流程(Agile Process) 中扮演了一個很重要的角色，不過本文的重點在於TDD，不談Agile，實際上我也不懂，不懂的東西我也不談。 第一次接觸TDD，是在開發 JSR-184 時。在你的JSR(Java Specification Requests)實作和VM整合之前，VM Vendor會要求你的實作至少要通過TCK(Technology Compatibility Kit)。TCK是透過 JCP(Java Community Process) 取得，目的是用來驗證某JSR的實作品是否符合規範。實際上TCK就是一組使用JavaTest harness的測試包，包含了各種用來測試JSR的單元測試(Unit Test)。 以TCK for JSR-184來說，總共包含了161個測試項目，每一個測試項目裡面又再包含了2至10個子測試項目，而每一個子測試項目裡面又有不定數量的更小的測試。JavaTest是個自動化測試的環境，只要載入JSR-184的測試包，設定好環境之後就可以執行自動測試，然後看看結果如何。 JavaTest的測試都是Java寫的，雖然是Java新手，但是當時在發開發的過程中也能感受到TDD的威力。舉個簡單的例子：對於像我這樣不懂3D的人來說，還可以開發3D引擎，你說利不利害。我只需要想盡辨法讓測試能過關就行了，很多細節其實也不懂。這樣說雖然是比較誇張點，但我想要表達的是，TDD果然是神。 ; 話說回來，C/C++是我使用最多的程式語言，所以我如果也要使用TDD的話，就需要找一套支援C/C++的TDD程式工具。因為我沒那麼聰明，所以都只挑簡單易用的，最後終於讓我找到了 CppUnitLite 這個工具。實際上是在閱讀< 修改代碼的藝術 >這本書時，從中學到的，CppUnitLite是作者設計實作的一套短小精幹的UnitTest工具，簡單易用。 這本書的內容我全部忘光光了，但我學會了使用CppUnitLite就算是值回票價了。現在底下內容要作個簡單的介紹，看看如何撰寫單元測試。 ; 下載 後解開檔案，我們只需要將om/CppUnitLite裡的檔案加到我們自己的專案就可以了，om/CppUnitLite裡的Cpp和CppUnitLite資料夾不用管它。 ...