weak table是什么意思,建議不要看中文翻譯的,我以前看了半天還是沒懂啥子意思.

lua 手冊原文是這樣解釋的:

最近做了個DEMO,飛機追飛機的.
利用AOI模塊產生的enterAOI,LeaveAOI事件 觸發NPC追隨玩家

順便也測試下服務器實體的歐拉角計算


先運行RegionApp.exe
然后再運行ClientDemo

WSAD 前后左右 J上K下

客戶端做的很簡單..., 支持多開...

下載DEMO

最近在優化游戲服務器的AOI（area of interest)部分，位置有關的游戲實體一般都有一個視野或關心的范圍，
當其他實體進出某個實體的這個范圍的時候，就會觸發leaveAOI或enterAOI事件，并維護一份AOI 實體列表。
我們來考慮最簡單的實現，假設區域R中有1000個Entity，當某個entity位置發生變化時，需要計算entity的AOI事件和列表，偽代碼如下：

function onEntityMove(who)   
  for entity in entities do
    if who <> entity then
        計算who和entity之間的距離
        如果who移動前entity在who的AOI范圍內，且現在在范圍外
           觸發who.onLeaveAOI(entity)
        如果who移動前entity在who的AOI范圍外，且現在在范圍內
           觸發who.onEnterAOI(entity) 
         如果who移動前在 entity的AOI范圍內，且現在在范圍外  
          觸發entity.onLeaveAOI(who)
          如果who移動前在 entity的AOI范圍外，且現在在 范圍內
           觸發entity.onEntityAOI(who)
      end
  end
end
每次一個實體移動一次位置就要遍歷1000個實體來計算，這 樣做顯然不行，效率太低了，
那么就需要引入場景管理，將區域R分成n個格子，每個格子維護一個實體鏈表，entity移動時，只遍歷它所在的格子和周圍的8個格子的實體鏈表，
再優化下，可以加入AOI圓和格子的碰撞檢查，9個格子中再去掉沒有相交的格子。。。等等
也有用四叉樹來進行場景管理的。

還有些方案更簡單，直接是畫格子，按以實體為中心的九個格子進行位置廣播， 實體從一個格子移動到另外的格子時觸發事體。。好處是計算量簡單，缺點是帶寬占用大

我上面的方案都試過了，效率和帶寬占用都不理想，最近終于弄出一個新的方案，現在的AOI計算量是我們服務器以前計算量的1/40-1/80，由于涉及到公司的保密制度，不便細說，上幾個測試的抓圖：

機器配置：win7 ,T5870 inter雙核2G,2G內存
20個entity 隨機運動計算一次所有entity AOI的時間在0.02毫秒左右：

220個實體，選擇的實體AOI范圍里有68個實體：

4000個實體，選擇的實體的AOI區域里有465個實體

AOIDemo.exe 下載

SOA:Service-oriented architecture
最近在做游戲服務器引擎，查了不少有關SOA的設計方面的資料。發現JAVA世界有相當多的技術標準。
其中比較好的是OSGi （http://www.osgi.org/About/WhatIsOSGi），OSGi技術是面向Java的動態模型系統。OSGi服務平臺向Java提供服務，這些服務使Java成為軟件集成和軟件開發的首選環境。Java提供在多個平臺支持產品的可移植性。OSGi技術提供允許應用程序使用精煉、可重用和可協作的組件構建的標準化原語。這些組件能夠組裝進一個應用和部署中。
參考它的思路，結合C++語言的特點，我將一個服務器基礎框架設計成了這樣一種:

一個服務器應用，由多個組件組成，組件物理上可以是動態庫，也可以是EXE里一段實際的代碼，每個組件可以向ApplicationFramework注冊多個服務（比如日志服務，網絡服務等）。
ApplicationFramework啟動時，通過配置文件，動態加載和啟動組件，讀取服務的可配置屬性。Framework觸發IComponentActivator的OnStart() 和OnStop()事件，在Start事件中，可以注冊組件自己的服務，也可以加入一個服務監聽器來監聽關心的服務的注冊，注銷等事件。
我隨便畫了幾個大概的接口：
  

