太陽系後援會

一般化(Generalization)是很重要的一個步驟
卻也是常常被人忽略的一個細節
簡單來說，就是把特殊用途的程式碼
轉變成為一般用途的程式碼
舉個例子來說，我現在有20種怪物的AI要寫
直覺上我們會建立20個Class來分別實現
但是事實上，真的需要那麼多嗎？
仔細分析一下怪物的種類與特性
地上爬的，天上飛的，水裡游的，就分成三大類
攻擊模式，體型大小等等都可以是分類的依據

最近在天瓏看到一本新書叫做
Short Coding 寫出簡潔好程式－短碼達人的心得技法
探討程式原始碼可以縮到多短，一邊研究資料結構、演算法、執行環境的過程。
程式高手可透過思考如何寫出簡捷好程式的過程，加強其邏輯思考與解決問題的能力，甚至對數學、資料結構與演算法等的活用有更多的體會。

什麼是程式碼壞味道(Code Bad Smell)?
簡單的說就是指程式碼中會讓你感覺不舒服的地方，比如說洛洛長的程式碼和重複性的程式碼沒有被提出來成為一個function來執行功能。
這樣的狀況是不是常常出現在你的程式碼中?

 http://theflashgames.blogspot.com/2008/09/lightbot.html
寫程式讓機器人走到藍色框框點燈
通常第一次玩total command約180~190

 今天由製作人那學到了關於美學的基本原則
他告訴我們那就是--[規律中有混亂，混亂中有規律]
為什麼會說到有關於美這個哲學層級的東西呢
通常我們在做遊戲時，為了讓遊戲有所變化，常常會加上很多亂數
感覺上會因為很多亂數不同而造成許多效果。
想想看
我們平常自然的走路時是以一種很規律的步伐、速度前進
看上去是很規律
實際上每一次踏出去的步伐距離與瞬間速度都不一樣
都會產生微小的偏差亂數
在做遊戲時也是要有這樣的模式
每一個AI的行為或是特效的表現
都是在一個規則之下給於微小的亂數產生自然的效果
之前玩過一款PS3的遊戲叫做--[秘境探險：黃金城秘寶] (這是個好Game，推薦一下)
這款遊戲利用Animation Blending的技術號稱你不會在遊戲中看到相同的動作
他在每一個動作的細微上都加上一些微小的亂數來Blending
比如人在走動時頭會左顧右盼，手的擺動也會有不同幅度等等
他呈現的效果就是生動自然
黃金矩形也是符合這個原則
圖片出處http://zh.wikipedia.org/wiki/%E9%BB%84%E9%87%91%E7%9F%A9%E5%BD%A2
它在每一個矩形中切出正方形另一邊也是一個黃金矩形
符合了--[規律中有混亂，混亂中有規律]

__FILE__ ：取得目前的檔案名稱及路徑，回傳的是字串。
__LINE__ ：取得該巨集呼叫的行數，回傳的是integer。
 
__DATE__：取得系統日期，格式為"Mmm dd yyyy"

__TIME__：取得系統時間，格式為"hh:mm:ss"

__TIMESTAMP__：取得系統日期與時間，格式為"Mmm dd yyyy hh:mm:ss"

__FUNCTION__：取得呼叫該巨集的函式名稱(包含類別名稱)。

進入這一個章節的最後一部份
一口氣就介紹三小節State，Composite和Command
不過不用太擔心，我想這篇文章會很短
因為...我懶得打那麼多的字～
前兩篇文章不斷提到觀念，也是這個章節的中心思想
當你遇到複雜的巢狀判斷式，或是冗長的判斷式時
請毫不猶豫的簡化它！
所以延續前面的主題，另外有三個Pattern可以幫助你簡化
也就是State，Composite和Command
講到State，就不能不提到目前的AI State machine架構
沒錯，它就是典型的State Pattern
AI利用FSMActor來操縱State的轉移
來達成不同階段AI的行為
再來是Composite
看完書中的範例，我腦中只想到一個架構：AI Parser
其實就是XML Parser
利用Composite的架構來解析複雜的語法標籤
真是再合適不過了
至於Command，我並不是很熟這個架構
但是我直覺性的聯想到Debug Tool裡面的Command Mode
因為Debug Tool是會無限延伸的
定死了架構到後面一定會很悽慘
Command在這時候就是很好的選擇
把各種不同類型指令放到底下的Class去解析，去處理
只訂定共通的操縱介面
如此一來Debug Tool的Parser就會很乾淨，也容易管理和擴充
以上，就是Simplification最後一個部分～

