跳到主要內容

C++編譯時期靜態多型在遊戲中的應用

上次談到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,讓所有物件都能存取到它,也就能存取到所有資料。為了簡單起見,我們讓CGameApp同時作為這個singleton範理所有狀態。
; 範例3
class CGameApp
{
CGameApp();
public:
CGameDB mGameDB;
CGameMgr<CGameObj> mObjMgr;

static CGameApp& getInstance();
};
如範例3,我們加了一個getInstance的靜態方法用來取得CGameApp的唯一實體物件。這樣就解決了所有問題。

;;;

底下我要開始介紹我使用的方法,應用C++編譯期靜態多型的小技巧,同時也包含跨平台設計的基本架構思想。
; 範例4
template<class GameT>
class CGameApp
{
};

class CGameAppWin : public CGameApp<CGameAppWin>
{
CGameAppWin();
public:
static CGameApp& getInstance();
};
CGameApp<>是GamePlay主體,完全只和GamePlay有關,是可跨平台的部份,因為它完全沒有使用到任何和平台相關的功能。CGameAppWin繼承CGameApp<>,實作和平台相關的全部功能,如顯像,音樂音效,讀寫檔等等。要跨平台的時候,只需要提供不同平台的CGameApp<>繼承者即可。

以上就是我的遊戲架構主體慣用手法,非常簡單。

;;;

這個架構如何作到跨平台?舉個簡單的例子會很容易了解。
template<class GameT>
class CGameApp
{
void onEnterGameMenu()
{ // 進入遊戲選單畫面。
...
// 此時,需要改變背景音樂。
GameT* pGame = static_cast<GameT*>(this);
pGame->notifyChangeBgm(ID_BGM_GAMEMENU); // 由GameT實作,CGameApp只作呼叫。
...
}
};

class CGameAppWin : public CGameApp<CGameAppWin>
{
// 實作,播放指定背景音樂。idBgm由CGameApp<>定義。
bool notifyChangeBgm(int idBgm);
};
如上例中,CGameApp<>在進入遊戲選單時會呼叫onEnterGameMenu函式,而在onEnterGameMenu中會呼叫一個叫作notifyChangeBgm的函式來發出通知,改變播放背景音樂。notifyChangeBgm函式在CGameApp<>中沒有實作,而是由GameT也就是CGameAppWin來實作。這樣就完全把音樂音效的實作細節切離開來。其它的功能也能如法炮製達到GamePlay和平台相關實作分離。

;;;

下面再看一個例子。
template<class GameT>
class CGameApp
{
// 初始化遊戲,成功回傳true失敗回傳false。
bool init();
};

class CGameAppWin : public CGameApp<CGameAppWin>
{
typedef CGameApp<CGameAppWin> BaseT;

// 改寫CGameApp::<>init。
bool init()
{
if (!BaseT::init())
return false;

// 其它初始化動作。設定顯示模示,初始化音樂音效模組等等。
...
}
};
上例中CGameApp<>有個init的函式用來初始化和平台無關的GamePlay,而CGameAppWin因為和平台有關,還有其它和平台相關的初始化需求,如初始化顯示模式,音樂音效等。所以CGameAppWin改寫了CGameApp<>::init達到這個目的。

實際上,這個例子並沒有使用到C++編譯期靜態多型,它只是單純的函式改寫,只不過是在實作上的一個慣用手法..

留言

  1. 不是不要在主專案用到平台相依的.h就好了?

    回覆刪除
  2. 是的,不使用和平台有關聯的.h是第一步; 另外這篇文也想要提供一個方便作移植的簡單方法

    回覆刪除

張貼留言

這個網誌中的熱門文章

單人撲克牌遊戲 - 蒙地卡羅

更多可在網頁玩的 單人撲克牌遊戲 ; 新增一個簡單的單人撲克牌遊戲: 蒙地卡羅 ,簡單介紹一下玩法。 下載 事先排列好5x5張牌。 每次移動一張可以配對的牌,並消除這對牌。在上下、左右及斜向相隣的二張牌,只要擁有同樣數字(不計花色),即可配對。 消除二張配對的牌後,剩餘的牌以往左往上的方式補滿空隙,接著在發新牌補滿後面的空格。 重覆步驟2~3,直到沒有牌可以配對及發完所有牌為止。 結果有二種。一個是勝利,成功的消除掉所有牌。另一個是Gameover沒有牌可以再作配對。

以lex/yacc實作算式計算機

前面我們透過 手工的方式 實作了一個簡易的算式計算機,現在我們要開始使用工具來作同樣的事,比較看看手工和使用工具有什麼不同的差別。首先要介紹的就是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字元定義字串樣式,以下列出一些常規表示式所使用的符號。 . 表示除了換行字元...

窮人的 AI:自動漫畫分鏡切割

  ( 試試看 ) 在手機上看漫畫時,有一個體驗上的問題: 漫畫原本是「整頁設計」 手機最適合的是「一格一格往下滑」 與其強迫使用者縮放、拖曳、放大,更直覺的做法是: 直接把一頁漫畫自動切成多個分鏡,轉成瀑布流閱讀。 這篇文章分享一個不靠深度學習、完全在前端完成的實作方式: 使用 OpenCV.js 做分鏡偵測 輸出 rect list 再用 全畫面 Canvas 把每個分鏡當成一個「閱讀單位」 整個系統可以拆成三層: 漫畫圖片 ↓ 影像處理(找出 rects) ↓ 排序後的 rect list ↓ 全畫面 Canvas 逐格呈現(瀑布流) Step 1:灰階化 漫畫的資訊 90% 都在線條上,顏色反而是干擾。 cv.cvtColor(src, grayImage, cv.COLOR_RGBA2GRAY); 灰階化的好處: 降低維度 對邊緣偵測更穩定 對黑白漫畫特別有效 Step 2:邊緣偵測,抓出「分鏡的邊」 接下來用最經典、也最夠用的 Canny Edge Detection: cv.Canny(grayImage, edges, 50, 150); 在漫畫中,分鏡外框通常就是最明顯的邊界。 Step 3:形態學操作,把破碎邊框「補起來」 真實漫畫的線條並不完美,常常有斷線、陰影、留白。 所以要做一個很重要的步驟:膨脹(Dilation) const kernel = cv.Mat.ones( 5 , 5 , cv.CV_8U); cv.dilate(edges, dilatedEdges, kernel); 直覺理解就是: 把細線「抹粗一點」, 讓本來斷掉的邊界連成封閉區域。 這一步直接決定後面能不能成功抓到「一整格分鏡」。 Step 4:找輪廓,轉成矩形框(rect) 有了封閉區域之後,就可以找輪廓: cv.findContours( dilatedEdges, contours, hierarchy, cv.RETR_EXTERNAL, cv.CHAIN_APPROX_SIMPLE ); 每一個 contour,代表一個「可能的分鏡區塊」。 接著轉成矩形: const rect = cv.boundingRect(contour); rects.push([rect.x, rect.y, rect.widt...