stratagus的ai規(guī)則：

stratagus這個高仿war2的程序會分時間段來調用ai的處理函數(shù)。它的ai規(guī)則主要是用一些ai函數(shù)來定義，
比如說某方電腦可以定義對應的ai規(guī)則函數(shù)，記得是通過類似aidefine, aineed, aiwait, aiattack的函數(shù)進行ai規(guī)則的定義，比如說aineed 兵種 個數(shù)，然后aiwait會陰塞直到程序ai處理到達條件才繼續(xù)執(zhí)行后面的ai規(guī)則函數(shù)，這就可以非常方便的定義各種電腦的ai行為，比如說生產(chǎn)出aineed一些農(nóng)民，然后等待，夠出就會aineed兵營之類，等待夠了就aineed多少個兵，aiattack開始嘗試出兵攻擊玩家.

另外這個游戲的迷霧作法是以地圖塊記錄陣營迷霧表，地圖塊的unit進出會進行刷新，而迷霧簡單地用預處理好的迷霧圖塊（作法跟地表紋理一樣的）進行拼接渲染，這種作法跟當前war3的作法基本一致，只是war3的迷霧圖塊是實時更新的,迷霧可以動態(tài)圓滑過渡（在之前一文章分析過了），而這個迷霧圖則只能按格子跳動，不能圓滑漸變。

 

另外存下一下以前的跟蹤流程，以備用。

                          stratagus流程

一。 腳本Start Game按鈕調用 RunMap(mapname)中執(zhí)行程序中StartMap(map)
二。 程序中CreateGame后GameMainLoop中游戲循環(huán)處理.

//---------------------------------------------------------------------------
一。祥細:
1. 腳本初始:
   程序通過加載stratagus.lua進行初始設置, 并裝載其它腳本，通過
   DefineUnitType(..)來定義各種類型unit的屬性

2. 渲染初始:
   InitVideo()

3. 聲音初始:
   InitSound() && InitMusic()

4. 加載字體:
   LoadFonts()

5. 顯示splash:
   ShowTitleScreens

6. 單位管理器初始:
   UnitManager.Init(); // Units memory management

7. 界面加載:
   PreMenuSetup();     // Load everything needed for menus

8. 界面:
   在MenuLoop()中加載guichan.lua，這會運行RunProgramStartMenu() //如果是編輯器則是另一函數(shù)
   創(chuàng)建WarMenu界面，上面Single Player Game按鈕綁定RunSinglePlayerGameMenu()函數(shù)，
   響應后里面再創(chuàng)建另一個WarMenu界面，并綁定Start Game函數(shù)為
   RunMap(mapname),該函數(shù)會調用InitGameVariables遍歷調用初始化函數(shù)表InitFuncs[]()中每個函數(shù).
   最后調用程序的StartMap(map)游戲開始

//---------------------------------------------------------------------------
二。祥細:
1. CreateGame中:
   a. 迷霧初始
      InitVisionTable
   b. .smp地圖初始:
      執(zhí)行.smp地圖(lua文件來的, 就兩行調用DefinePlayerTypes()定義PlayerType和PresentMap()函數(shù)設置地圖信息)
      DefinePlayerTypes("person","nobody","nobody","nobody","nobody","person") //neutral||computer||person||nobody||rescue-passive||rescue-active
      PresentMap("Mysterious Dragon Isle", 2, 128, 128, 1)
   c. 玩家初始:
      遍歷16個玩家進行CreatePlayer創(chuàng)建(從Player[]取出), ThisPlayer=Players[NetLocalPlayerNumber];
      應用上述b中設置的PlayerType進行team設置(中立=0，電腦=1，玩家=2+i, PlayerRescuePassive及PlayerRescueActive=2+i,)

   b. InitUnitTypes
     初始type->BuildingRules, type->stats[player](stats->Costs，stats->Variables)

   c. .sms地圖加載:
     執(zhí)行.sms地圖(lua文件來的)，其中
用類似以下方法設置幾個玩家資源等信息（如下第一個參數(shù)0表示玩家號, 本地圖有0-5個玩家）
SetStartView(0, 80, 30)
SetPlayerData(0, "Resources", "gold", 2000)
SetPlayerData(0, "Resources", "wood", 1500)
SetPlayerData(0, "Resources", "oil", 1000)
SetPlayerData(0, "RaceName", "orc")
SetAiType(0, "wc2-air-attack")
SetStartView(1, 0, 0)
SetPlayerData(1, "Resources", "gold", 2000)
...

