[筆記] 全文轉錄 - 好的遊戲程式系統簡介

 作者  ie945167 (龍蝦)                                      站內  Lobster
 標題  [筆記] 全文轉錄 - 好的遊戲程式系統簡介
 時間  2012/04/04 Wed 17:53:15
───────────────────────────────────────

好的遊戲程式系統簡介
日前發於DCI的文章...
關於遊戲系統架構的一點淺見

http://forum.dci.org.tw/viewtopic.php?t=519

文章主題: 自問自答: 怎樣才是好的遊戲系統? (一個技術與非技術的討論)
1. 符合玩家需求(非技術性，歡迎參與討論...)

文章主題: 2. 應用物件導向設計系統(技術篇)

文章主題: 3. 最終章 封閉系統但是保持系統擴充性


內容太多了…懶得貼了…有興趣的自己去看吧…0rz

--

     身高不是距離
                   技巧不是問題
                                 只要有"心"
                                             人人都可 定‧三‧米


--
▅◣ Origin:  謠 言 報  bbs.csie.fju.edu.tw
▋◤ Author: ie945167 從 219-85-0-189-adsl-nei3.dynamic.so-net.net.tw 發表

[筆記] 全文轉錄 - 類別的設計

 作者  ie945167 (龍蝦)                                      站內  Lobster
 標題  [筆記] 全文轉錄 - 類別的設計
 時間  2012/04/04 Wed 17:50:12
───────────────────────────────────────

http://imandrewliao.blogspot.com/2009/01/blog-post_16.html

類別是C++實踐物件導向程式的基礎，一般人對類別設計應該都有了些基本的概念，

這篇想要以系統開發的角度，來強調類別設計與使用的注意事項。


1. 變數封裝

基本上除了特別特別的需求，一般都建議你，把資料放在private區段，

為什麼呢，這樣我才可以設計函式，管控如何存取這些變數值，

避免變數被莫名奇妙的變更，

造成錯誤時，難以追蹤的困擾，

所以一個基本的變數，如果需要被外界存取，那需要一個設定函式，一個讀取函式，

如果不需要，內部使用，那一個都不需要提供。


可以放在protected嘛？基本上，類別設計，建議你忘記有這個區間的存在，為什麼？

protected區間可以被後續繼承類別存取，除非你有特殊用途，否則你埋下了一個炸彈，

你如何知道後續繼成出去的類別，不會胡亂更動其值？

不會又寫了一個函式，把資料public出去？


class NPC
{
    private:
    int m_iHp;  // 生命力，除了初值化外，不應該由外界來操作這個變數
    int m_iAcc; // 物理攻擊準確度，由企劃公式產生，更不應該由外界來操作
};


這樣的寫法，也斷絕了，系統開發時，有人妄想修改資料的念頭，減少將來系統長大時，

潛藏錯誤發生的機會，真的需要處裡內部數值時，再以下列方法處理:

class AStrangeClass
{
    private:
        NPC *m_pNpc;

    public:
        void SetNpc( NPC *npc ){ m_pNpc=npc; }
        NPC *GetNpc(){ return m_pNpc; }
};

關於全域變數呢，基本上建議，寫程式應該要把他視為罪惡，

這意味著有一個完全不能改的機制在那邊，無法控制其變數名稱，

只要跟這個變數有瓜葛的類別，形成了一個盤根糾結的系統，

如同先前我提到的，少用繼承一樣的結果，

將來改其中任何一個地方，潛在需要修改的程式是全部。


可是全域變數一定會用到的，這個地方建議去參考"Design Patterns"的Singleton樣式，

提供了一個將變數全域化，但卻被類別管控的方法。

2. 成員函式設計

成員函式設計，視目的而定，沒有一定的規範（除非專案本身的規定），

這裡建議，請在函式放置位置的時候，多思考一下，要放在哪個區段，

一般的建議是這樣，

如果函式需要被外界存取，放public(廢話...)，

不需要的時候，請放private(廢話兩枚)。

是廢話嗎？回去隨便拿一個別人寫的類別看看，

