戰魂小筑

一直不是很清除VC的斷點保存于何處，讓我們看幾個證據：

1. 多人開發中，經常更新別人的代碼后，突然停在某個自己沒打過的斷點上，我們組稱之為附送斷點。
2. 并且無論VSS還是SVN等代碼管理工具都會出這樣的問題。但是你提交的只有代碼，沒有其他單獨的配置文件
3. VC2005中，即便打過SP1，也會碰到某個文件突然無法打斷點的BUG（排除沒有重編，打錯文件斷點等低級錯誤），解決辦法是：打開記事本，將這個文件的代碼全部粘貼到記事本，再帖回來
4. VB中的代碼文件，使用記事本打開時，可以看到比IDE里看到更多的配置型代碼

綜上所述，基本可以斷定VC的斷點被保存于代碼的尾部的某個位置，看不見的一些字符

    目前項目中使用Flash為主設計的UI，因為兼容性問題，Flash中編輯框雖然可以輸入中文，但是光標是看不到閃爍的。經過仿佛研究發現，必須將d3d 的flash容器程序在后臺時，才能顯示光標，這一個測試結果讓我們雷的不行。最終決定將flash拆解開，每個界面一個flash。但依然發現很多影響開發效率的問題。

    GameBryo引擎中支持原生的C++ GAME UI，也支持直接播放flash，這部分（ScaleForm）使用的是以GameSwf為基礎的手動解析flash文件，因此在編輯框等方面做的非常好。

    Flash的UI開發靈活度很高，底層庫bug少，但是與現有工程結合難度大，因此仍然轉向研究以XML為基礎的UI庫設計。

    這里推薦幾個參考：

    WowBench： http://sourceforge.net/projects/wowbench/

        這是魔獸世界的UI的模擬器，開源，可以從中了解魔獸世界的基本UI架構及API構成。同時，魔獸的lua腳本在安全性和開發度上做的非常好，這部分可以參考下。

    Mozilla XUL：https://developer.mozilla.org/En/XUL

        這是Mozilla戰略中的一個重要組成部分，這套UI支持類似于wxWidgets或者HTML方式的排版

    騰訊新產品線：QQ2009, QQ 旋風2，QQ影音等都使用了非常漂亮的界面。一直以為是自己寫的，畢竟QQ2009需要一個安全的環境以避免外掛的衍生。經過spy++探測，發現一個TXGuiFoundation，再在網上一搜，搜到了這個東西：

    DSkinLite: http://uieasy.cn/downloads.html

     Dskinlite 是一款輕量級的C++皮膚庫，使用XML文件根據規則來管理GDI資源如顏色，字體，圖片，并描述界面構成，最大程度的將界面和程序邏輯分離，同時為軟件皮膚更換，換色等提供基礎支持。DSkinLite將界面構成元素抽象為線條元素，矩形元素，圖片元素，文本元素，并提供相應規則來使用這些元素"組合"界面。DSkinlite開發團隊有較深的Windows界面開發的實際經歷，對軟件界面處理頗有心得，致力于將實用，高效，前沿的界面處理技術介紹給廣大開發人員。

        DSkinLite與其他界面庫相比有以下特點： 沒有采用Hook所有進程消息的方式，因此沒有替換系統相關對話框。DSkinLite只是采用MFC，ATL等framework類似的方式，簡單替換窗口過程，截取界面繪制等消息，對應用程序來說基本上是透明的。從這個方面講，DSkinLite是一款輕量級的界面庫。 同時，DSkinLite沒有特別的Frameword的依賴，可以在Win32，MFC,ATL,WTL等環境中使用。 DSkinLite界面庫使用XML管理GDI資源并配置窗口界面，用戶可以方便的保持界面的一致性，同時可以很方便的構造出更多的窗口樣式 界面庫的高效性。DSkinLite將專注于程序庫的高效性，具體表現在內存占用，界面繪制速度，界面防止閃爍，程序加載圖片資源、解析XML文件的速度等方面，我們做了很多工作，并不斷持續優化。以期望程序各方面表現最為高效的界面程序庫。 
        DSkinLite 皮膚庫的程序架構考慮到可能出現的界面特效，使得實現諸如透明，漸隱漸顯，動畫等界面特效變得更加容易，目前支持大多數控件的透明效果，后續會根據用戶需求，開發更多的實用的界面特效。