替換^M字符
在Linux下使用vi來查看一些在Windows下創建的文本文件，有時會發現在行尾有一些“^M”。有幾種方法可以處理。

1.使用dos2unix命令。一般的分發版本中都帶有這個小工具（如果沒有可以根據下面的連接去下載），使用起來很方便:
$ dos2unix myfile.txt
上面的命令會去掉行尾的^M。

2.使用vi的替換功能。啟動vi，進入命令模式，輸入以下命令:
:%s/^M$//g # 去掉行尾的^M。

:%s/^M//g # 去掉所有的^M。

:%s/^M/[ctrl-v]+[enter]/g # 將^M替換成回車。

:%s/^M/\r/g # 將^M替換成回車。

3.使用sed命令。和vi的用法相似：
$ sed -e ‘s/^M/\n/g’ myfile.txt

注意：這里的“^M”要使用“CTRL-V CTRL-M”生成，而不是直接鍵入“^M”。

轉自：http://hi.baidu.com/mofeis/blog/item/23c7b2fb92dc97234e4aea6d.html

    在游戲服務器中，處理玩家登陸需要向數據庫查詢玩家的賬號和密碼，玩家上線和下線需要對玩家的角色數據從數據庫中讀取和保存。可以說，相對于游戲邏輯處理來說，數據庫操作是一種相對很慢的操作，即便你通過使用多個線程多個數據庫連接來提高數據庫操作的處理能力，但是，在高并發高負載的服務器應用中，這樣仍然會是相當的負載瓶頸。設想這樣一種設計方案，見下圖：

    在大量玩家登陸游戲服務器時，由于有大量的數據庫訪問請求，即便是有自己實現的CACHE機制，還是會導致服務器耗盡所有的邏輯線程資源，服務器的處理能力將降低成DBMS的處理能力。
    
     為了不阻塞邏輯線程，可以采用異步數據庫訪問的方式，即數據庫操作請求提交給專門的數據庫處理線程池，然后邏輯線程不再等待數據庫處理結果，繼續處理其他，不再阻塞在這里。
     抽象的來看，對于一個需要持久化的游戲對象來說，可以考慮它有2個方法，讀取和保存。那么我們抽象一個DBO接口：
   

   
     然后把設計方案改成下面這種：

 

     改成數據庫異步處理后，在想想現在的游戲數據的保存機制應該是怎樣改進的，為了保障數據安全，我們希望不只是玩家下線的時候才會保存玩家數據，而是希望每隔一段時間統一保存所有在線玩家的數據，那么，可以考慮這樣的思路：假設我們有一個GAMEDB服務器，GAMEDB緩存了所有在線玩家的角色數據，每到保存時間，GAMEDB就將所有在線玩家的數據(DBO）的副本都統一提交給DB線程池，讓它保存數據，提交的過程很快，提交完后，GAMEDB的邏輯線程仍能繼續處理游戲服務器的更新和讀取CACHE的請求。為什么要保存副本呢，DB線程的執行保存隊列的過程也許很耗時，但是隊列中的數據都是GAMEDB提交DBO那個時刻的數據，這樣就能保證玩家的游戲數據的完整性。
      當然，我這里提的這只是個思路，這里面還有很多細節沒有討論，例如如果DB線程池正在保存九點鐘時刻保存的數據，到了十點鐘新的保存時刻時，DB線程池還沒保存完九點鐘時刻的DBO副本隊列，這時應該怎么處理；DBO對象的劃分粒度的問題；DBO隊列的優先級的問題等等。

     PS:這篇文章里的架構其實就是一個GAMEDB服務器，里面的邏輯處理就是GAMEDB的邏輯處理。你可以把這篇文章理解成：一個GAMEDB服務器 的實現思路。。。

編輯~/.vimrc 加入以下代碼

 

一個典型的游戲服務器設計中，一般都是用的多線程，服務器中一般運行兩類線程，N個SOCKET IO線程，1個邏輯線程，
IO線程接受客戶端發來的信息，通過消息隊列發送給邏輯線程處理后，再發送消息給客戶端，發送消息這里一般是IO線程處理實際發送。

其實我認為，如果邏輯線程都是消耗的CPU運算資源的話，服務器完全采用單線程的方式來做。

首先，我們看IO處理，基本就是數據入隊、出隊，send、recv操作，作為服務器的SOCKET處理一般都是異步SOCKET，也就是說，send、recv操作只是將信息copy到socket底層的發送接收緩沖區去了，不存在IO堵塞的問題。

然后，我們再來看邏輯處理，前面已經說了，采用單線程的前提是邏輯處理只是消耗CPU運算資源，那么，不管你開幾個線程，對單核的CPU來說，它的處理速度就是這么多，并不會因為你線程開的越多，就處理的越快。

因此我們可不可以這樣說呢，在單核機器上，只消耗CPU運算的服務，多線程并不比單線程能提高多少效率。

接下來，我們再討論下多核的情況，你肯定要想，我這臺服務器是4個雙核CPU，就只跑一個單線程的服務器不是虧死了，多線程多好，我開8個線程，就能很好的利用我的機器啦。是啊，我也覺得這樣很好，不過在LINUX、UNIX下，對線程的支持并不像WINDOWS下那么好，LINUX、UNIX下一般都是用LWP（輕量級進程）的方式來支持多線程程序的，Linux內核只提供了輕量進程的支持，限制了更高效的線程模型的實現，但Linux著重優化了進程的調度開銷，一定程度上也彌補了這一缺陷。同時，濫用多線程也會造成不必要的上下文切換，不必要的同步機制的引入（如pthread_mutex），讓程序頻繁的在內核和用戶間頻繁切換。另外，從開發角度來看，單線程開發比多線程環境開發更不容易出錯和更加健壯。

在游戲服務器架構中，為了提高玩家在線人數，實現負載均衡，現在一般都是采用分布式的多進程服務器集群的方式，我們來看看服務器集群中，每個服務進程是采用多線程的方式還是單線程的方式好呢？我覺得，對于有慢速IO訪問的需求的應用進程，多線程肯定比單線程好，最典型的情況就是數據庫訪問這塊，完全可以采用N個DB線程，一個邏輯線程的架構，而對只是消耗CPU運算資源的應用進程，盡量單線程就行了，如果覺得單線程負載不行的話，完全可以分成多個進程來跑。。

以上只是我自己的一些看法，表達有限，歡迎指正。。。

    boost里的program_options提供程序員一種方便的命令行和配置文件進行程序選項設置的方法。
    其文檔例子中有如下代碼：
   
    看第4到6行，是不是感覺很怪？這種方式體現了函數式編程中最大的特點：函數是一類值，引用資料來說,所謂“函數是一類值（First Class Value）”指的是函數和值是同等的概念，一個函數可以作為另外一個函數的參數，也可以作為值使用。如果函數可以作為一類值使用，那么我們就可以寫出一些函數，使得這些函數接受其它函數作為參數并返回另外一個函數。比如定義了f和g兩個函數，用compose(f,g)的風格就可以生成另外一個函數，使得這個函數執行f(g(x))的操作，則可稱compose為高階函數（Higher-order Function）。

    program_options里的這種方式是怎么實現的呢？通過分析boost的源代碼，我們自己來寫個類似的實現看看：
     test.h   
test.cpp

使用方式：

是不是很有意思。add_some()方法返回一個Test_easy_init類的對象，Test_easy_init類重載了操作符()，操作符()方法返回Test_easy_init類對象自身的引用。。