是不是有很多函式被外界呼叫後，如果數值亂填，可能造成系統錯誤之類的？

你也許會反駁說，說明中有寫，這是內部使用的，錯誤是因為外界亂用啊？

可是我要說，設計類別的基本原則，就是讓人容易使用，且不容易出錯，

與其你放任函式public，裡頭寫一大堆exception，

為什麼不把這些函式private起來，錯誤發生率也小多了不是嗎？


常在程式之間流傳的對答：

啊，我知道bug發生原因了，是因為某某某呼叫了我一個函式，

而這個函式是內部使用的，不可以這樣呼叫...，



謹慎考慮多少可以減少潛藏可能發生問題的機會。


3. 注意別人類別的規範

接下來是使用別人類別的注意事項，不要企圖去改變回傳值的屬性，

原因是來自Ｃ＋＋轉型的方便，許多人喜歡把參數或是回傳值，

亂轉型，變成其他的類型來操作，

這本是無可厚非的事情，最明顯的就是const回傳值，

但是，系統開發的時候，標明const，就是不希望你去改變這個數值，

嚴重的說來，改變這個值，搞不好會發生嚴重的錯誤，而經常有人就愛去碰：


class A
{
    public:
        const char *GetTypeName(){ return "this is a type"; }
};

void main()
{
    A a;
    const char *ptr=a.GetTypeName();
    strcpy( (char *)ptr, "this is not a type" );
}

編譯都對，執行的時候，就當給你看，所以

(a) 當你看見函式回傳值有const時，不要嘗試去改變回傳值內容

(b) 當函式宣告有throw時，請處理exception

    因為throw表示，函式內可能發生無法預期的錯誤，catch它，

    可以明瞭錯誤的原因，方便除錯

(c) 當類別裡面沒有虛擬函式時，不要嘗試去繼承它

    如果你寫個類別，會給後續類別繼承，你會怎麼寫？一定是在裡面寫一些虛擬函式，

    暗示後來的程式師，這幾個函式可能以後會有其他的寫法，

    如果你寫個類別，沒有任何虛擬函式，那表示什麼？

    不想被別人繼承？功能已經完備？不論哪個答案，都不該再有類別繼承它了。

    除此之外，還有一個原因，虛擬解構式，在繼承情況下，

    解構的記憶體才會正確的釋放，

    你的類別什麼虛擬函式都沒有（含解構式），繼承它，

    未來背負著一個memory leak的風險。

(d) 正確的繼承

    假設，CHuman是個基底類別，CHuman人物會動、可裝備、會說話....，

    假設遊戲中出現了一種東西叫"假人"，人類經常習慣用名稱將之歸類為人類的一種，

    所以他該繼承CHuman，然後把所有不能用的功能重寫。

    你做了什麼事？把一個功能齊全的人類別，降級成什麼都不會的假人？

    只因為它長得像人？

    或者應該由一個物品，開始去繼承，增加功能比較適合？


    這裡提一個繼承基本上的判斷標準: 假人是不是一種人?

    意思是，人類會什麼，應該假人也要會什麼，少把類別寫成，假人是人的一種，

    但是他太多不會這不會那時...，大概就是錯誤的繼承關係了。



--
▅◣ Origin:  謠 言 報  bbs.csie.fju.edu.tw
▋◤ Author: ie945167 從 219-85-0-189-adsl-nei3.dynamic.so-net.net.tw 發表

[筆記] 全文轉錄 - 少用繼承

 作者  ie945167 (龍蝦)                                      站內  Lobster
 標題  [筆記] 全文轉錄 - 少用繼承
 時間  2012/04/04 Wed 17:46:41
───────────────────────────────────────

http://imandrewliao.blogspot.com/2009/01/blog-post_07.html

物件導向程式設計中，為了提升程式碼的再利用性，提供了繼承這樣的架構給我們使用，

只要看不順眼的類別，就可以用繼承改寫舊功能，達到擴展的目的，範例如下:

class AI
{
    private:
    virtual void FSM(); // AI類別實做FSM
};