然后LoadTileModels("scripts/tilesets/wasteland.lua")（這個函數(shù)同等于直接執(zhí)行l(wèi)ua腳本）
在wasteland.lua中執(zhí)行了DefineTileset(...)來設置一堆地形中各圖塊資源位置
并調用BuildTilesetTables()程序進行處理, 接著調用 Load("scripts/scripts.lua")這個會據(jù)當前玩家的playertype來調用不同的ui.lua(human/org)

之后是一堆
SetTile(32, 0, 0, 0)
SetTile(35, 1, 0, 0)
...
作用是HP for walls/ Wood Regeneration

最后是通過
unit = CreateUnit("unit-oil-patch", 15, {7, 5})
這個會據(jù)第一個參數(shù)來找到對應的type并創(chuàng)建出unit對象，然后刷新unit所處在地塊的UnitFieldFlags用于尋路,
以及MapMarkUnitSight刷新視野, 視野的做法有點怪，他是根據(jù)角色視野來刷新地塊MapField->Visible[屬方]是否可見，
然后再從unit所在位置的地塊的visible[]來刷新unit->visible[屬方]，刷新時判斷
上次和今次變化，從而得知unit是不是從屬方player視野中進出.

SetResourcesHeld(unit, 20000)
unit = CreateUnit("unit-gold-mine", 15, {66, 6})
SetResourcesHeld(unit, 35000)
...
來創(chuàng)建一些資源

    d.  Map.Init();這個只調用了InitFogOfWar()

    e. PlayersInitAi()      
       遍歷16方玩家，產(chǎn)生查詢對應aitype信息(有aiscript函數(shù))設置給PlayerAi對象，并將對象綁定給該玩家.
 
    f. InitTriggers()
       用于注冊條件函數(shù)以及要執(zhí)行的函數(shù)。當前調用SinglePlayerTriggers()腳本函數(shù)，只注冊了勝利或失敗條件函數(shù)及對應執(zhí)行處理函數(shù)

    g. InitPathfinder()

2. GameMainLoop中:

主要是分時段來執(zhí)行ai處理函數(shù)等，具體不寫了。。。

 

之前臨時看了下mygui，發(fā)一下跟蹤的信息，以備參考:
一。 創(chuàng)建每個widget, 用所得皮膚進行初始化,
一個皮膚可以由子皮膚以及子控件組合成。
1. 創(chuàng)建皮膚對應的一個貼圖并創(chuàng)建皮膚下所有子皮膚（存入mSubSkinChildo數(shù)組中, 它們都是使用此相同貼圖)，并加到mSubSkinChild以及mDrawItems中。
2. 然后設置該皮膚對應的屬性值。
3. 創(chuàng)建該皮膚所有子控件(存入widget中的mWidgetChildSkin數(shù)組中)

二。將所創(chuàng)建的控件加入到對應的layernode中:   
LayerManager::getInstance().attachToLayerNode(_layer, widget);
其中會遍歷widget中所有mDrawItems(子皮膚),加到對應的layernode中，
當前子皮膚(SubSkin)使用該widget中的mTexture來創(chuàng)建mRenderItem(在layernode中有映射表按textrue來歸類, 其中文字放入mFirstRenderItems，其它放入mSecondRenderItems)
而mRenderItem中也有一個mDrawItems數(shù)組，用來存入SubSkin的. 同時mRenderItem中有mVertexBuffer，當渲染時，會遍歷所有mDrawItems，將它們收集到mVertexBuffer中進行批次渲染.

三。渲染:
遍歷所有mLayerNodes進行渲染
1. 遍歷mFirstRenderItems和mSecondRenderItems中所有RenderItem進行渲染
   在RenderItem中遍歷mDrawItems，調用其doRender()方法，將頂點渲染到mVertexBuffer中.

2. 渲染mChildItems中所有

四。 關于文字的渲染:
simpletext是一個renderitem

simpletext從edittext中派生
edittext::updateRawData會使用mTextView生成貼圖uv等數(shù)據(jù)
每個RenderItem提供一個vertext buf，供其中的數(shù)據(jù)進行填充批次渲染


文字的渲染由于是一次讀入的（老外就是不考慮中文），如果中文修改范圍直接用的話則加載時必定卡。。。
而且中文字多，一般不好全部一次存入貼圖中，只能使用貼圖緩存方式處理。

2d游戲中可以做到局部更新，3d游戲中這種處理已經(jīng)絕跡了，最近還是嘗試弄了下，
3d游戲中界面的局部更新問題