使用XML配置控件的界面

• 使用XML定義GDI資源（顏色，字體，圖片，cursor）
• 使用XML配置控件的界面風格
• 繪制元素被抽象為線條，文本，矩形，圖片
•  

  XML語法簡單，易于學習和掌握

   

  其他關鍵特性

   

• 基于Win32 API，沒有framework依賴。
• 支持大多數標準控件
• 支持改變皮膚色調
• 支持大多數控件透明，包括子窗口透明
• 支持動畫效果
• 支持png, bitmap, gif, ico圖片格式。支持帶透明通道的png圖片
• 支持將皮膚文件打包到一個文件
• 支持Unicode
• 支持Popup Menu等，包括不規則的menu window
•  

  支持滾動條控件，同時支持所有內置滾動條控制

     

  該網站還提到一個DirectUI的東西，這個東西是一種windowless的架構，具體概念類似于游戲中的UI，不依賴平臺句柄，因此外掛只能截取諸如QQ基于ATL的外窗口，但是無法獲取窗口內部的數據

????Svn現在已經是非常流行的代碼管理，雖然vss更容易接受。但是真正方便的而強大的卻是git。

????這個東西沒有獨立服務器提交代碼，每個本地都是一個代碼庫，包括log等等。而且代碼管理文件夾不像svn每個文件夾都有，更不像vss用只讀文件的巨傻辦法來做，git使用的是獨立一個文件夾來做，簡單而又簡潔

????這里記錄git的安裝方法和使用說明以便下次快速索引

????說明和下載：http://hi.baidu.com/mcspring/blog/item/171b1e38986d39fab211c71b.html

使用指南：http://www.linuxgem.org/2008/8/1/git-tutorial.4889.html

一分鐘指南：http://blog.enjoyrails.com/2008/12/31/git一分鐘教程/

更直觀的教學：http://hi.baidu.com/proteus/blog/item/6ec19322c2a39cf4d6cae22d.html

    10年前的廣播節目中大概都有這么一個設計：某某節目開始，讓聽眾打進電話。一般不會像聲訊臺那樣設置很多的接線員，因此電臺會設置一個導播來接聽電話，打不進來的聽眾就只有在接通電話后等待著。這樣做，用戶體驗其實并不好，時間長了，別人會認為怎么你那電話怎么老是打不進來。

    四川電臺經濟廣播每天早上9點開始的人氣節目《方言社會》是這樣設計的：主持人會隨機選擇一條成都的街道，讓在這條街道上的聽眾打進電話來說他看到了什么，然后獲贈諸如電影票之類的東西。這樣分析下來，沒有在那條街上的人自然也就不會打進電話進去。畢竟在那條街上還聽這個節目的聽眾比起整個四川人口來說還是算少數。

    因此這就是很好的一個負載平衡的小例子

    最近聊天系統測出一個問題：測試人員使用的是韓文操作系統，在上面安裝了搜狗中文輸入法。他們互相之間發送韓文聊天是沒有亂碼的，但是我們和他們互相以中文發送時，會出現亂碼情況。隨即進行測試發現以下問題：

    對于 "德國"

    他們發送的編碼數據為 d3 ec 3f

    而我們的中文系統為 b5 c2 b9 fa

    因為聊天系統采用ANSI的架構，但是為什么同是東方語言系，一個會是UTF8,一個是ANSI雙字節，因此將聊天系統整體發送換成純UNICODE進行測試

    朋友催促下，想很快的做出新一版的戰魂，并且添加這4年多來自己所有研究出來的高科技！

    對于大量的子彈彈幕和高速微操控制，只有幀同步能解決這個問題，但是中國國內對于幀同步研究的人很少，國外也少見這類文章，甚至用google都很難搜到，難不成是我用錯搜索詞？

    大學時期曾經看過一本重慶大學出版社出版的游戲編程。基于DX8寫的，很基礎，里面還記得有王鑫寫的幀同步的基本原理。

    這里個人總結下：

1. 幀同步，顧名思義：就是每一幀都同步，所以就是真同步
2. 由于數據量巨大，一般使用UDP做發送
3. 要做到數據的絕對同步，延遲不能太大，最好能在局域網來做，延遲20ms以下
4. 如果要在公網傳輸，由于采用的是P2P傳輸，因此，UDP的打洞也是必不可少的