class Monster : public AI
{
    private:
    virtual void FSM(); // Monster類別改寫原來的函式
};


但就"程式碼再利用的"目的而言，事實上，我們常用的方法還有一種，

"組成"，利用物件彼此間的協力，完成特定工作，

譬如，老闆要求去做一件A、B君都只會做部分功能的工作，

依照繼承的觀念，是否要生成第三個類別C，繼承A、B的能力，

然後改寫部分關聯而增加的程式碼?

然而我們是不是可以換個方向思考，

我可以設計個類別C，工作交代C，C會先請A君做完他會做的，

然後B繼續接手，一樣可以完成工作，

與繼承兩者，事實上複雜度一樣，都需要3個類別，

但是程式維護的小心程度卻是不可相提並論，程式如下


class AI
{
    public:
        void FSM();
};

class TimeControl
{
    public:
        void DoSomething();
};


用繼承:
class Npc:public AI, public TimeControl
{
    void DoSomething(); // 這裡遭遇第一個難關
                        // 多重繼承，要小心AB的成員變數、成員函式設計關係
};

用組成:
class Npc
{
    private:
        AI ai;
        TimeControl tc;

    public:
        void DoSomething(); // 我可以在這裡，靈活運用ai, tc物件的函式
                            // 達成老闆目標
};

你可以看見，往後ABC三個類別的修改，相依性是否會降低很多很多，

說白話，只要AB類別確定功能正常，發生BUG一定就是C，

A類別新增怎樣的功能，不會影響C或B的運作，同理C增減怎樣的函式，AB都不會影響，

而使用繼承呢? 就算你確定ABC三類別功能都正確，卻有可能因為繼承的關係，

造成邏輯錯誤，像是C發生BUG的原因，是因為C修改了一個變數值，

然後是A或B非常重要的變數，不允許由外部變更的

(這裡有個小伏筆，避免修改到別人家的變數，變數請用private封裝...)。


加上有許多程式濫用繼承，一個遊戲專案裡頭隨便都成千上百個類別，

加上彼此繼承的關係，專案像是N坨大肉粽樹，盤根錯節，

某Z類別有BUG，原因卻是在千里之外八竿子打不到關係的A類別造成，

改了A，卻連鎖反應要把某個肉粽樹的函式都要改過，想到就累人啊，

所以，有得選的情形下，請少用繼承多用組成。


再舉個生活上的例子，老闆要設計個簡報在客戶面前推銷商品，為了達到目標，

他需要繼承文書小姐的能力+產品部門對商品規格特色了解的能力+簡報能力+....，

或者，

他可以把公司內文書小姐、產品部經理、行銷推廣部經理叫來，說出需求，

接下來大家就自動會把事情搞定，而老闆則可專心挑毛病去，

愛用繼承的，通常工作累得要死，

愛用組成的，通常是老闆，你選哪個?



--
▅◣ Origin:  謠 言 報  bbs.csie.fju.edu.tw
▋◤ Author: ie945167 從 219-85-0-189-adsl-nei3.dynamic.so-net.net.tw 發表

[筆記] 全文轉錄 - 類別裡面的const"變數"

 作者  ie945167 (龍蝦)                                      站內  Lobster
 標題  [筆記] 全文轉錄 - 類別裡面的const"變數"
 時間  2012/04/04 Wed 17:44:20
───────────────────────────────────────

http://imandrewliao.blogspot.com/2009/02/const.html

最近被問到，類別裡面的const變數撰寫方式，乾脆整理const的一些規則，

首先，const應該是常數不是變數，所有的常數只能被初值化，不能被賦值，

所以只能寫在建構式的initial-list中，一般常數的設計方式有以下幾種:


1. 用#define 這個方式是最暴力的，被define的常數本身不隸屬任何類別，

曾經看過這樣的程式碼，寫在程式的任何地方意義都是一樣的:

// 寫在裡面
class ABC
{
    #define PI 3.14159
};

#define PI 3.14159
class ABC
{
};