要在3d游戲中使用界面系統(tǒng)的局部更新，需要先準備一塊畫布，然后界面局部更新時刷新到這塊畫布上，這樣每幀只畫畫布
雖然之前有想過這樣的方法，但一直沒去弄過，最近弄了下，碰到的問題在于使用的帶透明信息的文字渲染上, 如下：
最近有人再次討論了這個問題，為了說明這個問題我又重新整理了下，新整理如下：
最近為公司寫了個性能優(yōu)化曲線工具, 可配置，如圖：


查了下war3場景同屏面數(shù)在4000-10000面左右, 可以看到單機下war3穩(wěn)定限幀在15到16毫秒（也即60幀左右）, 以下是一個簡陋版本載圖:

同時發(fā)現(xiàn)war3的迷霧似乎4格一個16*16像素的動態(tài)圖（樹陰影也動態(tài)做到上面), 例如：64*64大小地圖分成8*8個fog塊，
下圖是我載了些圖手動還原迷霧大致如下:




另外三國的曲線（部分渲染消耗，每一格為1ms, 測試機器比較爛，是集成顯卡）

另外show下山邊為公司寫的靜態(tài)性能分析工具， 用在cpu的消耗測試還是比較有用的，當然渲染消耗由于涉汲runtime/driver的緩存以及gpu處理等原因是測試不準的.
，另外難得今天有空又擺弄了下以前寫的地形引擎，順手載一下圖:

一。世界分布:
map中最多有64*64個block(即block[4096])
每個block對應一個terrain(大小約為533*533)分成16*16個tile(即tile[256], 每個tile大小約為33*33)
最后每個tile分成8*8個CELL(大小為4*4左右)，每個CELL中間附帶一個點，用于
在渲染時，如果是在tilelod內(nèi)則這個8*8個cell中間加一個點細分繪制,否則不用繪制這細分的三角形.

二。Tile渲染:  
   每個tile最多可存4層地表紋理，
   當渲染tile時，看有幾層地表就設置對應的不同層的shader，并賦與對應地表貼圖以及對應一張alpha map進行渲染
   求出地表base位置到角色位置距離，看是否超出tile的lod距離，超出則用粗格子，否則用細格子進行繪制。

 

小場景測試：反折射水，實時陰影，高光+泛光，splatting地表

男人撐過10秒minigame游戲...，周五晚上一時興致幾個小時弄的測試程序

地表刷:

//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
// UI的渲染:
//         flipcode@msn.com
//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

一。批次渲染:
1. 在界面上的3d模型渲染及特效需要每幀渲染到貼圖上再當UI來畫，否則將會打亂渲染狀態(tài)

2. 控件及文字按渲染順序生成z值，然后將不透明的按貼圖打包，先批次畫不透明的控件和文字，再關掉z write按排序畫非透明控件和文字.
   優(yōu)化方案:
      由于透明的控件和文字很可能沒法批次畫(除非它們順序畫時都在同一貼圖上)，所以約定所有控件和文字只用alpha test方式
   而不能用alpha　blend方式，也就是說控件和文字只能用colorkey（為了效率忍痛去掉類freetype用alpha blend產(chǎn)生的一些自然過渡的效果）
   并且盡量讓所有控件所用圖片都作成一兩張圖上。(文字則是程序為每種字體創(chuàng)建大概兩張貼圖cache, 并先緩存一些最常用的字)
　
二。去掉UI重疊部份的渲染:
1. 合并所有控件矩形ui_rect為一個全局多邊形集g_merge_rgn（并集）

2. 從上往下順序將所有控件矩形ui_rect與g_merge_rgn分別作交集測試, 成功則將交集存回UI控件ui_render_rect_rgn,
   并且如果控件為非透明(控件已在上述“批次渲染”約定為非透明但可有colorkey)時將全局g_merge_rgn減去該ui_render_rect_rgn交集

3. 從下往上順序遍歷所有所有控件并用控件自己的矩形ui_render_rect_rgn畫出控件

三。臟矩形渲染:
  有了上述的"去掉UI重疊部份的渲染", 這步就容易了，只要在渲染時判斷一下該控件是否更新過, 如果更新過則將更新過的rect與該ui_render_rect_rgn交集出新的rgn來畫.

四。關于渲染可能出現(xiàn)的邊線問題:
  一般是紋理在縮放過渡時使用linear采樣方式而控件使用UV尋址貼圖中小格子塊產(chǎn)生的（可在作圖時將格子塊象素外擴一圈，或者程序將UV內(nèi)縮一圈來處理）