這次來比較兩個有趣的東西：Strategy和Decorator
同樣是巢狀邏輯判斷式的寫法
改法不止限於上次提到的Composed
Strategy和Decorator也是不錯的選擇
艾倫史密斯在互動元件那邊做了一個示範
詳細內容我不贅述了，有興趣可以去找找看
總之是在處理主角吸上互動元件後
怎麼對主角施予重力和建立Joint
讓主角不會掉下來，並且可以做有限制的移動
第一個碰到的問題是
當主角踩在互動元件上面的那一瞬間
要怎麼去判斷他踩到的是什麼呢？
想當然爾，碰撞會有碰撞訊息
於是以下的Code就會出現：
switch (pMsg->m_uiType)
{
    case MST_TRIGGER_COLLISION:
    {
        ksMsgActor *pObj = pMsg->m_pTouchAI;
        if ( NiIsKindOf(ksObjA, pObj) || NiIsKindOf(ksObjB, pObj) )
            // 建立第一種Joint
        else if ( NiIsKindOf(ksObjC, pObj) || NiIsKindOf(ksObjD, pObj) )
            // 建立第二種Joint
        else if ( NiIsKindOf(ksObjE, pObj) )
            // 建立第三種Joint
        else if ( NiIsKindOf(ksObjF, pObj) )
            // 建立第四種Joint
        break;
    }
}
很好，決定了Joint的種類
接下來主角開始移動，但是磁力物件千百種
有的直有的彎，怎麼知道主角該不該轉彎呢？
主角吸在物件上面，所以會有Trigger的訊息
於是下列的程式碼出現：
switch (pMsg->m_uiType)
{
    case MST_TRIGGER_ON_STAY:
    {
        ksMsgActor *pObj = pMsg->m_pTouchAI;
        if ( NiIsKindOf(ksObjA, pObj) || NiIsKindOf(ksObjB, pObj) )
            // 走在直線型的物件上
        else if ( NiIsKindOf(ksObjC, pObj) || NiIsKindOf(ksObjD, pObj) )
            // 走在圓弧形的物件上
        break;
    }
}
如果你以為艾倫史密斯是這種寫法，那你就錯了
要知道，他可是史密斯
寫法當然要不一樣，所以他採取的是Strategy
一種抽象到不行的寫法，害我每次Trace Code都很痛苦...
不過這真的是物件抽象的極致
搞到最後他也不知道是碰到哪一個種類的物件～XD
使用Strategy，可以大大減少主角這邊判斷的機制
我只需要呼叫統一的介面，就可以輕鬆吸上磁力物件
就像這樣：
ksTerrainDestKit* pKit = (ksTerrainDestKit*)pAI->GetKit(TERRAIN_DEST_KIT);
pKit->CreateJoint();
這裡的CreateJoint裡面包著就是Strategy function
同理，主角移動時也用類似的方式來取得資料：
pKit->AddForce();
剩下的由物件自己去處，而ksTerrainDestKit就是Strategy委託者
那麼Decorator何時會使用呢？
對我來說，如果Strategy是橫向的封裝
那Decorator就是縱向的封裝
Strategy會依據種類來決定使用哪一種function
但是Decorator是一層一層的
封裝多少層，就會經過多少個function
兩個Pattern詳細比較在豬屎排程寫的比較多
但是真正要使用的時刻，怎麼判斷用哪一個
還真的是靠個人修行！
講了那麼多，其實兩種Pattern的比較只講了一點點...
好吧，我承認自己修行不夠，沒法寫出精闢的解析
所以就讓我繼續下一章節吧！XD

 
最近玩了不少 Web game，不過都大同小異，沒有吸引我的
不過前幾天發現了這個，把我嚇到了(http://az4.webgame.com.cn/)
它是第一個即時對戰 PK 的 Web Game
這是什麼意思？
目前大家所熟悉的 Web RPG Game 的移動的方式大多是用點的(點移動的地區)
雖然這個也是用點的，不過它所呈現出來的是會動態移動你要到的位置
看起來和 MMORPG 的移動方式一樣
下面是他其它的介紹
一般的 Web RPG Game 按熱鍵喝水放技能算啥
它能直接在地圖上點選，並用攻擊技能打怪，或者放輔助技能幫人補血  
一般 MMORPG 遊戲所具備的功能它都有
排行榜 ＆ 任務
商店
 
人與人間的互動都有的也都有 怪物血條、聊天頻道、工會組織  

結束了創建(Creation)的部分，接下來則是簡化(Simplification)
 
我想又臭又長的程式碼是沒有人可以接受的