所以，嚴格說來，這不算"類別裡面的const變數"。


2. 用const修飾的變數
class ABC
{
    const float PI;
};
這種方式只能在建構式的initial-list初值化，錯過這個機會，變數值就不知道是什麼了

ABC::ABC()
: PI(3.14159) // 這裡
{
}

3. 類別內共用的常數變數，可以用static修飾，讓所有物件共用這個"常數"
class ABC
{
    static const int SONG=123;
};

用這種方法可以直接在類別宣告裡面給初值，但是有一個限制，

這種方法僅限於型別是整數的型態(至少VC是這樣的)，

如果想要用非整數的型態，要用這樣的寫法

class ABC
{
    static const float PI;
};

在CPP某處加:
    const float ABC::PI=3.14159;

為什麼要加在CPP? 只是因為不能讓"const float ABC::PI=3.14159;"被編譯兩次以上，

如果放在.h有可能發生，而造成編譯錯誤。

4. 使用enum
    class ABC
    {
        enum { SONG=134, STOP=1113 };
    };

用這種方法，只要enum區段合法，任何時候都可以用 ABC::SONG

這樣的寫法來取得其值，不過限制是，enum只支援整數型別...。

這麼多種常數設計方式，我們要如何挑選正確的呢?

以下提出一般常用的原則（記住，只是原則，沒有規定一定要這樣）

1)#define大致上會被丟到歷史的洪流去了，因為本身有很多隱藏的危機，

    在系統寫大的時候，經常造成不知所謂的BUG

2)const變數，每個物件還有機會設定各自的常數值

    class ABC
    {
        private:
            const float PI;

        public:
            ABC(float a)
            :PI(a)
            {
            }
    };

    void main( void )
    {
　　    ABC abc(100);
    　　ABC def(200);
    }

3)通常用於類別內，獨一無二的非整數的常數值

4)通常用於類別內，獨一無二的整數的常數值


--
▅◣ Origin:  謠 言 報  bbs.csie.fju.edu.tw
▋◤ Author: ie945167 從 219-85-0-189-adsl-nei3.dynamic.so-net.net.tw 發表

[筆記] i++ 好，還是 ++i 好？

 作者  ie945167 (龍蝦)                                      站內  Lobster
 標題  [筆記] i++ 好，還是 ++i 好？
 時間  2012/04/04 Wed 17:41:35
───────────────────────────────────────

不負責任聲明：以下憑印象+google寫成，有錯誤很正常 0rz

              如果有人願意指出錯誤，我會很感謝您的 <(_ _)>

--------------------本文開始分隔線--------------------

下面是我們常用到的迴圈
for(i=0 ; i<? ; i++)
{
    (something)
}

大家常用 i++ 還是 ++i 呢？

其背後的運作模式為何？

T& opertor++ ()
{
    a = i++;
    a = ++i;
}

取址運算子 &
取值運算子 *

i++
    temp = (*this); // temp = i
    ++*this;        // i = i + 1
    return *temp;   // return = temp

++i
    ++*this;        // i = i + 1
    return *this;   // return i

簡單來說，i++ 背後會比 ++i 多複製了一次(我印象中聽到是兩次…0rz)

如果 i++ or ++i 的 i 只是單純的資料型態，如 int

那麼先加或後加就沒什麼太大的差別了

但是如果 i 是代表一個很大的物件

那麼多做的那些動作對於程式執行的效率就會有所影響

因此建議盡可能養成使用 ++i 的寫作習慣 (不過我已經寫了快七年的 i++ 了…0rz)

(對於ints 和 pointer，編譯器最佳化可將這額外的動作去除。但對於較複雜的
 iterator 型別，這個額外動作的潛在代價可能很高。)

--

     身高不是距離
                   技巧不是問題
                                 只要有"心"
                                             人人都可 定‧三‧米


--
▅◣ Origin:  謠 言 報  bbs.csie.fju.edu.tw
▋◤ Author: ie945167 從 219-85-0-189-adsl-nei3.dynamic.so-net.net.tw 發表