五。最后提下，要先渲染UI，再渲染場景，這樣來避免無效的ps, 另外UI固定部分在渲染場景時可用viewport去掉。

//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
// 關于漢字輸入相關:
//         flipcode@msn.com
//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

一。創(chuàng)建dialog模式設備：

   為了不用自己渲染輸入法框，也只好犧牲點性能，使用這種非真正獨占的模式的設備。

二。接收輸入漢字

　１。可以直接使用windows消息的WM_CHAR，漢字高位是大于１２７的（有符號char<0）自己處理判斷組合一下即可。

   ２。也可以使用IME的來處理

三。漢字長度

　漢字有等寬字和非等寬字（普遍），非等寬字計算長度比較麻煩，需從頭遍歷。。。

四。非unicode漢字的截斷處理

　這個也比較麻煩，需從頭遍歷，如果使用unicode就沒這個問題

五。漢字的顯示

　需要貼圖緩存，再批次顯示

六。表情符號混顯：

　關于表符號混顯問題主要有兩點，一個是排版(具體處理就略過了)，一個是表情動畫處理

　表情動畫可以簡單的使用cximage讀取解開各幀再整合到一張紋理上，按幀播放顯示。

　

七。輸入法定位：

　由于輸入法的處理一般是在消息回調函數(shù)里得到目標wnd句柄，然后定位到這個wnd位置上，如果游戲中不使用windows控件的話，輸入法沒法自動定位到自定義的。只能靠用戶自己拖動。有一個簡單的處理是創(chuàng)建一個不用于顯示的假控件在對應位置讓輸入法得以定位。。。（魔域這個網(wǎng)游真的很邪惡，里面全部使用mfc控件，只是渲染使用directx來接管。。。）

八。輸入法充許與關閉:

    估計很多人會碰到這個問題，就是只在輸入框打開時才充許有輸入法，如下處理

     m_hImc = ImmAssociateContext(hWnd,   NULL); 來關閉，再使用ImmAssociateContext(hWnd, m_hImc);   來打開

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/flipcode/archive/2009/06/22/4287894.aspx

hon的歷史:

http://zh.wikipedia.org/wiki/S2_Games
S2 Games是一個專注開發(fā)電腦游戲的游戲開發(fā)機構，由Marc "Maliken" DeForest投資，設在加利福尼亞的

Rohnert Park。他們的第一作Savage: The Battle for Newerth于2003年夏天發(fā)行，是歷史上第一個RTTS——

即時戰(zhàn)略射擊游戲。續(xù)作 Savage 2: A Tortured Soul，2008年1月16日首先放出Windows版本。最新作品

Heroes of Newerth是一個仿照魔獸爭霸III著名場景DotA制作的游戲。

引擎:
Silverback
K2

大事記
2004，3個S2 Games成員離開并成立Offset Software
2006，S2 Games把與零售版本相同的Savage: The Battle for Newerth在自己網(wǎng)站上免費釋放
2008，年初S2 Games發(fā)布Savage 2: A Tortured Soul；年末設立帳號制度，出現(xiàn)免費帳號
2009，beta測試Heroes of Newerth
2009，啟動與Mod DB協(xié)作的活動

關于Offset Software
http://www.j2megame.org/index.php/content/view/1230/121.html
Intel收購游戲廠商Offset Software 
2008-02-27
　　我們目前見到的畫面驚人的游戲引擎中，除了Epic的“虛幻引擎3”，還有就是Crytek的“Cryengine 2”

，實際上還有一家公司也曾經(jīng)宣布過自己有畫面驚人的游戲引擎，并在當時引起了不小的爭論。這家公司就是

Offset Software。目前，在Offset Software公司的官方主頁上，已經(jīng)正式公布了他們已被Intel收購的消息

。
　　2005年左右，Offset Software曾公布過他們獨自研發(fā)的“Offset Engine”引擎，在當時不但光影效果驚

人，再加上支持圖形化的使用界面、64位HDR光影特性以及其他先進技術，確實營造出了不錯的效果。而且通

過“Offset Engine”非常直觀化的操作界面，使用者不需要掌握復雜的程序語言，僅需鼠標就可以開啟多種

特效，使得游戲開發(fā)的過程過程變得異常簡便。

　　而《Project offset》則是他們近期開發(fā)的具有奇幻背景的FPS游戲，據(jù)悉Intel收購Offset Software極

有可能是為了強化自家的3D技術，以期提高將來Intel顯卡的游戲性能。