因此，可以先定下采用的網絡庫是Raknet（http://www.jenkinssoftware.com/），從網上down了一個下來看視頻，還是很強大的，雖然用的項目不是很多。不過用于個人的項目已經足夠了。

    Raknet和XNA下的網絡庫很類似，支持可信賴的UDP發送。由于是自定義的傳輸方式，同時，沒有TCP的負載均衡的復雜算法，因此網絡傳輸速度可以很快

    在游戲中的幀同步，在我的考慮將是這樣的：

1. 游戲中的邏輯幀與渲染幀是不同步的，邏輯幀也許遠遠低于渲染幀
2. 對于一個使用elapse值在邏輯控制下移動的物體，這個移動算法必須能被時間插值。
3. 那么我們將這段時間進行分段，每一段就是一幀。我們為這些幀進行編號，類似于封裝TCP協議一樣。這些編號更類似于指令號。
4. 游戲中有一人被作為服務器使用，每個玩家將自己的操作編碼成指令后發送給這臺服務器，由服務器統一分配序號廣播給所有的其他玩家
5. 對于可以被時間插值的動畫軌跡（尋路），那么將發送軌跡（如果尋路算法出來的結果是唯一的，就只需要發送起點跟結尾點）以及每幀更新這個物體的時間插值參數。
6. 由于外界輸入對系統的干擾，才產生了需要同步的數據。外界輸入干擾保護用戶操作和AI
7. 考慮到每人的網絡ping值的不同，對于特別慢的玩家，可能在其廣播指令時，其他玩家已經走出很多步，因此需要計算一個平均ping值，當網絡中某人的ping值低于這個值時，將彈出類似于魔獸/星際的同步對話框，等待其本地指令序號趕上其他玩家的序列號
8. 由于所有物體的移動都可以被時間插值，因此，游戲中的每一邏輯幀，只需要將本地服務器在上一幀的ping值和幀號廣播給所有的玩家
9. 當物體啟動和結束移動時廣播
10. 當渲染幀數下降時，將很明顯的看到幀同步對象有很明顯的"跳躍"現象，這個現象在星際中更是明顯。但在技術成熟的魔獸中已經被插值予以替代

    我的項目中由于還沒有加入轉發服務器，因此暫時有3臺對外服務器，服務器與服務器之間暫時用內網連接，今天將服務器放到雙網卡的服務器，發現竟然將服務器內網地址告訴給客戶端來連接，很明顯這是錯的！

    馬上著手解決這個問題：是否可以根據配置，對某幾條連接自動從gethostname中獲取到內網或者外網地址？事實證明是錯誤的！這里有一個例子：

    某公司的電話只能對內打，對外打只能靠私人手機。如果 A正在用私人手機跟公司外的B打電話，此時，B想打C的手機，但是B不知道C的號碼。但同時，A只知道C的內線號，但不知道其手機。這種情況下，B只有找公司的前臺D要到 C的手機號，因為A,C在進入公司時就已經注冊過他們的手機號。這樣，B就成功的打通了C的手機號。

    這是一種解決方法，也就是說，在現有的服務器管理的上層，再做一層平臺服務器，其他服務器到這臺服務器獲得自己在外網的地址，然后對需要進行外網聯系的服務器組和客戶端之間傳輸使用外網地址。

    還有一種方法：

        C首先將自己的手機號告訴A，之后B與A聯系后，得到C的手機號，而不是其內網號，即可聯通

    這種方法的原理就是：將要讓客戶端轉接的某臺服務器的地址的公網ip保存在配置文件里，在讀取后將這個地址告訴給列表服務器，這樣客戶端連過來就會獲得一個正確的外網地址

    由于書寫習慣，現在項目里依然使用我原來習慣的頭文件定義協議結構體的方式：

struct EnterLobbyREQ : public ProtocolHeader

{

        char mSessionID[64];

}

這種寫法比較傳統，有以下優點：

1. 確實叫協議，帶頭文件，如果協議有修改，客戶端和服務器代碼馬上能看得出來
2. 可以在結構體里添加一些自動填充size,type等的構造函數和一些自動計算變長包大小的函數，減少拷貝代碼出現的錯誤
3. 書寫直觀，初學者容易理解