關于《Project offset》:
http://pc.yezizhu.com/news/200903/8035_2.shtml
奇幻FPS《project offset》展示精彩物理效果發(fā)表時間：2009-03-28 作者：abao 來源：未知查看熱點評論 
　　Offset Software史詩式奇幻FPS新作《project offset》在此次GDC會展中公開了一段視頻演示，名字命

為“Meteor”（流星），展示了精彩的物理效果。該作有可能將會是PC獨占，因為已經(jīng)被Intel收購用來展示

Larrabee，不過目前還未確認是否取消Xbox 360版本。
 

hon初步分析(flipcode@msn.com)

一。物件
1.紋理:
a. 一般是兩層貼圖:
   第一層是物件的基本貼圖(256*256)，第二層各種物件總是相同的一個奇怪的縷空黑白圖(256*256)，
中間是個黑色形狀圖塊(對應的alpha全白，其它全灰).

b. 另外有些是3層貼圖:
   第一層是物件的基本貼圖(256*256)，第二層各種物件總是相同的一個奇怪的縷空黑白圖(256*256)，
第3層是個team color圖（黑白圖，白色部分混上顏色）

c. 此外有些物件帶光暈面片(用貼圖*頂點色渲染）
例如: 塔邊上有一個個發(fā)亮星星/光暈（就是一個個面片，然后用星狀顏色圖/中間發(fā)亮的黑白圖來跟面片頂點

色相乘)

2. 面數(shù):
  建筑600左右面(一個dip畫完，其它一些發(fā)光面片再另外按貼圖一起畫)

3. 渲染:
物件并不批次渲染，只是按貼圖排序渲染。(但是看到物件上的發(fā)亮相同貼圖的面片會合成一個批次,這可能是

美術直接作成一個mesh的)

另外hon的懸崖是直接使用地面網(wǎng)格做的，懸崖對應地表格子可以水平移動并同時拉高，貼圖使用懸崖貼圖，這樣看起來也還可以。

好處是跟地表一致，渲染處理過渡自然，省面數(shù)。

二。角色:
1.紋理:
  一般是兩張紋理，一張是物體本色圖，另一張是team color圖（黑白圖，白色部分混上顏色）
  另外在高效果顯示時，會有法線圖。

2. 面數(shù):
  兵800左右面(一個dip畫完)
  英雄1200左右（一次dip畫完, 包括手上武器）

3. 渲染:
  物件并不批次渲染，只是按貼圖排序渲染。
  低效果時只是受漫射光，環(huán)境光，平行光影響, 如下:

  clr=貼圖顏色*頂點色*光照(光照=ambient+dot(N.L)*suncolor);

  高效果時會用法線圖進行光照運算，同時有高光計算.
  另外高效果時似乎還有點光源支持以及一個云貼圖，自遮擋陰影？沒具體分析.

  對于team color是這樣的:

  貼圖顏色 = 原圖色 * (teamcolor圖*teamcolor)
  即SetTexture( Texture0 = 原圖色, Texture1 =teamcolor圖); 然后只draw一次完成.

以上看來hon的角色非常簡單，是只有一個帶骨架的模型，不可換裝.

三。陰影:
  使用shadowmap動態(tài)陰影，在我機器上(ati hd3200集成顯卡)比較消耗，打開時fps30-40, 關閉時60-70

四。地表:
1. 紋理:
地表貼圖，最高時使用512*512,32bit,mip為9級

2. 渲染:
地表分批次渲染，每次最大不超過1089個頂點, 每批次對應兩層紋理，通過頂點alpha混合過渡(頂點比較密)

五。界面:
1. 紋理:
血條的貼圖由黑底，紅條，黃條，綠條組成

2.渲染:
血條的渲染，先畫黑底框，再畫紅條，然后畫黃條，最后畫綠條.當血漸漸少了，紅黃綠3個條同時由右向左縮

小（紅黃綠alpha漸少，紅少得快，黃其次，紅不變或少得慢）, 黑框保持不縮放。

注：hon的這個血條并不批次渲染，而是每次渲染一個血條的一層.由底向上渲染，渲染完再換一個血條渲染.

渲染完所有血條之后，這才開始渲染普通界面。（alpah blend方式下使用貼圖*頂點顏色渲染）

六。后期處理:
   后期渲染，使用全屏泛光，類似nvglow，只是不指定物件alpha通道渲染，而是全屏泛光.
渲染順序, 先物件，再地表，然后是后期處理

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/flipcode/archive/2010/04/06/5453714.aspx