但也有以下缺點：

1. 一個修改可能導致全盤重編
2. 發送復雜結構的數據不靈活：

   如果只想發送10-20個成員的結構體里的7，8個成員，就需要寫很多的賦值表達式，而且這樣的代碼充斥整個工程

    比較流行的寫法就是流式寫包，在有些工程里叫ProtocolComposer

void Foo (ProtocolComposer& composer)

{

        composer << pos << action ;

}

    其優點顯而易見：

1. 協議可以只是一些注釋，客戶端和服務器只需要約定俗成就可以，修改協議無需重編
2. 可以在復雜結構中自由構造發包內容，拷貝復制方便自如
3. 自由制作變長包及類型決定包內容種類等

但其缺點也是有的：

1. 一端修改協議后，另外一端若不及時修改，在編譯期將無法發現，如果最后在運行期暫時沒有報錯，將形成bug
2. 組包速度慢于前者，對C++類型的代碼支持較好，但是c方式接受較為麻煩

總的來說，后者還是為很多項目所用，所以下一個項目將啟用后者進行編寫，希望能得到更好的游戲邏輯編寫體驗。如果有更好的建議可以回復。

    終于拖著8500GT動畫片般的將波斯王子4打通。說實在話，這游戲做的確是好，可惜太卡，居然做夢都想買臺360感覺下。

    波斯王子4繼承刺客信條，依舊是那款命名為"彎刀"的引擎（可以從其打包文件頭看出來）。整個游戲從一開始到最后，我多被其骨骼動畫混合系統驚嘆不已。

游戲中，如果王子先爬上欄桿或者木樁子，公主上來之前，王子自然會讓開，甚至會伸出一只手拉她上來。另外，協作動畫到處都是，基本上很平滑，不過需要批評的就是在拉機關時，如果女主角距離很遠，此刻她會閃現在機關面前

對比前幾作，本作取消了時之沙系統，取而代之的是無限制接關和不死身。很多人抱怨，很多人不滿，但是在我看來，這是對游戲性的極大擴展。時之沙可以讓時間倒退，但是用完后還是會復位，降低了游戲的流暢感。其實波斯王子是啥？就是一個古代跑酷的RPG，相比鏡之邊緣來說，波斯王子的體驗感和厚重程度要好很多

值得夸獎的是本作戰斗系統及人物感覺。前幾作的人都跟紙片貼墻上飛一樣。經過刺客信條的洗禮，波斯王子估計也徹底換了引擎，人物也有厚重感了。戰斗系統的防御及反擊做的極為舒服，只不過重復的擊打4個boss有點回到二代的感覺，這就是歐洲游戲和日本游戲的本質區別：策劃和美術都很懶！

本作的對話系統很有意思，在你多次掉下懸崖時，公主會說："我需要你！你不能死"，王子偶爾抱住公主時也會說她長胖了，游戲間，很多感情戲就漸漸的讓玩家感受到了，雖然劇情很俗，但是你卻能體味其中。最有意思的就是公主8分身時的唯一解法就是跳下懸崖，讓公主來救你，太精妙的設定了

下一作大猜想：

    想必加入類似于FC版刺殺希特勒的爪子，增強游戲性？

    希望繼續保持現在的戰斗系統和不死身

    劇情再離奇一些

    至于場景嘛，最好是來個小時候看過的 從地里倒長的樹，那可是正宗的阿拉伯故事哦

波斯王子系列歷代都走的是劇情+感動+細節+語言。

時之沙，最終女主角死后，主角利用時之沙之力回到從前，對過去的女主角說曾經有過那么一段情。

武者之心，雖然被達哈卡追的個死去活來，但是能在GF4上看到那么唯美的世界已經很滿足了，從紅色絲綢的誘惑到最終與時之女王的纏綿，讓這個王子不愧為playboy。

王者無雙，從二代劇情延續過來，但是時之女王一開始就掛了，之后又回到了初代

而最新作：復生，講的便是一個mm和一個gg一起周游世界打敗黑暗，當然，最后mm掛了，因為生命換來了光明，gg不肯，把黑暗重新帶回了世界，不過mm活了，私欲啊，私欲啊，o(>﹏<)o